The imin Platform
2.0.0
2.0.0
  • Introduction to the imin Platform
  • Using the Platform
    • imin's Platform Products
    • Authentication
    • Our Platform Data
      • Understanding Responses
      • Namespaces and Extensions
      • Defensive Data Consumption
      • Mocking the Interface
  • platform products
    • Search
      • imin Events API
        • Events API Reference
        • Virtual & Physical Sessions
        • Concepts
          • EventSeries
          • ScheduledSessions and eventSchedules
          • Activities and Collections
            • Activities
            • Activity Concept Collections
          • Accessibility Support
          • Prices
        • Filters
          • Modes
          • Age Ranges
          • Dates and Times
          • Activities and Concept Collections
          • High Frequency Sessions
      • imin Facilities API
        • Query Parameter Search
          • Mandatory Query Parameters
            • mode=discovery-geo
            • mode=upcoming-slots
          • Optional Query Parameters
        • ByID Search
          • FacilityUse By-ID
          • Slot By-ID
        • FacilityUses and IndividualFacilityUses
        • Slots
        • Facilities Slot Booking
      • imin Places API [BETA]
        • Example Request & Response
    • Firehose
      • Introduction to the Firehose
      • Accessing the Firehose
      • Firehose Usage Policy & Restrictions
      • Firehose and Search
      • Bookable Firehose Feeds
      • Bookable Sellers Feed
      • Attribution Catalog Endpoint
    • Live Timetables
      • Pre-Requisites: Open Data Feeds
      • The Onboarding Process
        • 1. Ensuring your Data Offers the Best User Experience
        • 2. Setting up and Embedding your First Timetable
        • 3. Setting up the Rest of your Timetables
        • 4. Activating Booking via Guest Checkout
      • Features Available Upon Request
      • Styling the Live Timetables
      • FAQs
    • Data Dashboard
  • incorporating book and pay
    • imin Branded Checkout
      • Introduction
      • Setup
        • Information We Require From You
        • Actions You Need to Complete
      • Authenticated Checkout
        • Testing [BETA]
        • 👪Group Booking [BETA]
      • Standalone Checkout
      • Firehose and Checkout [BETA]
        • Loading the Checkout via Firehose
    • imin Booking Platform
      • Customer Account Management
        • Create Customer Account
        • Update Customer Account
        • Get Customer Account
        • Delete Customer Account
        • Example Scenario
        • Payment Card Management
        • Linked Accounts
        • Entitlement
          • Evidence Requests
          • Entitlement Pricing in Search
          • Entitlement Pricing in Checkout
        • Access Pass
        • Webhooks
      • Orders
        • Order History
        • Order (by ID)
        • Cancellations & Refunds
      • Upcoming OrderItems
      • Receipt (by ID)
  • imin and booking systems
    • Seller Onboarding
      • API
  • HINTS & TIPS
    • Get the Best Out of Search
      • Displaying Schedule Information
      • URLs and Offering a Call to Action
      • Searching by Activity
      • Your Search Results and HighFrequencySessions
      • Customer Specific Images
  • Info for Data Publishers
    • Your RPDE Feed & the imin Platform [BETA]
      • Providing Places Data [BETA]
      • Providing Schedule Information [BETA]
Powered by GitBook
On this page
  • Properties and Namespaces
  • Understanding the Namespaces in Use
  • Namespace Evolution and Deprecation
  • SKOS: Simple Knowledge Organization System
  • OpenActive
  • imin
  • OpenActive Beta
  • Extensions
  1. Using the Platform
  2. Our Platform Data

Namespaces and Extensions

An introduction to "@context" URLs and field names, namespaces (their evolution and deprecation), and extensions.

PreviousUnderstanding ResponsesNextDefensive Data Consumption

Last updated 3 years ago

Properties and Namespaces

In the world of linked data on the web, "namespaces" ("@context") are a collection of "properties" (fields) that have a well defined meaning.

Within the imin data, there are five primary namespaces used, all which are listed in the table below. You can click on each of the namespaces below to see a list of the properties contained within.

