openactive / modelling-opportunity-data Goto Github PK
View Code? Open in Web Editor NEWOpenActive Modelling Opportunity Data specification
Home Page: https://www.openactive.io/modelling-opportunity-data/
License: Other
OpenActive Modelling Opportunity Data specification
Home Page: https://www.openactive.io/modelling-opportunity-data/
License: Other
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"
}
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.
Process is currently manual, need to build and push to gh-pages branch.
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?
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?
(Should be OpenActive for branding consistency)
Examples include within:
Should equipment be
oa:Equipment
class -- may be more detailed than required for simple discovery use casesWorth doing a find-replace on "Open Active" (case insensitive) and replacing with "OpenActive" throughout
Source: SportStarta, Our Parks, GoodGym
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
{
"@context": "https://www.openactive.io/ns-beta/oa.jsonld",
"type": "Event",
"beta:attendeeCount": 42
}
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?
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?
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"
}
]
Should cover:
We should collect and publish more example data about activity lists.
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.
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) .
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?
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.
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" },
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 availableSource: 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}"
"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:"
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, ...)?
The description doesn't match for the following (i talks about schema:Person):
schema:schedule | optional | A schema:Person, e.g. a coach, staff member or volunteer who will be helping to run the event. **Note: this is a draft Schema.org property. See Issue) for discussion. |
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.
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"
},
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)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
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?
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.
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.
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.
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.
Based on discussion from 26th April. See notes.
The majority of these can build on existing schema.org markup
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.
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 abovePopular UN/CEFACT Common Codes for Opportunity Data:
MTR
- metresKMT
- kilometreSMI
- mileInclude explanation of why we're using "type" and not "@type" (as schema.org examples mostly use the latter)
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)?
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
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?
Source: GO Mammoth, Better, Fusion, activeNewham
Useful to have the price, name, and URL of specific offers (this is just pulled from schema.org)
To make it clearer for those glancing through the spec, include "logo" in Example 21
Schema.org doesn't currently have general terms to cover the following ways to categories events:
We should work to define these within Schema.org
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.
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?
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
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"
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.