Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quasi-enumerable value for gender #541

Closed
ghost opened this issue May 25, 2015 · 13 comments
Closed

Quasi-enumerable value for gender #541

ghost opened this issue May 25, 2015 · 13 comments
Labels
schema.org vocab General top level tag for issues on the vocabulary

Comments

@ghost
Copy link

ghost commented May 25, 2015

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

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

@danbri
Copy link
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)

@danbri danbri added the schema.org vocab General top level tag for issues on the vocabulary label May 27, 2015
@ghost
Copy link
Author

ghost commented May 27, 2015

@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
Copy link
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
Copy link
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
Copy link
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 added a commit to vholland/schemaorg that referenced this issue Jun 26, 2015
@vholland
Copy link
Contributor

Please review pull request #626.

@chaals
Copy link
Contributor

chaals commented Jun 30, 2015

Looks OK to me

@danbri
Copy link
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
Copy link
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 added a commit to vholland/schemaorg that referenced this issue Apr 5, 2016
@vholland
Copy link
Contributor

vholland commented Apr 5, 2016

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

vholland added a commit to vholland/schemaorg that referenced this issue Apr 20, 2016
@vholland
Copy link
Contributor

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

danbri added a commit that referenced this issue Apr 20, 2016
Issue #541: Add enumerations for male/female, but allow other values as well.
@danbri
Copy link
Contributor

danbri commented Apr 28, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
schema.org vocab General top level tag for issues on the vocabulary
Projects
None yet
Development

No branches or pull requests

6 participants