imin data is valid JSON-LD, which means that properties will always exist in one of the specified namespaces ("@context").

Namespace

Prefix

Context URL

Bundles

Prefix Required

Status

Deprecation Policy

-

https://schema.org/

No

Living Standard

-

http://www.w3.org/2004/02/skos/core#

No

Stable

-

https://openactive.io/

schema.org, SKOS

No

Stable

Yes

imin:

https://imin.co/

Yes

Stable

Yes

beta:

https://openactive.io/ns-beta

Yes

Experimental

*

*

Yes

Experimental

The includes a "profile" (subset) of schema.org and SKOS, which has been defined for OpenActive use, along with the specification for OpenActive namespace.

Descriptions and examples of the most commonly used properties from schema.org and SKOS, together with all properties from OpenActive, are included in the . imin and OpenActive Beta namespaces are documented separately at the links above.

Please note that properties defined outside of the and namespaces are not subject to the imin deprecation policy and are subject to change at any time. Therefore, we strongly encourage a approach.

However, if you are considering one of these fields to drive critical production functionality, please get in touch with us at and we will work with you to propose your use case to the and move the field into either the OpenActive or imin namespace.

Understanding the Namespaces in Use

When reading a response which contains JSON-LD, you'll should refer to the "@context" property, which is designed to let you know which namespaces are in use.

Three key things to remember:

  • The OpenActive namespace also bundles SKOS and schema.org namespaces inside it:

    • So writing

      "@context": [ "https://openactive.io/" ]

      is the same as writing

      "@context": [ "https://openactive.io/", "https://schema.org/", "http://www.w3.org/2004/02/skos/core#" ]

  • OpenActive, SKOS and schema.org namespaces do not require a prefix when using them:

    • So you must write "name": "Tai chi Class" instead of "schema:name": "Tai chi Class"

  • All other properties always require a prefix:

    • You must write "imin:fullAddress" and never "fullAddress"

Example

{
  "@context": [
    "https://openactive.io/",
    "https://imin.co/"
  ],
  "type": "SessionSeries",
  "name": "Tai chi Class",
  "url": "http://www.example.org/events/1",
  "location": {
    "type": "Place",
    "imin:fullAddress": "ExampleCo Gym Kingswood, 1 High Street, Kingswood, South Gloucestershire, BS1 4SD"
  }
}

This example references the namespaces of OpenActive (as noted above, this automatically includes schema.org and SKOS) and imin.

Namespace Evolution and Deprecation

schema.org

The OpenActive W3C Community Group and imin both contribute to discussions within schema.org, however, consensus involves a number of stakeholders and can be time consuming to reach.

SKOS: Simple Knowledge Organization System

This specification is not expected to be updated, however, the use of the specification within OpenActive is subject to change in line with the OpenActive versioning policy.

OpenActive

imin

OpenActive Beta

Data consumers should not assume that properties in the OpenActive Beta namespace will either be added to the core specification or be included in the namespace over the long term.

Extensions

imin data sometimes contains additional namespaces, known as extensions. Data publishers may use these extensions to include additional fields that are not currently being considered as part of the evolving OpenActive standards.

Example

{
  "@context": [
    "https://openactive.io/",
    "http://data.goskyride.com/opendata/britishcycling.jsonld"
  ],
  "type": "Event",
  "name": "Wheel Do It! - Blindside loop (with Betty-Ann)",
  ...
  "britishcycling:gpxFile": "https://lr-media.staging.phoenixdigital.agency/download/2c89c364a0738a26fde9b68eb35bfeb0",
  "meetingPoint": "Start of Loxley Road just past the bus stop, which is immediately after the pedestrian crossing/traffic lights."
}

In this example, the "britishcycling:gpxFile" field is defined by an extension provided by British Cycling, using their custom namespace "http://data.goskyride.com/opendata/britishcycling.jsonld".

[]

