search

openactive / place-types

Place Types controlled vocabularies data and documentation
0 stars 0 forks source link

Proposal: Controlled vocabulary of Place types #1

Open thill-odi opened 2 years ago

thill-odi commented 2 years ago

Proposer

Playwaze

Use Case

As an end-user, I would like to be able to filter my search results by the type of organisation putting on an event. For example, I would like to be able to filter to include only sports clubs, leisure centres or facilties.

Why is this not covered by existing properties?

There's nothing explicitly stated in the Opportunity specification itself. Conceivably the schema.org additionalType property could be used.

Please provide a link to example data

Check the 'I'm looking for ....' dropdown on https://activelincs.wpengine.com/find-activities/

Proposal

As noted above, schema:additionalType might be a candidate here in terms of the property used. We'd also ideally have a controlled vocabulary listing permissible values (e.g. 'Leisure Centre', 'Facilities', 'Sports Club', etc).

nickevansuk commented 2 years ago

See similar requirement from MCR, which they've implemented in a custom namespace using a custom mcr:placeClassification property, with values as below:

Type Value Description
mcr:PlaceClassification https://data.mcractive.com/ns#EducationCampus Place is the campus of an educational institution
mcr:PlaceClassification https://data.mcractive.com/ns#LeisureCentre Place is a leisure centre
mcr:PlaceClassification https://data.mcractive.com/ns#OpenSpace Place is an open space
mcr:PlaceClassification https://data.mcractive.com/ns#Park Place is a park

See here for more information: https://mcractive.github.io/ns/

nickevansuk commented 2 years ago

I wonder though whether another SKOS controlled vocabulary (as the title of this issue suggests), similar to the activity list, is a better solution here - rather than either an enumeration (as in MCR above) or set of classes (as schema:additionalType would require).

The advantage of a SKOS controlled vocabulary is that it is easy to maintain, and open to new additions much more easily than either an enum or classes. Enum/classes would need to be formalised in the Modelling Spec (as with Amenities), whereas the SKOS controlled vocabulary exists independently.

Looking at other examples of where such "place classification" has been attempted (such as Google Maps "Place types"), it seems that what we're inherently trying to model here is broader than a few simple options that could live inside the spec itself, even if it might initially look like a short list based on the narrower use cases of individual implementers.

nickevansuk commented 2 years ago

Combining the above with the list from @charlieclarke5 for values relating specifically to a Place, we have the following initial proposed list of Place types:

nickevansuk commented 2 years ago

A placeType beta property has been added as agreed on the W3C call on 2021-12-06, and an initial corresponding SKOS controlled vocabulary created at https://github.com/openactive/place-types

(Class) Property Expected Type Description
(schema:Place)
beta:placeType		 Array of skos:Concept The type of Place. See https://openactive.io/place-types/.
nathansalter commented 2 years ago

I wonder though whether another SKOS controlled vocabulary (as the title of this issue suggests), similar to the activity list, is a better solution here - rather than either an enumeration (as in MCR above) or set of classes (as schema:additionalType would require).

I think this makes a lot of sense. It's a real bonus just having the activity list when adding new activities. Also would allow for additional types to be added with relative ease both as part of the list, or as optional extensions for different implementions.

nickevansuk commented 2 years ago

It was raised on the call yesterday that we need to be careful to consider overlap with FacilityType list, so as not to confuse the user.

On reflection, the following have the potential to overlap with specific instances from the FacilityType list:

However a broader term could be used for this:

Note that a FacilityType of “Ice Rink” would only be used to book the whole ice rink. Therefore it is unlikely to be used as a FacilityType, and more likely an “Ice Skating” session (from the activity list) would be used to book an individual ticket for entry. “Gym” is also not a FacilityType as it would also imply booking the whole Gym. “Gym Workout” is an activity.

Hence guidance could be added to use terms that are obviously associated with a Place rather than a Facility.

Based on the analysis above, provided we define the terms correctly, the overlap issue becomes an edge case. It is then the responsibility of the Brokers to present any place-based searching and filtering correctly.