Re: Latest specification revisions

Hi all,

This is useful input thanks.

I deliberately made the definition of the "*attendeeInstructions*" property
as it stands to cover both use cases, whether its what to bring or where to
turn up, it seems like its still information for attendees. Generally, from
a specification point of view I'm keen to keep to broadly defined
properties and then specialise if there's a need, rather than adding too
many property which can add complexity (and need for further clarifications
on their purpose).

I can see the argument here for wanting to encourage collection of separate
information though. So think there may be a case to separate out. That
said, there's a couple of things to discuss around meeting point.

* If we're capturing instructions for where people should go if they're
attending an Event, then that's a property of the Event, not the Place. The
Place data should (broadly) be unchanging across different Events that are
held there. Attaching a "*meetingPoint*" of "At the Basketball Courts" to a
specific Park might be useful for a basketball team, but not for a running
club.

I think "*"Outside City of London building with Public Toilets Parliament
Hill Fields / Highgate Road""* falls into that category.

* In some cases the examples are actually notes about the Place, for
example a note about a temporary diversion or clarification on how to find
the entrance, e.g. "*Ongoing work at the Totenham FC means access to the
pool...*". In this case the qualification could just be added to the
*description* of the Place, as its relevant to it as a whole.

* And, as Nick (SE) pointed out, in some cases the qualification is
actually indicating a facility within a place. We can already express those
using the *containedInPlace* property. Although I suspect that may be
tricky to handle in existing systems.

It would be useful to know what, if anything, some of the other platforms
support. Does anyone else have examples?

Cheers,

L.


On 26 May 2017 at 11:24, Ben Kirk <ben@imin.co> wrote:

