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

Proposal: genderRestriction changes #69

ldodds opened this issue Apr 18, 2018 · 13 comments

Proposal: genderRestriction changes #69

ldodds opened this issue Apr 18, 2018 · 13 comments


Copy link

@ldodds ldodds commented Apr 18, 2018


This has been proposed based on reviewing currently published data

Use Case

  • as a participant I want to know whether an event is suitable for me
  • as a data user I want to be able to reliably filter events, e.g. to help women find women only events

Why is this not covered by existing properties?

This is a proposed change to the existing genderRestriction property

The change will effect the following publishers:

  • activeNewham
  • fusion
  • GLL
  • Good Gym
  • Lawn Tennis Association
  • Leisure World Colchester
  • Salford Community Leisure
  • Sport Starta
  • Vision Redbridge Culture & Leisure


genderRestriction is currently a literal value. It's defined as having values of "male", "female" or "mixed". However people are using inconsistent values ("Male"), or incorrect values ("men"/"women")

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 defines and

We could define three URIs for gender restrictions:


Other than this the property stays the same:

  • if genderRestriction is not supplied then consumers SHOULD assume the value is
  • if supplied it can only have a single string value, which must be one of the URIs
  • a value of indicates that the event has no restrictions
  • a value of indicates that the event is restricted to the male gender
  • a value of indicates that the event is restricted to the female gender

This usage and naming aligns with GDS recommendations


"@context": "",
"type": "Event",
"genderRestriction": ""
@ldodds ldodds self-assigned this Apr 18, 2018
@ldodds ldodds added the proposal label Apr 18, 2018
@ldodds ldodds added this to Backlog in Specification revisions via automation Apr 18, 2018
@ldodds ldodds moved this from Backlog to In progress in Specification revisions Apr 18, 2018
Copy link

@nickbaileyuk nickbaileyuk commented Apr 18, 2018

Suggest that this property is not mandatory. If it is not provided in the feed the event should be considered as suitable for all genders.

ldodds added a commit that referenced this issue Apr 20, 2018
@ldodds ldodds moved this from In progress to In Editors Draft in Specification revisions Apr 20, 2018
@ldodds ldodds added this to the 1.1 milestone Apr 20, 2018
Copy link

@nickevansuk nickevansuk commented Apr 23, 2018

Just noticed this is "" rather than "" (which had been suggested in britishcycling-oa/opendata#3 and openactive/activation#113, and follows the pattern used in goodrelations).

Suggest that:

  1. We are consistent with recommending /ns/bar or /ns#bar (if we want to switch to /ns/bar, now is an excellent time to do so).
  2. We are consistent with "" as the prefix (the same as the IDs in, rather than, as it removes the requirement for co-hosting the schema with the website at www in the future, and also removes the need for that schema to be secured with https
Copy link

@nickevansuk nickevansuk commented Apr 23, 2018

For completeness of the discussion I'll also suggest using using as per

Personally is still my preference, as it's shorter.

Copy link
Contributor Author

@ldodds ldodds commented Apr 25, 2018

The use of https and / is a typo, will fix that in the proposal and the Editors Draft.

Copy link
Contributor Author

@ldodds ldodds commented Apr 25, 2018

change the default assumption for unspecified values to be "null" and state that comsumers should exclude events when filtering. invalid values should be similarly handled

ldodds added a commit that referenced this issue May 2, 2018
Copy link

@nickevansuk nickevansuk commented Jun 6, 2018

Note I've amended the original proposal above from "/" o "#" to fix the typos, to aid the casual reader

Copy link

@kent-gosweat kent-gosweat commented Jun 6, 2018

Just picking up on the gender restriction. Is it wise to make it a trinary M/F/M+F only? Especially in metropolitan areas where non-binary events are more common.

Copy link

@kent-gosweat kent-gosweat commented Jun 13, 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?

Copy link

@kent-gosweat kent-gosweat commented Jun 13, 2018

How we have decided to implement this in GoSweat is to introduce a field genderRestrictions that if null or empty means there are no restrictions (aka "mixed"). The field is a list (array) of string items that represents a list of accepted genders.

E.g., "genderRestrictions":["women", "transgender women", "a-gender"]

We are going with the plurals for each gender: "women" over "woman".

We are supplementing this with a second field called restrictionsInformation that is free text to give context / rules / advice.

E.g., "restrictionsInformation":"If unsure please contact xxxx."

Copy link

@nickevansuk nickevansuk commented Jun 18, 2018

@ldodds note that the Editors Draft still reads rather than "" (see discussion above), also should it actually be ""

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

restrictionsInformation is nice, though this could be included in the existing attendeeInstructions too if we wanted to ensure it was displayed by more data users.

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?

Copy link

@someoneinatree someoneinatree commented Jun 18, 2018

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 identityRestrictions - a list of case-insensitive keywords that describe identity groups that the session is aimed at the members of. (Optionally, you might want to be able to specify strictness per keyword, i.e. do you need to match all listed identities, or just one; are any of them mandatory; etc).

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.

Copy link

@kent-gosweat kent-gosweat commented Jun 18, 2018

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 restrictionsInformation field is also provided.

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 agree, identityRestrictions could be another way of approaching this. Although we'd perhaps end up with a confused list of group membership identities and gender identities. Gender being a specifically protected attribute suggests to me it should be it's own thing.

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.

Copy link
Contributor Author

@ldodds ldodds commented Jun 29, 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:

  • rather than using genderRestriction a publisher can tag events using category allowing for more freedom with labelling
  • the title, description and attendeeInstructions all provide some scope to clearly indicate whether an event is suited for a particular audience, whether there's a code of conduct, etc
  • genderRestriction itself isn't a closed set of values. We've just defined some initial ones based on existing usage. Publishers are free to define and use their own URIs to help classify events. This allows the community to explore additional approaches to describing events

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

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