ScheduledSessions and eventSchedules
An Introduction to the SessionSeries
subEvent
SessionSeries
subEvent
In each SessionSeries
, there are two fields that determine when a session can occur:
subEvent[]
containingScheduledSession
s, which are normally present for each item and deemed to be authoritative, i.e. the session is guaranteed to take place at this time.The
eventSchedule
, which can include aSchedule
orPartialSchedule
. These have more general information useful for supplementing theScheduledSession
. They are not necessarily deemed to be authoritative, i.e. the session may take place at this time.
If a ScheduledSession
is not present, caution should be exercised when presenting PartialSchedule
information to the end user as it only tells us that a session might take place in the future.
Top tip: if there are ScheduledSession
s, any information within the eventSchedule
(if present) can be considered supplemental. Only if there are no ScheduledSession
should the PartialSchedule
included in the eventSchedule
be used to display non-authoritative information about session timings.
ScheduledSession
s
ScheduledSession
sGenerally speaking, most SessionSeries
in our data will will include, at a minimum, a ScheduledSession
. These objects will include information about exactly when a session is going to take place. It should be considered to be the source of truth when it comes to a session's scheduling information.
Example
ScheduledSession
s and EventSchedule
s
ScheduledSession
s and EventSchedule
sWhere an EventSeries
includes a ScheduledSession
, you can treat this as authoritative and can, in theory, disregard any other scheduling information, including the EventSchedule
.
You can present ScheduledSession
s to the end user on the front as authoritative, i.e. they are definitely taking place.
However, the EventSchedule
can be used to supplement the information provided to the end user to improve the UX.
The eventSchedule
eventSchedule
The items in a SessionSeries
'seventSchedule
array can be either take the form of a Schedule
or a PartialSchedule
and this is dictated by the open data we receive from different providers. As a user of our data, the difference isn't incredibly important, but it may interest you nonetheless.
Why do we have Schedule
s and PartialSchedule
s?
Schedule
s and PartialSchedule
s?Schedule
s
Schedule
sPartialSchedule
s
PartialSchedule
sInternally, imin does not ever generate ScheduledSession
s from PartialSchedule
s. This includes in the ByID
route.
What do Schedule
s/PartialSchedule
s look like in our data?
Schedule
s/PartialSchedule
s look like in our data?Schedule
s
Schedule
sPartialSchedule
s
PartialSchedule
sDisplaying Schedule
s and PartialSchedule
s on the front end
Schedule
s and PartialSchedule
s on the front endAs a rule of thumb, Schedule
/PartialSchedule
s information in our APIs should be approached with caution. This is because the information is limited to such an extent that it is only possible to say that a session might be taking place, e.g. the instructor might be ill or the session falls on a Bank Holiday.
Where there is a ScheduledSession
present
ScheduledSession
presentAs noted above, the ScheduledSession
should always be used as the authority when displaying information to the end user as it is guaranteed to take place at this time. However, the Schedule
/PartialSchedule
does offer helpful information that can supplement the ScheduledSession
to further inform the user.
You should not extrapolate based on the information found in the eventSchedule
and communicate to the end user that a session will definitely take place, e.g. every Tuesday and Thursday, as the future ScheduledSession
s may tell us otherwise.
Where there is not a ScheduledSession
present
ScheduledSession
presentWhere a ScheduledSession
is not present and instead only a PartialSchedule
, we recommend using the data included in the eventSchedule
to render it on the front end and use a pop-over to explain to the end user that the session information should be referred to, but not relied upon, with the best course of action being for the end user to contact the session organiser to check it is taking place.
If you are presenting PartialSchedule
information to the end user and there is no ScheduledSession
, it should be made abundantly clear that:
The sessions are not guaranteed to take place; and
They should contact the organiser to find out whether it is taking place or not.
Data consumers should consider how to present this information in a way that will make it clear to end users that the event details may be subject to change.
Time Zones For eventSchedule
s
eventSchedule
sBecause a Schedule
/PartialSchedule
can occur over time zone boundaries (e.g. it may occur on the week before clocks go forward and the week after), it cannot have a single time zone designator (e.g. 12:00Z
would refer to 12:00 before the clocks go forward and 13:00 after).
The scheduleTimezone
field will not always be included. When it is not, please assume that this field is set to Europe/London
.
Last updated