This change is needed so that when people load the ontologies using the about files they get precisely the version that they have asked for, with all of the IRIs reflecting the corresponding specification version.

The impact here is on the 1.0, 1.1, 1.2, and 1.3 (new) about files for FND, at their version-specific (yyyymmnn) and non-versioned1.x locations; the about FND (non-versioned) ontology should be revised to include all of the non-versioned IRIs (i.e., latest) for FND, for ease of use by anyone wanting the latest version without concern for the specific versions of the individual ontologies.

Corrections to two of the ISO 4217 currency codes are needed to reference the latest revisions to LCC, and the FND 1.3 about file needs to import the language codes to correct references as well as refer to the proper version of the country codes.

There are a couple of property references in the currency codes that cause punning for currency identifier and funds identifier that should be eliminated.

Terms_Agreement: I agree
First_Name: John
Last_Name: Gemski
Email: jgemski@thegoldensource.com
Company: GoldenSource Corp
CODE: OMG621
B1: Submit

Comments:

The xml files contained in "Updated UML-XMI for Foundations" (finance-13-09-06.zip) cannot be imported into our UML tools. We tried Visual Paradigm and Erwin and got the same results. Only the class name was imported.

Inability to import UML-XMI files into generic UML

The resolution to this issue requires submitting a single UML project for all of the FIBO ontologies, which the FIBO team has determined may be accomplished via a new approach to integration of the UML XMI. Testing this has necessarily been deferred to a subsequent revision task force due to the need for modifications to the existing tool infrastructure used to generate the XMI, however.

Terms_Agreement: I agree
First_Name: John
Last_Name: Gemski
Email: jgemski@thegoldensource.com
Company: GoldenSource Corp
CODE: OMG621
B1: Submit

Comments:

The xml files contained in "Updated UML-XMI for Foundations" (finance-13-09-06.zip) cannot be imported into our UML tools. We tried Visual Paradigm and Erwin and got the same results. Only the class name was imported.

These are in informative about files for several of the FIBO FND modules, and do not affect the specification itself, but should be corrected with the FND 1.2 submission.

In addition, the original AboutFND-1.0 and AboutFND-1.1 files should be revised to use the original versionIRIs for ontologies that are modified by the FND 1.2 revision, so that they still reference the older versions for users that choose not to update to the latest. A new AboutFND-1.2 file should be provided to reference only the latest revisions of all of the ontologies that make up the FND specification.

The informative files should be provided in a separate archive from the normative files with the FND 1.2 revision.

Several FND about files have incorrect prefixes

This issue affects informative machine readable files only, and has no impact on the specification text.

It involves (1) providing a new FIBO FND 1.2 about file for the latest version of the specification, which describes the revision and provides metadata for use on the OMG server in the specification catalog as well as acting as a "make file" for the ontology, (2) revising the FIBO FND 1.1 about file to reference the versionIRIs from the prior version of the ontologies, for those users who are not ready to adopt the latest versions, and (3) corrects the about files for several of the modules in FND, attached.

Note that the FND 1.0 about file for FIBO FND 1.0 does not need revision.

