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

Comments

@ghost
Copy link

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

@akuckartz akuckartz commented May 26, 2015

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

@danbri
Copy link
Contributor

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

@ghost
Copy link
Author

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

@vholland vholland commented Jun 26, 2015

Please review pull request #626.

@chaals
Copy link
Contributor

@chaals chaals commented Jun 30, 2015

Looks OK to me

@danbri
Copy link
Contributor

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

@vholland vholland commented Apr 20, 2016

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 danbri commented Apr 28, 2016

@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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.