Proposal: genderRestriction changes

ldodds commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Just noticed this is "https://www.openactive.io/ns/Male" rather than "http://openactive.io/ns#Male" (which had been suggested in https://github.com/britishcycling-oa/opendata/issues/3 and https://github.com/openactive/activation/issues/113, and follows the pattern used in goodrelations).

Suggest that:

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).
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 commented 6 years ago

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 commented 6 years ago

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

ldodds commented 6 years ago

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 commented 6 years ago

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

kent-gosweat commented 6 years ago

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 commented 6 years ago

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?

kent-gosweat commented 6 years ago

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

nickevansuk commented 6 years ago

@ldodds note that the Editors Draft still reads https://www.openactive.io/ns#Mixed rather than "http://openactive.io/ns#Mixed" (see discussion above), also should it actually be "http://openactive.io/ns#None"

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

someoneinatree commented 6 years ago

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.

kent-gosweat commented 6 years ago

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.

ldodds commented 6 years ago

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.

openactive / modelling-opportunity-data