Replace usages of the property 'designates' in Occurrences and references thereto in FinancialDates annotations
Replace the references to the property 'designates' in three restrictions in the Occurrences ontology, with identicatl references to the property 'comprises', from Relations.
Edit references to these in the annotations in the FinancialDates ontology.
Discussion and Rationale:
Discussion
From Elisa Kendall:
There are three places where 'designates' is used in FinancialDates:
AdHocScheduleEntry, RegularSchedule, and ScheduleStub. The sense that Mark had originally was that a schedule entry would designate an
occurrence kind, so that an occurence of that schedule entry would be of
exactly that occurrence kind. We have two options here:
(1) remove AutonomousAgent as the domain of designates, or (2) use a
different property in FinancialDates in these restrictions, revising the
definitions appropriately.
My preference is that we do (1), since I think the usage is in keeping
with the definition of designates before AutonomousAgent was added as
its domain, but if you were to do (2), an alternate property would be
denotes.
Investigation
The restrictions are actually in the ontology “Occurrences” where there are additional assertions applied to the three classes named above (via three proxy classes in VOM). The three applications of this property are therefore all in the Occurrences ontology.
The semantics of “designates’ was significantly overhauled in FIBOFTF2-10 (the ‘Property Domains and Ranges’ issue resolution). The original dispensation of designates, hasDesignation and the child property ‘appoints’ and its inverse ‘isAppointedBy’ were inconsistent with each other and with the stated definition, which explicitly referred to the deliberate act of designating (therefore by some person), some other person to some role or position.
The suggested alternative above is to use ‘denotes’.
The property ‘denotes’ is a child of ‘represents’ and links a class of “Representation” to a class of thing which it represents – that is, this is a relationship between some form of representation and something which it is a representation of, the form of representation in this case being denotation.
The use of ‘denotes’ would work if it is OK to regard AdHocScheduleEntry, RegularSchedule, and ScheduleStub as kinds of representation, which will be OK if the semantics of “Schedule” (being the parent of RegularSchedule, and ScheduleStub) is intended to refer to the data representation of a set of dates and events, and not to the set of dates and events itself.
There are two possible meanings of “Schedule” in general: it may mean a set of dates and events or it may mean the representation of those. Given the split between ad hoc and regular schedules, this would suggest the latter. That is, the real thing in the world which is a set of dates on which events occur, may be represented by one of two means: as an ad hoc listing of dates with an event for each, or as a parametric representation from which the individual occurrences of the event may be calculated.
This would make the use of ‘denotes’ appropriate.
On the other hand, Schedule itself has a property ‘hasOverallPeriod’ which is described as a date period, and the third class in the above, AdHocScheduleEntry has a property ‘hasDate’ which takes the Range of ‘Date’. These suggest that Schedule and AdHocScheduleEntry are really intended to be real things that are a schedule or schedule entry and that have a duration or a date (otherwise the properties would be ‘definesOverallPeriod’ and ‘definesDate’) which they are not. These properties are themselves sub properties of ‘has’, meaning that they are an actual characteristic of a thing and not a data representation of a characteristic of a thing.
That being the case, it would be wrong to cause the model to infer that a Schedule or an ad hoc schedule entry are really kinds of representation, and therefore it would be wrong to use the property ‘denotes’. What is needed instead is an assertion that a schedule, stub or ad hoc entry each includes as part of it, some event (the OccurrenceKind which is the target of the required property as restricted in each case).
It would also be optimal to use an existing property in Relations if there is one.
Therefore the best solution is to use the property ‘comprises’ from Relations. This has a domain and range of Thing and has the definition: “includes, especially within a particular scope, is made up of”.
This has the effect of saying that a regular schedule, a schedule stub and an ad hoc schedule entry each comprises (among other things e.g. the date or regular period), some kind of occurrence i.e. some event.
