Proposal: Consistent levels #82
imin and EMD
When presenting data from multiple sources, inconsistent levels become a problem for both display and filtering.
Why is this not covered by existing properties?
The existing model allows free-form levels, which does not allow for easy categorisation.
Please provide a link to example data
England Netball has "beginner".
SportStarta have published their level data: http://www.devapi.lewishamparklife.co.uk/api/concepts/level
British Cycling uses "Easygoing", "Steady" and "Challenging".
ClubSpark has "All" for many sessions.
The priority is to agree a standard way to represent a beginner or entry level session (which is one of the main objectives of OpenActive). It would also appear that language around some notion of both "intermediate" and "advanced" is common. Expressing mixed ability / "open to all" would also be useful.
Similar to amenityFeature it is useful to allow a custom label ("Easygoing") as well as a defined term (Beginner).
It is also useful to mark sessions as catering for multiple levels e.g. '"Beginner and Intermediate"
As a starter for 10:
The text was updated successfully, but these errors were encountered:
Would a level rating (0-100) perhaps work better here?
So internally the systems might rank "EasyGoing" as a 0-30, "Moderate" as a 30-70+, and "Hard" as a 70+
This would allow external consumers with more, or less levels, to set their own boundaries against a scale of 0-100.
0-50 / 50-100 split for Easy/Hard - or more granular splits if you offer more elite courses perhaps?.
This is similar to the way font-weights work (see here for reference) in that there are "well known" values (400 for normal, 700 for bold), but then if the systems (fonts) support it, you can get lighter and heavier weights too, with reliable fall-backs.
On the basis that every source seems to have some notion of easy, medium, hard: define an approach where the names can be customised for specific types of activities or data sources, within standard types for "Beginner", "Intermediate", and "Advanced". Data users can then choose to display consistent labels or the provider's own labels.
We could also include a difficulty value on each for the case where multiple are supplied, as @dolkensp suggests. This is similar to defining "Bold" as 700.
To allow for the simplest implementation of this:
This gives room for 3 levels within each level, if required.
This also allows for transparency what will likely appear under what filter in a user's experience e.g. there might be 8 levels of a martial art, where 5 are considered advanced, and helps with validation.
So suggested mapping to fonts:
Additionally in terms of validation (providing a range of 300 on each):
The other nice property of this 50-950 range is that you can create a scale of 1-10 difficulty score out of it quite easily with Math.round(difficulty/100).
So simple case:
Simple case with custom labels:
Custom labels and more than 3 levels:
What do you think @ldodds? Given most sources have 3 levels are we overcomplicating this, and should we have them use the names alone to differentiate between levels where there are more than 3? But does that limit potential uses of the data?
I guess the aim here is to create uniformity across disparate data sources for simple aggregation use cases without losing potentially useful granularity for more complex / interesting use cases?
I'm wondering about the extent to which any difficulty level needs to be extensible. Off the top of my head/doing some quick Googling, it doesn't take long to start hitting edge cases - which makes me think they're not really 'edge cases' at all.
One way to deal with this would be to view difficulty rating as a hierarchy, with 'Easy', 'Intermediate' and 'Difficult' as top-level terms. As a data-publisher, I would want to be able to use my own terms and either map them or subordinate them to these broad catch-all terms; as a data-consumer, I might also want to be able to see a definition of these terms, how standardised they are, and/or a URL to where they are defined.
For example, for the sport of Aikido:
Intermediate has narrowerTerm 3Kyu, with definition "have at least 50 days experience", asRecognisedBy "The International Aikido Federation" and described in more detail at http://www.aikikai.or.jp/eng/information/review.html.
Easy has narrowerTerm Dolphin with definition "Has completed BSAC Dolphin certificate' as recognised by Organisation "The British Sub-Aqua Club' and described in more detail at 'https://www.bsac.com/training/snorkelling-courses/'
Another open question is how we relate this to age-ranges: it's often the case (as in the snorkelling example above) that there's a distinct category of skill-levels and certifications for children. We'll need to think about how we capture these cross-cutting concerns.
Reviewing the initial proposal again, it seems like there's two broad use cases:
I think A requires us to:
There's also an argument to be made for having a simple beginner/intermediate/advanced set of levels for people that have very simplistic classifications. But at @thill-odi its not clear how widely used that is. I'd recommend exploring usage of the
To handle B, it may be that a standard set of levels will help meet this requirement. Although I note in the comments that we have several distinctions:
So I'm wondering if instead we defined these terms as a controlled vocabulary and recommend that they are used for the
The recommendation would be that Events should have at least one value for
Reviewing the thread so far:
Given that some set of broad terms used across all activities is evidently a useful thing to have, and that more specialised terms are also useful and frequently encountered, much of the above discussion is substantially about how we map these more specialised terms to the general terms. Broadly speaking, the approaches suggested fall into two camps:
So, for the sake of example, the first might look something like this:
The second might be:
(@ldodds might spot that this is basically what he wrote, but that the implicit equivalence in the examples he gave above is now explicit).
The advantages of the former approach are that:
The advantages of the latter are:
Does this sound like a fair summary of the thread and the issues it raises so far?
Couple of additional comments:
The other thing that I think is missed in your summary @thill-odi is that I was proposing:
Reviewing and collating the evidence above, in the prerequisites issue, as well as some of the feedback from the questionnaire, I come up with this list:
Reviewing this, and surveying the population of
@thill-odi as the thread above seems to cover quite a bit of ground, would it be possible to summarise the proposal that your analysis indicates is the best way forward? Including a couple of examples? This will make it easier to review / discuss?
The proposal would be, first, to define a small controlled vocabulary consisting of the terms
Sure - So for example, from EMD UK’s perspective: “Intermediate” and “Advanced” would both be narrower terms of “Experienced”? Is it worth including these in the official OA list as they are so common?
Ok great, and I guess we’ll need to clearly define “No Experience Required”, “Beginner” and “Open for All”?
Does the “Open for All” distinction basically mean “we don’t have levels for this activity”?
Happy with this as discussed on previous w3c call - we are being asked for this feature within our products by a few customers and would make it easier for people to find the suitable activity for their level so we definitely support this alongside our customers and the spec proposed.