W3C home > Mailing lists > Public > public-contacts-coord@w3.org > July to September 2010

Re: gender/sex field in contact formats

From: Simon Perreault <simon.perreault@viagenie.ca>
Date: Thu, 09 Sep 2010 08:12:43 -0400
Message-ID: <4C88CF3B.1080603@viagenie.ca>
To: Dan Brickley <danbri@danbri.org>
CC: jsmarr@stanfordalumni.org, Joseph Smarr <jsmarr@gmail.com>, Thomas Roessler <tlr@w3.org>, public-contacts-coord@w3.org, Tantek Çelik <tantek@tantek.com>
On 2010-09-09 06:54, Dan Brickley wrote:
> 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?

I think there was low interest in thinking about the psychological vs
biological gender identity. We just started with the property name
GENDER with male and female values. Eventually somebody asked all the
same questions you are now asking. When somebody pointed to ISO 5218,
that allowed us to not deal with this (imho uninteresting) issue because
other people had done it before. And that was it. We were done.

See e.g.

> 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!

So are you arguing for allowing the SEX property to be reset to a
free-form text value?

NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org
Received on Thursday, 9 September 2010 12:13:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:38:00 UTC