Add gist:scheduleSpecification property to gist:ScheduledEvent

[Jamie-SA]

It seems like gist:ScheduledEvent should support a "schedule specification". This would be to implement something similar to what the unix "cron" command does, or for adding recurring calendar events (however it doesn't have to be a recurring event so I don't use the word "recurring" anywhere in the terms).

My first thought was to add a new datatype property and modify the gist:ScheduledEvent restrictions to include it in a unionOf with the existing restriction on gist:plannedStartDate. However, Dave suggested creating a subclass of gist:ScheduledEvent and add the new restriction to it (which would then be an "and" of the 2 properties instead of an "or").

To be more concrete, a new property might be:

    gist:scheduleSpecification
           a owl:DatatypeProperty ;
           skos:definition "A specification of when something should happen."^^xsd:string ;
           skos:prefLabel "schedule specification"^^xsd:string ;
           skos:scopeNote "gist does not define the format. One option would be to use a 'cron' string."^^xsd:string ;
           skos:example "45 1 * * 1"^^xsd:string ;
           .

One option is to change the gist:ScheduledEvent definition to a union of 2 properties:

    gist:ScheduledEvent
           a owl:Class ;
           owl:equivalentClass [
                   a owl:Class ;
                   owl:intersectionOf (
                           gist:Event
                           owl:unionOf (
                                   [
                                           a owl:Restriction ;
                                           owl:onProperty gist:plannedStartDateTime ;
                                           owl:cardinality "1"^^xsd:nonNegativeInteger ;
                                   ]
                                   [
                                           a owl:Restriction ;
                                           owl:onProperty gist:scheduleSpecification ;
                                           owl:cardinality "1"^^xsd:nonNegativeInteger ;
                                   ]
                           ) ;
                   ) ;
           ] ;
           skos:definition "An event with a planned start datetime."^^xsd:string ;
           skos:prefLabel "Scheduled Event"^^xsd:string ;
           skos:scopeNote "If the event already started, but has not yet ended, it is a contemporary event with an actual start datetime. If the event is over, it is a historical event having an actual end datetime. The event always retains its planned start datetime, and thus continues to be a scheduled event."^^xsd:string ;
           .

Dave replied and suggested something like this below with the comment "with open world we don’t have to worry too much about the presence of the plannedStartDate. It does seem like in the real world, there would be a planned start date for the cron job (it may be redundantly expressed in the string) but it might be handy to have a real date that could be sorted on."

    gist:AutoScheduledEvent # need to pick a good name
           a owl:Class ;
           rdfs:subClassOf
                  gist:ScheduledEvent,
                   [
                        a owl:Restriction ;
                         owl:onProperty gist:scheduleSpecification ;
                         owl:cardinality "1"^^xsd:nonNegativeInteger ;
                   ]
                   ;
           .

[rjyounes]

This doesn't strike me as a core property. The specifications and examples you suggest are computer-based, and therefore could go into gistComputing.

Is this model meant to encompass the kind of auto-scheduling we do in, say, Outlook? In that case, you need a more complex model (which I actually built for a client). But that does not seem like a core functionality either.

[Jamie-SA]

I think it is kind of inherent in the concept of a Scheduled Event (that there are other ways to schedule an event other than just stating a planned start date), if so, then it seems like it should be included in the base definition. If changing the restriction to use a union seems like the best way to handle this, you can not do that in a lower level ontology after importing gist.

I specifically did not want to require any particular model other than (sort of required to) choosing between datatype property or object property. The actual implementation model should be left to a more specific domain model. I also tried to pick a fairly generic term for the property in order to not bind it tightly to any particular use case or technology.

It could be pushed into a lower level ontology if sub-classing seems like the best way to handle it. But then you have to import that whole ontology anytime you want to do a little calendaring.

Lastly, whether it ends up in gist or not, I am interested in the discussion about the tradeoffs between the two proposed modeling options.

[uscholdm]

II prefer the AutoScheduledEvent version over the union of restrictions. Maybe use a more generic property, to address Rebecca's concern. I like the idea of having the specification be a thing not a literal. That leaves open any level of complexity. ALternative:

    gist:AutoScheduledEvent # need to pick a good name
           a owl:Class ;
           rdfs:subClassOf
                  gist:ScheduledEvent,
                   [
                        a owl:Restriction ;
                         owl:onProperty gist:hasSpecification ;  [or maybe isSpecifiedBy to be more generic?]
                         owl:someValueFrom gist:SchedulSpecification ;
                   ]
                   ;
           .

[rjyounes]

Regarding datatype vs object property, a cron job could be specified with a string because there is a standard convention for doing so, as in the example "45 1 1" - at least I think that is what is being claimed. One could even define a datatype for such strings. I still believe modeling cron jobs doesn't belong in a core upper-level ontology. gistComputing would be a good place for them.

Then there are human schedules, such as we make in Outlook. To use in meaningful ways, you'd have to have a structured object rather than a string. Strings could be entered in various ways, for one thing. How do I know whether a meeting I want to schedule for October 1, 2023 at 10am conflicts with a series of meetings scheduled for the first of each month at 10:00 am ending on Nov 1, 2023, as opposed to one ending on Sept 1, 2023, unless I have broken down the data into pieces? Again, I think this goes way beyond the domain of a core upper ontology.

I've created such a model and used exactly what Michael suggests, a ScheduleSpecification (I called it just Schedule, I think "specification" is redundant in this case). We could reasonably put the Schedule class in gist without giving it further definition with additional classes and properties. Then @Jamie-SA's idea seems reasonable - a ScheduledEvent must either have a planned date (a one-off) or be determined by a schedule (as part of a series). But a schedule still provides a planned date for each of its events, so instead of the union we can just say, using OWA, the event has a planned date, and how that's determined differs from case to case and doesn't need to be expressed formally.

[uscholdm]

Then there are human schedules, such as we make in Outlook. To use in meaningful ways, you'd have to have a structured object rather than a string.

Exactly - that means an object property is warranted.

[uscholdm]

I've created such a model and used exactly what Michael suggests, a ScheduleSpecification (I called it just Schedule, I think "specification" is redundant in this case).

There is an important distinction. "Every Thursday from 10-11am with 12 occurrences" is a specification of a schedule. The actual schedule is the 12 occurrences with specific dates and times.

[rjyounes]

It's not worth debating the terminology, I guess, but I don't interpret "schedule" that way. The 12 occurrences are the scheduled events.

[rjyounes]

Thinking further about the terminological question, "schedule" can be used in both ways, to refer to the series of actual events with their datetimes (e.g., the display of a train schedule in the terminal) or the specification of that schedule (e.g., "What is the schedule of the train to Boston?" "It runs every hour on the half hour."). I suppose to avoid ambiguity we could go with ScheduleSpecification, although I like the conciseness of Schedule.

[uscholdm]

Thinking further about the terminological question, "schedule" can be used in both ways, to refer to the series of actual events with their datetimes (e.g., the display of a train schedule in the terminal) or the specification of that schedule (e.g., "What is the schedule of the train to Boston?" "It runs every hour on the half hour.").

Exactly. The distinction is very important, finding good terms is also important.