Describing surfaces of pitches

[ldodds]

How should we support specifying the surface of a football pitch (for example).

One option is to add a surface property which can be applied to a SportsActivityLocation

[nickevansuk]

Suggest this property should now be on FacilityUse?

[nickevansuk]

Worth thinking about: court/pitch type, i.e surface type, indoor/outdoor. Perhaps surface and indoor/outdoor are separate properties?

[jamiefoale]

Based on discussions with Izy at Sport England, Tom at Played and myself we have thought the following:

• Active Places have worked with NGBs to create a structure for their sport facilities already, which incorporate the different facility types
• Therefore we believe this is suitable as a source of truth as is already curated by the NGBs and hosted by SE / Active Places
• While it doesn't strictly cover each sport that can be played on a facility, this is more intangible now as a 'space' eg pitch can be used for multiple purposes as formats are becoming more flexible. Eg you have tag rugby played on a traditional 5 a side football pitch
• There are other gaps eg tennis courts are pretty limited, but if NGBs can be informed of the use of this structure (which should in turn be used by many operators) then it should motivate them to ensure thorough curation
• There is an existing API for Active Places which could make any tech work easier

The two fields are 'Facility type' and 'Facility sub type'. These are mapped so each sub type is specific to the ID of the Facility type. These two sheets are attached.

In order to make the use of opportunity data scalable we feel this should be included in the FacilityUse.

Thanks

FacilityType and FacilitySubType.xlsx

[IzyChampion]

Hiya

Here's some more contextual information on how Active Places is structured, provided by my colleague Mark, which answers (to some extent) the question on tennis courts above from @jamiefoale :)

The key tables/tabs within the Sport Data Model are: FacilityType, FacilitySubType, and Lookups, however there are some inconsistencies with Active Places as to where surface type is defined. For example the Facility Type of Artificial Grass Pitches has Facility Sub-Types based upon the surface type - Surface Type is not a facility specific attribute and does not reference the lookup table within the Sport Data Model (SDM).

AGP Rubber crumb 3G Sand dressed Sand filled Water based Length Width Pile length …..

However, for Tennis Courts, the Facility Sub-Type is Tennis Courts. The Surface Type is an attribute within the facility specific details references surface type within the lookup table in the SDM

Tennis Courts Tennis Courts Surface Clay Grass ….

We're keen to see if we can iron out some of this detail through use of Active Places via OpenActive - and potentially explore creating common data standards between the two!

[nickevansuk]

Comments regarding progressing this as a maintained list in OpenActive

Interesting! Just had a quick look… the list supplied seems to be a mix of activities which already feature in the OpenActive Activity List (e.g. “Paragliding”, “Canoeing”, “Horse Racing”, “Baseball”, “Hurling”), some surface types (e.g. “Permanent Grass”) and some other facility types (e.g. “Indoor Climbing Wall”, “Dodjo”, "Boxing Gym").

I suspect, as Mark has pointed out, that this list might have been created for a slightly different purpose?

Given the high number of duplicates between this list and the current OpenActive Activity List, it looks like there's still quite a bit of work to separate out the concept of an "Activity" (in OA terms) from the types of "Facility" (e.g. "Sports Hall", "Pitch", "Climbing Wall") and attributes of "Facility" such as "Surface type" ("Rubber crumb pile (3G)") and Indoor/Outdoor.

@jamiefoale for reference, would you be able to post MLP's own surface/pitch type schema you mentioned in the last call, as a point of comparison?

It would be good to get lists from a few different sources, as we've done with other aspects of the standards, to ensure we've got a range of inputs for this.

This is likely to take some time, though is certainly worthwhile.

Comments regarding the short term

Another great input into the long term discussion is to see early use of a property in the wild, which would be achieved via a "beta" property. This way how the "beta" property is used becomes another input to the long term discussion, and also provides data users with useful data in the interim too.

For this to be viable within short-term timescales we'd need to get to something a bit more curated fairly rapidly.

Perhaps existing schema's such as MLPs could be a good way to do this? Or perhaps we want to focus on the long term here?

