Re: OpenActive - Describing Events request for comments and comments on updated Modelling Opportunity Data Spec

Hi Nick,

Thanks for the feedback. A couple of comments on a few points.


On 8 March 2017 at 08:51, Nick Evans <Nick.Evans@sportengland.org> wrote:

> Hi Leigh
>
>
>
> Following on from the last session and your e-mail, please find attached
> Allison and my comments:
>
>
>
> *which descriptive properties are most relevant for people searching for
> events?*
>
>
>
> We know from the Digital Radish research done for spogo that it the
> activity and location which are important. What we don't know is what do
> they look for next when they click through. Not sure how you could pick
> this up without some further research. A quick way to get an opinion on
> this would be to ask an operators what are the common questions they get
> through via email or on the phone about a session.
>
>
>
> *what are the additional properties of events we need to describe?*
>
> *what controlled vocabularies, e.g. age ranges, fitness levels, etc are
> already in use?*
>
>
>
>
>
> *Potential Areas*
>
>
>
> ·         *Age *Many sports have different age ranges, therefore we would
> not recommend trying to group these. NGBs often change groupings over time
> particular around children and young people. This should be really be a
> simple Start age and an End Age, perhaps with an additional category of not
> applicable
>
> ·         *Sex* - Are the sessions mixed, single sex etc.
>
> ·         *Height & Weight* - Some activities may have restrictions on
> weight and Height. An example of this is Go Ape - https://goape.co.uk/faqs.
> So there may be a need to add a minimum height and maximum weight. This is
> evidently only going to apply to some activities
>
> ·         *Price - *cost of session, court hire by hour etc.
>
> ·         *Equipment* - what is required, can it be hired on site
>
> ·         *Entry Leve*l - Something about whether the event is open to
> Beginners. It may be harder to define areas around Intermediate and
> Advanced as these could be very subjective and vary considerably between
> activity.
>
> ·         *Intensity Level* - It may be possible to describe whether the
> activity would be moderate or vigorous in terms of the CMO guidelines, so
> the user would know how it is contributing to their daily or weekly
> targets. Evidently these targets vary between age ranges.
>
> ·         *Free Text* - Most providers will have some form of free text
> field which will describe what they put in. Is it worth providing some
> advice on what other information could be relevant to put in this which
> would be picked up by web crawlers, which could be relevant but not easily
> definable
>


This is a useful breakdown. We can discuss this on Monday, I'd like to get
some opinions on what we want to try and cover from the first version of
specification. We could just focus on activity, location and a description
(free text) as we have in the specification already, but are there one or
two other items we should cover?


>
>
> Evidently there may be further information that would be useful such as
> the session being Coached and then the info about the coach. This is
> evidently not an area that we have looked at yet.
>

Yes. The specification currently allows allows a Coach to be added and some
information about them to be described, e.g. a description, homepage, etc.
But we need to be mindful of personal data here, so my preference would be
to not dig into this for the first version of the specification.


>
>
> *do we need to define some standard values for these properties, or just
> allow people to publish what they currently capture?*
>
>
>
> I think where possible we should provide some standard values and start to
> define these where they are obvious (see above) so that people who are
> developing systems do not have to reinvent the wheel.  In saying this we
> need to be mindful on the time that we could spend on this.  As a starting
> point you could get members to provide lists of what they have done already
> as a reference point.
>

Again, we can discuss Monday but my personal preference would be to treat
these as we are for activity lists: provide a means for people to share
their lists and then look at convergence at a later date.

If there are existing standards, e.g. the CMO guidelines, then we could
look at publishing those openly, at a standard location for people to use.
We don't have to recognise all of them in this specification.


>
>
> *Other Comments on Modelling Opportunity Data:*
>
>
>
> ·         Section 3.1 - Is it worth adding a note here that Coaches and
> Volunteers are not added at this time?
>

Yes, I have a note to add a comment re: personal data.


> ·         Section 3.2 - We thought that there was common consensus at the
> last meeting that people wanted a standard activity list but with
> acceptance that it was something that people would work towards?
>

Yes, that's my understanding too. I don't think the wording disputes that.
>From the point of view of a technical specification, I think we just need
to reassure people that they can start using the data model without having
to, e.g. rework their existing data to match an activity list standard. The
wording in the note is intended to try and convey that.

Is there a better statement I can include?



> ·         Section 3.3. – why is schedule defined – bolded twice here? And
> it states we aren’t defining session, but then we do essentially define it
> in the sentence after the note and reference it a number of times. As
> reworded this section is now quite confusing. The example of the gym class
> also doesn’t help, as most consumers would likely just refer to it as a
> class, rather than a session? Starts to draw out the difference between
> what a consumer would refer to an event as, and what the sector would refer
> to it as – a session and we should seek to overcome this through some
> separate consumer research. Should we clarify whether we are seeking to
> develop a standard for the sector, or for the consumer?
>

