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
barrycarter opened this Issue May 25, 2015 · 13 comments

Comments

Projects
None yet
7 participants
@barrycarter

barrycarter 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

This comment has been minimized.

Show comment
Hide comment
@akuckartz

akuckartz May 26, 2015

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

akuckartz commented May 26, 2015

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri May 27, 2015

Contributor

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)

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

This comment has been minimized.

Show comment
Hide comment
@barrycarter

barrycarter 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.

barrycarter 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

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals May 28, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp May 28, 2015

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jun 8, 2015

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jun 26, 2015

Contributor

Please review pull request #626.

Contributor

vholland commented Jun 26, 2015

Please review pull request #626.

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jun 30, 2015

Contributor

Looks OK to me

Contributor

chaals commented Jun 30, 2015

Looks OK to me

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 4, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@betehess

betehess Apr 4, 2016

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Apr 5, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Apr 20, 2016

Contributor

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

Contributor

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

Merge pull request #1112 from vholland/gender
Issue #541: Add enumerations for male/female, but allow other values as well.
@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri
Contributor

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