Adding Schedules #1457
Comments
|
Hi ldodds, Thanks for putting this together. I had some comments on your proposal:
As mentioned above, Also, I would change the names around so I’ve put together some examples of how it may work with different schedules: Every 3rd Monday from 9am to 10am Every 1st and 15th of every month from 9am to 10am Every working day of the week twice, from 9am to 10am and then from 2pm to 3pm Thoughts? |
|
Hi,
I'm not convinced by changing daily/weekly/monthly frequency indicators for numbers though. Specifying the unit seems clear to me. |
|
This all looks pretty sensible. Any thoughts on how it relates to our existing (two!) mechanisms for opening hours? |
@ldodds The only reason I suggested numbers as frequency indicators is because I didn't think the daily/weekly/monthly indicators would work as well with schedules such as "every 3 mondays". Happy to be proved wrong though. |
|
I'll post an updated proposal here in next few days or so incorporating comments. @danbri I'll also highlight overlaps with opening hours. |
|
This looks pretty good. My only lingering queries would be:
|
|
ping @ldodds - any updates? |
This makes sense. +1 |
Revised ProposalTHIS IS THE LATEST VERSION OF THE PROPOSAL. I've left the original proposal and discussion intact above, but will revise this comment in line with ongoing discussion. Please add comments below. GoalProvide a means to define scheduled events. The primary use case is to describe schedules for things like:
The goal isn't to offer the full flexibility of iCalendar, so the features described here are a subset of iCalendars recurrence rules. Alignment with iCalendar is preserved where possible. It's a tried and tested model. Summary of Proposed Changes
|
|
@rdebourbon @magicomartinez I'm not sure it makes sense to specify frequency using the duration support in ISO 8601. Is there a reason to prefer that over the (revised) specification. @rdebourbon also there's already the duration property of an event. That could be specified on the Event rather than the schedule as normal. For setup/teardown, that might be something we need to consider as part of OpenActive as it doesn't necessarily apply to Schema.org's more general Event support? |
|
@ldodds - My rationale around specifying it in something other than an integer was to avoid any potential confusion / misinterpretation around the original frequency as an integer. An ISO 8601 duration string also effectively combines frequency and interval into a single standard well described type. @ldodds - The duration of an event can vary at the session level. In fact, experience has taught me that quite a few properties typically defined at the event level can vary at the session level (eg location). An example of varying duration though is often encountered when defining schedules for peak / off peak periods - which again can have different recurrence rules. Eg Peak period sessions are 30minutes long every 30minutes between XX:XX and YY:YY on days F,Sa. Off peak they are 60minutes every 120minutes between AA:AA and BB:BB on days M,W,F. Noticing that Friday occurs in both peak & off-peak so needs complimentary recurrence rules defined depending on the actual dates involved. |
|
Hi guys, Is there a way we can include a provision for bank holidays? Theres a big inconsistency between venues about whether they are / aren't open and I know many recurring activities are not held on bank holidays, but some are. It doesnt seem like it is on Schema.org but Im thinking something along the lines of Thanks |
|
From an entirely non technical perspective - how do the proposals above - or whatever we incline towards get piloted or tested with some users? There is a bit of a risk in putting lots of work into features / formats that are not used and that we miss others that will be found useful. No doubt you have an approach to this already that I am not aware of..... |
|
@jamiefoale I would expect that Bank Holidays and other closures would be handled via an "exceptDate" array of values. This allows for greatest flexibility from an underlying data structure. If we include a "bankHoliday" attribute we then potentially need to clarify how a particular data source determines bank holidays. In this instance a more generic exception list is probably easiest for everyone involved. Having said that, @ldodds, would it be a good idea to allow for an optional reason text for the exception so that venues / operators can distinguish between expected closures and unexpected changes to the schedule? |
|
Great point @rdebourbon around cancellation, I wonder if that question can be framed even more broadly: Assuming we have a recurrence rule in place, how do we associate additional property values to a particular occurance. Examples include:
What this leads me to wonder is whether there's a parent-child model where the "master" event specifies a number of properties including a recurrence rule, and "override" events are provided in an array similar to exceptDate, but with an array of type Event. Each Event would inherit the properties of the master, and only include additional properties required (such as "cancelled" and "cancellation reason", or "location", or simply an "available spaces" integer). This would potentially reduce the size of data payload required to cater for e.g. Recurring sessions which include availability. |
|
Catching up here, most of the follow-up comments relate to how to add extra information to specific instances of an event (e.g. why cancelled, or change of location). I think that can already be accommodated by the existing For example I can associate a specific instance of an Event (which might have changed duration and venue) with the schedule by a But I think that's outside the scope of specifying a simple set of recurrence rules. And some of this is specific to OpenActive rather than a more general Schema.org mechanism. @danbri what do we need to do to move this forward? I'm trying to decide whether to:
I'd prefer the latter :) |
|
@danbri @rvguha I'm looking to move the OpenActive specification a step forward through the W3C community group process. The only major area that currently has a caveat is the handling of recurring events. As I noted in my previous comment, I've got two options, either define our own mechanism or progress this proposal. I'd prefer to keep alignment with Schema.org as we've been doing that elsewhere for the core model. What's the likelihood of getting my proposal here, which seems to have reasonable support, accepted into Schema.org? Is there anything I can do to help move that forward? |
|
I would be happy to have this in schema.org, so long as we figure out how it relates in expressivity and scope to our two(!) existing opening hour mechanisms. Many many interesting events, and associated changes of state (beyond opening/closing of availability) happen on schedules, not least for devices (see iot.schema.org). It feels like some kind of test cases repo might be useful for documenting clearly the meaning of complex schedule and opening hours data..m |
|
@danbri just to confirm, the 2 mechanism you're referrring to are openingHours and OpeningHoursSpecification. Want to make sure I'm focusing on the right things before clarifying overlap. I'll note that neither of those address our use case, but agree its worth describing the overlap. Also, re: test repo would a public github repo with JSON-LD examples we enough, or were you thinking of something else? If there's an example of how you've done this for other proposals that would be great. |
Comparison with Opening Hours MechanismsAs requested by @danbri How does this proposal relate to the two existing mechanisms that Schema.org has for describing "opening hours"?
|
Schedule |
OpeningHoursSpecification |
|---|---|
startTime |
opens |
endTime |
closes |
startDate |
validFrom |
endDate |
validThrough |
count |
- |
frequency |
- |
interval |
- |
byDay |
dayOfWeek |
byMonthDay |
- |
byMonth |
- |
exceptDate |
- |
The meaning of dayOfWeek and byDay are not quite the same but are close.
It should be possible to express any OpeningHoursSpecification as a Schedule but not vice versa.
OpeningHoursSpecification could be seen as a specialisation of Schedule that supports a specific use
case.
Schedule because it's grounded in iCal provides a better foundation for capturing other scheduling information than OpeningHoursSpecification.
OpeningHoursSpecification and its predecessor are designed to better support adding structured data to existing opening hours text on websites, whereas Schedule information is more likely to come from automated systems and calendaring type applications.
Data could be directly exchanged as iCal schedules, e.g. via an rrule, but this approach avoids all clients having to implement full iCal support and supports use cases where schedules are presented to users.
In terms of encouraging alignment and rationalisation it might be better to:
- public deprecate
openingHoursin favour ofOpeningHoursSpecification(outside the scope of this proposal) - consider formally defining
OpeningHoursSpecificationas a sub-class ofScheduleand defining some alignment between properties
@danbri does that help? :)
|
@ldodds I like your Schedule. For me it works. But...Hmm... it seems that iCal has acknowledged a few gaps in their modeling over the years and are trying to fill those in. Will Schedule have a "location" property also ? Because it seems that iCal is trying for an approach where Schedule itself can have a Location property. Your case with OpenActive is approaching against an Event (which already has Location property) and then saying the Event has a Schedule. Referencing https://icalendar.org/RFC-Specifications/iCalendar-Venue-Draft/ and all the new properties forthcoming https://icalendar.org/RFC-Specifications/all/ Is there anything for or against also having a location property under Schedule as in the iCal Venue Draft above ? Example that iCal Venue Draft proposal is saying :
|
|
@thadguidry I wasn't aware of that. I should be clear that I'm not aiming for a complete import of ical into schema.org so haven't look at achieving a complete mapping, or looked at any proposed enhancements. However, I'm not sure it makes sense to add a location field for the The proposal here is essentially to map ical |
|
@ldodds Thanks. And I completely agree, an Event is at a location... not a Schedule :) We got things right in Schema.org and iCal is just catching up :) Just wanted to point that out for all for posterity sake and in case anyone comes back to this asking silly questions. (That proposal affords a VVENUE btw, which we already have) |
For testcases, I am not entirely sure what the right structure is. @gkellogg and friends have done a lot around RDF testing. For this case the idea would be something like:
There would be some nuance around cornercases like open all day, closed all day, times spanning midnight, broadening to schedules, mixing the two idioms for opening hours in one description, dealing with defaults and missing information and so on. |
|
@danbri am still not quite sure what you're asking in terms of shaping up this proposal. As it stands schedule and the 2 opening hours mechanisms are really separate features, although clearly both are about specifying time periods in some form. Rationalising the two opening hours mechanisms is a separate issue I think. Am not sure resolving that legacy decision should block this proposal? Or are you also suggesting that we also need to broaden this proposal schedule to make it work for opening hours too, before it'll be considered further? That's possible as I've outlined above, but could also be done as a separate exercise? I may be confused by your examples which are all about opening hours. I'd originally assumed you just wanted better documentation and examples to back up the schedule proposal. |
|
@ldodds they are indeed separable. I am just wary of having three partially-equivalent mechanisms for specifying time periods. Even if "opening hours" was not fragmented, we ought to at least understand the extent to which the schedule proposal differed. The test case idea is essentially a sketch of a way of mapping out this expressivity so we know what we've done, and whether e.g. one is a strict superset of the other's. |
|
@danbri does the analysis I posted above, with the property breakdown not cover that already? Opening hours seems pretty limited in scope to me. I'm very happy to put together some more examples of using schedule and opening hours, but am wary about committing to building a testing framework where none exists. |
|
I've submitted PR #1693 to cover moving this to pending. Can I suggest that any further suggestions on naming, etc are added as comments on specific changes there? |
|
To throw something else in here: should we also include "duration" in the schedule? Currently this is defined in http://schema.org/Event, but would it make more sense to include it in the schedule along with the start and end times?
|
|
I think that duration would be good as an inherited property from Event, so that if it differs from the Event duration, it can be included in Schedule to override it, but isn't normally required there. |
|
Also have we factored in the "every 2nd Thursday of every two months" scenario here: openactive/implementation-tracker#6 (comment) |
|
@nickevansuk @dolkensp what use cases do we have for specifying duration? Some concrete examples would be useful. Duration can be derived from start/endTime so can be calculated, so really looking for examples of where a publisher couldn't just specify an end time. It looks like a simple change, but we'll need to be clear that what is being specified isn't the duration of a schedule (it has its own start/end times) and also avoid any confusion about having 2 properties both of which contain a ISO 8601 duration. @nickevansuk I've not considered the "every 2nd Thursday of every two months" scenario, largely to focus on getting the core properties in place. To make that change the This raises questions of how much of iCal to import (there are other "byX") properties and also complexity in working out the interplay between ISO 8601 durations and those properties. Anyone else have thoughts on that? Btw, I'm keen to get a basic proposal into pending (ref earlier PR) to capture what agreement we've been able to get to date, before extending further if possible. |
|
@ldodds You'll want to add duration. I agree for some of the same reasons that @nickevansuk gives. Sometimes folks just don't state the end time on even repeated events. Even cool calendar apps automatically calculate the endtime for you when you type or slide in the duration. "My meeting starts in 1 hour and I'll be tied up for 2 hours everyday this week....sorry, can't give more advice, gotta run" :) That's a use case for Google Home and Alexa. |
I think @ldodds's point was that given a start time, and a duration, we should be able to calculate the end time anyways. I'm inclined to keep both properties, as having the duration alone may be useful for some activities which take a fixed amount of time, but may be started at ANY time (private classes, etc) |
|
@ldodds in terms of duration, this is to allow the schedule to be expressed using either duration or endDate, and for it to explicitly override the duration in the parent event. In addition to the use cases above, using duration in the parent event when all other time-related properties live in the (potentially multiple) schedules seems inconsistent. In terms of iCal, we must be aware that many implementations will be mapping from iCal, so we need to be clear on the equivalence. Using a byDay property that accepts both DayOfWeek and iCal Text values (using iCal format, e.g. 2TH) makes sense to me, as we want to use as much of schema.org as possible while not reinventing the wheel when existing standards exist. Potentially referencing iCal text values is akin to using UN/CEFACT common codes (http://schema.org/unitCode). Given we're likely to want to have as much consistency as possible with Schema.org, but also mirror iCal's feature set, it looks like moving ahead with getting this into Schema.org pending asap would be a good step. |
|
Regarding "duration" - I expect there are cornercases (e.g. daylight saving time changes) when computing the duration requires background knowledge or a supporting library. Being close to iCal would be good (and we can ask that community for a sanity check too). |
|
Ok this is published now at schema.org (as 'pending', which means we want more review, discussion, implementor feedback e.g. w.r.t. mappings to ical, how to integrate with opening hours at least cross-referencing documentation, possible applicability in iot.schema.org, etc etc.). https://schema.org/docs/releases.html#g1457 Let's leave this issue open to continue the discussion! Thanks Leigh et al for getting us to this milestone :) |
|
Here's hoping BTW just wrapping my tired old brain around this stuff. Way cool ... but dynamically calling all the meetings for the next week as "Events" seems silly ... so thanks much for the work y'all have done towards make a Schedule a thing :) |
|
@EdB2 Everything is optional in Schema.org technically, its consumers of the data that place restrictions where they see fit. Ah, interesting use case with 12-step recovery groups ! Also, I see that use case as similar to perhaps a curriculum at a college where there's a final completion event of graduation after proceeding through all the courses (step 12 - "Carrying the message of the 12 Steps to others in need" is basically, "using the knowledge", just as students typically do after graduation. @danbri Perhaps this also brings about the need for a narrower type "CourseSchedule" based on evidence in issues: ? dunno, but something we should investigate more within those 3. |
|
@danbri can I suggest we close this issue? The original proposal is now part of pending. Further iteration can happen in separate issues? Can I ask what the process is for pending to move to live? |
|
Sorry just to pick up as I noticed this was closed, two things to raise:
|
|
I'm not sure if this is the correct place but I also noticed a couple of few other things. There are some inconsistencies in the https://pending.schema.org/Schedule specs and examples as well as with the original proposal here.
I also have a suggestion for exceptDate to accept Duration as a value, as in my case I need to express a period of holidays there. |
|
From the documentation:
An Event <https://pending.schema.org/Event> that is associated with a
Schedule <https://pending.schema.org/Schedule> using this property should
not have startDate <https://pending.schema.org/startDate>or endDate
<https://pending.schema.org/endDate> properties. These are instead defined
within the associatedSchedule <https://pending.schema.org/Schedule>
This would suggest to me that at the very least, the start date/time
properties are currently missing from Schedule documentation. From previous
comments in this thread, it would seem that StartTime/EndTime are expected
to be available, and I would expect StartDate/EndDate to be available too.
The documentation should also clarify if *Duration* is the duration of a
single event, or if it's the duration of the entire schedule. I'm assuming
the former.
…On Sat, Sep 1, 2018 at 8:40 AM, Kalin Maldzhanski ***@***.***> wrote:
I'm not sure if this is the correct place but I also noticed a couple of
few other things.
There are some inconsistencies in the https://pending.schema.org/Schedule
specs and examples as well as with the original proposal here.
1.
We have startTime/endTime missing, which could be represented as a
Duration and I assume this is the reason why "eventSchedule" property is in
there.
However, the documentation of it and the examples doesn't match.
On the other hand we have those mentioned in the release notes
https://schema.org/docs/releases.html#g1457
<https://schema.org/docs/releases.html#g1457>
What's the idea there?
2.
startDate/endDate for the validity of the Schedule (not the Event
duration), are also missing. what's the idea here?
I also have a suggestion for exceptDate to accept Duration as a value, as
in my case I need to express a period of holidays there.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1457 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAcqoojt2rupdv14jMT58jKLdd94wVe_ks5uWjn4gaJpZM4LNG0Z>
.
|
|
@ldodds can you help us with updating the spec if needed, and any evidence of adoption - especially consuming applications that use rather than just publish this vocabulary? |
|
I have some questions:
|
|
@danbri I'm going to defer to @thill-odi who is leading the specification work on OpenActive and can give you concrete examples. A quick look at the current docs suggest that they aren't correct. They should mention start/end Time and Date. Basically, I'd expect Schema.org to be reflecting most, if not all of the recommended approach that we have in the OpenActive documentation: https://www.openactive.io/modelling-opportunity-data/#publishing-event-schedules OpenActive will likely have its own conformance criteria but I was hoping that the core Schedule model could end up in Schema.org. I notice that the id/url template stuff is also not yet in Schema.org. I think that's useful on consumer side. |
|
Did I miss something? (Likely!) Is there any way yet of specifying the last Tuesday of every month? (Guess who has been asked to manage such an event and would now like to put up a page for with with correct metadata?) Is it byDay = "-1TU" and repeatFrequency= "P1M"? Rgds Damon |
|
For reference for anyone landing here looking for "last day of month" syntax, as far as I understand the docs, @DamonHD is correct because the docs for
And the iCal's docs says:
Meaning this should be valid. {
"@type": "Schedule",
"startDate": "2016-12-24",
"endDate": "2017-12-25",
"frequency": "P1M",
"byDay": "-1FR",
"startTime": "14:00",
"endTime": "15:00"
}It would be really useful to add a note to the |
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
scheduleproperty, aEventScheduletype and some additional properties for describing the schedule.The
scheduleproperty will be associated withEvents. It will allow the description of a schedule, expressed as a recurrence rule for describing the frequency of upcoming events.The
EventScheduletype 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 startsendTime- existing property, date/time at which the schedule endsfrequency- "daily", "monthly", "yearly"day- DayOfWeekmonth- month of the yearhour- hourminute- minutecount- optionally specfiy the number of recurring eventsexceptionRule- repeating property, specifies date-times when the schedule doesn't apply, equivalent toexrulein icalI 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.
The text was updated successfully, but these errors were encountered: