JIRA 82 Occurrences Proposed
Resolution
Title: Financial Dates incorrect properties usage
Description
Following the tightening up of domains and ranges in FIBOFTF2-10, some of the usages of one property
in the Dates and Times module cause incorrect classification. Three classes that have restrictions on the
property “designates” are now reclassified as Autonomous Agents because the property in Relations
now has a domain of AutonomousAgent.
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.
Model Changes
In Occurences,
On the diagram ‘Extensions to FinancialDates:

On property restriction fibo-fnd-dt-oc-01
o

On property restriction fibo-fnd-dt-oc-02
o

Change the target of the onProperty relation from ‘designates’ to ‘comprises’ (from
Relations)
On property restriction fibo-fnd-dt-oc-03
o

Change the target of the onProperty relation from ‘designates’ to ‘comprises’ (from
Relations)
Change the target of the onProperty relation from ‘designates’ to ‘comprises’ (from
Relations)
Remove ‘designates’ from the diagram
o
Note that the starting point of the work will show this not in the diagram because the
domain of AutonomousAgent was not on the diagram. Having added these to the
diagram to make the edit, they must now be removed
Also edit the diagram to remove the element IRI graphics – these do not belong on this style of diagram
but on separate annotations diagrams that are not published in the formal specification.
Updates to Annotations in FinancialDates
The use and intended application of the property ‘designates’ is written up in one or more annotations.
These are not in Occurrences but in FinancialDates. This reference needs to be edited to refer instead to
describe the use of the property ‘comprises’.
The affected annotations are in the FinancialDates ontology at:

AdHocScheduleEntry – one usageNote

RegularScheduleo
one skos:example (which also incorrectly states that the property is a property in the
Occurrences ontology and not in the Relations ontology)
o
one explanatoryNote
o

one usageNote
ScheduleStub
o
One skos:editorialNote
Changes Details
AdHocScheduleEntry
 Change the usageNote

From:
Other ontologies can extend AdHocScheduleEntry as needed.
In particular, the Occurrences ontology extends AdHocScheduleEntry to 'designate' an
OccurrenceKind. The meaning is that an Occurrence of the OccurrenceKind should
happen on the Date of the OccurrenceKind.

To:
Other ontologies can extend AdHocScheduleEntry as needed.
In particular, the Occurrences ontology extends AdHocScheduleEntry to 'comprise' an
OccurrenceKind. The meaning is that an ad hoc schedule entry comprises a date and an
event which is scheduled to occur on that date; in other words Occurrence of the
OccurrenceKind should happen on the Date of the OccurrenceKind.
RegularSchedule

Change the skos:example
o
which also incorrectly states that the property is a property in the Occurrences ontology
and not in the Relations ontology)
o
From:
A corporate bond pays interest for 10 years starting on the first day of 2015. Interest
payments are due 15 days after the expiration of each 6 month period: on July 15 and
January 16.
The payment schedule is a RegularSchedule, wiith these properties:
* designates: identifies the interest payment details
* overall DatePeriod starting date is "2015-01-01", ending date is '2025-01-15', and duration
is 'P10Y15D"
* hasCount is 20 (2 payments per year for 10 years)
* hasRecurrenceInterval is "P6M"
* hasRecurrenceStartDate is "2015-01-15"
o
To:
A corporate bond pays interest for 10 years starting on the first day of 2015. Interest
payments are due 15 days after the expiration of each 6 month period: on July 15 and
January 16.
The payment schedule is a RegularSchedule, wiith these properties:
* comprises: identifies the interest payment details
* overall DatePeriod starting date is "2015-01-01", ending date is '2025-01-15', and duration
is 'P10Y15D"
* hasCount is 20 (2 payments per year for 10 years)
* hasRecurrenceInterval is "P6M"
* hasRecurrenceStartDate is "2015-01-15"

Change the skos:example
o
From:
A 30 year mortgage is payable monthly on the 10th of the month, starting July 2015. The
mortgage is issued on June 15, 2015 so the first payment is for the period June 15-June 30,
and the last payment is for June 1-14 2045.
The payment schedule is a RegularSchedule with these properties:
* designates: regular payment OccurrenceKind (with payment details) (see the 'designates'
property of the Occurrences ontology)
* hasInitialStub: June 15-30, 2015 for initial payment
* hasFinalStub: June 1-14, 2045 for final payment
* hasCount: 358
* hasOverallPeriod starting Date: June 15, 2015 with a duration of 30 years
* hasRecurrenceInterval: specifies 10th day of each calendar month
* hasRecurrenceStartDate: July 1, 2015
o
To:
A 30 year mortgage is payable monthly on the 10th of the month, starting July 2015. The
mortgage is issued on June 15, 2015 so the first payment is for the period June 15-June 30,
and the last payment is for June 1-14 2045.
The payment schedule is a RegularSchedule with these properties:
* comprises: regular payment OccurrenceKind (with payment details) (see the ‘comprises’
property of the Occurrences ontology)
* hasInitialStub: June 15-30, 2015 for initial payment
* hasFinalStub: June 1-14, 2045 for final payment
* hasCount: 358
* hasOverallPeriod starting Date: June 15, 2015 with a duration of 30 years
* hasRecurrenceInterval: specifies 10th day of each calendar month
* hasRecurrenceStartDate: July 1, 2015

