Re: gender/sex field in contact formats

On Thu, Sep 9, 2010 at 2:12 PM, Simon Perreault
<simon.perreault@viagenie.ca> wrote:
> 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.

Thanks, nice clear explanation :)

> See e.g.
> http://www.ietf.org/mail-archive/web/vcarddav/current/msg01060.html

>
>> 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.
[...]
>> 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?

I'm not qualified enough in vcard issues (deployment constraints,
format / data model etc.) to comment knowledgeably on what you should
do within vCard.  On the W3C angle, ... if W3C is to endorse a model
for describing people's sex-and-or-gender, yes, I would encourage
adoption of an open rather than closed set of values. Enumerating the
things people might want to say, beyond 'male' and 'female' sounds
like a vast project in social anthropology and rather daunting. I
think as a minimum allowing a value of 'other' would be progress,
alongside the non-descriptive, non-values of 'not applicable' / 'don't
know' / 'won't say', empty field etc. My guess is that allowing
additional unconstrained text values is worthwhile, even if it makes
the field harder to write software for. Something like a schema
equivalent to the structures that show up in UI as a combo box,
http://en.wikipedia.org/wiki/Combo_box ...? But it's hard to know what
is worth doing, without knowing more about how (or whether) the field
has been used in practice. I know Joseph has done a lot of work with
aggregated addressbook data and wonder if he can comment on how widely
present this field is. Joseph?

cheers,

Dan

Received on Thursday, 9 September 2010 12:31:15 UTC