This section of the document should be revised to discuss the "about" files

Add description of About files and edit existing descriptions of metadata to reflect these

A new set of files are now released the machine readables for every FIBO submission. These have the effect of putting the module metadata in an about file for each module and the specification metadata in an about file for the specification, along with a version-specific about file describing the changes in that specific release.

These are not currently described in the metadata chapter of the FIBO Foundations specification, where they should be.

In addition, these are presented as ontologies and have their own namespace abbreviation. Therefore the table showing namespace abbreviations for each specification (including chapter 8 in the Foundations specification) need to include the namespace abbreviations for these.

This metadata was previously repeated in each ontology file, and no longer is. Any references to that previous arrangement will need to be corrected in Chapter 9.

Several new ontologies have been added as a part of FTF 2, including a new module, which affects Figure 8.1 and Table 8.3. These should be revised accordingly.

Updates to Architecture section 8 to reflect new modules and ontologies

Several new ontologies have been added as a part of FTF 2, including a new module, which affects Figure 8.1 and Table 8.3. These should be revised accordingly.

Details
New module(s) introduced in FTF2:
• Arrangements
• DatesAndTimes
The affected table (Table 8-3) actually shows individual ontology namespaces not just modules.
New ontologies introduced to existing modules in FTF2:
• OwnershipAndControl/OwnershipAndControl
• Places/Facilities
• Places/VirtualPlaces
• Utillities/Analytics
Full list of new row entries required in the namespace abbreviations table:
• Arrangements/Arrangements
• Arrangements/Codes
• Arrangements/documents
• Arrangements/IdentifiersAndIndices
• DatesAndTimes/BusinessDates
• DatesAndTimes/FinancialDates
• DatesAndTimes/Occurrences
• OwnershipAndControl/OwnershipAndControl
• Places/Facilities
• Places/VirtualPlaces
• Utilities/Analytics

On review of changes made previously to implement the "Lattice" pattern, some existing model elements needed to be removed, and additional ones added, for this to fully reflect the intended model.

Changes for Lattice Pattern in FIBOFTF2-56 merged with FIBOFTF-17

The proposed resolution for the issue FIBOFTF2-56 is described in the issue resolution sub-issue for the merged issue FIBO-FTF-17

Changes identified during subject matter expert review for agreements and contracts.

Implement minor changes in Agreement and Control for FIBOFTF55

At a Subject Matter Expert review with GRCTC the following observations were made which should be taken into account in the Agreements and Contracts ontologies”
• Contracts are necessarily bilateral – this does not mean they have two parties (bipartite) but that they have two sides
• Agreements with more than two sides, for example partnership agreements, are not contracts in that sense but are agreements
o FIBO BE will also need to be changed, to make OrganizationCoveringAgreement a child of Agreement not Contract
• CommitmentAtLarge should be a kind of UnilateralCommitment.
• A further kind of unilateral commitment would be one where one party makes a commitment explicitly to another party with their agreement. We did not discuss a name for this.
• Contract types should follow this, with TransferableContract becoming a kind of UnilateralContract (as well as its current parentage)
• TransferableContract was our own made-up name. Discussed whether there is a better name covering not only securities but other kinds of contract that can be passed on without the involvement of the principal, such as software licenses.
o Agreed we could call this NegotiableContract
• There is a separate legal situation in which a contract is assignable – this is where some part of the responsibilities of one or other party is handed on to a third party such as a bank, with the agreement of the principal. The two parties to the contract remain parties to that contract.
o This is covered in the definition and notes for isAssignable already and in an editorial note on TransferableContract
• Covering agreements such as a Master Agreement in swaps trading forms part of the arrangements around an agreement or transaction, by way of a kind of “Mechanism”
o We need not include this in FIBO Foundations but would want to consider it when implementing the REA concepts for Derivatives.
Not all of these insights will be implemented at the present time, for example we don’t really have the means to describe “sides” of an agreement – these would need to be framed in terms of clusters of commitments made by each party to the other(s).
We also do not have an obvious means of framing the “Mechanism” role of a master agreement, and will need to think about this during work on derivatives.

There are 3 things that needed to be done in OWL files subsequent to the completion of the written specification. These are:
• Missing imports
• Missing ‘references’ relationships
• Use of non compliant text characters from Word (smart quotes, em dashes etc.)

The “Missing” imports are the only ones of these that will impact the written specification, where these will need to be added to the imports list in the ontology metadata in Section 10.

There are two kinds of “Missing” imports:
• Non conformance with the recent stated policy of including an import for every element that is directly reference from an ontology, even if it is already in the imports chain; (note there are also too many imports in many cases because of this)
• At least one where there was no import of some element in the imports chain, which would cause the ontology to fail for those users who use the conformance point whereby they use a FIBO ontology in isolation.

Add and remove sm:dependsOn line entries in ontology metadata tables

For the ontologies listed by Elisa Kendall as having required changes to bring them into line with the new policy and / or which needed additional imports to support recent issues:

where the new policy identifies that the reference is no longer needed remove it;

where an ontology import was needed and was not reported in the table, add it.

See attached document for analysis of what changes were needed with reference to the overall list of ontologies that required hand editing changes since the specification was generated.

Lint findings: these point to model features in which it is possible that the model is saying something other than we intend it to say. These are therefore investigated as part of testing.

Two lints were found which represented possible issue with the use of equivalent class axioms. Specifically, the equivalence was related to a class which itself had other sub class relationships which may cause the model to say more than we want it to say. These were:

• People – there is a union class which is equivalent to the named class “LegallyCapablePerson” while this is also a sub class of Person