The concept of a structured collection is not limited to indicators, and should be moved from IND to FND/Arrangements. This is needed so that a new concept, that of a Record, can be added to FND/Documents (using the definition from the OMG's RMS), as a child of Document and of StructuredCollection, which is required to fix the definition of an account in FBC.

This is a first step in the process – a subsequent revision to IND should deprecate the current StructuredCollection concept in favor of this one added to FND.

Move StructuredCollection from IND to FND

The concepts of a structured collection and record are needed to support a number of downstream definitions, and because they are very general notions, they should be added to Foundations.

The definition of transferable contract is an equivalence of a number of restrictions with both written contract and unilateral contract. Not all transferable contracts are unilateral, however.

Unilateral contract should be eliminated from the intersection, and, per the FIBO development policy, the two min 1 QCR restrictions in the intersection should be changed to someValuesFrom.

Not all transferable contracts are unilateral

The definition of transferable contract is defined as the intersection of written contract, unilateral contract, and several restrictions - that it confers some commitment, that it has a minimum of 1 ContractPrincipal and that it has a minimum of 1 ContractCounterparty.

This definition is overly restrictive and should be loosened to eliminate the requirement for being a unilateral contract. Further, the min 1 restrictions should be changed to someValuesFrom, which is more efficient from a reasoning perspective. Without eliminating the constraint that a transferable contract must be unilateral, the FIBO FBC specification cannot depend on this concept as a parent for security.

This resolution depends on the resolution of FIBOFND12-7.

As noted by several FCTs, the current Contract Terms Set concept does not adequately capture the semantics of contract terms, and is also named misleadingly.

This was originally modeled as a grouping of terms, which are terms of the contract, according to some common theme such as interest payment or call terms. The current OWL logic does not reflect that these are a common grouping of terms whose intended range would be that of the Contract.

One change needed is to revise the term that is called Contract Terms Set, which is in effect a Commitment, to actually make it a child of Commitment, thus making the terms of the Contract Terms Set qualifying terms of the Commitment.

This does not reflect the whole story, since those properties which qualify a commitment are themselves also terms of the contract. This can be implied, as a minimum, by identifying that the Commitment is itself related to the contract by some kind of parthood. Changes have been identified by the Foundations FCT to address this, and in fact the kind of parthood relation referred to here applies to things other than the Commitment.

Revise and refactor ContractTermsSet and its relationship to Contract

This issue affects section 10.9.2 Ontology: Contracts. It calls for the addition of a new concept, ContractualCommitment, as a child of both ContractualElement and Commitment, changing the parent class of ConditionsPrecedent and NonBindingTermsSet (renamed via deprecation of the original and the addition of a new NonBindingTerms concept) from ContractTermsSet to ContractualElement, revision of definitions related to contractual element, adding definitions for contractual commitment and deprecation of contract terms set. A new property, hasContractualElement, is introduced as a replacement for hasTerms (which is deprecated via this resolution), and finally deprecation of ContractTermsSet.

Minor clean-up of annotations should also be accomplished as appropriate (such as elimination of preceding ‘ ‘ in front of some annotations or at the end of others, revising definitions and sources for some of the existing terms to align better with the new ones, etc.).

Finally, while working through the resolution text, the task force noted that the part of the table describing the properties details for this ontology was incorrect, copied from another ontology and including the properties from that ontology not contracts. This resolution fixes that.

This resolution depends on the resolution to issue FIBOFND12-5.

Several concepts, such as business recurrence intervals including the day of the month, day of the week, and end of the month (as classes) are needed to support downstream FIBO development, such as for securities and loans.

In addition, a higher level concept of convention is needed to capture business day adjustments and conventions as their parent class, to clean up the hierarchy.

A number of the definitions in the BusinessDates should be cleaned up as a part of this revision to follow our policy for use of ISO 704 conventions for definition development as well.

Several additional concepts are needed in the Business Dates ontology to support specific schedule definitions

The primary modifications made by this resolution primarily involve the addition of Convention as a structural concept to group some of the others in this ontology and the addition of three classes as business day conventions, including day of the month, day of the week, and end of the month, all of which are needed to support more complex schedule definitions in downstream FIBO ontologies.

A handful of definitions were revised to support an ISO 704 approach and a couple of missing definitions were added for some properties.

A schedule is defined as a collection of potential / planned / possible / past / events associated with dates. It has no parent class at the moment, but should be modeled as a child of Collection. It's definition should also be revised to reflect the broader sense as stated herein rather than as a "table of dates", with an explanatory note that talks about the difference between ad hoc and regular schedules.

There are a number of places in the other downstream FIBO ontologies where the use of a generic hasSchedule property would be appropriate in restrictions, rather than inventing several local and more restricted properties.

In addition, the custom datatypes for dateValue and durationValue should be deprecated in favor of xsd:string, to eliminate reasoning errors in downstream processing.

Individuals for the days of the week are also needed to support definition of certain rules for loans (interest payments) and coupon payments. These should be defined as time intervals in accordance with the OMG DTV specification.

A number of the definitions need to be reformulated to correspond to our policy of using ISO 704-style definitions as well.
Attachments

Schedule in FND/DatesAndTimes should be a child of Collection

This issue resolution covers a number of issues in the FinancialDates ontology, including addressing the problems identified in the issue itself, including numerous editorial changes to the annotations on various concepts in the ontology, as highlighted in the text of the resolution, attached below.

comprises is used in places in FIBO as a broader concept than has part, that is somewhat related to hasPart (i.e., similar to and possibly a synonym of includes), where we need cardinality restrictions on how many parts of some type that something can have, or on the thing that something must be included in. Comprises is not defined as transitive to facilitate the use of cardinality restrictions.

In order to help make this clear, we need an explanatory note on comprises, and an inverse for it, possibly called isIncludedIn, that can be used for this purpose.

comprises needs an explanatory note and inverse property

This issue involves adding a note to the definition of comprises as well as creating a new inverse property, isIncludedIn, for use in other downstream ontologies.

The resolution of this issue depends on the resolution of FIBOFND12-2 and FIBOFND12-3.

The "isUsedBy" property links a currency to the geopolitical entity that uses that currency, and was originally intended to be useful with not only autonomous agents but entities such as geopolitical entities in its range.

The addition of the domain for uses and range for isUsedBy as a part of the FND 1.1 RTF work now cause individuals that are geopolitical entities to be inferred to be AutonomousAgents, which is wrong.

The domain of uses and range of is used by should be removed, eliminating this constraint, and the definitions revised accordingly.

The domain of the "uses" and range of "isUsedBy", added in FND 1.1, cause reasoning errors

The correction to this issue involves loosening the domain and range restrictions on two properties: isUsedBy and uses in the Relations ontology, and revising the definition of uses so that it does not refer to an autonomous agent as the entity in the domain of uses.

Resolution of this issue depends on the resolution to FIBOFND12-2.

provides: makes something available to

The “to” at the end implies a 3 way relationship between provider, what’s provided and whom it is provided to. In fact the predicate does not involve the latter at all so the “to” should be removed.

Definition of property 'provides' implies a specific audience

Resolution of this issue requires (1) modification of the Relations ontology to revise the definition of provides, and (2) modification of Table 10-11, Relations Details, to make the corresponding change to the text of the definition.

The change to the ontology itself necessitates revision of its version IRI as well.

The current set of about files for FND does not include the latest ontologies. These should be revised so that a user can automatically import the entire set of ontologies for FND if so desired.

This issue affects machine-readable files only, and has no impact on the specification text.

Revise the about files for FND to include the new ontologies added by FBC

Two machine-readable files are affected by this issue resolution, which does not make any changes to the specification text.

The FIBO FND 1.0 about file requires revision to (1) include the module-level about files, and (2) use the versioned IRIs for the set of ontologies that comprise the FIBO FND 1.0 specification.

In addition, a new FIBO FND 1.1 about file is needed to incorporate all of the new ontologies integrated via FBC as well as to include the reference to the LCC Country Codes ontology required for representation of Currency Codes in FND 1.1.

FIBO now allows for the usage of all constructs in ODM. We should therefore remove any references o FIBO defining as part of the standard a sub-set of ODM to be used in FIBO models.

Amend Clause 8 to reflect possible use of all ODM constructs

In Clause 8.1:
1. Remove sub-clause 8.1.2 including Table 8.1 (and renumber subsequent tables)

2. Delete the two sentences in 8.1.1 which read:
“The FIBO specifications use an explicit subset of ODM as detailed in Table 8.1 below. This subset eliminates some of the flexibility that ODM provides in exchange for consistency in terms of the graphical notation. “
3. Remove heading for 8.1.1

There is a disagreement in the FIBO LOANS working group for what to use for LoanAmount, PropertyValuationAmount, and other types of concepts usually based on a measure of currency. This is caused by confusing definitions of MonetaryAmount and MoneyAmount. This confusion should be resolved so that FIBO users know what concept to use for what purpose.

Resolve issues with Monetary Amount and Amount of Money

There is a disagreement in the FIBO LOANS working group for what to use for LoanAmount, PropertyValuationAmount, and other types of concepts usually based on a measure of currency. This is caused by confusing definitions of MonetaryAmount and MoneyAmount. This confusion should be resolved so that FIBO users know what concept to use for what purpose.

This issue affects sections 10.12.1, Ontology: AccountingEquity, and 10.12.2, Ontology: Currency Amount. It requires that the revisions identified in resolutions to issues FIBOFND11-10 and FIBOFND11-20, which revise the Currency Amount ontology, have already been applied.

The business entities standard requires the notion of litigation capacity in addition to other capacities already provided in the LegalCapacity ontology. This is a capability of a LegalPerson, LitigationCapacity would be a subClassOf LegalCapacity.

Introduce the concept of Litigation Capacity into the LegalCapacity ontology

The business entities standard requires the notion of litigation capacity in addition to other capacities already provided in the LegalCapacity ontology. This is a capability of a LegalPerson, LitigationCapacity would be a subClassOf LegalCapacity.

This issue affects section 10.10.3 Ontology: Legal Capacity. It depends on the resolution of FIBOFND11-14, which also modified the Legal Capacity ontology.

Some of the revisions made to the 1.0 FND specification, including those made by FBC, have revised the table notation included in section 10 of this specification. The new notation should be described in section 6, and the various tables that have not been revised by other resolutions should be updated accordingly.

Addition of new Clause 6.3, changes in other Clause 6 mterial, plus new tables in Clause 10

This proposal covers all the works required for resolution to number 42 (originally in the accident-prone #52 which may now safely be ignored or closed))

The latest thinking with respect to the FIBO specifications and conformance was captured in FBC. The Foundations specification needs to be revised to reflect these changes as well, particularly with respect to how other specifications should reference the various conformance points.

Changes to wording in Conformance clause

“FIBO Model Conformant”
1. Change the heading 2.2.1 from
2.2.1 Assessing Model Conformance

To

2.2.1 Assessing FIBO Model Conformance

2. In the first paragraph in sub clause 2.2.1 italicize the words “FIBO Model Conformant”

(also a change that is in the redline but may or may not have been covered by another issue):

In Sub-clause 2.2.2.1 insert the word “Foundations” between “FIBO” and “Model”

So that the clause which reads:

“If a technical application is FIBO Model Conformant with the complete set of FIBO Foundations ontologies, then the application satisfies Full FIBO Model Conformance.
Now reads
“If a technical application is FIBO Model Conformant with the complete set of FIBO Foundations ontologies, then the application satisfies Full FIBO Foundations Model Conformance.”

“FIBO Extension conformant”
1. Rename the heading for Sub-clause 2.3
From:
Conformant Extensions of FIBO Content
To
FIBO Extension conformance
2. In paragraph 4 of this sub-clause, italicize the words “FIBO Extension conformance”
FIBO Business Diagram Conformance and FIBO Business Table Conformance
1. In sub-clause 2.4, insert the following text after the existing text:
“For the avoidance of doubt, this sub-clause describes diagrams which are to be presented to business subject matter expert and not diagrams which form part of this specification itself. FIBO Model Conformance may be asserted without reference to this conformance point, and model content may be presented to various audiences including business audiences without asserting conformance to this sub-clause.”

2. Rename sub-clause 2.4.2
From
2.4.2 Business Diagram Conformance
To
2.4.2 FIBO Business Diagram Conformance
3. Rename sub-clause 2.4.3
From
2.4.3 Business Table Conformance
To
2.4.3 FIBO Business Table Conformance
4. In 2.4.3, in paragraph 1, Delete the words “two kinds of” and replace the words “: Basic Table and Extended Table”, replacing these with “These may range from basic presentation of terms, definitions and synonyms, to tables which represent all of the model content or all model content except relationships between relationships. “ so that paragraph 1 reads:
This sub clause concerns tabular presentations. These may range from basic presentation of terms, definitions and synonyms, to tables which represent all of the model content or all model content except relationships between relationships. Conformant FIBO Business Tables may be rendered as spreadsheets or as textual documents in a tabular layout.

5. Rename heading 2.4.3.1 to read:
“2.4.3.1 Basic Tables”

6. Rename heading 2.4.3.2 to read:

“2.4.3.2 Extended Tables”

7. In 2.4.3.2

Amend the first bullet, “Class”, to read:

• Class (including classes which are equivalent to logical unions and classes which are enumerations of individuals)

After the bullet “Simple Property” add the following new bullet:
• The relationship between any named class which represents a logical union, and those classes which are members of that union

After the bullet “Individuals’ and the sub bullet which follow, insert the following bullet and sub bullet:

• Enumerated sets of individuals
o ‘oneOf relationships from the enumerated class to each of the individuals members of that set

The current version of the Foundation specification refers to UML 2.4.1. This should be updated to refer to UML 2.5.

Update UML Reference in Section 3.1 Table

In Section 3.1 Table, in the row for [UML2]:

Replace the next in the “Description” column, which reads:
"Unified Modeling Language™ (UML®), version 2.4.1. OMG Specification formal/2011-08-06. Available at http://www.omg.org/spec/UML/2.4.1/."

With the following text
"Unified Modeling Language™ (UML®), version 2.5. Available at http://www.omg.org/spec/UML/2.5/."

There is a fundamental property "hasAddress" missing from the Addresses ontology in FND.

We go right from the ultra-generic (and IMO pointless) "has" to very specific address properties such as hasOperatingAddress, hasPrimaryAddress etc. Further these are very restricted by domain (FormallyConstitutedOrganization).
There is a clear and fundamental need to record the address of things generally including organization units, branches etc.

In addition, we need concepts related to physical delivery address – so that the range of isRegisteredAddress in BE can be more accurately represented.

Missing a generic "hasAddress" property in the Addresses ontology

There is a fundamental property "hasAddress" missing from the Addresses ontology in FND. We go right from the ultra-generic (and IMO pointless) "has" to very specific address properties such as hasOperatingAddress, hasPrimaryAddress etc. Further these are very restricted by domain (FormallyConstitutedOrganization). There is a clear and fundamental need to record the address of things generally including organization units, branches etc. In addition, we need concepts related to physical delivery address – so that the range of isRegisteredAddress in BE can be more accurately represented.

This issue affects section 10.7.3 Ontology: Addresses, with downstream impact on Organizations and on People. The resolution of this issue is independent of other resolutions in the FND RTF 1.1 report.

Revisions include modifying the Addresses ontology as discussed. In addition, and because of the overlap with changes in People, an additional issue, to change the “identifies <something>” properties of IdentityDocument to be “verifies <something>” was also incorporated into this resolution, together with moving a few altLabels to use the FIBO synonym annotation instead.

Finally, also with respect to the definition of IdentityDocument, the RTF determined that because a passport can identify both a mother and child, the restriction that an identity document identifies exactly 1 person should be relaxed to be someValuesFrom person.

The FIBO FBC RFC noted issues in the conformance section of the specification and made changes to FND 1.0 as noted in the revised text.

Correct errors, including section references, in the conformance section of the specification

The FBC RFC, which was adopted at the December 2015 meeting in La Jolla, made the following modifications to the FND 1.0 specification that should be incorporated into the document itself. They details that make the conformance section more readable by implementers.

FinancialDates was introduced as a part of the FND FTF 1.0 activity. A number of properties, such as hasDateOfIssuance and hasExpirationDate in FND/Arrangements/Documents, hasEffectiveDate in FND/Agreements/Contracts, hasCommencementDate in FND/Parties/Parties, and possibly others should be revised to be children of hasDate in FND/DatesAndTimes/FinancialDates with a range of Date from the same ontology.

The set of dates in FND that are defined as datatype properties rather than object properties should be reviewed as to whether or not they should become object properties that are children of hasDate with a range of the Date class as well.

Several properties involving dates require revision to leverage the FinancialDates ontology

FinancialDates was introduced as a part of the FND FTF 1.0 activity. A number of properties, such as hasDateOfIssuance and hasExpirationDate in FND/Arrangements/Documents, hasEffectiveDate in FND/Agreements/Contracts, hasCommencementDate in FND/Parties/Parties, and possibly others should be revised to be children of hasDate in FND/DatesAndTimes/FinancialDates with a range of Date from the same ontology.

The set of dates in FND that are defined as datatype properties rather than object properties should be reviewed as to whether or not they should become object properties that are children of hasDate with a range of the Date class as well.

This issue affects section 10.4.1 Ontology: Parties, section 10.5.4, Documents, and 10.9.2 Contracts. The resolution of this issue is independent of other resolutions in the FND RTF 1.1 report.

Revisions include revising the four date properties to have hasDate as a parent property, as discussed. In addition, minor errors in annotations (text), and the label on IndependentParty were corrected as well. In some cases, where the diagrams in the model did not match what was in the specification, those diagrams were also replaced. In particular, several diagrams in the Parties ontology were revised using the current notation and color scheme.

The property, isDomiciled in, which is in FND/FormalOrganizations, has a definition of "the country in which the formal organization is domiciled" which is not adequate. A proper definition, sourced from Black's Law Dictionary or Barron's is required for this property.

The definition of isDomiciledIn is inadequate

The property, isDomiciled in, which is in FND/FormalOrganizations, has a definition of "the country in which the formal organization is domiciled" which is not adequate. A proper definition, sourced from Black's Law Dictionary or Barron's is required for this property.

This issue affects section 10.8.2 Ontology: Formal Organizations. The resolution of this issue is independent of other resolutions in the FND RTF 1.1 report.

The list of files on the coversheet of the FIBO Foundations 1.0 Specification lists the UML XMI files (suffixed .xml) as a mix of paths: some include the Module namespace fragment and some do not.

At an earlier version of Foundations, all UML XMI files were listed without the Module fragment due to some technical constraint. If that constraint still holds, all the UML XMI files should be listed without the Module URI fragment in the path; if that constraint no longer holds, they should all be listed with the Module URI fragment in the path.

In addition, the list includes the module-level 'About' files. However, the list is identified as being a list of Normative files. According to the Inventory supplied with the FBC RFC, About files are not considered normative, These should therefore be removed from this list.

Delete About files and insert Module URI Framgments for UML XMI

1. Removal of About Files Reference
Remove the following entries from the normative listing of RDF/OWL Files:
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Accounting/AboutAccounting.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/AgentsAndPeople/AboutAgentsAndPeople.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Agreements/AboutAgreements.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Arrangements/AboutArrangements.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/DatesAndTimes/AboutDatesAndTimes.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/GoalsAndObjectives/AboutGoalsAndObjectives.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Law/AboutLaw.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Organizations/AboutOrganizations.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/OwnershipAndControl/AboutOwnershipAndControl.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Parties/AboutParties.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Places/AboutPlaces.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Relations/AboutRelations.rdf
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Utilities/AboutUtilities.rdf

2. Changes to UML XMI URIs
With the exception of UML XMI files listed as part of the FBC submission, and ones listed at the submission of the FTF2 Report or Beta2, all UML XMI files are listed without the name of the Module component. Add the Module name after the version fragment and before the ontology name in all file entries ending in .xml so that the resulting listing looks like the below:
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Accounting/AccountingEquity.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20150801/Accounting/CurrencyAmount.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20150801/Accounting/ISO4217-CurrencyCodes.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/AgentsAndPeople/Agents.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/AgentsAndPeople/People.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Agreements/Agreements.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Agreements/Contracts.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Arrangements/Arrangements.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20150801/Arrangements/ClassificationSchemes.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Arrangements/Codes.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Arrangements/Documents.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Arrangements/IdentifiersAndIndices.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/DatesAndTimes/BusinessDates.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/DatesAndTimes/FinancialDates.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/DatesAndTimes/Occurrences.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/GoalsAndObjectives/Goals.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/GoalsAndObjectives/Objectives.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Law/Jurisdiction.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20150801/Law/LegalCapacity.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Law/LegalCore.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Organizations/FormalOrganizations.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Organizations/LegitimateOrganizations.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Organizations/Organizations.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/OwnershipAndControl/Control.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/OwnershipAndControl/Ownership.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/OwnershipAndControl/OwnershipAndControl.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Parties/Parties.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Parties/Roles.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Places/Addresses.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Places/Countries.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Places/Facilities.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Places/Locations.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Places/VirtualPlaces.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20150801/ProductsAndServices/PaymentsAndSchedules.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20150801/ProductsAndServices/ProductsAndServices.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20150801/Quantities/QuantitiesAndUnits.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Relations/Relations.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Utilities/Analytics.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Utilities/AnnotationVocabulary.xml
http://www.omg.org/spec/EDMC-FIBO/FND/20141101/Utilities/BusinessFacingTypes.xml

When PostalAddress was renamed to PhysicalAddress this created a non backward compatible change to the Addresses ontology. This needs to be changed to a non-disruptive change so that BE and others can still refer to the class PostalAddress.

Retain the existing PostalAddress concept alongside the new PhysicalAddress concept in the Addresses ontology

Add a new class PostalAddress with the same assertions as the original class of that name, as a sub class of the previously renamed PhysicalAddress.

Note that for OWL backward compatibility it is sufficient that the assertions exist (including by inheritance), so it is not necessary to add back the sub class relationships that the original class had, since these are inherited by the class now called PhysicalAddress.

T.he task force reminded one another that any renamed element would be retained but deprecated for some period of time (possibly until a 2.0 version) of the FIBO standard. Thus, although we have renamed MoneyAmount to AmountOfMoney, we agreed to retain a deprecated concept called MoneyAmount, and make that equivalent to AmountOfMoney

Replace renamed MoneyAmount concept with a deprecated concept

The task force reminded one another that any renamed element would be retained but deprecated for some period of time (possibly until a 2.0 version) of the FIBO standard. Thus, although we have renamed MoneyAmount to AmountOfMoney, we agreed to retain a deprecated concept called MoneyAmount, and make that equivalent to AmountOfMoney.

This issue affects section 10.12.2, Ontology: Currency Amount. It requires that the revisions identified in resolutions to issues FIBOFND11-10, FIBOFND11-20, FIBOFND11-44, which revise the Currency Amount ontology, have already been applied.

Two ontologies referenced MoneyAmount before the resolution to issue 44 revised it, and were missed until the "about files" were modified and the two ontologies were included in regression testing.

This issue affects only these two ontologies and corrects the oversight.

Revise the two products and services ontologies to reflect the name change made to MoneyAmount

Two ontologies referenced MoneyAmount before the resolution to issue 44 revised it, and were missed until the "about files" were modified and the two ontologies were included in regression testing.

This issue affects only these two ontologies and corrects the oversight.

This issue affects the new section 10.15, Products and Services Module.

Both ontologies in this section are impacted by this issue.
This resolution depends on the resolution of issue FIBOFND11-12 and FIBOFND11-44.

An FND Beta 1 resolution to revise the minimum number of parties to an agreement to be 2, (originally a minimum of 1), which was revised properly in the body of the specification, was not implemented in the machine-readable ontology files.

This issue affects the ontology files only, not the specification text.

The Agreements ontology does not match the FND 1.0 Specification for the definition of Agreement

An FND Beta 1 resolution to revise the minimum number of parties to an agreement to be 2, (originally a minimum of 1), which was revised properly in the body of the specification, was not implemented in the machine-readable ontology files.

This issue primarily affects the ontology files rather than the specification text.

FBC integrated a new ontology, Classification Schemes, for use in classifying organizations, financial instruments, and other concepts via standard schemes such as the NAICS industry sector classification scheme and ISO 10962 classification scheme for financial instruments. This issue and corresponding resolution integrate the ontology defined in the FBC RFC into the FIBO FND specification.

Add a new Classification Schemes ontology to FND as required by the FBC RFC

FBC integrated a new ontology, Classification Schemes, for use in classifying organizations, financial instruments, and other concepts via standard schemes such as the NAICS industry sector classification scheme and ISO 10962 classification scheme for financial instruments. This issue and corresponding resolution integrate the ontology defined in the FBC RFC into the FIBO FND specification.

This issue affects sections 3.2 Non-Normative References, 8.2 Ontology Architecture and Namespaces, and introduces a new section 10.5.2 Classification Schemes.

The modifications defined herein are entirely additive, i.e., this is all new content for Foundations.

We need the definition of "rate" in IND, which should be a child of quantity in the quantities and units ontology, with a definition of "a quantity measured with respect to some other quantity", adapted from http://www.thefreedictionary.com/rate and http://www.icoachmath.com/math_dictionary/rate.html

We also need a definition for "interest rate", which should be added to currency amount, as a child of rate (above) and monetary measure in currency amount, with the following definition: "a rate of interest charged for the use of money, usually expressed as an annual rate", with explanatory note "The rate is derived by dividing the amount of interest by the amount of principal borrowed. Interest rates are quoted on bills, notes, bonds, credit cards, and many kinds of consumer and business loans.", adapted from "Barron's Dictionary of Finance and Investment Terms, Ninth Edition, 2014.

This is critical for both securities and IND and should be included in the FIBO FND 1.1 Specification, in addition to the changes required to support FBC.

A definition for rate is missing from FND/Utilities/Analytics, required to represent interest rate, payment rate, and market rate

We need the definition of "rate" in IND, which should be a child of quantity in the quantities and units ontology, with a definition of "a quantity measured with respect to some other quantity", adapted from http://www.thefreedictionary.com/rate and http://www.icoachmath.com/math_dictionary/rate.html

We also need a definition for "interest rate", which should be added to currency amount, as a child of rate (above) and monetary measure in currency amount, with the following definition: "a rate of interest charged for the use of money, usually expressed as an annual rate", with explanatory note "The rate is derived by dividing the amount of interest by the amount of principal borrowed. Interest rates are quoted on bills, notes, bonds, credit cards, and many kinds of consumer and business loans.", adapted from "Barron's Dictionary of Finance and Investment Terms, Ninth Edition, 2014.

This is critical for both securities and IND and should be included in the FIBO FND 1.1 Specification, in addition to the changes required to support FBC.

Additionally, the Securities specification requires a definition for price, currently missing in currency amount, that includes (1) a basic price, which could result in the exchange of money or something else, such as a financial instrument or something tangible (i.e., a service or other barter), (2) a monetary price, which is a price that involves the exchange of money for something, and (3) a calculated price, which is a price that involves a monetary amount that is calculated via a formula.

This issue affects sections10.1.3, Analytics, 10.12.2 Currency Amount, and the new section 10.14, Quantities, which was added via the FIBO FBC RFC (adopted in December 2015). It requires that the revisions identified in resolutions to issues FIBOFND11-6, FIBOFND11-8, and FIBOFND11-10, which augment the FIBO FND specification with ontologies for Classification Schemes and Quantities, and revise the Currency Amount ontology to support ISO 4217 Currency Codes, have already been applied, in other words.

The changes specified in this resolution are incremental, monotonic revisions (i.e., they preserves the set of axioms defined in the ontology in their entirety) to the specification, and thus will not have any negative downstream impact on the FND or other FIBO specifications.
The changes to the Analytics ontology also correct a reasoning error uncovered during testing of the resolution to this issue, namely, elimination of the use of a custom datatype in favor of the equivalent XML Schema datatype.

FBC extended the existing LegalCapacity ontology to cover licensing concepts for use in downstream FIBO ontologies, such as for operating licenses for banks. This issue and corresponding resolution integrate the changes to LegalCapacity defined in the FBC RFC into the FIBO FND specification.

Revise the Legal Capacity Ontology as required by FIBO FBC

FBC extended the existing LegalCapacity ontology to cover licensing concepts for use in downstream FIBO ontologies, such as for operating licenses for banks. This issue and corresponding resolution integrate the changes to LegalCapacity defined in the FBC RFC into the FIBO FND specification.

This issue affects section 10.10.3 Ontology: Legal Capacity. The modifications are additive, i.e., this change represents new content for Foundations.

This resolution is independent of other resolutions in the FND RTF 1.1 report.

FBC integrated a new module, Products and Services, and two new ontologies, Payments and Schedules and Products and Services, for use in downstream FIBO ontologies, such as for defining financial products and ISDA schedules for derivatives payment streams. This issue and corresponding resolution integrates the module and ontologies defined in the FBC RFC into the FIBO FND specification.

Add a new Products and Services Module to FND as required by FIBO FBC

FBC integrated a new module, Products and Services, and two new ontologies, Payments and Schedules and Products and Services, for use in downstream FIBO ontologies, such as for defining financial products and ISDA schedules for derivatives payment streams. This issue and corresponding resolution integrates the module and ontologies defined in the FBC RFC into the FIBO FND specification.

This issue affects sections 8.2 Ontology Architecture and Namespaces, and introduces a new section 10.15, Products and Services. The modifications defined herein are additive, i.e., this is all new content for Foundations.

This resolution depends on the resolution of issue FIBOFND11-10.

FBC extended the existing CurrencyAmount ontology and added a new ontology, ISO4217-CurrencyCodes, containing individuals representing all of the ISO currency codes as of August 30, 2015, for use in downstream FIBO ontologies, such as for defining currency-based instruments, interest rates, etc. This issue and corresponding resolution integrate the changes to CurrencyAmount and new ontology (machine readable files only) defined in the FBC RFC into the FIBO FND specification.

Revise the Currency Amount Ontology and add ISO Currency Codes as required by FIBO FBC

FBC extended the existing CurrencyAmount ontology and added a new ontology, ISO4217-CurrencyCodes, containing individuals representing all of the ISO currency codes as of August 30, 2015, for use in downstream FIBO ontologies, such as for defining currency-based instruments, interest rates, etc. This issue and corresponding resolution integrate the changes to CurrencyAmount and new ontology (machine-readable files only for the codes themselves) defined in the FBC RFC into the FIBO FND specification.

This issue affects sections 3.1, Normative References, 8.2 Ontology Architecture and Namespaces and 10.12.2 Ontology: CurrencyAmount. The modifications are additive, i.e., this change represents new content for Foundations. In addition to the specification changes as noted, the resolution adds a new set of machine readable files for the currency codes themselves.

This resolution depends on the resolution of issue FIBOFND11-8.

FBC integrated a new module, Quantities, and a new ontology, Quantities and Units, for use in downstream FIBO ontologies, such as for defining commodities. This issue and corresponding resolution integrate the module and ontology defined in the FBC RFC into the FIBO FND specification.

Add a new Quantities and Units Ontology to FND as required by FIBO FBC

FBC integrated a new module, Quantities, and a new ontology, Quantities and Units, for use in downstream FIBO ontologies, such as for defining commodities. This issue and corresponding resolution integrate the module and ontology defined in the FBC RFC into the FIBO FND specification.

This issue affects sections 8.2 Ontology Architecture and Namespaces, and introduces a new section 10.14, Quantities.

The modifications defined herein are entirely additive, i.e., this is all new content for Foundations.

This resolution depends on the resolution of issue FIBOFND11-6.

In addition to the issues including FIBOFND11-4 through FIBOFND11-14, a few minor text changes were incorporated via FBC, in section 6.4.9 of the FBC RFC. These include revision of Figure 8.1 and replacement of Table 8.2. This issue and the corresponding resolution capture those revisions.

Revise Sections 8.1 and 8.2 of the Specification with additional changes made by FBC

In addition to the issues including FIBOFND11-4 through FIBOFND11-14, a few minor text changes were incorporated via FBC, in section 6.4.9 of the FBC RFC. These include revision of Figure 8.1 and replacement of Table 8.2. This issue and the corresponding resolution capture those revisions.

This issue affects section 8.2 Ontology Architecture and Namespaces only. It has no impact on any of the ontologies that comprise the FIBO FND specification.

This resolution has no dependencies on any others in the RTF 1 report.

The code for the ISO 4217 Currency as defined in the ISO4217-CurrencyCodes ontology is mispelled as "NewIsraeliShekel" and should be "NewIsraeliSheqel"

The currency code for the New Israeli Sheqel is misspelled in the ISO4217-CurrencyCodes ontology

The code for the ISO 4217 Currency as defined in the ISO4217-CurrencyCodes ontology is mispelled as "NewIsraeliShekel" and should be "NewIsraeliSheqel"

The correction for this issue affects machine-readable files only, and has no impact on the specification itself.

Terms_Agreement: I agree
First_Name: John
Last_Name: Gemski
Email: jgemski@thegoldensource.com
Company: GoldenSource Corp
CODE: OMG621
B1: Submit

Comments:

The xml files contained in "Updated UML-XMI for Foundations" (finance-13-09-06.zip) cannot be imported into our UML tools. We tried Visual Paradigm and Erwin and got the same results. Only the class name was imported.

This issue has several potential solutions that have not been resolved.

The FIBO Leadership Team will discuss this and come to a conclusion at the March 2016 OMG Technical meeting in Reston, VA.

Section 6.4.2 of the FIBO Indices and Indicators (IND) specification augments the FIBO FND specification with (1) the addition of a property (appliesTo) to the Relations ontology, and (2) a new ontology, called Analytics.

The Analytics ontology requires revision to the specification metadata, revised use of the dct:license property, and integration with other FIBO FND ontologies to be properly integrated into the FND framework.

Integrate the changes made to FIBO FND by FIBO IND with the baseline FND specification

The Analytics ontology was incorporated by reference into the FIBO FND specification by the FIBO IND specification. The FIBO IND specification was recently adopted by the OMG, however. Thus, the diagrams, metadata, and definitions were not actually present in the baseline version of the specification, nor were they incorporated in the FTF1 version. This issue formally requests integration of the ontology in the main FIBO FND specification.

Having said this, issue FIBOFTF2-23 extends the original ontology to incorporate terms required for the FIBO SEC specification. Given that the ontology will be incorporated and revised by the resolution to issue #23, the FTF recommends closing this issue to that resolution.

Definition of securities exchanges, ticker symbols, codes for currency (ISO 4127) and FpML Business Centers, all needed for SEC/Securities, require the addition of a Codes and Coding Schemes ontology, based on ISO 11179 and derived, in part, from material in the original semantics repository under the "Information" module. This ontology is closely related to the IdentifiersAndIndices ontology and should be integrated with it in the Arrangements Module.

Changes in Arrangements module, chnges in Relations to support these; consequent impacts on FormalOrganization

In reviewing what needed to be done to integrate a new set of capabilities into the Arrangements module / set of models, we uncovered some additional issues in other ontologies in Foundations. These include:

 Collection in the Arrangements ontology was originally modeled as a child of the Arrangement class, and should not be

 Group in FormalOrganizations – should- be a child of Collection when Collection becomes standalone at the top of the hierarchy

 Additional structure and clarity were needed with respect to a handful of properties in the Relations ontology that a solution for Codes requires, and

 The change to Relations should also be reflected in the Identifiers and Indices ontology

The wording of the conformance criteria for FIBO extensions seems to allow for importing the FIBO ontology and introducing new axioms that can significantly change (by narrowing) the intended meaning of the imported FIBO elements. Please consider whether the wording could be revised from being merely logically consistent to being a conservative extension of the imported FIBO elements.

http://en.wikipedia.org/wiki/Conservative_extension

In ontology engineering, ontology modules are based on conservative extension:

http://cgi.csc.liv.ac.uk/~dirk/modularity/

In addition to being logically consistent, a conformant FIBO extension must be a conservative extension of each FIBO ontology that it imports.

Currently FIBO has no limits on extensions to its existing ontologies. The intention of this new paragraph is to insure that every conferment FIBO extension is a conservative extension.

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

A percentage only makes sense as a percentage of some other value. FIBO is missing the notion of the other value.
For example a fee expressed as a percentage is (implicitly) a percentage of some amount. But for common occurrences such as a management fee that is "1% of value invested" a lot more precision is needed as to when the value is taken, currency etc.
In fact percentageMonetaryAmount definition states "A measure of some
amount of money expressed as a percentage of some other amount,
some notional amount or some concrete Money Amount" with an editorial note "This will have a relationship to what it is a percentage of.
Alternatively and for some applications of this term, there may be an
enumerated list of possible things it is a percentage of."
However there is no such capability provided that I can see.

Change the representation of percentages so that a percentage can refer to what it is a percentage of

This Issue Resolution covers the following issues:

Issue 11: “hasPercentageAmount is semantically flawed”

Issue 6: “Allow for percentage notional amounts” is merged with this.

Issue 6 deals with one specific impact of this (on percentage notional in the CurrencyAmounts ontology) which is described here.

hich is described here.
Rationale
It has been pointed out that while percentage exists as a datatype on data feeds the semantics of this are incomplete – it would be more correct semantically to frame percentage in terms of what it is a percentage of
This means that references to percentage should be replaced: instead of a datatype property with the datatype percent, these should all be object properties with the range of percentage.
Percentage itself is then to be modeled as a class with an object propery whose range is Thing, identifying the thing that this is a percentage of (unless a mode specific but suitable abstract class comes to hand); and a datatype property of type “percent” being the numeric amount.
Naming is to be thought about e.g. what is percent and what is percentage, which name to apply to the datatype which contains the numeric % amount and so on.
Impact is to be assessed – there will be considerable impact in Indices and Indicator and in in future Securities, derivatives etc. models. Impact within Foundations is also to be assessed but is probably minimal. There will be impact on CurrencyAndAmount, where Issue 6 was filed. Use of the new properties should make reference to the concept of Notional Amount.
The existing percentage datatype is in BusinessFacingTypes
Change is to be carried out in the BusinessFacingTypes ontology, where these properties are already present. Note that Basis points should be subject to a similar treatment.

Many properties (especially but not only in Relations.rdf) are set at too high a level of generality. Properties which are given with a domain and range of "Thing" include many properties whose definition and intended meaning are specific to a given context, such as Contract or Organization.

Properties should always be defined at the level at which they apply, and ideally should be placed in an ontology for the subject matter to which they apply.

Specific examples are given in two additional Issues already raised. See for example the usage of hasEffectiveDate (Issue #33)

The entire model should be reviewed for such occurrences

Changes to property domains and ranges and related issues

This issue resolution covers the following merged issues:
• FIBOFTF2-3 Property hasInForce is in wrong ontology
• FIBOFTF2-4 Property Characteristics
• FIBOFTF2-10 Property Domains and Ranges
• FIBOFTF2-64 Application of FinancialDates to date related properties

Please see attached Word document for more detailed description and rationale.

Include the intersection of ownership and control in Foundations (at present this is only articulated in the context of FIBO-BE).

Rationale: in most real world contexts ownership implies some degree of control. However this is not universally the case in share ownership (non voting shares do not confer control of the entity that the equity is in; and when control is exercised it is control over the entity you hold equity not control of the thing you own namely the shares). Therefore these concepts have been kept very separate in FIBO so far. However, the more common scenario in which the two go together, should be included in Foundations so it can be picked up when needed.

This would simplify other applications of ownership and control outside of BE, and would also potentially simplify the way that FIBO-BE OwnershipAndControl is structured since at present these intersections are deep within the Business Entity ownership and control models (modeled bottom-up from voting and non-voting shares and their equivalents in Partnerships etc.)

Add new OwnershipAndControl ontology in module OwnershipAndControl

A new ontology is required which implements a logical intersection of the Ownership and Control classes.

A number of properties and a few classes were added to the FIBO FND Ownership and Control ontologies to support the structural work completed under FTF 1. None of the new properties or classes have definitions, and some properties do not conform with the naming conventions established for all FIBO ontologies.

In the Control ontology, the following properties are missing definitions: (1) controlByParty, (2) controlOfThing, (3) isControlledThingInRole, and (4) isControllingPartyInRole. Two of these, controlByParty and controlOfThing are not verbs, which is not conformant with FIBO naming conventions. In the same ontology, the newly added Control and ControlledThing classes are also missing definitions.

In the Ownership ontology, the following properties are missing definitions: (1) isOwnedThingInRole, (2) isOwningPartyInRole, (3) ownershipByParty, and (4) ownershipOfThing. Two of these, ownershipByParty and ownershipOfThing are also not verbs, i.e., are not conformant with FIBO Naming conventions.

Add missing definitions for Ownership and Control and rename some properties

Change names of properties in Ownership and in Control ontologies to conform to naming conventions

Add/change skos:definition as appropriate

Changes are relative to the version submitted for FTF2

Summary of Model Changes
1. Rename properties as follows:
a. controlByParty -> hasPartyInControl
b. controlOfThing-> isInControlOfThing
2. Add skos:definitions as follows
a. To fibo-fnd-oac-ctl:Control “The possession by a party, direct or indirect, of the power to direct or cause the direction of the management and policies of a thing, whether through the ownership of voting shares, by contract, or otherwise.”
b. To fibo-fnd-oac-ctl:isInControlOfThing “Indicates the thing in a control relationship where a party controls a thing.”
c. To isPlayedBy “indicates the actor (the independent thing) that performs a role.”
d. To fibo-fnd-oac-ctl:ControlledThing “Thing over which some party exercises some form of control in some context.”
e. To fibo-fnd-oac-ctl:hasPartyInControl “Indicates the party in a control relationship where a party controls a thing.”

Contract is a subclass of Agreement
A contract is expressed via a communication (verbal or written)

Changes in Agreements and Contracts ontology; addition of Documents ontology and consequent change in People

Overview
This Issue Resolution addresses issue #16. This Issue Resolution also describes changes in response to the merge issue 14 (addition of UnilateralContract).

There are two components to the proposed changes for issue 16:

1. Make Contract a sub-class of Agreement (changing its semantics accordingly);

2. Introduce concepts for the physical expression of Written Contract, drawing upon new document concepts (contract document); also firm up the semantics of transferable contract by relating it to a new type of commitment in the Agreements ontology for commitments at large. There are additional changes in Agreements to firm up the nature of mutual or bilateral contracts, add the commitment at large concept. The concept of a unilateral commitment is already there and did not need to be added.
In addition

3. The addition of a Documents ontology, and consequent changes to the People ontology.

Then for Issue #14
4. Add Unilateral Contract to Contracts ontology.

Misclassification of Role and PartyInRole in Owbnership and Control ontologies. Also happens in FIBO-BE (separate issue to cover that).

Existing pattern uses a cascading sequence of restrictions and logical unions, the end result of which is to cause types of PartyInRole (in OwnershipAndControl) to be classified as types of Role

See FND Control ontology, restrictions 01 and 02. See restrictions 04 and 06 in Ownership ontology.

Change range of hasRole to ThingInRole; other changes to OrganizationMember

The issue as described indicates a misclassification of roles versus parties in roles when a reasoner is run on the model as it was at Beta1.

Subsequent changes in Beta2 render the original issue moot since it is unlikely that the changed model would yield the same results.

As part of the remodeling of Ownership and Control, changes were made in FTF1 which also render the property ‘hasRole’, with domain of Thing and range of Role would also either be moot, or would require a new domain and / or range.

This proposed resolution is to have hasRole with a domain of ThingInRole and a range of Role, making effectively a terminological equivalence to the semantics of the role as defined for the ThingInRole class (e.g. Issuer).

Changes described for OrganizationMember (in the Parties ontology) remain as they were in the previous proposed resolution to this issue.

Detailed analysis:
There is a restriction on this property in the ontology Roles:
ThingInRole is sub class of fibo-fnd-pty-rl-02 onProperty hasRole min 1 onClass Role

This is retained.

Previous usages of hasRole:
In Control – property restriction 02 (this is now onProperty ‘isPlayedBy’instead of ‘hasRole’)

In Ownership: Property restriction 06 (this is now onProperty ‘isPlayedBy’ instead of ‘hasRole’)

There is one other usage of this property, in Parties:
fibo-fnd-pty-pty:OrganizationMember

In Parties: Property restriction 04 – this is a parent of OrganizationMember and forms part of a complex restriction cascade whereby OrganizationMember is necessarily a member of the class of things with property hasRole, with someValuesFrom the restriction on property isMemberOf allvalueFrom Organization.

Change: as with the previous 2 restrictions, this should now be in property isPlayedBy. This means that an organization member, as a party in a role, is played by (a kind of hasIdentity relationship), that which is a member of some organization.

We should more formally align with the W3C Organizations ontology.

See also W3C working paper which extends the W3C Organizations ontology to a Legal Entities ontology.

Apply our published Shared Semantics treatment (see Annex) to both of these, and infill any gaps we may find.

We would not use the Annex B treatment for this because Organization has a completely different meaning. Agreed out of scope.

We would not use the Annex B treatment for this because Organization has a completely different meaning. Agreed out of scope.

hasNotionalAmount in Currency Amounts does not allow for percentage notional amounts.

Should be a kind of "Monetary Measure" which may be expressed in one or other of these physical expressions, percentage and monetary amount.

Merge issue for percentage notional amounts with iffue FIBOFTF2-11

Proposal is to merge this issue with the overarching percentages issue, FIBOFTF2-11. The proposed resolution for that issue also described the changes needed for percentage notional amounts.

TakesForm property should be segregated into 2 or 3 separate concepts.

Currently there is a "takesForm" property in Ownership which is a subProperty of the hasIdentity relationship (as intended). This gets re-used in other contexts where a different meaning is intended, i.e. the form which an economic resource takes, as distinct from the form which an asset takes. Make takesForm more general than just the ownership context and then create sub-properties for the different meanings, with localized restriction on those properties for additional applications of these separate meanings.

Merge with issue 17 because this issue involves ownership.

Merge with issue 17 because this issue involves ownership.

There is currently no support for the temporal nature of such relationships as ownership and control, i.e. when they begin and end.

Resolutions for 17, also 56 and 5

This issue resolution introduces temporality to the Ownership and Control ontologies.

This resolution also describes the required changes for merged issue # 56 to complete the ownership and control “Lattice” pattern implementation.

This issue resolution also describes the changes for merged Issue 5, the misplacement of the takesForm property.

Properties should have their "Property Characteristics" defined. What that means in this context is the indications of specific types of property as defined in OWL2, including but not limited to "functional", "transitive", "symmetric", "irreflexive". Full list as defined in OWL2 specification.

Note that these are modeled as UML tagged values in ODM but only a fraction have had these settings applied to date.

Note also that efforts to provide natural language expressions of properties which have these characteristics applied, should be used in presenting the business impact of these settings to a business audience before signing off on each property to which these characteristics have now been added.

Merge property characteristics issue with FIBOFTF2-10 Property Domains and Ranges

This issue is merged with FIBOFTF2-10 Property Domains and Ranges since the work may be carried out at the same time and involves changes to properties

Shouldn’t hasInForce (”relates a jurisdiction or situation to a policy, rule, regulation or law that is currently in force in that situation or jurisdiction”) be in Jurisdiction.owl? And, given the definition, why does it have no domain and range (or even a restriction) at all?

Merged with issue ten.

Issue 3 is a subset of issue 10.

UrbanCenter within PhyscialLocation is defined to represent a large and densely populated urban area. This eliminates city, town, village and hamlet. Perhaps this can be replaced with PopulationCenter, which is more generic and covers non-urban areas.

Rename class urban center to populated place

Change of name of urban center because all places are not urban.

Terms_Agreement: I agree
First_Name: John
Last_Name: Gemski
Email: jgemski@thegoldensource.com
Company: GoldenSource Corp
CODE: OMG621
B1: Submit

Comments:

The xml files contained in "Updated UML-XMI for Foundations" (finance-13-09-06.zip) cannot be imported into our UML tools. We tried Visual Paradigm and Erwin and got the same results. Only the class name was imported.

Deliverables to resolve this issue are imminent so this issue can be closed in December

The deliverables required to resolve this issue are to be delivered at the December OMG meeting. This issue can be closed as soon as this is delivered. The issue is therefore deferred to the FIBO Foundations RTF which will be chartered at the December OMG DTC Plenary and will be closed immediately thereafter.

Provision of XMI export capabilities by NoMagic will provide clean export of UML XMI from ODM-compliant models regardless of whether these are produced using VOM or using a vanilla ODM implementation in Cameo / MagicDraw. This will be loadable by any suitably XMI compliant UML modeling tool, and should therefore address the issue as raised provided the user was using a tool which is XMI compliant.

A vanilla ODM profile in one place with no dependencies on VOM or anything else will enable data exchange including diagrams.

NM will demonstrate this at the OMG meeting in Long Beach in December 2014. This will address FIBOFTF2-1 to the extent that the tools people are using will support it.

In some cases it's used to represent "thing" - for example takesForm is (inadequately) defined as: "identifies the form the entity takes"; in others it's used to represent "IndependentParty" (or similar) as in the definition for isheldBy "something that is possessed by and at least partially under the control of some entity, which can be used or acted on by the holder, regardless of ownership".
We should review all uses of "entity" and ideally replace by a term that has a formal definition in FIBO e.g. Independentparty (and we should update the domain/range of the properties to reflect that).

New definitions for terms that had the word entity in them

All definitions which contained the word entity are to be replaced by definitions which don't.

As far as I can understand it, takesForm has nothing to do with ownership so is in the wrong ontology. The definition is utterly inadequate and says nothing about what "form" means: " identifies the form the entity takes". I would also expect a range to provide an indication thereof.

Will be merged with issue 5 - its doppleganger.

DIFF # 10 goes in to JIRA 12 “The property takesForm is in wrong ontology and with inadequate definition” It is a duplicate with JIRA 5.

This may involve more than one party but only one has an obligation/commitment.
See http://www.investopedia.com/terms/u/unilateral-contract.asp

Merged Issue 14 into Issue 16 (resolution proposals given in sub-issue 30)

The required changes are described in the Issue Resolution attached to Issue 16, which takes the form of a sub-issue (Issue 30) containing all of the proposed model changes, document change descriptions and attached diagrams, ontologies etc. covering the changes to add UnilateralContract to the model.

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.

The FIBO SEC/Securities specification requires concepts related to financial dates and schedules. The concepts required, including adjustable dates and schedules to cover payments, interest schedules and so forth, are not covered by the OMG's Date Time Vocabulary (DTV) specification, nor are they available in the well-known OWL Time ontology.

The Financial Dates ontology, derived in part from analysis of FpML and related XML standards, was developed specifically to support the requisite terminology and has been tested on basic use cases including, but not limited to, interest rate swaps and other ontologies from FIBO SEC/Securites and DER/DerivativesContracts. It also covers concepts originally in the "out of scope" semantics repository Time module. This ontology and related concepts should be integrated either into the Utilities module in foundations or a parallel Time module, as determined by the FTF.

Additions in Countries; Addition of DatesAndTimes module and 3 ontologies

The following changes are to be made in the model. The corresponding diagrams and tables are generated from the model and are described in the section which follows.
A. Modifications to the model elements specified in the Countries Ontology
1. Add two new classes to the FIBO FND Places/Countries ontology: Municipality, as a child of GeopoliticalEntity, and BusinessCenter, as a child of Municipality.

2. The skos:definition for Municipality should be “an urban administrative division having corporate status and usually powers of self-government or jurisdiction”, with fibo-fnd-utl-av:explanatoryNote of “A municipality is a general-purpose administrative subdivision, as opposed to a special-purpose district.”, and skos:example of “A municipality can be any political jurisdiction from a sovereign state, such as the Principality of Monaco, or a small village, such as West Hampton Dunes, New York.”. An additional skos:scopeNote should read, “The territory over which a municipality has jurisdiction may encompass:

• only one populated place such as a city, town, or village
• several of such places (e.g., early jurisdictions in the state of New Jersey (1798-1899) as townships governing several villages, Municipalities of Mexico)
• only parts of such places, sometimes boroughs of a city such as the 34 municipalities of Santiago, Chile.”
  The fibo-fnd-utl-av:adaptedFrom property should have a value of “http://en.wikipedia.org/wiki/Municipality”.
  3. The skos:definition for BusinessCenter should be “a municipality where business is conducted, especially one that is considered a financial center”, with fibo-fnd-utl-av:adaptedFrom of “FpML Business Center and related codes, see http://www.fpml.org/coding-scheme/business-center-7-14.xml”.
  B. Insert a new Module: Dates and Times, with three new ontologies: FinancialDates, Occurrences, and BusinessDates.
   Add a new “About” file with the module metadata, including the module abbreviation fibo-fnd-dt
   Update the specification metadata in the specification About file(s) to include references to the new module and ontologies.

Additional classes and properties are needed to support FIBO SEC/Securities and dependent derivatives ontologies. These include basic Expression, Formula, and Variable classes, as well as properties such as hasArgument, hasExpression, and hasFormula, originally part of the "out of scope" material from the semantics repository ontologies in the Math module. The target set of concepts should include exactly those concepts and relationships required for SEC/Securities, SEC/Debt, and and SEC/Equities, as well as to support DER/DerivativesContracts, but no unnecessary material.

Changes in Analytics for JIRA issue 23

The original Analytics ontology included with the FIBO IND specification included classes describing measures and statistical measures. This issue merges that ontology into the main FIBO FND Specification and augments the ontology to provide additional features needed in for Business Entities, Indices and Indicators, Securities, and additional ontologies to be integrated into the FIBO family of specifications over time. Some of the properties of the original Analytics classes referenced dates, such as applicable start and end dates, calendar years for which the measures are appropriate, and so forth. These need to be revised to reference the new FND FinancialDates ontology for more accurate and complete definition. In addition, several new classes and properties for Expression, Formula, and Variable are required to support the forthcoming SEC/Securities specification.

The SEC/Securities module requires concepts such as Facility, Site, and Venue, as well as NotionalPlace and VirtualLocation in order to properly define trading venues, physical and online exchanges, and so forth. Two additional ontologies have been developed to represent these concepts, derived from content from the semantics repository originally in the Places module. These new ontologies should be added to the FND/Places module in support of the SEC/Securities specification.

Integrate Facilities and Virtual Places ontologies into the FIBO FND Places module

Model Changes - The following changes are to be made in the model. The corresponding diagrams and tables are generated from the model and are described in the section which follows.
 Add two new models to the EDMC-FIBO/FND/Places/ module: Facilities and VirtualPlaces.
 Update the specification metadata in AboutFND-1.0.rdf to include references to the new ontologies.

Specification Changes - New ontologies in the Places Module, section 10.7
Add two new sub clauses 10.7.4 and 10.7.5 within this sub-clause as follows:
Sub-clause 10.7.4 is titled “Ontology: Facilities”
Sub-clause 10.7.5 is titled “Ontology: VirtualPlaces”

Under the title for sub-clause 10.7.4, replicate the text from the “sm:fileAbstract” annotation metadata element in the Facilities ontology.

Insert a new diagram or diagrams after the file abstract text noted above and before the table which follows. This diagram or diagrams shall be taken directly from the source model for the Facilities ontology and shall comprise each of the diagrams in the model folder called “Spec Diagrams”. The figure number(s) is/are not known at this time but is to follow on from the last diagram in sub-clause 10.7.3.

In sub-clause 10.7.4 add a new Table 10.34 “Facilities Ontology Metadata”. The content of this table is generated from the Facilities ontology.

In sub-clause 10.7.4 add a new Table 10.35 “Facilities Details”. The content of this table is generated from the Facilities ontology.

Under the title for sub-clause 10.7.5, replicate the text from the “sm:fileAbstract” annotation metadata element in the VirtualPlaces ontology.

Insert a new diagram or diagrams after the file abstract text noted above and before the table which follows. This diagram or diagrams shall be taken directly from the source model for the VirtualPlaces ontology and shall comprise each of the diagrams in the model folder called “Spec Diagrams”. The figure number(s) is/are not known at this time but is to follow on from the last diagram in sub-clause 10.13.1.

In sub-clause 10.7.5 add a new Table 10.36 “VirtualPlaces Ontology Metadata”. The content of this table is generated from the VirtualPlaces ontology.

In sub-clause 10.7.5 add a new Table 10.37 “VirtualPlaces Details”. The content of this table is generated from the VirtualPlaces ontology.

Four of the generated OWL files, including People, Contracts, Roles, and Relations, use rdf:type to state that some of the properties in these ontologies are functional (or symmetric, or other kinds of OWL properties). rdf:type is misspelled in these ontologies as "rdfs:type" which should be corrected.

Four of the RDF/XML serialized OWL files for Foundations misspell rdf:type

Four of the FIBO FND ontologies, namely Contracts, People, Relations, and Roles, contained this misspelling in the versions delivered by FTF1. The Contracts ontology was corrected in the resolution to FIBOFTF2-16, in ballot #1.

The resolution to this issue corrects the other three machine-readable RDF/XML serialized OWL files, and does not impact the specification text.

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.

a) modifiedon should be modifiedOn (which is what the OWL and Figure has)
b) modifiedBy should have range (Related Thing) of terms:Agent (inherited from dct:contributor)
c) the first 4 entries derived from sm:directSource should be of type resource not Literal: in Dublin Core dct:source (from which these are derived) has no range and it says "This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/). As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration."
d) None of the properties have any Definitions shown (despite them being in the OWL)
e) None have any definition Source shown (despite several having adaptedFrom in the OWL)

