RE: BookingBug Services

Hi Leigh.

Apologies for “hi-jacking” this thread – but can we start a new thread specifically talking about schedules and recurrence rules using a format similar to iCal. I think it would be good to have a proper “clean” discussion around this element as it is central to all booking systems, and we need to ensure consistency, clarity and completeness on this matter.

Thanks
Raymond de Bourbon

From: Leigh Dodds [mailto:leigh.dodds@theodi.org]
Sent: 10 March 2017 16:48
To: Ed Clements <ed@bookingbug.com>
Cc: public-openactive@w3.org
Subject: Re: BookingBug Services

Hi Ed,

On 6 March 2017 at 13:44, Ed Clements <ed@bookingbug.com<mailto:ed@bookingbug.com>> wrote:
Hi Everyone,

I've been looking at the sport activities offered by some of our clients here at BookingBug. There are activities ranging from Coasteering to Aerial Yoga to Pole Dance Fitness. I'll work on collating a full list to share.


Great, thank you.


With regards to modelling opportunity data I'd like to outline how we model bookable activities. At BookingBug we support two main types of bookings; events and services.

Events occur at a set date & time with a specified duration. They can be configured as one-off or occurring regularly according to a repeat rule. They can also be set up as part of a course, where all the occurrences are booked and paid for collectively.

It was interesting for me to see in 4.3.1 in 'Modelling Opportunity Data' that a recurrence rule is being seen as possibly required. While we use a recurrence rule for the creating of events we haven't generally needed to expose that in our APIs for booking events. We just return the available events between the requested dates along with the number of spaces remaining or spaces remaining on the wait list if configured.

OK. So the intention of allowing recurrence rules to be defined is to ensure that there is a way for people to share that type of broader schedule data, as well as individual events.

From the perspective of offering a discovery API/service it makes sense to allow a user or application to query for events between a time period and then return the actual instances.

But I'm also keen to allow schedules to be exchanged to support aggregation of opportunity data. In that scenario I think it's better to share an event description with a recurrence rule (that can be reliably interpreted anywhere) rather than a stream of events.

I can see there may be issues if individual events are cancelled, etc but this can be supported by publishing an updated schedule with a specific date(s) excluded. Or, as a final step, catching it at the stage of booking.

Does that seem OK to you? In short, its trying to ensure we have a common way to exchange this data but over time we can work out what the most useful patterns are from a publishing and API perspective.

As there's a good model for recurrence rules in icalendar its not a great deal of work to include it in the specification.


Services are continuously available and allow time slots (appointments) of variable duration to be booked for them. We allow configuration of the schedules of associated staff and resources.

I'm concerned that our services aren't going to fit into the event definition. It could've been entirely possible that none of our sport activity clients had services configured but having had a look I can see that this isn't the case. In a small set of 10 clients I looked through there were a couple that have services configured. One was a volleyball court, the other a football pitch. These are both resource based organisations but I wouldn't be surprised if we also had staff based organisations such as a personal trainer.

Here's an example of how we represent the bookable times of a service:

[{
 "start": "2017-03-06T09:00:00+00:00",
 "durations": ["PT60M", "PT120M", "PT180M"],
 "prices": [10, 20, 30]
}, {
 "start": "2017-03-06T10:00:00+00:00",
 "durations": ["PT60M", "PT120M", "PT180M"],
 "prices": [10, 20, 30]
}, {
 "start": "2017-03-06T11:00:00+00:00",
 "durations": ["PT60M", "PT120M", "PT180M"],
 "prices": [10, 20, 30]
}, {
 "start": "2017-03-06T12:00:00+00:00",
 "durations": ["PT60M", "PT120M"],
 "prices": [10, 20]
}, {
 "start": "2017-03-06T13:00:00+00:00",
 "durations": ["PT60M"],
 "prices": [10]
}, {
 "start": "2017-03-06T15:00:00+00:00",
 "durations": ["PT60M"],
 "prices": [10]
}]

Can the specification be expanded to support this kind of data? Or do we just indicate that the day is available and the consumer of the OpenActive data redirects the user to our booking journey for them to find out available times?

If I'm understanding correctly, then a service in your system is a facility like a court, pitch, etc? If so then the specification currently allows for facilities to have opening times when they're available. That feels close to the model you're describing here. That would allow the broad availability of a facility to be available, but would defer to the booking flow to handle actual availability of a time slot.

I've not considered staff based organisations. There are some additional issues there relating to personal data (e.g. describing availability of a specific person at a time and place) which we'd need to be careful to avoid.

An approach for staff would be to share the availability as a recurring event, e.g. "personal training with person a", which the trainer with be attending as an organiser or contributor.

What do others think? Do we need to consider staff based opportunities or is that better deferred to when we explore booking in more detail?

Cheers,

L.



Omnico Group UK Limited, Registration No: 02739937
Registered in England - 1 Beechwood, Lime Tree Way, Basingstoke, Hants, RG24 8WA, UK