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

From: Sarah Dopp <[email-masked]>
Date: Fri, 8 Oct 2010 11:36:22 -0700

I'm new to this discussion, and wish to express some concerns about the
treatment of sex/gender in the new VCARD specifications.

As I understand it, the current plan is to call it "Sex" and allow four
integer values: 0, 1, 2, and 9 ("not known," "male," "female," and "not
applicable") [1].  I see two major issues with this plan:

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

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

With Gender as a category, you need to consider transgender people (in
various stages of transition) [6] and gender-variant people (of various
cultures and identities) [7-10].  People in these groups may claim
identities that blend genders, they may move freely between genders, they
may reject gender altogether, or they may claim new language for their
genders.

The bottom line: For someone who claims a gender or sex less clear-cut than
Male or Female, "not known" is offensively inaccurate, and "not applicable"
is offensively dismissive.

*Possible Solutions*

I've argued in the past that Gender is going the way of Race in terms of
meaningfulness for social categorization [11].  I don't see Race on the
VCARD specs -- am I missing it?  Why wasn't it included? 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.

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.

Thanks for your time and consideration.  My reference notes, including two
posts I've written on the subject of gender-variance and data collection,
are below.

~Sarah

References:
[1]
http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-13#section-6.2.10
[2] http://www.who.int/gender/whatisgender/en/index.html
[3] http://en.wikipedia.org/wiki/Intersex
[4] http://en.wikipedia.org/wiki/Sex_reassignment_surgery
[5] http://en.wikipedia.org/wiki/Hormone_replacement_therapy
[6] http://en.wikipedia.org/wiki/Transgender
[7] http://en.wikipedia.org/wiki/Gender_variance
[8] http://en.wikipedia.org/wiki/Genderqueer
[9] http://en.wikipedia.org/wiki/Third_gender
[10] http://en.wikipedia.org/wiki/Two-spirit
[11] http://www.sarahdopp.com/blog/2008/genders-and-drop-down-menus/
[12]
http://www.sarahdopp.com/blog/2010/designing-a-better-drop-down-menu-for-gender/

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 08 Oct 2010 14:55:32 -0400

Le 2010-10-08 14:36, Sarah Dopp a écrit :
> 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.

> 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

---

From: Sarah Dopp <[email-masked]>
Date: Fri, 8 Oct 2010 13:47:03 -0700

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.

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 <
[email-masked]> wrote:

> All the issues with gender that you describe were counted as arguments in
> favor of sex. Sex is straightforward.
>
> I'm not following you here. There is no gender field. There is a sex field.
> The latter was defined by ISO.
>
>
> group wants to attack this problem again. It would also be way outside of
> our charter.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Kevin Marks <[email-masked]>
Date: Mon, 11 Oct 2010 15:48:04 -0700

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 <[email-masked]> wrote:

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

---

From: Sarah Dopp <[email-masked]>
Date: Mon, 11 Oct 2010 16:19:27 -0700

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 <[email-masked]> wrote:

> Value type: A single structured text value. Each component can have a
>> single value.
>
> Cardinality: (0-1)
>
>> art: http://genderfork.com   /   show: http://queeropenmic.com   /
>> love: http://cultureconductor.com
>>
>>