gender/sex field in contact formats

Hi all. Subject-line changed to pick one of these themes. And an
explicit Cc: to Tantek as we've discussed this before a bit re
foaf/hcard commonalities.

On Wed, Sep 8, 2010 at 6:59 PM, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
> (Just trying to reply to the technical points concerning vCard...)
>
> On 2010-09-08 12:12, Joseph Smarr wrote:
>> For instance, compare the
>> representations of gender in Portable Contacts and the proposed vCard XML:
>>
>>     <gender>male</gender>
>>
>>     vs.
>>
>>     <sex><integer>1</integer></sex>
>>
>>
>> I think it's hard to argue that the first version (PoCo) is far more
>> readable and semantically clear.
>
> more readable: Agreed, but who cares? Users are not going to see this.
> more semantically clear: Disagree, the semantics of vCard are very well
> defined.
>
> Note that we had exactly <gender>male</gender> at the beginning and
> gradually changed it to what we have now, for two reasons:
>
> 1. It's better to follow standards.

We all love standards around here, but it's also important to think
about what the standards are being used for. In this case, you've
chosen a very strict, biological and essentially binary way of talking
about gender/sexuality which I fear risks needlessly framing a lot of
people as awkward misfits.

>  In this case, ISO 5218 applies. It
> says that the term "sex" is preferred, and defines the applicable
> values. Standards are good.

Standards are good for lots of things. But when we're dealing with
describing people and putting them into categories, we have some duty
to consider how those people might see the situation. If the Wikipedia
entry at http://en.wikipedia.org/wiki/ISO_5218 is correct, then

"The four codes specified in ISO 5218 are:
0 = not known,
1 = male,
2 = female,
9 = not applicable.
The standard specifies that its use may be referred to by the designator "SEX"."

This puts a large chunk of humanity into a kind of limbo. Other
schemas have taken different approaches, eg. see
http://microformats.org/wiki/gender-examples
http://community.livejournal.com/feminist/2925885.html

Even if we take a strictly biological view, there are arguments that
binary m/f is an over simplification
(http://en.wikipedia.org/wiki/Intersex etc). But when this field
manifests itself in phones, desktop software, Web sites etc., users
are only going to have this one option for expressing this side of
their life. Telling them, "ah but the field is SEX not GENDER" is
unlikely to come across  as helpful; it's their phone and their
addressbook and online profile, after all, not ours. I think it is
quite proper to offer some possibility for other values here, rather
than giving them only the ISO options 'because they are standard' or
'because they are scientific, not fuzzy woolly social notions that
keep changing and are hard to track in a schema'.

What was the thinking in the vCard community that led to this being
'sex' rather than 'gender'? Was it driven by a desire for precision,
by deployment concerns, or a need to interoperate with other ISO-5218
datasets?

As engineers, it's always tempting to look for schema structures that
have a nice tidy value space. But there's also value in webby
flexibility, especially when talking about something so personal. As
engineers, 80-20% tradeoffs are often the prudent, pragmatic option.
But when the 20% (or 2%, or 0.2%) are people, we should take extra
care not to casually model them as corner-cases and misfits; even 0.2%
of the user population of the Web is a lot of people.

Let's step back from the 0s and 1s, and ask ourselves why it's
important in contact formats to have a standard for saying whether
(crudely) someone was born with a penis or not. Do those use cases
require a closed value space?

A quick look at some other webby specs -

http://portablecontacts.net/draft-spec.html has
"gender:
The gender of this contact. Service Providers SHOULD return one of the
following Canonical Values, if appropriate: male, female, or
undisclosed, and MAY return a different value if it is not covered by
one of these Canonical Values."

Microformats -
http://microformats.org/wiki/hcard-faq#How_is_gender_represented
"Instead, you could use tags/categories to tag people's hCards with
their gender, "male", "female", or any other tag you feel is
appropriate. See gender identity for more on the topic."
http://en.wikipedia.org/wiki/Gender_identity

In FOAF we said http://xmlns.com/foaf/spec/#term_gender
"Values other than 'male' and 'female' may be used, but are not
enumerated here."

These all suggest open value spaces, hypertext flexibility, and an
emphasis on social notion of gender rather than raw biology.

I'm sure there are all kinds of good reasons why vCard has its current
approach to this topic, but 'standards are good' isn't itself an
adequate explanation!

If you could say a bit more about the thinking behind this decision,
that'd be great. As Joseph I think mentioned, a lot of the trend here
is about closer links between 'contact' and 'social Web'
representations of people; in the latter, people naturally highly
sensitive to the way they are portrayed in computer schemas, since
those schemas shape how they're represented in online profiles. This
gives us something of a clash-of-cultures between formats, and an
opportunity to go back and rethink the structure of these fields when
the resulting data is circulating in new contexts...

cheers,

Dan

Received on Thursday, 9 September 2010 10:54:48 UTC