Re: gender/sex field in contact formats

In my experience, gender is almost always returned by providers as a string,
and they don't all agree on canonical string values for male and female. But
the following heuristic usually works: "if the gender string starts with
'm', normalize it to 'male', if it starts with 'f', normalize it to
'female', otherwise, leave it as is". In PoCo, our string-valued fields work
exactly like this--we specify a few "canonical values" that people should
try to use if possible, but leave the value open for people to also use
non-standard or extensible values. Then depending on your UI for
displaying/changing gender on your end, you can either look for the
canonical values and map them to male/female radio buttons, or recognize
that it's not male/female and show "other", or even show the exact string
value.

Seems like with <sex><integer>1</integer></sex> you're stuck throwing out
all the non-male/female string gender values, right?

Thanks, js

PS: And I still can't get over the fact that <sex><integer>1</integer></sex>
is just ugly and bloated and semantically opaque. This kind of thing *does*
matter if you want developers to understand, use, and, like your spec. Just
because a spec is official doesn't mean it will automatically get wide
adoption! Caring about being beautifully designed and user-friendly isn't
just a smart tactic for consumer software/hardware, it's for anything humans
have to deal with! :)

On Thu, Sep 9, 2010 at 5:30 AM, Dan Brickley <danbri@danbri.org> wrote:

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