Errors in Table 10-4

a) modifiedon should be modifiedOn (which is what the OWL and Figure has); b) modifiedBy should have range (Related Thing) of terms:Agent (inherited from dct:contributor); c) the first 4 entries derived from sm:directSource should be of type resource not Literal: in Dublin Core dct:source (from which these are derived) has no range and it says "This term is intended to be used with non-literal values as defined in the DCMI Abstract Model (http://dublincore.org/documents/abstract-model/). As of December 2007, the DCMI Usage Board is seeking a way to express this intention with a formal range declaration."; d) None of the properties have any Definitions shown (despite them being in the OWL); e) None have any definition Source shown (despite several having adaptedFrom in the OWL)

It seems to have been a copy and paste error from the previous property.

This issue appears to have been fixed in the model but presumably we didn’t see a Proposed Resolution text.

This issue appears to have been fixed in the model but presumably we didn’t see a Proposed Resolution text.

In sub-clause 10.1.1, Figure 10.1 will have been replaced by four diagrams segregated as to subject matter. For the subject matter of Alternate Label Annotations (covering the elements called synonym and abbreviation among others), replace the material reflected in the original Figure 10.1 with the diagram shown below.

In the SEC/Securities ontologies, there is a requirement to be able to determine the domicile of the issuer of a security. This is also important with respect to describing participants in a contract more generally. Given that bonds can be issued by municipalities and other government organizations (including water and power districts in California, for example), this property should be available at the formal organization level.

