ScheduledSession <-> Event reclassification #264

Background

The types of opportunities in OpenActive have a specific semantic meaning:

• SessionSeries and ScheduledSession: This is an event (usually 1 or 2 hours in duration), that happens with some regularity. It is expected that if a user attends one of these events, that they would find another event in the series happening soon afterwards. [ref]

• Event: These events are one-off occurrences, e.g. a fun run organised by a local group may run as a standalone event on a particular date or an organisation that runs many individual events e.g. Human Race, Race for Life, International Women's Day. [ref]

• CourseInstance: Courses generally involve an upfront commitment to a number of sessions, with a consistent attendee group and/or organisers for the duration of the course. [ref]

Within booking systems, the difference between an Event and a ScheduledSession is usually as subtle as whether the Event is part of a recurrence rule - often the user can tick a box to say "repeat every Tuesday" as they can in Google Calendar, and an Event then becomes a ScheduledSession.

The current guidance for this scenario is for the booking system to remove the Event from their Events feed, and add it into their SessionSeries/ScheduledSessions feed.

According to Bookwhen this is not an uncommon occurrence, e.g. an organiser scheduling the first Event, and then deciding to add a recurrence to it afterwards for it to become part of a SessionSeries. Potentially bookings have already been made against the Event when this happens.

Challenges

Within the booking system an Event and a SessionSeries/ScheduledSession are usually represented by the same underlying structure. Forcing the same underlying structure to output two feeds can create extra work for the booking system, and also is in opposition to one of the principles of RPDE (which exists for the same reason):

Does your implementation match your internal state as closely as possible (i.e. you are not generating sessions that don't actually yet exist as records in your system from a recurrence rule, but are instead providing the recurrence rule data directly). [ref]

When an Event becomes a ScheduledSession and visa versa, the current guidance implies that the item be marked as deleted in its current feed, and a new item (with a new @id) be added to a new feed. When the Open Booking API is implemented, changing the @id of an item will break Change of Logistics Notifications (openactive/open-booking-api#138) (e.g. if an Event becomes a ScheduledSession then its location is updated).

Potential solutions

If we want to retain the semantics of Event and its subclasses, given that it is possible for systems to switch between the types after bookings have been made, one potential solution is to allow an opportunity to have its @type changed, while maintaining its @id.

The feed split could then be:

• SessionSeries
• ScheduledSession + Event (where this feed contains both types, with the same @id namespace used for both)

When an Event becomes a ScheduledSession in the second feed, it is then linked to the schedule it is now part of (SessionSeries). When a ScheduledSession becomes an Event in the second feed, it is effectively unlinked from the schedule, as it is a one-off session.

(N.B in the case of Bookwhen this doesn’t actually help as their Events feed and ScheduledSession feed are driven from two different underlying database tables)

Further investigation is required to determine whether having a JSON-LD object change @type while maintaining its @id is (a) allowable and (b) best practice