[IzyChampion]

You're right in terms of that list covering a myriad of uses, and I think we'd be keen to understand how we can make it more useful! The other thing to note is that this list covers all the technical specifications for different surfaces (eg Sand Filled, Sand Dressed, Rubber Crumb etc) - and not what they might be named by someone promoting the pitch. For example, through this process I learnt that there's no such thing as a 4G pitch, despite many places advertising their pitches as such!

We suggested that one way around not distorting the technical specifications (which are agreed and set with NGBs) and the need to call them something meaningful to consumers would be to follow the lead of the activity list spec - e.g. where a leisure operator calls a session something strange like 'bubble buddies' but it can still be tagged as swimming to make it meaningful.

[nickevansuk]

Regarding using language from the technical specifications: it depends on how widely recognised the technical specs are, and how diverse the consumer facing brands are compared with the underlying spec names - agree we should certainly aim for canonical activities where we can.

In terms of making it more useful / linking it with existing OA data, I've just had a quick chat with @jamiefoale and looks like we might have a way forward with this for an MVP.

Facility types are often shared between sports, and as the Active Places list shows, sometimes sports don't have specific facility types (e.g. "Drag Racing").

MVP vocab and Beta property

So to create this MVP, I've created the following template as a starting point:
https://docs.google.com/spreadsheets/d/1ZZ1J13Ry3y8p5nA2Voady98A3dZocvGebuNu1PYIveI/edit#gid=0

Note that this will only be a straw-man at this stage, and is to give implementing systems something to include to prove the concept and usefulness of the data. It will change and evolve over time.

Instructions

For each facility type we want to include, we need to find the relevant activities that would be applicable to it from http://activity-list-editor.openactive.io/en.html, and reference them against that facility type. Notice the pattern in the example of including the URL of the activity from the activity list along with its name, this is important as it includes the ID.

Note the highest level activity includes all sub activities
so e.g. Football (http://activity-list-editor.openactive.io/en/concepts/_0a5f732d-e806-4e51-ad40-0a7de0239c8c.html) will include all of these:

We want to avoid duplicating facility types with the same name (e.g. I notice Active Places includes "Rubber crumb pile (3G)" twice).

As an example of a user interface to give some context to this: when a provider selects the standard "activities" related to their facility use, they can then select multiple matching entries from the relevant Facility Types which are related to it. E.g. they select "Football", then can choose "3G" from the list of types that becomes available. If they select both "Football" and "Netball" for their FacilityUse, and both of Football and Netball are linked to the Facility Type "3G", then the 3G option only appears once and can be selected for the FacilityUse once.

Note that there is also an "altLabel" column, which follows SKOS and the pattern of the OpenActive Activity List - the altLabel can be used for alternative terms that a consumer might use during a search. This helps capture the widely recognised terms that are being used for the same thing. To include multiple altLabels just separate them with commas.

Also note you don't need to have an Active Places reference for each entry that exists at this stage, but if you can see one then do use it. The main thing is the prefLabel column in the middle (in yellow) and the activity list references on the right.

[nickevansuk]

Additionally shall we use a beta property named beta:facilityType to reference these entries from a FacilityUse, and that we use SKOS to represent this list? In a very similar way to how this works: https://www.openactive.io/accessibility-support/

Thoughts welcome!

[nickevansuk]

One further question, should we also have a property for beta:facilitySetting: with options of either https://openactive.io/IndoorFacility or https://openactive.io/OutdoorFacility?

Or otherwise should we just have Outdoor and Indoor included as facility types? I ask as Indoor/Outdoor seems to be relevant to every type of activity.

[tommarley148]

Hi guys,

Have made a first pass at this S/S -https://docs.google.com/spreadsheets/d/1ZZ1J13Ry3y8p5nA2Voady98A3dZocvGebuNu1PYIveI/edit#gid=0

Have used a combination of MLP's, Played's and Active Places resources and have included Activities that will take place at each of these surface types.

I aired on the side of caution so have maybe included too many surface types. i.e table tennis table - when there was not a clear surface that the sport could be played on.

I have just included Activities in the Applicable OpenActive Activities that would take place at a surface type included - I have included activities such as Tennis, Football, Volleyball etc and not included activities such as Angling, Gardening etc - does this approach make sense?

If you could feedback that would be awesome.

Thanks
Tom

[IzyChampion]

Hi everyone

I've made some comments on the spreadsheet shared by @tommarley148 - thanks Tom for pulling this together!

Overall, I think it's an excellent first stab. I've made a few comments based on some internal conversations I've had - apologies for the delay in getting on to this. The main points are:

• A couple of items seem more like pieces of equipment or facility properties rather than surfaces (like Table Tennis Table, or Cricket Nets) - I've made comments on each of these in the spreadsheet.

• A couple of surfaces were described in a way which didn't match their Active Places identifier (Sand and Sand Based Carpet, which are both types of Artificial Grass Pitch) - I've made suggestions on updating these, but they may in fact warrant new rows, depending on if there is a different kind of surface meant?

• A couple of surfaces were linked up to sports which didn't seem to match (Lawn and Crown Green) - AFAIK they are both just linked to Bowls. I've made those suggestions

• A couple of surfaces didn't appear in the Active Places data (Sports Hall and Squash Courts don't have associated surfaces). Part of me wonders how relevant the surface type is to the consumers who might be looking to book these - is the activity available in the space in these cases more important than the surface type?