Need the property "isDomiciledIn" to be moved from BE/CorporateBodies to FND/FormalOrganizations

Doing FIBO-BE surfaced this issue.

The definition text is far too general and allows for irrational and complex numbers. However that is not consistent with the axiom that it is equivalent to xsd:decimal which does not allow the representation of such quantities (they are not in its value space).

Inconsistent number definition

Unclear semantics.

Missing ContractParty as superclass to ContactParties, ContractCounterParty, and ContractPrinciple

Add the parent of ContractPrincipal and ContractCounterparty back in, This was called ContractParty

A percentage only makes sense as a percentage of some other value. FIBO is missing the notion of the other value.
For example a fee expressed as a percentage is (implicitly) a percentage of some amount. But for common occurrences such as a management fee that is "1% of value invested" a lot more precision is needed as to when the value is taken, currency etc.
In fact percentageMonetaryAmount definition states "A measure of some
amount of money expressed as a percentage of some other amount,
some notional amount or some concrete Money Amount" with an editorial note "This will have a relationship to what it is a percentage of.
Alternatively and for some applications of this term, there may be an
enumerated list of possible things it is a percentage of."
However there is no such capability provided that I can see.

hasPercentageAmount is semantically flawed

Percentage is only used when it is already a percentage OF something. When we come to the places where percentage is used, we can add assertions in those specific models, we can add some assertion to show what the percentage is a percentage of. MB will do this for Indices and we will see whether we have all the bits we need in Foundations to support this.

