Should equipment be

• a simple textual description -- fairly limited
• a controlled vocabulary -- allows for some structure
• modelling in some way, e.g. as as oa:Equipment class -- may be more detailed than required for simple discovery use cases

From Nick Evans:

Activities, more likely formal activities, also include disciplines – e.g. Swimming disciplines are Olympic, >Open water, Freestyle, Backstroke etc – this appears to fit with the need for categories or sub categories

Should disciplines just be a group/collection of Activities or are they more formally defined?

The repository description has a typo - currently says "Repository for the Modelling Oppportunity Data specification"

Should be changed to "Repository for the Modelling Opportunity Data specification"

Source: GO Mammoth, Better, Fusion, activeNewham

Useful to have the price, name, and URL of specific offers (this is just pulled from schema.org)

With thanks to @dolkensp for reporting this issue.

EXAMPLE 19: Locating a leisure centre is missing "type": "GeoCoordinates"

  "geo": {
    "latitude": "51.3816123",
    "longitude": "-2.3544367"
  }

Should be

  "geo": {
    "type": "GeoCoordinates",
    "latitude": "51.3816123",
    "longitude": "-2.3544367"
  }

Current availability for facilities, e.g. booking table tennis tables and squash courts, is more complex than that for events. Facilities tend to be booked in slots. While these could be modelled as individual events, there may be other options to explore.

What attributes do we need to capture about Programmes?

Name, description, and images as branding elements are already covered by Schema.org. Do we need more than this?

Schema.org doesn't currently have general terms to cover the following ways to categories events:

• Restrictions: e.g. gender, age, membership restrictions
• Suitability: e.g. level of fitness, experience
• Pre-requisites: e.g. membership, equipment needed
• Categorisation: e.g. intensity of session, activities involved, programme followed

We should work to define these within Schema.org

Source: Better, Fusion, activeNewham

For data publishers not wishing to disclose the granular availability of their sessions openly, this property offers 3 options:

• "available" - More than 5 spaces are available
• "limited" - 5 spaces or less are available
• "none" - 0 spaces are available

Add some more examples to the specification, including:

• Activities
• Programmes
• Recurring Events
• More fully described events to illustrate #3

Include examples from specific domains, e.g. cycling?

Probably best to set up another repo with github pages. Can include a HTML+RDFa view of the terms, plus a custom JSON-LD context, etc.

This is probably a dumb question, but after mapping opportunity properties to different schema.org types and extensions thereof, how do we get to representing a full class model for an opportunity and from there to data schemas in a variety of formats (eg XSD, JSON schema, CSV on the web, ...)?

It would be really helpful to have a beta namespace in order that additional properties can be implemented by data publishers while waiting for the next version of the spec.

To satisfy this requirement we have created a beta namespace: http://www.openactive.io/ns-beta/

Should this be included in the spec?

The example shows a type "Person" with organisation details (should be either type "Organisation", or more relevant details):

"organizer": {
    "type": "Person",
    "url": "http://example.org/orgs/bristol-tai-chi",
    "name": "Bristol Tai Chi"  },

From Nick Evans:

Clubs - Can we put a retainer in for defining clubs? Evidently they link across to a lot of the other areas >>such as place, activities, format etc. and could be seen as the organiser within 3.1. Queries around this >>are bound to emerge when discussing with NGBs about publishing lists of clubs as open data etc.

Coaches and Volunteers - Can we also put down retainers for these even if we are not defining them at this stage

Clubs are examples of Organisers. These should be called out in the key concept section.

Schema.org also has contributor which could be used to refer to coaches and volunteers.

Source: Fusion, Better

For offers that are for a particular age group (e.g. "Junior non-member"), include an age range to which this applies.

For example:

  "offer": [
    {
      "name": "Senior non-member",
      "price": "6.60",
      "priceCurrency": "GBP",
      "ageRange":"60",
      "type": "Offer"
    },
    {
      "name": "Adult non-member",
      "price": "6.60",
      "priceCurrency": "GBP",
      "ageRange":"16-59",
      "type": "Offer"
    },
    {
      "name": "Junior non-member",
      "price": "6.60",
      "priceCurrency": "GBP",
      "ageRange":"0-15",
      "type": "Offer"
    }
  ]

Just interested in the rationale behind this... Why have we created a new property oa:ageRange, and what's the difference from typicalAgeRange (also on an Event)?

Events involving physical activities can be organised and run in different ways. The specification currently refers to these as "Formats":

https://www.openactive.io/modelling-opportunity-data/#format

An alternative, and possibly better known term is "Programme"

