Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: genderRestriction changes #69
This has been proposed based on reviewing currently published data
Why is this not covered by existing properties?
This is a proposed change to the existing
The change will effect the following publishers:
A small non-breaking change (which would only impact Lawn Tennis Association and Sport Starta) would be to more clearly specify the expected values. E.g. require them to be "male", "female", "mixed" to be valid.
The alternative proposal is to use URIs for values rather than string literals. For example Schema.org defines
We could define three URIs for gender restrictions:
Other than this the property stays the same:
This usage and naming aligns with GDS recommendations
added a commit
Apr 20, 2018
Just noticed this is "https://www.openactive.io/ns/Male" rather than "http://openactive.io/ns#Male" (which had been suggested in britishcycling-oa/opendata#3 and openactive/activation#113, and follows the pattern used in goodrelations).
added a commit
May 2, 2018
This was referenced
Jun 6, 2018
This came up again when talking to a sports provider so I thought I'd share here.
They made the very valid point that "Male" and "Female" are Biological Sex and not Gender. Also the M/F doesn't account for intersex if the spec was to focus on sex rather than gender. Although many use "Male" and "Female" as synonyms for "Man" and "Woman" (so I'm less bothered about it in label terms) it does make a difference in language.
For example, a gender restricted session might be "Women's Football" rather than "Female Football".
Or, "Suitable for women" rather than "Suitable for females".
Is it possible to have recommended values but not have it as a limited / exclusive list?
How we have decided to implement this in GoSweat is to introduce a field
We are going with the plurals for each gender: "women" over "woman".
We are supplementing this with a second field called
@ldodds note that the Editors Draft still reads
@kent-gosweat - can I just check this from a practical perspective. Do we know of sessions listed that are only suitable for "transgender women" or "a-gender"? No reason why there couldn't be, but I'm wondering whether given the number of potential options and the LGBTQ+ community's focus on inclusivity, that most sessions are likely to be more inclusive rather than really specific e.g "a-gender only".
It's difficult to be totally inclusive with a restricted list, but it's also hard for data users to aggregate disparate lists (for example if "Gender neutral" and "a-gender" are both used, data users are going to have to map these onto the same value). Potentially given the number of events like this in the data and the complexity of a fixed list, it might be better to somehow label them as "LGBTQ+" and allow users who filter on this to read the descriptions to figure out if they are appropriate. It might be easier to persuade data users to implement a "LGBTQ+" filter or a few high level options in the first instance rather than trying to get them all to wrestle with this fairly complex subject (especially when a complete list might also be difficult to get agreement on).
Essentially my suggestion here is to simplify this initially to maximise the number of implementors (and inclusivity) as a first step, as my working theory is that more implementors implementing something simple is more inclusive than less implementors implementing something really comprehensive and complex?
Note the above thoughts are my own and do not represent those of any organisation or entity.
Of course we could also just allow any values in the "genderRestrictions" field as you suggest, but it's likely that this would result in less applications using the values rather than more, as they're essentially free-text?
Hey, yeah been a while but thought about this quite deeply with @nickevansuk when I was working on this stuff! My instinct is, given quite a thorough interest in the concept of gender, that determines ultimately having no gender is perfectly valid, having a specific field for this felt somewhat like a schema anti-pattern (in terms of basically "validating" and encouraging certain concepts that may not be fully future-compatible or are certainly not universal or objective enough to be strictly, consistently taxonimizable).
My suggestion in this vein would be to abstract the schema to allow something like
By all means an effort could be made to standardize and publish a standardized subset of these, for example, "male", "female", "agender", "gay", "lesbian", "trans". Where either adjectives (e.g. "male") or nouns ("men") could be chosen, but adjectives probably should be preferred because then there's no singular/pluralization confusion.
Aggergators can make their own mappings and coalescions, but this would essentially be a free text field, in the spirit of open data and people using this feature as broadly as possible. For example, I know a number of gay sports groups, and they would surely like to add a very similar type of metadata, and this would equally support their ability to express their identity restrictions. As well as adding future-forward support for arbitrary sports group categories, like (for the sake of argument) Liberal Democrat Running Group or Sikhs Who Wrestle.
I think the problem is actually similar to Disability Restrictions / Physical Requirements. There can't be a finite list as the list constantly grows. Or perhaps it's better to say it's like the list of sports/activities. That list can't be definitive because we don't know when the next Ocean Surfing Yoga will be invented.
Gender is especially hard as there is no real list, it's a self-applied label, and the meaning varies from person to person. I appreciate this makes codifying the field very hard.
On inclusivity, I think you make a good point @nickevansuk: it needs to be inclusive of the data users entering values as well as those who the data represents. A list of known and accepted synonyms would be good here. "Men" <-> "Male". I believe this to be a UI/UX problem that the applications should handle rather than the data specification.
I suppose the question is the use case. What is this data used for? Is it used for filtering data and therefore needs to be machine readable, or is used to display to user for them to make a judgement?
If a machine readable format is needed then perhaps ["Men", "Women", "See Description", "No Restriction"] would suffice. Where "See Description" is effectively "No Restriction" and the
I'd avoid "LGBTQ+" because that doesn't distinguish between "Gay" (men) and "Lesbian" (women), for example, and brings sexual orientation into the mix.
I'd still prefer the "free text" item list, inclusive approach but we can implement this in GoSweat and make sure we map whatever OA spec provides. It will limit how we share our data though - we'll likely have to have a "See Description" option for most of our sessions which makes filtering our data less feasible for people consuming it.
This was referenced
Jun 19, 2018
To respond to some of these comments
We definitely want to make sure that everyone attending events fully understands who the event may be targeted at, any restrictions based on space or support available, and any requirements on attendees.
However the current proposal, which is now part of the 1.1 specification is intended to capture current practice: a number of events are advertised as being suitable for a specific audience. Allowing that to be expressed, is a step towards addressing the above requirement, although clearly there's more to be done around how events are described.
We've gone with a fixed set of URIs, rather than labels to make it easier to be consistent across feeds. It also allows applications to also map those URIs to terms that might be more useful to users. The initial motivation for the proposal was to tighten up current practice which included inconsistent data.
We've also used the term "gender" based on this GDS recommendation.
Because there are so many considerations around how gender is described, how events might be run and advertised and the need for people to feel safe and included, we need to give space for the community to explore options, in conjunction with people leading sessions, rather than jump to a technical solution.
There's space within the current approach for that to happen. Some of these have been mentioned:
I would encourage everyone to use those options. Then, based on experience, we can then decide on next steps.
While the core proposal has been accepted, I will leave this proposal open for additional feedback and to collect results of any experiments.