An entity may have many unique identifiers e.g. SSN, driving license number, passport number.
If anything the property should be inverseFunctional but that is dangerous if the range is text as opposed to an identifier scoped by a scheme. e.g. it might be the case that my UK driving license number happens to match a French person's National Id number in which case the text, with no qualification, will not uniquely identify one person.

hasUniqueIdentifier should not be Functional

An entity may have many unique identifiers e.g. SSN, driving license number, passport number. If anything the property should be inverseFunctional but that is dangerous if the range is text as opposed to an identifier scoped by a scheme. e.g. it might be the case that my UK driving license number happens to match a French person's National Id number in which case the text, with no qualification, will not uniquely identify one person. "MB notes: Pete is right. Only a unique combination of an identifier and the scheme under which that identifier is framed, can be considered to uniquely identify a thing and it is never the unique or only thing which does so. The assertion of isFunctional has been added at some point without review, justification or discussion, and is wrong. This has been discussed before and either removed or vetoed.

This property should apply to the relationship/associative class representing the ownership, not the asset or the owner.
Otherwise the fact that it's defined as a functionalProperty makes no sense (since an asset may be acquired many times over its life and an entity may acquire many assets (including the same asset at different times).
Further the disjunction in the definition, which allows for the asset OR the owner to be the subject does not make sense.

*hasAcquisitionDate incorrectly defined *

This property should apply to the relationship/associative class representing the ownership, not the asset or the owner. Otherwise the fact that it's defined as a functionalProperty makes no sense (since an asset may be acquired many times over its life and an entity may acquire many assets (including the same asset at different times). Further the disjunction in the definition, which allows for the asset OR the owner to be the subject does not make sense.

The lexical space for xs:boolean is

http://www.w3.org/TR/xmlschema-2/#boolean

Hence it's not correct to say that yesOrNo is equivalent to boolean unless, absurdly, it does not permit the values "yes" and "no". Either the name of the type should be changed (e.g. to trueOrFalse) or a mapping defined between it and boolean.
Either way this could have a large impact on other parts of FIBO using this type.

YesOrNo is a no go

This may or may not address the issue but it describes a change which has been made and which will show up as change bars so we need to cover it under this issue anyway:

The definition for percentage states that it is "often denoted...using the abbreviation pct": in that case there should be a value "pct" for the annotation property "abbreviation".

No abbreviation for percentage

The definition for percentage states that it is "often denoted...using the abbreviation pct": in that case there should be a value "pct" for the annotation property "abbreviation".

In some cases it's used to represent "thing" - for example takesForm is (inadequately) defined as: "identifies the form the entity takes"; in others it's used to represent "IndependentParty" (or similar) as in the definition for isheldBy "something that is possessed by and at least partially under the control of some entity, which can be used or acted on by the holder, regardless of ownership".
We should review all uses of "entity" and ideally replace by a term that has a formal definition in FIBO e.g. Independentparty (and we should update the domain/range of the properties to reflect that).

inconsistent use of the word Entity.

Get rid of this word. There are ISO 1087 patterns for this (we could consider recasting definitions in a new structure). We can use those patterns to inform the structure of future definitions. Action: Defer this one for now, EK and Jim Odell will work on this, starting with a proposal in one ontology (checked with MB). See also "embellish" and also SBVR have various approaches. We arelooking at ISO 704 structures for this, and ISO 806 and ISO 12260 and another one.

As far as I can understand it, takesForm has nothing to do with ownership so is in the wrong ontology. The definition is utterly inadequate and says nothing about what "form" means: " identifies the form the entity takes". I would also expect a range to provide an indication thereof.

hasPercentageAmount is semantically flawed

Percentage semantically flawed

This may involve more than one party but only one has an obligation/commitment.
See http://www.investopedia.com/terms/u/unilateral-contract.asp

FIBO does not cover concept of UnilateralContract

This is a new concept.

First_Name: David
Last_Name: vun Kannon
Email: dvunkannon@hotmail.com
Company: Rational Exuberance
CODE: OMG621

OWA vs CWA
Many of the assertions of Appendix C wrt logical vs. semantic models are unnecessarily broad and disputable. The key and most helpful idea is that logical models describe a system that is already abstracted away from the real world, while semantic models purport to describe the real world itself.
ìA closed world model such as a database is built with the assumption that there is data available for each field defined in the database for a given record. An open world model does not make this assumption, and so facts may be asserted whether or not there is data to correspond to those facts. This is what gives a semantic model the capability to express facts which define things.î
The person who wrote this has obviously never encountered a NULL in a SQL database. Really, this is close to word salad. Given the tabular presentation of the ontology, Iím pretty sure it can be loaded into a set relational tables. As the Internet would say, ìYour argument is invalid.î Methinks she doth protest too much, consider revising.
More importantly, open vs. closed world assumptions are Things which need to be in the Foundation! Accounting and a good piece of Contract Law make the CWA, while other modules make the OWA. If you have one Address that youíve told me about, you might have others as well.

