Quasi-enumerable value for gender

[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").

[akuckartz]

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

[danbri]

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)

[danbri]

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.

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

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

[chaals]

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

[mfhepp]

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.

[mfhepp]

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]

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

[danbri]

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

[vholland]

Please review pull request #626.

[vholland]

Please review pull request #626.

[chaals]

Looks OK to me

[chaals]

Looks OK to me

[danbri]

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

[danbri]

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]

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

[betehess]

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]

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

[vholland]

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

[vholland]

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

[vholland]

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

[danbri]

Closing per http://webschemas.org/docs/releases.html#g541

[danbri]

Closing per http://webschemas.org/docs/releases.html#g541