The bold is a typo, the text should have been part of the note.

Again, the reference was to session is just there to help guide discussions
as in some of our early research people referred to both events and
sessions. But it's currently present as a note to help illustrate that
Event covers what people also refer to as a session.

I'm happy to remove it completely though if that would be clearer?


> ·         3.3. - Is schedule not just the date/time recurrence?? Are we
> overcomplicating by defining schedule separately?
>


In the data model there's are different properties used for specifying a
date time and a schedule: because they have different values (a date-time
versus a recurrence rule). So this is just introducing that as a concept.



> ·         3.4. – there is a need to differentiate between different types
> of Organisers – or do we mean Organisations here? The schema diagram
> references organisations not Organisers. Need to ensure consistent use of
> language. It’s also important to cater for the fact that the host of an
> event can be different from the arranger, who can be different from the
> funder (I am less clear why funder is important here?) And do we need to
> define to such detailed levels right now?
>

I was using the term organiser here as that matches the relationship
between an event and a person or organisation that is running it.

I'll improve the wording. Funder is referenced as sometimes events are
sponsored? Happy to remove if its out of scope though.


> ·         3.5 – the definitions of place/location/venue feel they would
> benefit from greater definition here – particularly having discussed that
> after activity, place is the thing that people may wish to
> search/understand next. As a* minimum,* we should state that all
> Locations should have a geospatial reference point - post code, lat/long or
> grid reference - a simple address description is not good enough. In
> looking at this in more detail we should go back and look at the Active
> Places data model around this, particularly in relation to facilities
>

I think the detail you're looking for is covered by the Schema.org
documentation that we link to from the data model documentation. Obviously
this can be improved so we reference more of that documentation directly
from our specification. But that does describe:

Place: https://schema.org/Place
Postal Address: https://schema.org/PostalAddress
GeoCoordinates: https://schema.org/GeoCoordinates
...etc

That said, I'm very wary about defining a minimum set of data requirements.
In the initial research we found examples of a wide degree of precision
around how people specify locations. As we support more of the "tail" the
flexibility around how much detail is required might be the difference
between someone publishing data or not.

What I had planned to do is that in the tools that we put together to help
validate data against the specification, we would highlight to publishers
where the lack of specific properties, such as a precise location or other
descriptive properties might make their data less useful or the events less
discoverable.


> ·         Also need to clearly differentiate between built facilities and
> natural environment facilities. The latter will require further input from
> other organisations such as Environment Agency, Forestry Commission, NGB
> natural resource sports etc.
>

Schema.org already defines a number of different types of places, e.g:

Civic Structure: https://schema.org/CivicStructure, which includes Parks
Landform: https://schema.org/Landform, which includes lakes, rivers,
mountains

These terms can be used as is without changing the specification, they're
just different types of Places.


> ·         3.7 – this adds a layer of confusion – are we not just
> referring to the combination of two key concepts here – Activities and
> Events? Rather than creating a new concept we should consider whether
> Events should be renamed Opportunities. I thought this was the suggestion
> from one of the W3C members anyway? Some of this should be picked up under
> the facilities section when looking at actual man made cycling tracks. This
> may benefit from a discussion with someone like Ordnance Survey or Sustrans
> around route information but this is a complicated area and would question
> whether this is a priority for the moment.
>

No, my understanding was that the suggestion was to add a new type of
opportunity, not to rename events. The key point being that an Event always
has a time (or schedule) and a location, whereas these opportunities are
purely location based.

>From a data publishing point of view the only difference will be to
specific a different value for the @type property. So there's not a great
deal of extra modelling or work here.



> ·         Agreed that Controlled Vocabularies would be useful, but we
> should discuss how essential this is to spend time on right now , except
> for the creation of an activity list. Maybe this is a later phase, but as a
> starting point should people be sharing their own controlled vocabularies?
>

This is the part of the model that will allow us to publish these lists,
see e.g. your recommendation to use the CMO controlled vocabulary. We need
to recognise in the specification that there's a data model for doing that.
It's not saying that there's a fixed list we must publish.


> ·         Section 4 refers to People – are we concerned with this yet –
> e.g. Coaches? If so, we should define People in the Key concepts section?
> We conversely refer to People as Person in Section 4?
>
·         4.2. – as referenced above, I don’t think we need to create
> Activity Opportunity
>
> ·         4.3.2. – We are not sure what we mean by describing
> participation requirements? We shouldn’t keep introducing new terms or
> reverting to old terms if we have defined new key concepts?
>

These are the descriptive properties we were discussing. Agree that the
naming is confusing.


> ·         4.7. – Describing Formats feels like it is an extension of 4.3.
> – would a format or programme not just be an attribute/properties/additional
> information of an Event/Opportunity?
>

Yes, they will be. But they may need to be more than a bit of text attached
to an Event, if there is then it needs to be a resource that can have its
own properties.

Cheers,

L.