Change the usageNote
o
From:
Other ontologies can extend RegularSchedule as needed.
In particular, the Occurrences ontology extends RegularSchedule to 'designate' an
'OccurrenceKind'. The intended meaning is that an Occurrence of the OccurrenceKind
should happen on each Date defined by the RegularSchedule.
o
To: “
Other ontologies can extend RegularSchedule as needed.
In particular, the Occurrences ontology extends RegularSchedule to 'comprise' an
'OccurrenceKind'. The intended meaning is that a regular schedule comprises a number of
scheduled dates and an event which is scheduled to occur on each of those dates – in other
words an Occurrence of the OccurrenceKind should happen on each Date defined by the
RegularSchedule.
ScheduleStub

Change the skos:editorialNote
o
From
The Occurrences ontology extends ScheduleStub to 'designate' an OccurrenceKind. The
intended meaning is that an Occurrence of the OccurrenceKind should happen during
the DatePeriod of the ScheduleStub.
o
To
The Occurrences ontology extends ScheduleStub to 'comprise' an OccurrenceKind. The
meaning is that a schedule stub comprises a date period and an event which is
scheduled to occur during that date period; in other words that an Occurrence of the
OccurrenceKind should happen during the DatePeriod of the ScheduleStub.
Revised Text
Occurrences ontology
In the new sub-clause introduced in FIBOFTF2-22 as 10.13.2 (Ontology: Occurrences):
Replace the diagram ‘Extensions to Financial Dates’ with the version attached as JIRA82-1_Extensions to Financial Dates.svg
The Table “Occurrences Details” (introduced in Issue FIBOFTF2-22 as Table 10-69) when regenerated should show that the three restrictions
should give the related property as being ‘comprises’.
The affected table rows are given in the attached file JIRA82-2_OccurrencesRows.docx
Name
Type Of
Thing
Property
fibo-fnd-dtoc-01
property
restriction
01
comprises
fibo-fnd-dtoc-02
property
restriction
02
comprises
fibo-fnd-dtoc-03
property
restriction
03
comprises
Definition
Equival
ent to
Parent
Mutually
Exclusive
With
Set of things with
the property shown
with exactly one
taken from the
class of thing shown
Set of things with
the property shown
with exactly one
taken from the
class of thing shown
Set of things with
the property shown
with exactly one
taken from the
class of thing shown
Related
Thing or
Type
Inverse
Of
Property
Concept
Type
Editorial Note
Explanatory
Note
Definition
Source
Occurrence
kind
Occurrence
kind
Occurrence
kind
FinancialDates ontology
The Table “Financial Dates Details” (introduced in Issue FIBOFTF2-22 as Table 10-67) when regenerated should show that the table row entries
for the classe Schedule Stub will have changes to the “explanatory notes” column entry, as shown in the rows given in the attached file JIRA823_FincialDatesRows.docx
Name
ScheduleStub
Type Of
Thing
schedule
stub
Property
Definition
A ScheduleStub
identifies a
DatePeriod before
the start of the
recurring part of a
Equival
ent to
Parent
Mutually
Exclusive
With
Related
Thing or
Type
Inverse Of
Property
Concept
Type
Class
Editorial Note
The Occurrences
ontology extends
ScheduleStub to
'comprise' an
OccurrenceKind. The
Explanatory
Note
Definition
Source
Name
Type Of
Thing
Property
Definition
Schedule or after
the end of the
recurring part, and
an associated
OccurrenceKind.
Equival
ent to
Parent
Mutually
Exclusive
With
Related
Thing or
Type
Inverse Of
Property
Concept
Type
Editorial Note
meaning is that a
schedule stub
comprises a date
period and an event
which is scheduled to
occur during that date
period; in other words
that an Occurrence of
the OccurrenceKind
should happen during
the DatePeriod of the
ScheduleStub.
Explanatory
Note
Definition
Source