• Contracts: there is one equivalent class relationship to a restruction, but there are also two other restrictions with subClassOf relations to this class, and it also has two parent classes (UnilateralContract and WrittenContract). Some but not all of these were introduced after the equivalentClasswasintroduced.

Additional analysis of the Contract model also reveals that while the property ‘isEvidencedBy’ is defined with relation to the class “WrittenContract”, what we actually intended to say was that a written contract is defined by the fact that it has the propertyisEvidenecdBy. This requires a restriction in addition to the presence of that property.

Lint Details
People
People.rdf has this issue with LegallyCapablePerson:

<owl:Class rdf:about="http://www.omg.org/spec/EDMC-FIBO/FND/AgentsAndPeople/People/LegallyCapablePerson">
<rdfs:label>legally capable person</rdfs:label>
<owl:equivalentClass>
<owl:Class>
<owl:unionOf rdf:parseType="Collection">
<rdf:Description rdf:about="http://www.omg.org/spec/EDMC-FIBO/FND/AgentsAndPeople/People/EmancipatedMinor"/>
<rdf:Description rdf:about="http://www.omg.org/spec/EDMC-FIBO/FND/AgentsAndPeople/People/LegallyCapableAdult"/>
</owl:unionOf>
</owl:Class>
</owl:equivalentClass>
<rdfs:subClassOf rdf:resource="http://www.omg.org/spec/EDMC-FIBO/FND/AgentsAndPeople/People/Person"/>
<skos:definition rdf:datatype="http://www.w3.org/2001/XMLSchema#string">a person who is allowed to conduct a business or any other occupation on his or her own behalf or for their own account</skos:definition>
</owl:Class>

The subclassof Person should be removed.
Contracts
The lint report from pellet is that it doesn't like complex class expressions as subclasses of other things. This happens in TransferableContract (expurgated quote):

fibo-fnd-agr-ctr:TransferableContract
a owl:Class ;
rdfs:label "transferable contract" ;
rdfs:subClassOf fibo-fnd-agr-ctr:WrittenContract , fibo-fnd-agr-ctr:UnilateralContract ;
owl:equivalentClass [ a owl:Restriction ;
owl:minQualifiedCardinality "1"^^xsd:nonNegativeInteger ;
owl:onClass fibo-fnd-agr-ctr:ContractOriginator ;
owl:onProperty fibo-fnd-agr-ctr:hasPrincipal
] .

The issue, from Pellet's point of view, is that equivalentClass to a complex expression (a cardinality restriction) and the subclass to a named class (two of them, in fact).

There is another issue in this pattern that is potentially problematic, and that is that having the restriction equivalent to this class means that anything that satisfies this restriction (e.g., has a single principal that is a ContractOriginator) is therefore a transferrable contract (and is therefore a WrittenContract and a UnilateralContract).

Implement recommendations from lint tests and review

As recommended in the lint tests:
People
Delete the subClassOf relation for LegallyCapablePerson

Contracts
Make the class TransferableContract equivalent to a union of all of the restriction and sub class axioms that it currently has a relationship with.

Add a restriction on WrittenContract to make the isEvidencedBy property a necessary condition for that class.

Following the changes in Roles to support the new lattice pattern used in Ownership and Control, the elements Role and hasRole have been deprecated. These are referred to by a restriction in the Facilities ontology.

Update the Facilities ontology to use isPlayedBy in place of hasRole

Change facililties ontology to use new Roles pattern

Following the changes in Roles to support the new lattice pattern used in Ownership and Control, the elements Role and hasRole have been deprecated. These are referred to by a restriction in the Facilities ontology.

Update the Facilities ontology to use isPlayedBy in place of hasRole

Also checked VirtualPlaces as this was not included in the initial analysis for changes to hasRole – there are no changes required in VirtualPlaces for this issue.

The class NegotiableContract (formerly TransferableContract) is to be renamed to TransferableContract

The original name "transferable contract' was selected as being self-defining but was not a legally attested label. This was changed to NegotiableContract as this is a parent of negotiable securities (it is what they are a kind of). However this label introduces an implication of negotiability between parties in a mutually agreed, bilateral contract which is not what is intended. What is intended is the definition of kinds of contract (not all of them negotiable financial securities) in which there is a commitment at large extended by one party to that contract so that the other party may purchase or sell that contract. In the absence of a legal label we should revert to the self-defining label "TransferableContract"

Renaming of Negotiable Contract

The class NegotiableContract (formerly TransferbleContract) is to be renamed to TransferableContract

With the introduction of the FinancialDates ontology, there are many properties which are currently framed as datatype properties with the dateTime datatype but are actually intended to refer to dates. Now that the concept of Date is available as a class in FinancialDates a number of properties in different ontologies should be replaced by object properties with a range of Date.

Many of these properties are in the Relations ontology, which does not import FinancialDates, an therefore these properties would also need to be moved to the ontologies in which they are used.

Merge the changes for FinancialDates implemented with the changes for property domains and ranges.

Merge this issue with FBO-FTF2-10 Property Domains and Ranges.

The work description and the formal Revised Text material for FIBOFTF2-10 will include actions in response to this issue alongside the overall domains and ranges issue.

There is no rationale for the OWL equivalent class relationship between Organization and sm:organization and this should be removed.

Remove equivalence relation between Organization and sm:Organization

There is no rationale in FIBO itself for the OWL equivalent class relationship between Organization and sm:organization and this should be removed.

Checked the annotations for any reference to this: there is none

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.

Following the investigation described below, it was decided that all three usages of this property should be replaced with the use of the property 'comprises (in Relations). See below for reasoning and alternatives considered.

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.

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.