Subject: Re: [calsify] [Jmap] JSContact: gender property

From: Joris Baum <[email-masked]>
Date: Mon, 3 Jan 2022 16:46:29 +0100

Hi Robert and happy new year everyone :) ,

I also like the proposal and would also vote for keeping it simple and 
not introduce things like variable substitution. For our use case it is 
not necessary to add a biological sex component to JSCalendar. Having 
grammaticalGender definitely improves mapping from vCard to JSCalendar.

As the topic of gender is apparently quite complex and also dynamic, 
maybe it would be a good idea to point to the Vendor-Specific Property 
Extension definition in the gender property section again? This way we 
could encourage developers to come up with their own extensions.

Regards,

Joris

On 23.12.21 20:55, Neil Jenkins wrote:
> Thanks Robert, I think this is a good, well-reasoned proposal.
>
> On Fri, 24 Dec 2021, at 12:48 AM, Ken Murchison wrote:
>> I also wonder if we might want to add a property for a user's 
>> preferred pronouns.
>
> Is that not covered by grammaticalGender?
>
> On Fri, 24 Dec 2021, at 1:51 AM, Andreas Hauser wrote:
>> Not only is there grammaticalGender but also salutations often differ 
>> based on relationship, like "Dear Robert" / "Dear Sir“ or „Lieber 
>> Robert“ / „Sehr geehrter Herr Stepanek“.
>
> That feels out-of-scope to me, especially if you have to start 
> introducing variable substitution.
>
> —Neil
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
Joris Baum
Tel: +49 721 170293 16
Fax: +49 721 170293 179

http://www.audriga.com  |http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Durlacher Allee 47 | 76131 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 03 Jan 2022 17:20:33 +0100

Hi Andreas,

On Thu, Dec 23, 2021, at 3:51 PM, Andreas Hauser wrote:
> Not only is there grammaticalGender but also salutations often differ based on relationship, like "Dear Robert" / "Dear Sir“ or „Lieber Robert“ / „Sehr geehrter Herr Stepanek“.

Agreed (I am a German native speaker, too).

> To make this most useful in practice, a field for salutation might be considered, taking variables for first name (e.g. %FN), nick name and last name (e.g.%LN): „Dear %FN“, „Dear Professor %LN“ etc.

I agree with Neil that the JSContact spec does not seem the right place for this. Such templates should rather go in the applications and services that build on the contacts data. Note that some of the template language that you suggest is covered by the Unicode Person Name Formatting spec: https://www.unicode.org/review/pri434/ We made sure that the naming properties in JSContact use the same terminology to interoperate with that PRI434.

What we might consider instead is to allow setting modifiers on the grammatical gender:

grammaticalGender:
  - gender:  ("animate", "female", ...") (mandatory)
  - modifiers (optional): list of
      - value
      - type ("formality", "deixis", "number")
   
where

"formality": allows values "intimate", "familiar", "distanced"
"deixis": allows values "proximal", "medial", "distal"
"number": allows "singular" and "plural"

This should cover a good number of human languages. However, I am not a linguist and I am afraid none on this mailing is either?

Cheers,
Robert

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 06 Jan 2022 15:04:30 +1100

> This should cover a good number of human languages. However, I am not a linguist and I am afraid none on this mailing is either?

Yeah, I'm wary of adding something here without a full understanding of how it would actually be used, as there's a danger of falling in the middle group of too complex to be understood by most, but not comprehensive enough to cover the use cases of those that need it.

> That being said, I do see the additional need for pronouns and it seems services and application developers do, too. Notably, the Google People API has the addressMe field in the Person.gender property. It is a free-text field and the examples suggest to store the pronouns in the form "they/them".

I think a free text field for this makes sense. Anything else is going to be too difficult to maintain (in one language, let alone for all languages), but it's a more-and-more common field for people to store with their contacts on different platforms, so I think a specific "pronouns" field is worth having.

—Neil

---

From: "Robert Stepanek" <[email-masked]>
Date: Fri, 07 Jan 2022 09:10:20 +0100

On Thu, Jan 6, 2022, at 5:04 AM, Neil Jenkins wrote:
> Yeah, I'm wary of adding something here without a full understanding of how it would actually be used

I agree. As a German speaker I can see some use for "number" and "formality", but it seems application developers did just fine without them in VCARD. Also, the risk is high that it would just introduce a bias for both English and German and still not being adequate for other languages.

>> the Google People API has the addressMe field in the Person.gender property. It is a free-text field and the examples suggest to store the pronouns in the form "they/them".
> I think a free text field for this makes sense.

Agreed.

The next RFC draft will reflect these decisions. Thanks to all of you for your input.

---

From: "Robert Stepanek" <[email-masked]>
Date: Wed, 12 Jan 2022 09:13:20 +0100

> The next RFC draft will reflect these decisions. Thanks to all of you for your input.

And this is what we will get published in the next draft version soon:

2.2.6.  speakToAs

   Type: SpeakToAs (optional).

   Provides information how to address, speak to or refer to the entity
   that is represented by this card.  A SpeakToAs object has the
   following properties, of which at least one property other than @type
   MUST be set:

   *  @type: String (mandatory).  Specifies the type of this object.
      This MUST be SpeakToAs.

   *  grammaticalGender: String (optional).  Defines which grammatical
      gender to use in salutations and other grammatical constructs.
      Allowed values are:

      -  animate
      -  female
      -  inanimate
      -  male
      -  neuter

      Note that the grammatical gender does not allow to infer the
      gender identities or biological sex of the contact.

   *  pronouns: String (optional).  Defines the gender pronouns that the
      contact chooses to use for themselves.  Any value or form is
      allowed.  Examples in English include she/her and they/them/
      theirs.

   The property values SHOULD be localized in the language defined in
   the language property.  They MAY be overridden in the localizations
   property (Section 2.5.1).

---

From: "Robert Stepanek" <[email-masked]>
Date: Wed, 12 Jan 2022 09:16:06 +0100

Sorry for the double cross-post, but earlier in this thread the jmap mailing list got split off.