-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handling generic descriptive terms for activities #23
Comments
@howaskew option 2 sounds more sensible to me. There are many scenarios where additional tagging would be useful and this is a good time to utilise it. We use 'collections' in a number of activity finders, which are a useful way of grouping activity types together. However, it would be useful to be able to create collections for things like 'GP referral' which could have different parameters for what meets those requirements outside of activity type. From a data publishers perspective, any additional steps when listing an activity (a) creates work for publishers, (b) adds another step to the providers listing experience, I would aim for working with the data that is already present (maybe through keywords in descriptions). From a data consumers perspective, more flexible categories and a search experience would be a nice to have - although I would say that this could be handled through other mechanisms (like keyword search, collections etc) that did not add additional work for publishers or providers. Have added some commentary to those specific examples below; Low Impact Exercise for Health - there is already a collection for 'Low Impact' which groups together activity types that are deemed 'low impact' like Walking, Seated Exercise etc. We originally created a collection for this - which you can see a reference to in the 'Walking' concept, although the link no longer works SEND Activities: This is an important one for us, although I feel that this could be something that is handled by 'accessibility'? However, more flexible collections could enable a collection to be created using various accessibility data points and activity types / providers for example. Adaptive Games: This seems the most like a genuine activity type which would be useful to include in the list, it also may be possible to create a collection based on other data points that already exist. GP Referral: Would be useful to see an example of this type of activity and a bit more info about the use case? Pups on SUPs: This is just a name of a session, not an activity type. The activity type is Stand up Paddle boarding. Could be better handled through a category. |
Issue
There have been several activities submitted for addition to the list that include terms that could potentially apply to many activities. Examples include:
Low Impact Exercise for Health: Low-impact can refer to any activity that doesn’t place a lot of strain or weight through the joints.
SEND Activities: SEND stands for "Special Educational Needs and Disabilities", and refers to activities which are inclusive of children and young people with learning disabilities.
Adaptive Games: Activities which are adapted to make them inclusive of participants with specific needs.
GP Referral: Activities which are specifically for people who have been referred by their GP.
Pups on SUPs: Activities where participants are welcome to bring animals. In this case, stand up paddle boarding with dogs.
The primary aim of the activity list is to facilitate search, and we try to include terms that will support effective searching, though we should consider the implications of the list becoming significantly longer.
Options
Option 1: We include ‘versions’ of activities in the activity list as separate concepts.
For example, we add concepts for ‘SEND rugby’, ‘SEND football’, ‘SEND cricket’, etc as they are requested or as they emerge as common search terms.
This may simplify search, allowing users to use specific terms to hone in on appropriate activities.
However, it will extend the length of the list significantly over time. We are interested to hear from data publishers and data consumers about potential issues this may cause.
Option 2: These ‘versions’ or attributes of an activity are reflected elsewhere in the OpenActive specifications.
As with age, level, and gender restrictions, there may be alternative approaches to reflect the intended audience for an activity.
The oa:category property can be used to provide a set of tags that help categorise and describe an activity...
The oa:accessibilitySupport and oa:accessibilityInformation properties can be used to specify the types of disabilities or impairments that are supported or to provide additional, specific documentation for participants about how disabilities are, or can be supported.
There is also the more detailed extension of the Accessibility Support datatype proposed by Tim Hill for use in cases where accessibility provision is good and data-collection practices are strong.
Again, interested to hear from data publishers and data consumers on the challenges associated with this approach.
For example, can publishers envisage processes to populate the above fields? Do consumers feel they can present such information in search interfaces in a useful format to improve search?
Also keen to hear ideas for any alternative approaches.
The text was updated successfully, but these errors were encountered: