Re: [VCARDDAV] sex vs. gender and social complexities

[Kevin Marks <[e-mail]>]

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 <[e-mail]> 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 <
> [e-mail]> 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
>> [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vcarddav
>
>