Discussions on Gender

Hermaphrodite

I just removed this. If we want to model beyond two genders, we will need a UI that makes this easier.

One question about gender - two of the instances deleted were "male to female transgender" and "female to male ...". Do transgendered people typically identify as "a to b transgender" or just "b"?

I was going to document this…
Typically, a transgender person identifies as either male or female, and that should be respected. However, when a high-profile person has a high-profile change (e.g., Walter/Wendy Carlos), it is useful to document that, to clarify confusion about attribution of work or publicity done before or after the change.
Having “transgender” on its own as a gender is very confusing; that’s more a collection of gender identities rather than an identity of its own.

The sense of the property name 'gender' is really a surrogate for 'sex', which is a less delicate term to be appearing on all people topics. If we can think of another name for the property, of if sex is OK, then we can switch to that.

For transgendered people, we may consider creating a cross-type called 'transgendered person' which includes properties for the from and to sexes that can be used to encode this for notable people.


I replied to this earlier, but something ate my post. So here goes again.

I thought about this schema a bit more, and sex makes a lot of sense for the property name. It's less ambiguous, and with less shading between property values, which means it's easier for us to handle in the UI.

"Sex" is the name of the field on my CA driver's license, so I don't think it will cause serious problems with our users.

"Sex" is a better name for the current field--- although it too should have multiple options. "Intersex" is the preferred name for anatomies that don't fit neatly into "male" or "female;" see Intersex Society of North America for more information. Anne Fausto-Sterling has popularized the idea that there are at least five sexes, and that categorizing humans into two statistically-common sexes reduces our understanding of the varieties of human anatomy and sexuality.

"Gender" should properly allow for a huge range of self-identified genders; here are some of the possibilities. Also, to answer an earlier poster's conjecture: for a transsexual person of female-to-male experience, "man" is often a fully sufficient gender, and he wouldn't want to be known as anything else; another FTM might not claim "man" as his gender, preferring another term.

If we decide to change "gender" to "sex", we currently will only be able to change the 'display name' as it is seen in freebase, but not the 'programmatic name' used by code. Why? Because it would break existing software. When we add proper aliasing, we should be able to create keys for both. When that is possible, we can consider changing the display name and adding a programmatic name (a key) for "Sex".

Not to derail this, but this is another good case for types having versions and a flag indicating whether the type is current, deprecated, or proposed. In this case, person v1.0 (gender) could be marked as current, and person v1.1 (sex) as proposed, giving developers some warning about coming changes.

Back to the topic at hand, UI clarity trumps API clarity. I vote for changing the display name to sex now, and the property key to sex later.

I'd also vote for changing the display name to "sex." And I'm with srl that we should consider adding "intersex" as one of the choices.

This use of "gender" is supported by many dictionaries (indeed, this is a pretty pedantic point), but if there is a mass movement to change it, we can accommodate it, even if it desynchronizes the programmatic names.

As for "intersex" or other sexes that are not strictly "male" or "female", I would say that this can cause confusion with our emumerated lists that are strictly alphabetized. Ideally, less frequent options would appear at the bottom. Currently, "Intersex" would appear first, which is odd for an option that is a fraction of a percent of instances that would appear in Freebase. Given srl's suggestion that there may be many more, this would only be compounded.

Sarah, I would suggest you submit a feature request for ordering enumerated lists. Once that's implemented, I think we can support this better.

Gender and sex

Sex is not binary, and neither is gender. And they're different types. Let's put both sex and gender on type "Person".

Hey, Liz. I more than agree that they're different things (it was something I noted in one of my first conversations at Metaweb). And I'm intrigued by the idea of having both, though I'm not sure how we'd model gender. That is, would it be an enumerated list with a range of options? If so, what are those? If it's not an enumerated list, I fear we'd be opening up a rich vein of confusion and bad data, given that most people aren't aware of the semantic difference between sex and gender in the first place.

Sarah

What about sex as female, male, intersex, other
Gender - very complicated and fashions in word use changes. Binary also leaves us with a terrible mess. So an enumerated list and as you say, bad data.

So as per the thread above, we're considering changing Gender to Sex, and then adding Intersex and/or Other to the enumerated list. But if we had both Sex and Gender properties, what would the values for Gender be? Feminine, Masculine, and It's All Performance and Perception Anyway?

OK, seriously, I'm just not sure how we'd represent the gender spectrum. As you say, very complex, and the words used to describe these things are in constant flux.