OpenActive Developers
Data ValidatorDataset DashboardW3C Community Group
  • Welcome to our community
  • Publishing Data
    • Data Feeds
      • How an RPDE data feed works
      • Types of RDPE feed
      • Implementing RPDE
      • Testing RPDE feeds
      • Scaling RPDE feeds
    • Activity list references
    • Including geo coordinates
    • Schedules
    • Dataset Sites
    • Virtual Events
    • On-Demand Events
    • Opening Hours
    • Data Quality
  • Using data
    • Harvesting opportunity data
      • Large Integers in JavaScript
    • Tutorial: Consuming an RPDE feed
    • Attribution
  • Open Booking API
    • Key Decisions
    • Implementing booking
    • Testing booking
      • Configuring Test Suite
      • Implementing the Test Interface
        • Test Interface Actions
        • Create Opportunity Endpoint
      • Random Mode: Generating Test Opportunity Data
      • Running Test Suite
      • Generating the Conformance Certificate
  • Data Model
    • Data Model Overview
    • @context and JSON-LD
    • Types Reference
      • Action
      • AudioObject
      • BabyChanging
      • Barcode
      • BookingService
      • BooleanFormFieldSpecification
      • Brand
      • ChangingFacilities
      • ConceptScheme
      • Concept
      • CourseInstance
      • Course
      • Creche
      • CustomerAccount
      • DataCatalog
      • DataDownload
      • Dataset
      • DropdownFormFieldSpecification
      • DynamicPayment
      • Entitlement
      • EventSeries
      • Event
      • FacilityUse
      • FileUploadFormFieldSpecification
      • GeoCoordinates
      • HeadlineEvent
      • ImageObject
      • IndividualFacilityUse
      • InternalApplicationError
      • InternalLibraryConfigurationError
      • InternalLibraryError
      • Lease
      • LocationFeatureSpecification
      • Lockers
      • MediaObject
      • OfferOverride
      • Offer
      • OnDemandEvent
      • OpenBookingError
      • OpeningHoursSpecification
      • OrderItem
      • OrderProposal
      • OrderQuote
      • Order
      • Organization
      • ParagraphFormFieldSpecification
      • Parking
      • PartialSchedule
      • Payment
      • Person
      • Place
      • PostalAddress
      • PriceSpecification
      • PrivacyPolicy
      • PropertyValueSpecification
      • PropertyValue
      • QuantitativeValue
      • Schedule
      • ScheduledSession
      • SessionSeries
      • ShortAnswerFormFieldSpecification
      • Showers
      • Slot
      • SportsActivityLocation
      • TaxChargeSpecification
      • TermsOfUse
      • Terms
      • Toilets
      • Towels
      • VideoObject
      • VirtualLocation
      • WebAPI
  • Specifications
    • Specifications Overview
  • Useful links
    • Data Visualiser
    • Data Validator
    • Dataset Dashboard
    • Non-technical Guidance
  • OpenActive on GitHub
    • Overview
    • Activity List
    • Community
    • Controlled Vocabularies
    • Dataset Publication
    • Documentation
    • Implementation Support
    • Programmes
    • RPDE
    • SKOS
    • Specifications
    • Validators
Powered by GitBook
On this page
  • Time-based Events: Regular Classes and Sessions
  • Property inheritance
  • Property inheritance overrides
  • Permissible configurations
  • Exposing the model in feeds
  • Use of @id and superEvent for split feeds
  • Time-based Events: Ad-hoc Events
  • Summary of ad-hoc event types
  • Property inheritance
  • Permissible configurations
  • Exposing the model in feeds
  • Slot-based Events: FacilityUses
  • Use of @id and facilityUse for split feeds
  • Other types of Time-based Events: Headline Events and Courses
  • Event relationship overview
  • Schema.org type inheritance overview
Edit on GitHub
  1. Publishing Data
  2. Data Feeds

Types of RDPE feed

PreviousHow an RPDE data feed worksNextImplementing RPDE

Last updated 1 year ago

Time-based Events: Regular Classes and Sessions

These always have at least activity, location and startDate specified: so a Yoga class in Downtown Leisure Centre, at 7pm, on a Tuesday. See for further clarification of the types available.

The OpenActive Modelling Specification 2.0 represents regular events using a hierarchy of types: , , and , linked via the superEvent and subEvent properties. These are described by example in the diagram below:

Property inheritance

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.

Property inheritance overrides

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:

Permissible configurations

A SessionSeries 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.

Exposing the model in feeds

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:

Use of @id and superEvent for split feeds

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",
  ...
}

Time-based Events: Ad-hoc Events

Summary of ad-hoc event types

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:

Property inheritance

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.

Permissible configurations

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.

Exposing the model in feeds

Systems must include Events 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:

Slot-based Events: FacilityUses

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.

Use of @id and facilityUse for split feeds

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",
  ...
}

Other types of Time-based Events: Headline Events and Courses

  • The OpenActive Modelling Specification 2.0 represents these events using a hierarchy of types: HeadlineEvent (for the overall event) and Event (for small events within the overall event) linked via the superEvent and subEvent properties.

  • The OpenActive Modelling Specification 2.0 represents these events using a hierarchy of types: CourseInstance (for the whole course) and Event (for the individual occurrences) linked via the superEvent and subEvent properties.

Event relationship overview

The following diagram illustrates the relationships between the event types available within the OpenActive Modelling Specification 2.0:

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 and Slot, which are linked via the facilityUse and event properties

  • FacilityUse and IndividualFacilityUse, which are linked via the aggregateFacilityUse and individualFacilityUse properties.

Schema.org type inheritance overview

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.

In order for data to be a ScheduledSession must be supplied, either embedded, within a separate feed, or generated through a Schedule.

For data, the possible feed combinations are described in the diagram below:

Small provider:

Small provider (inverted):

and (physical)

and (virtual)

Large provider: , and

Small provider:

Large provider:

When referencing data across feeds (such as between and ), 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 for more information.

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 for further clarification of the types available.

For data, example feed combinations are described in the diagram below:

Events only:

(including IndividualFacilityUse)

When referencing data across feeds (such as between and ), 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 for more information.

A feed of can be used to represent whole day or multi-day events, such as mass participation events, family fun days, etc.

See for further clarification, and for an example.

A feed of can be used to represent a fixed-length course.

See for further clarification, and for an example.

bookable
bookable
SessionSeries with ScheduledSession
ScheduledSession with SessionSeries
SessionSeries
ScheduledSession
SessionSeries
ScheduledSession
SessionSeries with EventSeries
ScheduledSession
SessionSeries
SessionSeries with EventSeries
SessionSeries
ScheduledSession
bookable
Event
FacilityUse example
Slot example
FacilityUse
Slot
HeadlineEvent
CourseInstance
EventSeries
SessionSeries
ScheduledSession
here
here
here
here
here
here
here
here