Describing surfaces of pitches #1
Comments
|
Suggest this property should now be on |
|
Worth thinking about: court/pitch type, i.e surface type, indoor/outdoor. Perhaps surface and indoor/outdoor are separate properties? |
|
Based on discussions with Izy at Sport England, Tom at Played and myself we have thought the following:
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 |
|
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! |
Comments regarding progressing this as a maintained list in OpenActiveInteresting! 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 termAnother 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? |
|
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. |
|
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 propertySo to create this MVP, I've created the following template as a starting point: 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. InstructionsFor 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 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. |
|
Additionally shall we use a beta property named Thoughts welcome! |
|
One further question, should we also have a property for 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. |
|
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 |
|
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:
I've also added some extra things in which are more 'for reference' than anything.
Hope that helps? |
|
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 addedThe 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 The Please create the proposals here. Properties
Classes
Enumeration Values
|
|
@jamiefoale @IzyChampion @tommarley148 as requested please see example UI below. Comments welcome!
|
|
Just a quick note that |
|
Following a few calls, myself, @tommarley148 and @jamiefoale have matched any activity type we think needs a facility type to the relevant ones. Hopefully this is now a pretty complete list! @nickevansuk let us know if we need to do anything else to get this finalised!! Thanks :) |
|
Hi, I've noticed Because this is used for both events and facilities, wondering it could be more intuitively named to avoid confusion about indoor/outdoor referring specifically to facilities, as opposed to both the facility and event. Perhaps something more widely interpretable across both events and facilities feeds like |
|
Hi everyone. As part of the MCRactive work, MCRactive would like for users to be able to search Facilities (Uses) and Places by facilityType. (e.g. show me the facility uses that are in a Sports Hall). I've reviewed the current facilityType list (https://www.openactive.io/facility-types/facility-types.jsonld and https://docs.google.com/spreadsheets/d/1ZZ1J13Ry3y8p5nA2Voady98A3dZocvGebuNu1PYIveI/edit#gid=0) and I believe the following updates would make this list more robust and usable in practice:
In the hierarchy, facilityTypes like Rubber Crumb Artificial Grass and Sand Based Artificial Grass could live under the types of pitches they refer to, e.g. Football Pitch. Or, Lawn & Crown Green can live under Bowling Green. In this way, data publishers can include the facilityType detail to whatever level of detail they are able to, but crucially data users will know if a given facilityUse is available in a Sports Hall, or a Football Pitch, etc. |
|
We thought about doing this approach but it then requires someone to be very prescriptive about what activities can take place on a facility. Eg an astroturf of any type (rubber crumb or sand based) can and is being used by multiple activity providers, beyond what the pitch markings indicate. So the parent property shouldn't be the sport but a description of the facility type. If instead 'suggested' sports (eg not an exclusive list) can be under a facility type that could make it easier for publishers but I would discourage giving the sport the seniority. When thinking about how this translates to booking systems, I believe that you'll find the space / resource is the parent entity and sports/activities sit underneath it. |
|
Maybe I'm confused about this (sorry if so!). My take on this was that facilityType is just a property under a FacilityUse, and doesn't force any prescriptive decisions to be made, but insteads offers a route for facility owners to be more specific about where (in what type of facility) a FacilityUse is "taking place". So if a data publisher has FacilityUse called "Badminton", with Activity Type "Badminton" and facilityType "Sports Hall", then the data publisher isn't being prescriptive about what else can happen in that Sports Hall, they are simply saying that this specific facilityUse use takes places in the sports hall. It's not saying that no other facilityuse can happen there. Or, if I am a facility and I have one grass pitch, that can be used for either Football or Rugby, I can have a FacilityUse called "Junior Football Pitch" (or whatever), activity type is "Football", and FacilityType is "Football Pitch" and maybe "Grass" or whatever other specifics under that or alongside it. I can also have a second facilityuse called "Senior Rugby Pitch", activity type is "Rugby" and FacilityType is "Rugby Pitch" (and then "Grass" or whatever). Moreover, I believe what I'm suggesting doesn't interfere with the previous proposals, but allows facility owners who wish to clarify where exactly a given faciiltyUse is taking place to do so. If data users just want to show the surface type, they can ignore the other facilityType labels? There's already faciiltyType like Squash Court in the list, but not tennis court or other core sport facilityTypes, so my believe this is just an extension suggestion to make the list more exhaustive. This allows users who want to search for Places that have certain Facility Types ("show me all the Places near me that have Tennis Courts"), or to search for Facilities only occurring on a facilityType ("show me the availability Basketball facilities in sports halls"). |
|
Reflecting on the mention of this in today's W3C call, and summarising thoughts as:
The options here seem to be:
Modelling best practice would be (1), however given that this is still a This would mean that a The downside of the above is that the splitting the lists later will mean updating all the IDs for one half of the list, which will create work/cost for all implementers to migrate. Hence if we know that the list can be clearly split into surface and type now, it would be cheaper to do it earlier rather than later. Thoughts welcome! |
|
Thanks @nickevansuk, yes that would work for the use cases we're coming across and is in line with what I was suggesting in my last comment |
|
Reviewing the list, we definitely need more implementation experience. My suspicion is that the modelling problems here are deep. If we go with @nickevansuk's suggestion above for the moment, however, the question is I think simply syntactic: how do we indicate that a given My first thought is that we could use |
|
Interesting, yes - Also noting this sentence in the SKOS Primer:
This is similar to the use of So another options could be to define a property which is a beta enum of e.g. Alternatively a simple boolean property Enum is more extensible as this problem evolves. |
|
Some examples of cases we have had to model in the past: "Court 1" which can be used for Indoor Cricket, Netball or Soccer, as it is largely just a loose netted off area, but which then has: "Court 1 Half 1" which is, as the name suggests, half of court 1 and can be used for dodgeball, birthday parties, or any other "generic" booking Half 1 and Half 2 are child courts of Court 1. And then: "Badminton 1", "Badminton 2", "Badminton 3" which are child courts of both "Court 1" AND of "Court 1 Half 1" (Badminton 1 and 2) AND "Court 2 Half 2" (Badminton 2 again and Badminton 3). On the "Badmintons" bookings of type "Badminton" can be made, or pilates or "Pitch hire" which is a generic booking type. This is probably the most convoluted set of "bookable area" relationships that we have modelled, but it was up to the provider to decide what could be done on each bookable area. The end user though would have been looking to book an activity type largely - ie, they would be looking to book to play Badminton. Unless they were not, of course... In which case they may just have been looking to book an indoor court area on which to play Indoor Softball for example (which is not popular enough to warrant it being a specific booking type in the system) - in which case it would have been the fact that it was "indoor" that was important, and probably the surface too (ie, you couldn't play indoor softball on the sand beach volleyball court that this arena also had down the other end of the warehouse). So not sure if that helps, but essentially I think both the booking type and the properties of the bookable area would be things that could drive a customer's decision as to whether they wanted to book. Meaning splitting the activities, the setting (indoor/outdoor) and the surface properties (which again there might be multiple of, so should allow a list so as to avoid combinatorial explosion - eg "Wood floor", "Spring loaded" etc - even the colour might be useful to someone looking to book the area for a photo shoot or a music video, though I appreciate that's not exactly sport based, but none the less the sort of thing people might want to be booking for.) |
|
A few examples of how it works for us: Bookteq
Playfinder We dont mind this element of curation, full automation is a great end goal but perhaps there are challenges to meet first. |
|
We are considering from both the perspective of the operator and the end user. How it currently works within our system for operators.
How it works for end users
The issue we need to address is multiple use spaces and non sports facilities (i.e classrooms for schools). |
|
Some screenshots for the call today:
|
|
Summarising conclusions from the W3C call on 2021-06-02:
Next steps:
Potentially unanswered questions (to answer once list is fully curated, and potentially to be explored during curation):
|
|
Note the |
|
Below are the lists that were referenced on the call above, useful for informing the FacilityType list with relevant entries: From Played
From Playfinder
From imin
Combining these shows the merits of a Facility Type list (and how this differs from the activity list), and the result has a large degree of overlap with the Active Places list above: Example Facility Type list
This indicates that taking another look at the Active Places list and original Facility Type MVP, and this time focussing on deriving a "Facility Type" list rather than a "Surface" list, should yield the result we are looking for. |
|
Looks good to me.
[data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=3D]
…On Tue, Dec 7, 2021 at 8:26 PM Nick Evans ***@***.***> wrote:
Surfacing two lists that were referenced on the call above, useful for seeding
the FacilityType list with the relevant types:
From Played
* Athletics Track
* Badminton
* Basketball
* Cricket
* Cricket Nets
* Football
* Futsal
* Golf
* Hockey
* Netball
* Padel Tennis
* Pickleball
* Racquetball
* Rugby
* Squash
* Table Tennis
* Tennis
* Volleyball
From Playfinder
* Dance Studio
* Drama Studio
* Function Room
* Spin Studio
* Classroom
* Badminton
* Kitchen
* School Hall
* Music Suite
* Multi Purpose Room
* Bar
These could be combined into the following initial Facility Type list, which
could be further augmented with Active Places categories:
Example initial list
* Athletics Track
* Badminton Court
* Bar
* Basketball Court
* Classroom
* Cricket Net
* Cricket Pitch
* Dance Studio
* Drama Studio
* Driving Range
* Football Pitch
* Function Room
* Futsal Court
* Golf Course
* Gymnasium
* Hockey Pitch
* Kitchen
* Multi Purpose Room
* Music Suite
* Netball Court
* Padel Tennis Court
* Pickleball Court
* Racquetball Court
* Rugby Pitch
* School Hall
* Spin Studio
* Squash Court
* Table Tennis Table
* Tennis Court
* Volleyball Court
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
[#1 (comment)],
or unsubscribe
[https://github.com/notifications/unsubscribe-auth/AHP2ZYQEKKGIIPTXFWTYSXTUPZUWLANCNFSM4G3UZMAA].
Triage notifications on the go with GitHub Mobile for iOS
[https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675]
or Android
[https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub].
[https://ci5.googleusercontent.com/proxy/qDk21GuWHxnLLgzo2n49j70Pwyz6cZmfDULY0tpUWpfqlTrASWAjHz8PsPhEKWajAUaezgR5IZMwjintRKuFJzFTMegR6h9FBuxSlcEiAej2SW5LlSRCIkmDqEUeIQcFbAVCWn556w79oTtDBiAFShKUmJSzCI4KY_8ZBI2gZ9YtmL9R1OAlT0EfWJOsIEj9XAMXi4_FHED2FWr4-NOUtDji7jVj5CaNsK82ipDi9A=s0-d-e1-ft#https://github.com/notifications/beacon/AHP2ZYU2GOCKSRZ2QGHQT3LUPZUWLA5CNFSM4G3UZMAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOHLTVVQA.gif]
--
Tom Marley
Co-Founder & CEO
[https://esr-storage.s3.amazonaws.com/images/9751/140845/images/5f870801c1635.png]
c.Played Limited
m.+44 (0) 7930917704
***@***.*** ***@***.***
w.www.played.co [https://played.co]
[https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041b2df1.png]
***@***.***[https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041bf05b.png]
[https://www.linkedin.com/company/11147682/][https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041cb687.png]
[https://twitter.com/playedapp][https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041ddee0.png]
[https://www.instagram.com/playedsports/]
© 2021 Played Limited. This email and any files transmitted with it are
confidential and it may be privileged.
It is intended solely for the use of the individual or entity to whom it is
addressed. Read more [http://www.played.co/privacy]
|
![https://www.linkedin.com/company/11147682/][https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041cb687.png](https://www.linkedin.com/company/11147682/][https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041cb687.png){kind=link}
![https://twitter.com/playedapp][https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041ddee0.png](https://twitter.com/playedapp][https://esr-storage.s3.amazonaws.com/images/9751/140845/icons/601d2041ddee0.png){kind=link}
Following the last calls on the subject, and to aid this discussion and current implementers (including #3), |
and others
How should we support specifying the surface of a football pitch (for example).
One option is to add a
surfaceproperty which can be applied to aSportsActivityLocationThe text was updated successfully, but these errors were encountered: