Proposal: genderRestriction changes

[ldodds]

Proposer

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

Proposal

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 Schema.org defines http://schema.org/Male and http://schema.org/Female.

We could define three URIs for gender restrictions:

• http://openactive.io/ns#Male
• http://openactive.io/ns#Female
• http://openactive.io/ns#None

Other than this the property stays the same:

• if genderRestriction is not supplied then consumers SHOULD assume the value is http://openactive.io/ns#None
• if supplied it can only have a single string value, which must be one of the URIs
• a value of http://openactive.io/ns#None indicates that the event has no restrictions
• a value of http://openactive.io/ns#Male indicates that the event is restricted to the male gender
• a value of http://openactive.io/ns#Female indicates that the event is restricted to the female gender

This usage and naming aligns with GDS recommendations

Example

{
"@context": "https://www.openactive.io/ns/oa.jsonld",
"type": "Event",
"genderRestriction": "http://openactive.io/ns#Female"
}

[nickbaileyuk]

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.

[nickevansuk]

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/implementation-tracker#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 "http://openactive.io/" as the prefix (the same as the IDs in http://openactive.io/activity-list/activity-list.jsonld), rather than https://www.openactive.io/), 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

[nickevansuk]

For completeness of the discussion I'll also suggest using http://purl.org/openactive/v1#Male using http://purl.org as per http://purl.org/goodrelations/v1#Cash.

Personally http://openactive.io/ns is still my preference, as it's shorter.

[ldodds]

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

[ldodds]

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

[nickevansuk]

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

[kent-gosweat]

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.

[kent-gosweat]

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?