recurrence rules (Re: BookingBug Services)

Hi,

We have an open issue to discuss how schedules can be handled in the
specification, issue is here:

https://github.com/openactive/modelling-opportunity-data/issues/2

My current proposal is that we use the recurrence rule model for icalendar:
its well used, well defined and can be expressed in JSON and other formats
fairly succinctly.

I've been involved in some discussion happening in the Schema.org community
around this and there's some support there in the approach. There's an
early draft of what that could look like here:

https://github.com/schemaorg/schemaorg/issues/1457

However I've got an updated version which I can share here later today
which aligns better with icalendar.

Any comments?

Cheers,

L.


On 13 March 2017 at 09:37, Raymond de Bourbon <RdeBourbon@omnicogroup.com>
wrote:

> 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> 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
>



-- 
Leigh Dodds, Senior Consultant, theODI.org
@ldodds
The ODI, 65 Clifton Street, London EC2A 4JE