is a collaborative, community activity with a mission to create, maintain and promote schemas for structured data on the Internet; on web pages, in email messages and beyond. It was founded by Google, Microsoft, Yahoo and Yandex.

The terms of schema.org continue to evolve through lively discussions on their and . Often properties are added for some specific use case and their potential relationship to other areas of schema.org only becomes clear later. This gives rise to changes in textual definition and property-to-type associations that gradually make schema.org more coherent, without introducing radical changes in meaning. Consumers of schema.org data can generally rely on schema.org term meanings not changing dramatically. However, term definitions often evolve gradually over time to accommodate new usage scenarios or to improve usability. When schema.org properties are occasionally deprecated, they stay in the namespace so that they can still be used and are simply referenced to their replacement property.

Where a schema.org property is explicitly included in the , it follows the OpenActive versioning policy. Where a schema.org property is not included in the OpenActive Modelling Specification, its usage may be subject to change. However, due to schema.org's internal processes and policies, it is highly unlikely to change in name, but somewhat more likely to subtly change in definition.

The , published in 2009, is centred around the Concept type and provides a mechanism for organising these concepts into a hierarchy. It is used for the and other controlled vocabularies where an enumeration of specific terms are defined.

The was established with the objective of facilitating the sharing and use of physical activity data. We very much encourage you to join the conversation and help shape the standards and our future API iterations through this process.

The defines a subset ("profile") of schema.org and SKOS that has been defined for OpenActive use, along with additional properties that feature in the OpenActive namespace.

Descriptions and examples of the , including the defined subset ("profile") of schema.org and SKOS, together with all properties from the OpenActive namespace, are included in the .

The within that specification specifies the use of version numbering to indicate potential for breaking changes: minor versions, e.g. 1.1, 1.2, etc. should be backwards compatible; major versions, e.g. 2.0, 3.0 are likely to include breaking changes. It is estimated that such breaking major version releases will only occur at most annually. imin will strive to align major version releases with OpenActive major version releases, with any deprecated imin API major version maintained for a period in accordance with the imin deprecation policy.

The properties defined in the are subject to the imin deprecation policy.

The is maintained to facilitate the early stabilisation of properties ahead of their broader adoption and standardisation. imin works as part of the to promote the use cases represented by the properties within this namespace, with the intention of standardising them into the over time (where applicable).

When a property "graduates" from the imin namespace into the , it will be maintained as a duplicate property for 12 months and deprecated in accordance with the imin deprecation policy.

The namespace provides a custom namespace that can be used by publishers experimenting with new properties that are likely to be added to the core specification. It is defined as a convenience to help document properties that are in active testing and review by the community.

Please note that OpenActive Beta namespace properties are not subject to the imin deprecation policy and are subject to change at any time. Therefore, we strongly encourage a approach. However, if you are considering one of these fields to drive critical production functionality, please get in touch with us at and we will work with you to propose your use case to the and move the field into either the OpenActive or imin namespace.

Please note that extension properties are not subject to the imin deprecation policy and are subject to change at any time. Therefore, we strongly encourage a approach. However, if you are considering one of these fields to drive critical production functionality, please get in touch with us at and we will work with you to propose your use case to the and move the field into either the OpenActive or imin namespace.

OpenActive Modelling Specification
OpenActive Developer Documentation
OpenActive Modelling Specification
imin
defensive data consumption
hello@imin.co
OpenActive W3C Community Group
schema.org
mailing list
GitHub issues
OpenActive Modelling Specification
SKOS specification
OpenActive Activity List
OpenActive W3C Community Group
OpenActive Modelling Specification
OpenActive Modelling Specification
OpenActive Developer Documentation
OpenActive versioning policy
OpenActive Modelling Specification
imin namespace
OpenActive W3C Community Group
OpenActive Modelling Specification
OpenActive modelling specification
OpenActive Beta
defensive data consumption
hello@imin.co
OpenActive W3C Community Group
defensive data consumption
hello@imin.co
OpenActive W3C Community Group
schema.org
SKOS
OpenActive
imin
OpenActive Beta
Extensions