However in some discussions, its clear that Programme may also be used to refer to a "campaign", e.g. a long running series of events or promotional activities. Campaigns are outside the scope of the opportunity data specification.

Would it better to just use Programme and clarify that campaigns are different?

Source: SportStarta, Our Parks, GoodGym

Proposal

For events that have an unlimited number of tickets, capture the number of attendees (actual attendance).

https://github.com/openactive/ns-beta/issues/12

If you are an implementer looking to provide feedback on the use of this term, then please follow the link to the proposal and leave comments there

How are you testing?

• What we're testing: Requesting feedback from implementors who find this property useful, both as a data provider and data consumer. Mainly from those who have an unlimited number of tickets.
• Who is testing: SportStarta, Our Parks, GoodGym, British Cycling

Example Data

{
  "@context": "https://www.openactive.io/ns-beta/oa.jsonld",
  "type": "Event",
  "beta:attendeeCount": 42
}

Should cover:

• Ability to add new properties in JSON-LD
• Adding new Schema.org properties
• Conformance criteria for the specification will be flexible
• Consumers should be generous in what they expect

Property: meetingPoint
Source: GoodGym, Open Sessions, Our Parks, British Cycling
Domain: Place

A brief description of where to meet - especially useful for outdoor activities where the postcode and address is not sufficient.

Examples:

• "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" (Our Parks)
• "Outside City of London building with Public Toilets Parliament Hill Fields / Highgate Road" (British Cycling)

Based on discussion from 26th April. See notes.

• event capacity, and current capacity
• event status, e.g. for cancellation
• instructions for attendees
• event leader/coach as distinct from organiser or contributor
• document use of schema.org offers for capturing prices, payment methods, etc
• revise primer to include more guidance and notes around sharing of contact information

The majority of these can build on existing schema.org markup

The description doesn't match for the following (i talks about schema:Person):

Source: GoodGym, Better

Sometimes a description is stored with formatting (e.g. href, bold, italics, embedded YouTube videos). This formatting can be useful for data consumers.

Source: Playwaze

https://schema.org/logo used within organizer - recommended PNG logo

Helpful for data consumers who want to display a logo for the organiser of the session

Source: GoodGym

Array of https://schema.org/ImageObject - versions of the main image with different dimensions, useful for situations where photos are manually cropped by users to match. Width and height should be included for each.

(Should be OpenActive for branding consistency)

Examples include within:

• Initial copyright statement
• Abstract (x2)
• Status of This Document
• Introduction
• 1.3 Scope
• A. Acknowledgements

Source: Bookwhen

For events that specify a schedule, where the Offer or Event url applies to each occurrence in the schedule, a urlTemplate allows a user to be linked directly to the relevant page for that occurrence. Value of urlTemplate should be of type http://schema.org/urlTemplate.

Example use:

"beta:urlTemplate": "https://bookwhen.com/bounce/e/ev-sird?startDate={startDate}"

Process is currently manual, need to build and push to gh-pages branch.

Summary of discussion and requirements here.

Actions:

• Create new small SKOS vocabulary of terms for describing disability
  support, based on the current commonly used terms

• Add a new "disability support" property for categorising support available at an opportunity

• Add a new description property for events to specifically capture notes

• Revise primer to include examples of using the above, and also recommendations, such as clear contact points, etc.

Schema.org doesn't currently handle recurring or scheduled events. There has been a number of discussion and proposals but not have yet been finalised.

For our use cases we need to publish and share the schedule and not just the individual sessions.

The proposal is to document a general purpose schedule property as suggested here.

Source: GoodGym, British Cycling, Run Together

Useful to know the distance of a run, cycle or other activity. Value of distance should be type of http://schema.org/QuantitativeValue, with a variation to allow for a "range" to be included instead of a "value" for circumstances where only a range is captured.

Example 1:

"distance": {
  "value": 6,
  "unitCode": "KMT"
}

Example 2:

"distance": {
  "range": "0-5",
  "unitCode": "KMT"
}

Range examples:

• "0-5" - 0 to 5 inclusive
• "5" - 5 exactly
• "50+" - 50 and above

Popular UN/CEFACT Common Codes for Opportunity Data:

• MTR - metres
• KMT - kilometre
• SMI - mile

Source: GO Mammoth, Better

For memberships, it is useful to know the frequency associated with the cost within an offer. E.g. "monthly" or "annual". This allows the data consumer to display and filter on memberships accordingly.

Assuming that oa:leader values are expected to be of type http://schema.org/Person - I can't find this actually written anywhere, either in the namespace or the spec? Might be worth including in the primer too?

We will probably need to describe facilities at venues. E.g. that there are table tennis tables that a sports club. Schema.org has an amenityFeature which can be used to list facilities.

