Thanks for highlighting that, Kevin. This looks like a good solution,
especially with the inclusion of "Other" and an open-ended text field under
Gender Identity.

Here's the most problematic case I can see for this setup: Consider a
transgender woman has transitioned socially and is claiming "she" and
"woman" everywhere, but is technically/biologically sexed male. Assuming
she's filling out a VCARD form for herself, it would be inappropriate to
expect her to mark Male under sex.

As long as there are no issues with her marking Female or Other there -- and
nothing that would make her feel like she's lying no matter what she writes
-- I think the system is fine.

Nice work, Tantek.

~Sarah





On Mon, Oct 11, 2010 at 3:48 PM, Kevin Marks <kevinmarks@gmail.com> wrote:

> Sarah,
> Tantek proposed a combined SEX/GENDER modelling here:
>
> https://wiki.mozilla.org/VCard4#section_6.2.10._SEX
>
>  GENDER
>
> Purpose: To specify the components of the sex and gender identity of the
>> object the vCard represents.
>
> Value type: A single structured text value. Each component can have a
>> single value.
>
> Cardinality: (0-1)
>
> Special notes: The structured property value corresponds, in sequence, to
>> the sex (biological), and (optional) gender identity. The text components
>> are separated by the SEMI-COLON character (ASCII decimal 59).
>
>  Sex component: The value M stands for "male", F stands for "female", O
>> stands for "other", N stands for "none or not applicable".
>
> Gender identity component: a single text value.
>
>
> In addition the current draft includes a notion of "not known", which,
>> though I haven't seen evidence for, can understand the potential utility as
>> it may help represent the explicit not knowing of information. Thus I would
>> be ok with:
>
>  Sex component: The value M stands for "male", F stands for "female", O
>> stands for "other", N stands for "none or not applicable", and U stands for
>> "unknown".
>
>
> Does that address your concerns adequately?
>
> (I haven't seen other follow-up to Tantek's proposals)
>
>
>
> On Fri, Oct 8, 2010 at 1:47 PM, Sarah Dopp <sarah@sarahdopp.com> wrote:
>
>> Thanks for your response, Simon.  Let me respond briefly:
>>
>>
>> > All the issues with gender that you describe were counted as arguments
>> in favor of sex. Sex is straightforward.
>>
>> Sex is no more straightforward than Gender, for the reasons I described,
>> particularly in cases of intersex conditions and transsexualism.
>>
>> But more importantly: Sex is much less relevant to VCARD use cases than
>> Gender.
>>
>> > By using an ISO standard, we're shoveling all these issues into ISO's
>> backyard. We could say "Don't tell that to us, tell it to them."
>>
>> I think this group has an obligation to consider the integrity of the
>> standards it adopts.
>>
>>
>> > However, if you want to add a GENDER property (and possibly remove SEX),
>> then I think you would need to send to this list the verbatim changes to the
>> draft's text that you propose. We're fairly late in the process, and this
>> would accelerate the reaching of a consensus.
>>
>> I'd be happy to. I'd also appreciate input from other existing group
>> members on the most appropriate direction (I offered several solutions).
>>
>> Thanks,
>> Sarah
>>
>>
>>
>>
>>
>> On Fri, Oct 8, 2010 at 11:55 AM, Simon Perreault <
>> simon.perreault@viagenie.ca> wrote:
>>
>>> Le 2010-10-08 14:36, Sarah Dopp a écrit :
>>>
>>>> *1) You probably mean Gender, not Sex.
>>>>
>>>> *
>>>> For the purpose of address books and social information, people are
>>>> interested in presentation and social categorization -- not shapes of
>>>> genitals and configuration of hormones at birth. [2]  We're talking
>>>> about gender here.
>>>>
>>>
>>> All the issues with gender that you describe were counted as arguments in
>>> favor of sex. Sex is straightforward.
>>>
>>>  *2) These data options do not accommodate edge cases.
>>>>
>>>> *
>>>> For most users, the data points of sex and gender are the same. The
>>>> distinction, however, is visible in the edge cases (for which there is a
>>>> significant population to account for).
>>>>
>>>> With Sex as a category, you need to consider people with intersex
>>>> conditions [3], as well as those who have undergone Sexual Reassignment
>>>> Surgery [4] and Hormone Replacement Therapy [5].  For many of these
>>>> people, to choose Male or Female on a form is to lie about half of their
>>>> bodies.
>>>>
>>>
>>> By using an ISO standard, we're shoveling all these issues into ISO's
>>> backyard. We could say "Don't tell that to us, tell it to them."
>>>
>>>
>>>  I don't see Race on the
>>>> VCARD specs -- am I missing it?  Why wasn't it included?
>>>>
>>>
>>> - It was not in vCard 3.
>>> - It's not widely available in vCard software.
>>> - It's not necessary for building extensions on top of vCard core.
>>>
>>>
>>>  If it was left
>>>> off because of data complexity, social complications, or irrelevance, I
>>>> challenge you to consider the possibility that Gender should be in the
>>>> same boat.
>>>>
>>>> If you wish to continue including the field, an open text field for
>>>> keywords is the most culturally-inclusive solution.
>>>>
>>>
>>> I'm not following you here. There is no gender field. There is a sex
>>> field. The latter was defined by ISO.
>>>
>>>
>>>  Finite data collection is always socially problematic, but I understand
>>>> its importance for aggregation. If this is truly a high priority, I ask
>>>> that you add an additional option to account for the cases discussed
>>>> above. While I cringe to suggest "Other" as this option [12], it might
>>>> be the path of least resistance. (Personally, I'd like to see "It's
>>>> Complicated" up there.  But that's just me.) Even better: allow the
>>>> option to be replaced with an alternate value provided by the user.
>>>>
>>>
>>> I think that changing the values for the SEX property should be out of
>>> question. Sex is clearly defined by ISO, and I don't think this working
>>> group wants to attack this problem again. It would also be way outside of
>>> our charter.
>>>
>>> However, if you want to add a GENDER property (and possibly remove SEX),
>>> then I think you would need to send to this list the verbatim changes to the
>>> draft's text that you propose. We're fairly late in the process, and this
>>> would accelerate the reaching of a consensus.
>>>
>>> Thanks,
>>> Simon
>>> _______________________________________________
>>> VCARDDAV mailing list
>>> VCARDDAV@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vcarddav
>>>
>>
>>
>>
>> --
>> Sarah Dopp
>> site: http://sarahdopp.com   /   blog: http://doppjuice.com   /   tweet:
>> http://twitter.com/sarahdopp
>> art: http://genderfork.com   /   show: http://queeropenmic.com   /
>> love: http://cultureconductor.com
>>
>>
>> _______________________________________________
>> VCARDDAV mailing list
>> VCARDDAV@ietf.org
>> https://www.ietf.org/mailman/listinfo/vcarddav
>>
>>
>


-- 
Sarah Dopp
site: http://sarahdopp.com   /   blog: http://doppjuice.com   /   tweet:
http://twitter.com/sarahdopp
art: http://genderfork.com   /   show: http://queeropenmic.com   /   love:
http://cultureconductor.com