Re: [VCARDDAV] two component GENDER

[Sarah Dopp <[e-mail]>]

Thanks for addressing these, Tantek.  I like your thinking, and your plan
has my support.

Sarah



On Thu, Dec 16, 2010 at 3:58 PM, Tantek Çelik <[e-mail]>wrote:

> On Thu, Dec 16, 2010 at 15:40, Sarah Dopp <[e-mail]> wrote:
> > "I'd prefer to *not* make the sex component extensible for now, until a
> > good case can be made based on real world examples that demonstrates
> > that such extensibility is necessary / useful above and beyond the use
> > cases for flexibility gender identity (which are already covered by
> > that respective free-text component)."
> >
> > The real-world example there is Intersex.
>
> Agreed, and that's specifically the use-case for the "O(ther)"
> enumerated SEX component value.
>
>
> > Some people are born with blended
> > sex characteristics, either physical or hormonal or both.  In most of
> these
> > cases, parents and doctors assign the person to the gender they resemble
> > most (and that assignment may or may not stick as the person grows). But
> the
> > medical sex is still different.  For stats on the frequency of the
> different
> > types of these case, look at the Intersex Society of North America's
> > numbers: http://www.isna.org/faq/frequency
>
> Agreed. An intersex person may according to background/preference
> choose to list M, F, or O as their SEX component.
>
>
> > That said, since this project is more about data management and personal
> > identity than medical records, I'm not quite sure what to advocate for
> > here.
> >
> > Tantek, do you think there are cases where a form will ask users for both
> > their sex AND their gender?
>
> Implicitly, yes, and there are already some (a few) sites that do this.
>
> That is, there are sites (e.g. Digg, and previously, Pownce) that
> provide a long list of possible "Gender" values which are a
> combination of various "male" labels, "female" labels, and other
> labels.  By choosing one of these options, the user chooses a gender
> identity label, and an implied sex in many of the cases as well.
>
>
> > Your system sounds like good data management: it
> > will allow any system to have either pre-defined or free-form values
> without
> > one data set muddling up the other.
>
> This is *precisely* correct, and in fact, the goal here is to allow
> for backward compatibility with the (perhaps simplistic) data models
> of some sites, while enabling such systems to evolve to allow more
> options for the sex component and finer granularity of gender
> identity.
>
> > I suspect, though, that in actual
> > application, only one component will be used at a time.
>
> In practice I foresee the majority of sites using the enum to start
> with (per the data gathered at microformats.org on real world
> examples), with a few sites using both.
>
> My *hope* is that as with many formats, that newer systems that
> support the vCard4 contact information schema will take into
> consideration the possibility of supporting both, and may do so,
> either like Digg.com, or perhaps with their own UI.
>
> > No recommendations or endorsements here. Just observations.
>
> I hope the above clarifications help.  Please let me know if you have
> any suggested improvements, or if there are any problems with the
> above examples and explanations.
>
> > ~Sarah
> >
>
>
> Thanks,
>
> Tantek
>
>
> > On Thu, Dec 16, 2010 at 3:02 PM, Tantek Çelik <[e-mail]>
> > wrote:
> >>
> >> On Thu, Dec 16, 2010 at 09:14, Florian Zeitz <[e-mail]>
> >> wrote:
> >> > Some time ago stpeter wrote:
> >> >> But, if someone registers "queer", the result would be what?
> >> >>
> >> >> 1. GENDER:;queer
> >> >>
> >> >> or
> >> >>
> >> >> 2. GENDER:queer
> >> >>
> >> >> My impression from the discussion in Beijing was #2, not #1 (if,
> again,
> >> >> someone registered "queer" with IANA).
> >> >>
> >> > +1
> >> > Registering values for a free-text field (which #1 would be as I
> >> > understand
> >> > it) seems rather strange.
> >>
> >> Peter, Florian, I stand corrected.
> >>
> >> You're right, it doesn't make sense to have an IANA registry for a
> >> free-text field (gender-identity component of gender).
> >>
> >> That leaves the question of whether or not it makes sense to have the
> >> sex component of gender be extensible / registerable.
> >>
> >> Frankly I'm not sure that it does.
> >> Or rather, I believe the enum set proposed (M,F,O,N,U) for the sex
> >> component is sufficient for vCard4.
> >>
> >> Since we already have a free-text field for arbitrary labeling with
> >> gender-identity, I believe that maps well to our goals of sufficient
> >> flexibility to allow expression of human diversity.
> >>
> >> I'd prefer to *not* make the sex component extensible for now, until a
> >> good case can be made based on real world examples that demonstrates
> >> that such extensibility is necessary / useful above and beyond the use
> >> cases for flexibility gender identity (which are already covered by
> >> that respective free-text component).
> >>
> >> Thanks,
> >>
> >> Tantek
> >>
> >> --
> >> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
> >> _______________________________________________
> >> 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
> >
> >
>
>
>
> --
> http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
>



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