Adding Schedules #1457

Open
ldodds opened this Issue Dec 14, 2016 · 3 comments

Projects

None yet

3 participants

@ldodds
ldodds commented Dec 14, 2016

A quick proposal based on discussion in #240.

Schema.org doesn't currently have a way to express recurring events.

While it will always be useful to share data on individual instances, e.g. the event happening this Tuesday at 6pm. There are also scenarios where it is useful to be able to share a general rule, e.g. this event happens at 6pm every Tuesday.

Use cases include sharing data about physical activities, e.g. regular gym classes or similar events.

iCalendar already refines a model and terms for expressing recurring events. And this
is independently supported in libraries like rrecurjs. We could draw on this to define a similar model for schema.org

The proposal is to define a new schedule property, a EventSchedule type and some additional properties for describing the schedule.

The schedule property will be associated with Events. It will allow the description of a schedule, expressed as a recurrence rule for describing the frequency of upcoming events.

The EventSchedule type will have properties based on those in iCalendar. But in the below, the naming has been aligned with existing schema.org properties.

  • startTime - the existing property, date/time at which the schedule starts
  • endTime - existing property, date/time at which the schedule ends
  • frequency - "daily", "monthly", "yearly"
  • day - DayOfWeek
  • month - month of the year
  • hour - hour
  • minute - minute
  • count - optionally specfiy the number of recurring events
  • exceptionRule - repeating property, specifies date-times when the schedule doesn't apply, equivalent to exrule in ical

I think this covers the core aspects of a schedule. I may have missed something essential (am not an iCal expert) but I think this type of rule will cover many use cases so worth considering.

This structure can be easily expressed in, e.g. JSON-LD, but may be trickier in RDFa. I've not tried that yet, but wanted to float this for discussion.

@ldodds ldodds referenced this issue in openactive/modelling-opportunity-data Dec 14, 2016
Open

Schema.org doesn't handle recurring events #2

@magicomartinez

Hi ldodds,

Thanks for putting this together. I had some comments on your proposal:

  • startTime: if you’re referring to the date when the schedule starts then startDate may be more appropiate
  • endTime: as above. May be worth mentioning that if no endDate is specified then it’s assumed the event has been scheduled indefinitely
  • frequency: what’s the expected type here? An easy way may be to specify a number, so it knows how many to skip
  • day: a distinction between DayOfWeek (e.g. to create a schedule on every Monday) and DayOfMonth (a new type) may be useful.
  • hour & minute: I would use startTime and endTime instead, both with Time as the expected type
  • count: because we’re already specifying startDate, endDate, and the frequency, I am not sure we need count as it can be calculated.

As mentioned above, DayOfMonth would be a new type that would have 1 to 31 as possibilities (http://schema.org/1, http://schema.org/2, http://schema.org/3, etc)

Also, I would change the names around so eventSchedule is the property from Event and Schedule is the new type.

I’ve put together some examples of how it may work with different schedules:

Every 3rd Monday from 9am to 10am

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Event",
  "name": "Example",
  "eventSchedule":
    {
      "@type": "Schedule",
      "startDate": "2016-12-24",
      "endDate": "2017-12-25",
      "frequency": “3",
      "day": "http://schema.org/Monday",
      “startTime": "09:00",
      “endTime": "10:00"
    }
}
</script>

Every 1st and 15th of every month from 9am to 10am

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Event",
  "name": "Example",
  "eventSchedule":
    {
      "@type": "Schedule",
      "startDate": "2016-12-24",
      "endDate": "2017-12-25",
      "frequency": "1",
      "day": [{"http://schema.org/1"},{"http://schema.org/15"}]
      “startTime": "09:00",
      “endTime": "10:00"
    }
}
</script>

Every working day of the week twice, from 9am to 10am and then from 2pm to 3pm

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "Event",
  "name": "Example",
  "eventSchedule":
    [
     {
      "@type": "Schedule",
      "startDate": "2016-12-24",
      "endDate": "2017-12-25",
      "frequency": "1",
      "day": [{"http://schema.org/Monday"},{"http://schema.org/Tuesday"},{"http://schema.org/Wednesday"},{"http://schema.org/Thursday"},{"http://schema.org/Friday"}]
      “startTime": "09:00",
      “endTime": "10:00"
     },
     {
      "@type": "Schedule",
      "startDate": "2016-12-24",
      "endDate": "2017-12-25",
      "frequency": "1",
      "day": [{"http://schema.org/Monday"},{"http://schema.org/Tuesday"},{"http://schema.org/Wednesday"},{"http://schema.org/Thursday"},{"http://schema.org/Friday"}]
      “startTime": “14:00",
      “endTime": “15:00"
     }
    ]
}
</script>

Thoughts?

@ldodds
ldodds commented Jan 16, 2017

Hi,

  • Specifying both start/end dates and time as you suggest seems reasonable to me
  • I'm fine either way with DayOfWeek or DayOfMonth. My reason for going with DayOfWeek is simply that it exists already and I was aiming for smallest set of changes.
  • replacing hour and minute with start/endTime also seems reasonable. Follows my above rule better or trying to use fewer properties. I specified several here to match iCalendar. I think its worth considering whether alignment with iCal is a good thing to preserve.
  • Agree that count can be calculated, but I don't see any harm in specifying exactly how many events will run. E.g. starting tomorrow we'll run 10 weekly events

I'm not convinced by changing daily/weekly/monthly frequency indicators for numbers though. Specifying the unit seems clear to me.

@danbri
Contributor
danbri commented Jan 17, 2017

This all looks pretty sensible. Any thoughts on how it relates to our existing (two!) mechanisms for opening hours?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment