- From: Erik Paulson <epaulson@unit1127.com>
- Date: Mon, 9 Aug 2021 18:27:22 -0500
- To: public-schemaorg@w3.org
- Message-ID: <CAKJO4n58i7Z=50S+UOLbnLxKjCxEwh1ZYeKoF4xYnm0eMJnDtg@mail.gmail.com>
Hello - I’m working with the Brick Schema (https://github.com/brickschema) which is an RDF ontology for buildings/energy/IoT/etc. Schedules are a pretty important part of that world, and rather than inventing our own format, we’d like to use the Schema.org data types. The Schedule type seems like a good fit: https://schema.org/Schedule Consuming systems are things like HVAC/lighting/security automation systems in a building, and any applications that might analyze data coming out of these systems. We are trying to be careful not to put too much in the way of semantics on the schedule object - for example, the schedule that the lights follow is probably similar to the schedule for which the building or business is “open” but it might not be quite the same thing. So we will want to be able to have multiple “schedules", the meaning of each to be determined by some other properties and relationships (hence, why would prefer the ‘Schedule’ type over the ‘OpeningHoursSpecification’ type) Schedules in this world are usually built up around a definition for a typical week. Most software creates a base schedule for a week, and then adds additional “exception” schedules on top of it. (Schedule objects get some kind of ‘priority’, in that the base schedule has the lowest priority and a ‘holiday schedule’ has higher priority, overriding the base schedule for the days that are holidays. The control software knows how to interpret the priorities and pick the right definition). There can be multiple exception schedules - think global exceptions and then local exceptions. I don’t know how we would deal with the ‘exceptDate’ property that’s already in the ‘Schedule’ object, but I think there's still a sensible interpretation of that even with multiple 'schedules'. Boundary conditions are super-important, especially for security systems. You don’t want to define a day as running from 00:00 to 23:59, and have a door unlock for 1 minute at 23:59 only to relock again 00:00 - we want to be able to say that the bar opens at 12 noon and closes at 1am the next day, and have that be one continuous stretch of time. It’s also common to want to do occasionally strange-looking repeats - you may have processes in your building that should happen on odd-numbered days, even though that means you go twice in a row when the calendar goes from July 31st to August 1st. I was hoping that someone could just spot-check me and make sure that I’ve got this right. It's abusing the 'evenSchedule' property a bit, but I’m imagining a schedule for say a pub, so something that’s open most but not all days of the week and usually closes at midnight, except on Friday and Saturday when it might stay open til 2am amd hence cross midnight, and on Sunday where it closes earlier: { "@context": "https://schema.org", "@type": "Event", "name": "Schedule Example", "eventSchedule": [ { "@type": "Schedule", "startDate": "2016-01-02", "repeatFrequency": "P1D", "byDay": ["TU,WE,TH"], "startTime": "12:00:00", "endTime": "00:00:00", "scheduleTimezone": "Europe/London" }, { "@type": "Schedule", "startDate": "2016-01-02", "repeatFrequency": "P1D", "byDay": ["FR,SA"], "startTime": "12:00:00", "endTime": "02:00:00", "scheduleTimezone": "Europe/London" }, { "@type": "Schedule", "startDate": "2016-01-02", "repeatFrequency": "P1D", "byDay": ["SU"], "startTime": "12:00:00", "endTime": "23:00:00", "scheduleTimezone": "Europe/London" } ] } (I’m using the RRULE syntax for ‘byDay’. I’m hoping that you can also use RRULE for byMonthDay too, because I might want to say something special about the last day of the month: { "@context": "https://schema.org", "@type": "Event", "name": "Count Example", "eventSchedule": { "@type": "Schedule", "startDate": "2016-12-24", "repeatFrequency": "P1M", "byMonthDay": [-1], "startTime": "09:00:00", "endTime": "17:00:00", "scheduleTimezone": "Europe/London" } } The “what should actually happen” when a schedule is “True” is a separate question - it might be the business is now open, or the light turns on, or the air conditioner lowers the temp or a heater raises the temp, or a door locks or unlocks, or who knows. I think what we’re looking for is just to be able to compactly say “given this schedule, does the current time fall in a time range defined by the schedule?” with either a ‘True’ or ‘False’, and we’ll figure out a new property to use in our ontology other than eventSchedule. We discussed this some on our mailing list and had a few more use case examples, mostly in how to translate over to recurrence rules, though none marked up in actual schema.org markup: https://groups.google.com/g/brickschema/c/5dWnd8_P9zA Thanks for reading this far and for any advice you can give! -Erik ps I’m happy to switch this over to a Github Discussion if you’d prefer to use that instead.
Received on Monday, 9 August 2021 23:30:48 UTC