> Just to add to this, the approach we’ve taken with Open Sessions is from
> the angle of prompting providers to describe their sessions in ways that
> attendees told us would make them feel more confident about turning up to
> sessions.
>
> The inclusion of clear meeting instructions was a great example of this,
> where even very simple information such as “report to the main reception”
> helps remove a friction point in an attendee's experience because they know
> exactly what to do when they reach the address of the session. One more
> reason not to go eliminated.
>
> As Nick (imin) says, 'what to bring’ relates to a different type of
> information. Separating this out into its own field should encourage
> providers to give more thought to the way they present their sessions to
> attendees.
>
> Ben
>
> *Ben Kirk*
> imin <http://www.imin.co/>
>
> On 26 May 2017, at 06:38, Nick Evans <Nick.Evans@sportengland.org> wrote:
>
> Nick
>
> On this I support this in principal, but we also need to think about just
> because people provide this data now in this format, it is where we we want
> to get to. Looking at a couple of the examples provided, I would question
> whether we should use them:
>
> - the Tottenham example to me suggests it is instructions for the whole
> venue and not just a specific activity which requires a separate meeting
> point
> - Our Parks - although this example is correct now this is effectively
> linked to a facility in the venue, with facilities being something we look
> at in the future. For example the OS green space dataset has created
> separate polygons/locations for the facilities the park - cafes, pitches
> etc. With some of this being open data.
>
> So again happy in principle but it has to be underlined with some good
> practice guidance so we don't jus accept the status quo at the moment and
> give direction as to how the data should ideally be provided (including
> descriptions) to drive up data quality.
>
> Sent from my iPad
>
> On 25 May 2017, at 23:39, Nick Evans <nick@nickevans.io> wrote:
>
> Hi all,
>
> Apologies for missing the last call. There is one issue I'm keen to raise
> with regard to "attendeeInstructions". I'd like to suggest the definition
> in the Editor's Draft of "Provides additional notes and instructions for
> event attendees. E.g. more information on how to find the event, what to
> bring, etc." is too broad.
>
> I'd propose that we split this out so that there is a specific
> *meetingPoint*, designated as a relatively short, snappy description as
> is currently the case in the data of GoodGym <http://data.goodgym.org/>, Open
> Sessions <http://data.opensessions.io/>, Our Parks
> <http://data.ourparks.org.uk/>, and British Cycling
> <https://github.com/openactive/activation/issues/5>. We then use
> attendeeInstructions to cover "what to bring or be prepared for". Such long
> form attendeeInstructions are currently available within GoodGym
> <http://data.goodgym.org/>, and Open Sessions
> <http://data.opensessions.io/>.
>
> I'd suggest that *meetingPoint* is key for events that do not occur in a
> specific venue, or where the venue is sufficiently large (e.g. a stadium or
> park).
>
> Semantically the attendeeInstructions are likely to be *important* so
> that the attendee brings the right equipment (though for many sports the
> equipment required - e.g. a towel for swimming, or trainers for running -
> is well known), by contrast the meetingPoint will be *essential* for
> anyone who has not been to the location before, regardless of their
> previous experience with the activity.
>
> Note these examples of meetingPoint values from existing data sources that
> already provide this data (added to the original proposal above too for
> clarity):
>
>    - *"Be careful – this is different to 289 Cambridge Heath Road. The
>    Arch gallery is 200m south of Cambridge Heath Road rail station, and north
>    of Bethnal Green tube. The Arch Gallery is hard to spot, look out for the
>    zebra crossing right outside the door." *(GoodGym)
>    - *"Ongoing work at the Totenham FC means access to the pool are from
>    the Northumberland Park road end of worchester avenue side entrance of the
>    school. Access is signposted inside of building with on site staff in case
>    of emergencies"* (Open Sessions)
>    - *"Basketball Courts"* within the specified park (Our Parks)
>    - *"Outside City of London building with Public Toilets Parliament
>    Hill Fields / Highgate Road"* (British Cycling)
>
> The other difference is that meetingPoint is a property of the *Place*,
> whereas attendeeInstructions is a property of the *Event*.
>
> I've added such a proposal for meetingPoint to the beta namespace, with
> the associated discussion here
> <https://github.com/openactive/ns-beta/issues/10>.
>
> I'd suggest for tomorrow's Candidate Specification we either make existing attendeeInstructions
> more specific by changing the example in the spec to e.g. "Provides
> additional notes and instructions for event attendees. E.g. what to bring,
> are there lockers available.", or move attendeeInstructions into beta for
> further discussion along with meetingPoint, and leave it out of the Candidate
> Specification for now.
>
> Hope this helps,
>
> Nick
>
>
>
> On Wed, May 24, 2017 at 4:44 PM, Leigh Dodds <leigh.dodds@theodi.org>
> wrote:
>
>> Hi,
>>
>> If anyone has feedback on these, can you let me know by Friday? Otherwise
>> I'll promote the editors draft to be the latest version of our Candidate
>> Specification.
>>
>> Cheers,
>>
>> L.
>>
>>
>> On 19 May 2017 at 17:39, Leigh Dodds <leigh.dodds@theodi.org> wrote:
>>
>>> Hi,
>>>
>>> I've just pushed out some revisions to the specification relating to our
>>> discussions around more information for participants and disability support.
>>>
>>> As we have several organisations starting to implement the specification
>>> I thought it was time to more clearly separate out our internal editors
>>> draft from the latest version of the specification. This gives us some
>>> space with make changes without impacting adopters.
>>>
>>> The 28th March Candidate Spec continues to be available at:
>>> https://www.openactive.io/modelling-opportunity-data/
>>>
>>> We also now have a separate Editors Draft which is available at:
>>> https://www.openactive.io/modelling-opportunity-data/EditorsDraft/
>>>
>>> This is also linked from the main specification.
>>>
>>> I've included a summary of the changes below. Please take a look and let
>>> me know if you have any feedback, we can also discuss at our next call. If
>>> we're happy with the changes then these can be promoted to the published
>>> specification.
>>>
>>> I suggest we get into the habit of agreeing any pending changes during
>>> our regular calls.
>>>
>>> The Editors Draft includes the following changes:
>>>
>>> * Revised section 5.3 to document new property for attendee instructions
>>>   https://www.openactive.io/modelling-opportunity-data/Edito
>>> rsDraft/#identifying-and-linking-resources
>>>
>>> * Added section 5.5.6 on describing event availability
>>>   This documents use of 2 additional Schema.org <http://schema.org/>
>>> properties
>>>   https://www.openactive.io/modelling-opportunity-data/Edito
>>> rsDraft/#describing-event-availability
>>>
>>> * Added section 5.5.7 on indicating event status
>>>   This documents use of the schema.org eventStatus property
>>>   https://www.openactive.io/modelling-opportunity-data/Edito
>>> rsDraft/#indicating-the-status-of-an-event
>>>
>>> * Added section 5.5.8 on disability support
>>>   This documents use of 2 new custom properties
>>>   https://www.openactive.io/modelling-opportunity-data/Edito
>>> rsDraft/#describing-support-for-disabilities-at-events
>>>
>>> * Revised Section 5.7 to reference new oa:leader property
>>> https://www.openactive.io/modelling-opportunity-data/#descri
>>> bing-organisers-code-schema-person-code-and-code-schema-orga
>>> nization-code-
>>>
>>> * And some minor changes:
>>>  * Fixed broken link in Event table
>>>  * Removed editorial note in the Section 5.3
>>>
>>> Cheers,
>>>
>>> L.
>>>
>>> --
>>> Leigh Dodds, Senior Consultant, theODI.org <http://theodi.org/>
>>> @ldodds
>>> The ODI, 65 Clifton Street, London EC2A 4JE
>>>
>>>
>>
>>
>> --
>> Leigh Dodds, Senior Consultant, theODI.org <http://theodi.org/>
>> @ldodds
>> The ODI, 65 Clifton Street, London EC2A 4JE
>>
>>
> The information contained in this e-mail may be subject to public
> disclosure under the Freedom of Information Act 2000. Additionally, this
> email and any attachment are confidential and intended solely for the use
> of the individual to whom they are addressed. If you are not the intended
> recipient, be advised that you have received this email and any attachment
> in error, and that any use, dissemination, forwarding, printing, or
> copying, is strictly prohibited.
>
> ------------------------------
> This email has been scanned for email related threats and delivered safely
> by Mimecast.
> For more information please visit http://www.mimecast.com
> ------------------------------
>
>
>


-- 
Leigh Dodds, Senior Consultant, theODI.org
@ldodds
The ODI, 65 Clifton Street, London EC2A 4JE