• Is this sufficient?
• Do we need a controlled vocabulary?

For the additional event properties #3 we will need some controlled vocabularies. These may be published by individual publishers or defined across the sector.

We need to decide how to publish these vocabularies, ideally following SKOS and in line with External Enumerations

I’d like to clarify how an activity* from one of possibly many activity lists is expected to be referenced. (And hope this isn't a stupid question.)

The data model shows that an event has an “activity” and I understand that activities are expected to come from SKOS lists.

Will every activity therefore have a URI from which its conceptScheme (and other properties like broader and narrower activities) can be derived?

If activities are referenced by multiple lists (of activity types, surfaces, etc) in the absence (at least initially) of one common list, will every list owner be expected to express its list as a SKOS concept scheme with a standardised approach for de-referencing?

FYI, in looser local government work (oten using CSV as a data exchange format) we’ve asked data publishers to describe concepts with as many of these properties as they can:
• Label – a text title / name
• Scheme – a text reference (a kind of namespace) from which a scheme can be identified
• Base URI – the stub of the concept URI, which might be the URI of the whole concept scheme
• Code – the final part of the URI
• Full URI – a concatenation of the above two, which should be sufficient if it exists and is dereferencable

'* BTW I understand “activity” to mean “activity type” (and have learned from experience of people discussing the SKOS lists that esd-standards maintains that each of our SKOS lists describes types of thing) .

Worth doing a find-replace on "Open Active" (case insensitive) and replacing with "OpenActive" throughout

Source: GO Mammoth, Better, Fusion, activeNewham

Whether the activity is "beginner", "intermediate", or "advanced". Perhaps there should be some discussion about the most generic categories that make sense here, and a way of using that, but also using a label specific to the activity. For example for martial arts you might have "blue belt and above, and "red belt and above" both as display labels, with the standard category of "intermediate" to allow searching across sports.

Source: SportStarta, Our Parks, GoodGym

To differentiate registration and attendance, adding registrationCount

Registration records participants’ intention to attend.

Attendance records participants’ actual presence at an event.

To make it clearer for those glancing through the spec, include "logo" in Example 21

"If the status property is not provided then applications should assume that a default "scheduled" status. The following example shows a Tai chi class that has been cancelled:"

We should collect and publish more example data about activity lists.

Related to 4 and the use of External Enumerations

For example, how does Publisher X say they are using their own terms, whereas Publisher Y is using an industry standard vocabularies?

Does this fall out from the URIs used in the data, or can they be declared in some form, e.g. in a JSON-LD context?

https://www.openactive.io/modelling-opportunity-data/#relating-events-to-physical-activities

Include something like the following in the spec to make it more explicit: "Note you only need to include id, prefLabel, type and inScheme as a minimum set of properties within the activity, as a consumer can pull the skos:definition etc from the referenced activity list. prefLabel could be pulled from the activity list, but is included for consumer convenience.

Minimal example:

    "activity": {
      "id": "http://openactive.io/activity-list/#cb174be9-744b-46ff-b5b8-623257590b0d",
      "type": "Concept",
      "prefLabel": "Canoe Polo",
      "inScheme": "https://www.openactive.io/activity-list/activity-list.jsonld"
    },

Source: GoodGym, Open Sessions

Boolean representing whether or not a session is coached. Note that the coach name is not always specified, and this is different to having a "leader", as the leader may or may not be a coach.

Example:

"hasCoaching": false

The Health & Life Science extension to Schema.org defines a PhysicalActivity and a
PhysicalActivityCategory type. These are broadly relevant to our needs, but may need to be extended with other terms.

How does this fit within Schema.org?

Include explanation of why we're using "type" and not "@type" (as schema.org examples mostly use the latter)

From Nick Evans:

In Active Lives we capture Setting, which describes where the activity is taking place - I.e. is it indoor or >outdoor? There is then a set of defined settings that you could allocate to the location, e.g. Indoor >examples are shown below:
At Home
Leisure/Fitness/Sport Centre or Gym
Community Centre or Village Hall
Specialist Facility

Should we be capturing setting as a descriptive property of an event? If so, then we should recommend a set of legal values. This would make it easier to filter/search by settings.

Alternatively, settings could be added as tags associated with an Event. This is simpler, but is more limited.

Related is:

Other event properties could include:
· Activity Style – e.g. Group, 1 to 1, Individual
· Activity Structure – e.g. formal or informal. Formal could include Club Training session, Coached >session, Competition, while Informal could include Holiday, Social
· Purpose – e.g. Leisure, Competition, Training, Commuting

Should all of these be additional properties, or just handled as tags?