Quasi-enumerable value for gender #541

Closed
barrycarter opened this Issue May 25, 2015 · 13 comments

Projects

None yet

7 participants

@barrycarter

While leaving gender as plain text (instead of just "male" or "female") is politically correct, it makes certain assertions difficult.

Example: if X is Y's sibling and X is female, then X is Y's sister.

However, the gender "female" could be written inconsistently as "F", "Female", "FEM", or in some other way.

I suggest gender be a "quasi-enumerable" value: "F" for female, "M" for male, but plain text allowed for other genders.

So, you couldn't use "female" or "fem" for female (since it already has an assigned enumeration), but you could still have non-male/female genders.

@akuckartz

If the range is plain text, then "female" will be used in addition to "F" (and "f").

@danbri
Contributor
danbri commented May 27, 2015

It's more than politically correct to have an inclusive design, it is the right thing to do.

But there is a case for having well known values, minimally for 'female' and 'male'.

(that's what we did in FOAF, http://xmlns.com/foaf/spec/#term_gender)

@barrycarter

@akuckartz Yes, and I'm arguing that's a bad thing, since it's
inconsistent. Even though we can't have consistent naming for all
genders, we should be consistent where possible. "F" for female, "M"
for male, and free text for entities that aren't identified as Male or
Female.

@danbri Agreed. I think we need a "enumerated type with other values"
or something.

@chaals
Contributor
chaals commented May 28, 2015

I agree with @akuckartz - we might as well have "female" and "male" since people will use them anyway...

@mfhepp
Contributor
mfhepp commented May 28, 2015

The standard pattern for "Text" or values is to set the range to Text OR (SomeType), and define individuals for standard types. This allows a uniform representation of common values while not discriminating other values.

@danbri
Contributor
danbri commented Jun 8, 2015

@mfhepp in this case indicating common textual values also seems appropriate, rather than having entirely different markup forms for any non-anticipated options.

@vholland vholland added a commit to vholland/schemaorg that referenced this issue Jun 26, 2015
@vholland vholland Issue #541: Create enumerations for gender, but also allow the gender…
… property to take text.
9f62959
@vholland
Contributor

Please review pull request #626.

@chaals
Contributor
chaals commented Jun 30, 2015

Looks OK to me

@danbri
Contributor
danbri commented Apr 4, 2016

Looking back for old issues to address, ... what happened here? @vholland your PR has gone away, though the draft is visible. It proposed Male and Female enumerations. I was thinking a soft enumeration would just be to list the expected textual values i.e. 'female' as a string, 'male' as a string. This gets us back into the territory we're discussing around dayOfWeek, 'Monday'/'monday' vs http://schema.org/Monday. /cc @betehess

@betehess
Contributor
betehess commented Apr 4, 2016

I see that some countries already have different approaches/terminology. Just to name a few from https://en.wikipedia.org/wiki/Third_gender: Indeterminate, X, Third Sex, Third Gender.

So this does look like DayOfWeek except that the gender enumeration is not sealed. Maybe we could make that more explicit in the ontology? Also, from the experience gained on DayOfWeek, maybe we should think about a system which lets people define new entities which are not just Text. For example, it's not clear to me that the following approach is "compatible" with Schema.org, nor it should be encouraged/documented:

{
  "@context": "http://schema.org/",
  "@type": "http://schema.org/GenderType",
  "@id": "http://some.australian.domain/X",
  "rdfs:label": "X",
  "rdfs:comment": "Definition of X in Australia goes here"
}
@vholland
Contributor
vholland commented Apr 5, 2016

I recreated the original pull request as #1077. We can iterate from there.

@vholland vholland added a commit to vholland/schemaorg that referenced this issue Apr 20, 2016
@vholland vholland Issue #541: Added enumerations for male and female genders. f2e5205
@vholland
Contributor

The third time's the charm. See pull request #1112

@danbri danbri closed this Apr 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment