Re: Latest specification revisions

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<mailto: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<mailto: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<mailto: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/EditorsDraft/#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/EditorsDraft/#describing-event-availability

* Added section 5.5.7 on indicating event status
  This documents use of the schema.org<http://schema.org> eventStatus property
  https://www.openactive.io/modelling-opportunity-data/EditorsDraft/#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/EditorsDraft/#describing-support-for-disabilities-at-events

* Revised Section 5.7 to reference new oa:leader property
https://www.openactive.io/modelling-opportunity-data/#describing-organisers-code-schema-person-code-and-code-schema-organization-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
---------------------------------------------------------------------------------------