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.

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.