I've also added some extra things in which are more 'for reference' than anything.

• Two additional columns: Id and FacilitySpecificSurfaceOptions - These are links to the relevant entry in the Sports Data Model which links to Active Places and which also contains some relevant surface information, including a whole host of rock climbing surfaces!

• Some sports have 'preferred surfaces' - e.g. Hockey prefers Sand Based Artificial Grass. I've added them in where I know them. This doesn't change the spreadsheet necessarily, but might help with designing how you serve options to consumers

Hope that helps?

[nickevansuk]

I've transferred this over to a repository of its own (also available at https://www.openactive.io/facility-types/), added a tab to the spreadsheet which renders the data sheet into JSON, and added the resulting JSON to this repo.

The cut of the data taken into the JSON is just directly from the spreadsheet, without adjusting for @IzyChampion's most recent comments.

@IzyChampion , @tommarley148 , @jamiefoale it would be great if you could work together to address these comments and get the sheet into a state you're all happy with. Please feel free to make any changes you like to the "Raw Data" sheet, as the formulae for JSON generation are all in the "JSON" sheet.

Beta Properties added

The following have been added resulting from the discussion in this issue. To progress these further they need to be formalised into two proposals: one for facilityType and one for facilitySetting (and its associated IndoorFacility and OutdoorFacility). If it would also be useful to have preferredSurfaces or similar, please create a further proposal for this also.

The facilitySetting has been added to both Event and FacilityUse as it is broadly applicable.

Please create the proposals here.

Properties

(Class) Property	Expected Type	Proposal	Description
(schema:Event, oa:FacilityUse) beta:facilitySetting	beta:FacilitySettingType	#1	Whether the facility is indoor or outdoor.
(oa:FacilityUse) beta:facilityType	skos:Concept	#1	The type of facility in use.

Classes

Class	subClasses	Proposal	Description
beta:FacilitySettingType	schema:Enumeration	#1	An enumeration of settings in which a facility can exist.

Enumeration Values

Type	Value	Proposal	Description
beta:FacilitySettingType	https://openactive.io/ns-beta#IndoorFacility	#1	Facility is indoors
beta:FacilitySettingType	https://openactive.io/ns-beta#OutdoorFacility	#1	Facility is outdoors

[nickevansuk]

@jamiefoale @IzyChampion @tommarley148 as requested please see example UI below. Comments welcome!

[nickevansuk]

Just a quick note that facilityType and facilitySetting might also be useful on SessionSeries for sessions that happen in facilities - I've added facilitySetting to Event for now as it's broadly applicable (and updated "Beta Properties added" above and the Beta namespace to reflect this)