remove and add

In Annex C sub-clause C.2 under the heading ”Open versus Closed World Assumption”, remove the following text:
“A closed world model such as a database is built with the assumption that there is data available for each field defined in the database for a given record. An open world model does not make this assumption, and so facts may be asserted whether or not there is data to correspond to those facts. This is what gives a semantic model the capability to express facts which define things. “

First_Name: David
Last_Name: vun Kannon
Email: dvunkannon@hotmail.com
Company: Rational Exuberance

The Accounting module is a good example of the question of knowing where to stop in a foundational ontology. Why define Retained Earnings but not Minority Interest? Why an Accounting module but not an Audit module? The answers to these questions are either absent or not well justified.
Similarly, there is an Organizations module, though everything in the module is generic and not specific to the financial services industry. Why, therefore, does it exist? If it does exist, why does it not contain financial industry concepts such as Exchange or Market?
Asset appears in two modules, Ownership and Accounting. The relationship is not made clear. A number of (IMHO) fundamental concepts are not represented anywhere that I could easily see ñ Risk, Loss, Price and Value. I think these are worthy of inclusion.

agreed

First_Name: David
Last_Name: vun Kannon
Email: dvunkannon@hotmail.com
Company: Rational Exuberance
CODE: OMG621

US/British slant in definitions of terms
Iím sure FIBO is intended to have global relevance, but the set of references and terms are all solidly grounded in US business law. I was hoping to see some awareness of other systems which might have subtly differing definitions. Was this work vetted with financial experts in French, Chinese, Islamic, etc. traditions ñ any of which might define the properties and relations of Agent, Contract, Law, etc. differently than what is here.

Definitions should have no borders

Some definitions appear to be based on British interpretations and some on American interpretations. All definitions are being reviewed.

First_Name: David
Last_Name: vun Kannon
Email: dvunkannon@hotmail.com
Company: Rational Exuberance

Found the use of meaningful use of color in the diagrams unhelpful. Color-blindness and cultural conventions argue against the use of color in this way.

New SW is being used that standardizes colors.

There is no universal agreement on colors. Every attempt is being made to create diagrams that do not depend on color.

They all are of the form: "Financial Industry Business Ontology (FIBO) Agreements Ontology".
Not only does this repeat "Ontology" but it means that if viewing them in a list (e.g. search results in a repository) it is very hard to tell them apart (the name is often longer than the normal column width so the last part is not shown).
Proposed resolution: make the names start with the real ontology. For example:
Agreements Financial Industry Business Ontology.

Ontology names too unwieldy and indistinguishable

The labels on the ontologies originally included "Financial Industry Business Ontology (FIBO) as a prefix.

Introduce ControlledThing, which is a kind of ThingInRole

Add this to Control ontology. Depends on changes requested in adjacent issue (add ThingInRole).

Add ControlledThing as a ThingInRole (see JIRA 55) to describe an entity that is in a relationship that it is controlled by another.

Added ControlledThing as a subClassOf ThingInRole, relate (via controlOfThing) to Control (see JIRA 58

Introduce a concept ThingInRole which is a sub-class of Relative Thing.

At present ThingInRole and RelativeThing seem similar but we can anticipate other contexts in which a relative thing is defined which do not relate to Role in any clear sense.

ThingInRole is needed to be a parent of ControlledThing, a new term requested to support proof of concept work,.

Add ThingInRole

The concept of a ThingInRole is needed as the parent of AgentInRole to support definitions related to securities for FIBO SEC. This concept has also been requested for ongoing prototype work for operational usage.

Misclassification of Role and PartyInRole in Owbnership and Control ontologies. Also happens in FIBO-BE (separate issue to cover that).

Existing pattern uses a cascading sequence of restrictions and logical unions, the end result of which is to cause types of PartyInRole (in OwnershipAndControl) to be classified as types of Role

See FND Control ontology, restrictions 01 and 02. See restrictions 04 and 06 in Ownership ontology.

Misclassification of PartyInRole and Role

Reasoner misclassifies PartyInRole and Role