Re: recurrence rules (Re: BookingBug Services)

Hi,

Just to follow-up on my own message, I've circulated a revised proposal for
scheduled events for comment by Schema.org community:

https://github.com/schemaorg/schemaorg/issues/1457#issuecomment-286423792

If you have comments from an OpenActive perspective, please weigh in here
or on that issue.

Cheers,

L.

On 13 March 2017 at 09:43, Leigh Dodds <leigh.dodds@theodi.org> wrote:

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


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