Types of RDPE feed
These always have at least
activity
, location
and startDate
specified: so a Yoga class in Downtown Leisure Centre, at 7pm, on a Tuesday. See here for further clarification of the types available. The OpenActive Modelling Specification 2.0 represents regular events using a hierarchy of types:
EventSeries
, SessionSeries
, and ScheduledSession
, linked via the superEvent
and subEvent
properties. These are described by example in the diagram below:The
ScheduledSession
will inherit the properties of the SessionSeries
, and the SessionSeries
will inherit the properties of the EventSeries
.This means that if an
EventSeries
is not supplied, its details must be included on the SessionSeries
.The OpenActive Modelling Specification 2.0 represents regular events using a hierarchy of types:
EventSeries
, SessionSeries
, and ScheduledSession
. These are described by example in the diagram below:A
SessionSeries
must always be supplied, including details that would otherwise be present in an EventSeries
if no EventSeries
is supplied.In order for data to be bookable a
ScheduledSession
must be supplied, either embedded, within a separate feed, or generated through a Schedule
.For large providers with many events that are described identically but occur in the same location or in different locations, an
EventSeries
should be used to group these together. This avoids seemingly duplicate search results from a single provider. For systems targeting small providers, the
ScheduledSession
may be embedded in the SessionSeries
or visa versa.For systems targeting large providers or small providers with high volumes of sessions, the
ScheduledSession
is highly recommended to be provided in a separate feed to the SessionSeries
. This will reduce data transfer volumes significantly.The
EventSeries
is unlikely to change frequently enough compared with the SessionSeries
to warrant its own feed, and so can usually be embedded in the SessionSeries
.Please note that the first two "combined feed" options given above are no longer recommended for new OpenActive implementations. These options increase complexity for data users, and create unnecessary additional load on all systems.
Bookable data feed examples:
- Small provider (high volume):
Listings data feed examples:
When referencing data across feeds (such as between SessionSeries and ScheduledSession), the value of the
@id
must be used.An
@id
is a globally unique identifier which must be in URL format for the purposes of namespacing. The @id
does not need to resolve to a functional endpoint, but must use a domain name controlled by the organization or system publishing the data. See here for more information.So for a minimal implementation simply invent a URL pattern that includes your domain for use as your
@id
, such as:"https://id.ourparks.org.uk/api/session-series/1234
"
For example within a
SessionSeries
feed, the SessionSeries
@id
is defined for each data item:"data": {
"@context": "https://openactive.io/",
"@type": "SessionSeries",
"@id": "https://id.ourparks.org.uk/api/session-series/1234",
...
}
And within a corresponding
ScheduledSession
feed, that SessionSeries
@id
is referenced by the superEvent
property:"data": {
"@context": "https://openactive.io/",
"@type": "ScheduledSession",
"@id": "https://id.ourparks.org.uk/api/session-series/1234#/subEvent/C5EE1E55-2DE6-44F7-A865-42F268A82C63",
"superEvent": "https://id.ourparks.org.uk/api/session-series/1234",
...
}
The OpenActive model allows for ad-hoc events to be described using the pattern below. Ad-hoc events must only be used to describe truly ad-hoc events, and not to describe regular events such as those described in the previous section. See here for further clarification of the types available.
The OpenActive Modelling Specification 2.0 represents ad-hoc events using a hierarchy of types:
EventSeries
and Event
, linked via the superEvent
and subEvent
properties. These are described by example in the diagram below:The Event will inherit the properties of the
EventSeries
.This means that if an
EventSeries
is not supplied, its details must be included on the Event
.An Event must always be supplied, including details that would otherwise be present in an
EventSeries
if no EventSeries
is supplied.For large providers with many events that are described identically but occur in the same location or in different locations, an
EventSeries
should be used to group these together. This avoids seemingly duplicate search results from a single provider.Systems must include
Event
s in stand-alone feeds separate from ScheduledSessions
and SessionSeries
.The
EventSeries
is unlikely to change frequently enough compared with the Event
to warrant its own feed, and so can usually be embedded in the Event
.Bookable data feed examples:
These always have at least
activity
andlocation
specified, where the activity can be booked in slots: so a Tennis at Downtown Leisure Centre with slots available hourly from 8am until 8pm.Two different levels of granularity are available: A
FacilityUse
represents "Badminton at Downtown Leisure Centre", where as IndividualFacilityUse
is "Court 2 in Sports Hall 3 for Badminton at Towntown Leisure Centre".The OpenActive Modelling Specification 2.0 represents slot-based events using a hierarchy of types:
FacilityUse
/IndividualFacilityUse
and Slot
, linked via the facilityUse
and event
properties.For facilities a publisher must implement the following two independent feeds:
http://www.example.org/feeds/facility-uses
http://www.example.org/feeds/individual-facility-use-slots
Note that the above examples publish
Slot
availability at the IndividualFacilityUse
level, which is now recommended for all new feeds.When referencing data across feeds (such as between FacilityUse and Slot), the value of the
@id
must be used.An
@id
is a globally unique identifier which must be in URL format for the purposes of namespacing. The @id
does not need to resolve to a functional endpoint, but must use a domain name controlled by the organization or system publishing the data. See here for more information.So for a minimal implementation simply invent a URL pattern that includes your domain for use as your
@id
, such as:"https://id.bookingsystem.com/api/facility-uses/1402CBP20150217/individual-facility-uses/1
"
For example within a
FacilityUse
feed, the FacilityUse
@id
is defined for each data item, and IndividualFacilityUse
@id
values are defined within these:"data": {
"@context": "https://openactive.io/",
"@type": "FacilityUse",
"@id": "https://id.bookingsystem.com/api/facility-uses/1402CBP20150217",
"individualFacilityUse": [
{
"@type": "IndividualFacilityUse",
"@id": "https://id.bookingsystem.com/api/facility-uses/1402CBP20150217/individual-facility-uses/1",
"name": "Main Tennis Court 1"
}
],
...
}
And within a corresponding
Slot
feed, that IndividualFacilityUse
@id
is referenced by the facilityUse
property:"data": {
"@context": "https://openactive.io/",
"@type": "Slot",
"@id": "https://id.bookingsystem.com/api/facility-uses/1402CBP20150217/individual-facility-uses/1#/event/2018-03-01T10:00:00Z",
"facilityUse": "https://id.bookingsystem.com/api/facility-uses/1402CBP20150217/individual-facility-uses/1",
...
}
A feed of
HeadlineEvent
can be used to represent whole day or multi-day events, such as mass participation events, family fun days, etc.The following diagram illustrates the relationships between the event types available within the OpenActive Modelling Specification 2.0:
.png?alt=media&token=3b0e9fbf-07f1-4a69-9da2-4849db6e09c9)
Note the use of aliases (e.g. "IndividualFacilityUseSlot") which are useful when referring to a specific type that is being used in a particular context.
The relationship between all types is represented via the
superEvent
and subEvent
properties, with the exception of:FacilityUse
/IndividualFacilityUse
andSlot
, which are linked via thefacilityUse
andevent
propertiesFacilityUse
andIndividualFacilityUse
, which are linked via theaggregateFacilityUse
andindividualFacilityUse
properties.
The model itself (the properties within the types) follows a different inheritance structure to the property inheritance structure described above.
EventSeries
, SessionSeries
, ScheduledSession
, HeadlineEvent
, CourseInstance
, and Slot
all sub-class Event
.This can be useful for modelling the entities within certain frameworks.
Last modified 11d ago