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

During discussion on 7/15/2014 of the definitions included in the Contracts ontology, it was determined that for the cases that we care about in Foundations, BilateralContract is overly constrained. The consensus was to rename BilateralContract to MultilateralContract, revise the definition accordingly, and delete the restriction that there should be exactly 2 parties to the contract.

BilateralContract is too limiting – rename to MultilateralContract

During discussion on 7/15/2014 of the definitions included in the Contracts ontology, it was determined that for the cases that we care about in Foundations, BilateralContract is overly constrained. The consensus was to rename BilateralContract to MultilateralContract, revise the definition accordingly, and delete the restriction that there should be exactly 2 parties to the contract.

an analysis of over-long definition revealed the following elements to have additional text in the Definitions metadata element / table column which are not definitional:
AccountingEquity:Capital
AccountingEquity:CapitalSurplus
AccountingEquity:RetainedEarnings
Contracts:Contract
Contracts:ContractPrincipal
Contracts:ContractTermsSet
Contracts:ContractualRelationship
Contracts:hasGoverningJurisdiction
Contracts:hasTerms
Contracts:PromissoryNote
Control:Control
fibo-fnd-acc-cur:isTenderIn
fibo-fnd-law-cor:GovernmentalConstitution
fibo-fnd-law-cor:Law
fibo-fnd-law-jur:CivilLawSystem
fibo-fnd-law-jur:LegalSystem
fibo-fnd-law-jur:StatuteLaw
fibo-fnd-plc-cty:FederalState
fibo-fnd-pty-pty:PartyInRole
fibo-fnd-rel-rel:hasUniqueIdentifier
fibo-fnd-rel-rel:isPartOf
fibo-fnd-utl-bt:number
fibo-fnd-utl-bt:text
fibo-fnd-utl-bt:URI
LegalCapacity:DelegatedLegalAuthority
Objectives:Objective

The additional textual material is to be moved to other (explanatory or editorial) metadata elements.

An analysis of over-long definition revealed the following elements to have additional text in the Definitions metadata element / table column which are not definitional:
[see list in Issue text]
The additional textual material is to be moved to other (explanatory or editorial) metadata elements.

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.

Due to the fact that a number of diagrams are involved in multiple issues, and that an entirely new set of diagrams for Foundations is required, this issue serves as the vehicle for providing a complete set of diagrams at the end of the FTF process.

Final version of all diagrams for the FND FTF 1 should be provided in SVG format.

Due to the fact that a number of diagrams are involved in multiple issues, and that an entirely new set of diagrams for Foundations is required, this issue serves as the vehicle for providing a complete set of diagrams at the end of the FTF process

Some of the diagrams in FND use an incorrect stereotype as a part of a qualified cardinality pattern. Replace all occurrences of <<valuesFrom>> with either <<onClass>> or <<onDataRange>> as dictated by the restriction type.

This issue requires changes in the VOM source models only and has no effect on the machine readables. The effect on the diagrams is negligible and takes the form of incorrect stereotypes on some relationships.

The affected relationships are to be replaced with ones of the correct stereotype prior to final generation of diagrams from the model repository files.

A legally capable adult is a missing concept, which should be a child of adult, and legally capable person should be equivalent to the union of legally capable person and emancipated minor.

A legally capable adult is a missing concept, which should be a child of adult, and legally capable person should be equivalent to the union of legally capable person and emancipated minor

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

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.

Align with W3C Organizations Ontology

Mapping ontology would be needed, Normative or not? Should also make the actual concepts more closely aligned, to make the mapping easier. EK to do the proposals.

Definition still reflects the sense intended by the previous class at this point in the model, Formal Business Organization, and incudes reference to its contractual standing. An alternative definition refers to the W3C definition which should be used as the actual definition of this class in place of the one given here.

See also separate issue about making more formal reference to the W3C Organizations ontology.

Definition still reflects the sense intended by the previous class at this point in the model, Formal Business Organization, and incudes reference to its contractual standing. An alternative definition refers to the W3C definition which should be used as the actual definition of this class in place of the one given here. See also separate issue about making more formal reference to the W3C Organizations ontology.

The text given in FIBO Foundations v 10 as "definition" consists of one definition and two additional narrative notes. These should be moved to two separate Explanatory Note metadata items.

The text given in FIBO Foundations v 10 as "definition" consists of one definition and two additional narrative notes. These should be moved to two separate Explanatory Note metadata items.

Blank definition. Add skos:definition and put the definition text in that.

Blank definition. Add skos:definition and put the definition text in that.

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.

*Needs a longer conversations. Need more examples. Need more labels for these, which the examples will help with. Agree that the distinction is worth pursuing. *

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.

*Needs a lot of discussion. EK and DA to meet and go through properties and resolve. *

TakesForm different meanings e.g. for asset form, instrument/ca;ital form and (in future) Economic Resource

Additional assertions around Control: Add ControlRelation as a kind of Mediating Thing. Make Control a sub-class of ControlRelation

Introduced as a first iteration of the lattice pattern

Make Control a kind of ControlRelation

This annotation property is already defined in AnnotationVocabulary and should be deleted from here.

Rogue copies of annotations.

Introduce upper ontology partitions for Independent Thing Relative Thing and Mediating Thing.

Would be a new ontology in Section 10. Needed for Proof of Concept operational ontologies.

agreed

The definition given for 'IndependentPartyʺ (credtied as being adapted from Property nd Casualty) does not refer to the same concept as that originally intended here. The definition is ʺAn independent party is an independent person, organization or group that can enter into a contract or other legal proceeding.ʺ which frames independent parties as being those capable of entering into contracts, where in FIBO that concept is carried by the class ʺContractuallyCapableEntityʺ and the concept intended as IndependentParty (ʺInvolved Partyʺ in the FIBO EA models), is intended to cover any entity which may own shares or participate in other ownership activities. Being contractually capable is not a pre-requisite for that.

Replace the P&C defition with one sourced from P&C or elsewhere which describes the concept intended here.

The definition given for 'IndependentPartyʺ (credtied as being adapted from Property nd Casualty) does not refer to the same concept as that originally intended here. The definition is ʺAn independent party is an independent person, organization or group that can enter into a contract or other legal proceeding.ʺ which frames independent parties as being those capable of entering into contracts, where in FIBO that concept is carried by the class ʺContractuallyCapableEntityʺ and the concept intended as IndependentParty (ʺInvolved Partyʺ in the FIBO EA models), is intended to cover any entity which may own shares or participate in other ownership activities. Being contractually capable is not a pre-requisite for that. Replace the P&C defintion with one sourced from P&C or elsewhere which describes the concept intended here.

Use Definition (1); adapt this to (a) remove the narrative note that is the last sentence; and (b) remove the reference to ʺsome sort of assumed developmentʺ. Otherwise the sense matches what we wanted. This is the wikipedia definition. also delete the definitionOrigin annotation for the other definition.

Use Definition (1); adapt this to (a) remove the narrative note that is the last sentence; and (b) remove the reference to ʺsome sort of assumed developmentʺ. Otherwise the sense matches what we wanted. This is the wikipedia definition. also delete the definitionOrigin annotation for the other definition.

Use the first one and delete the second. Remove the text that says (1) from the start of that. Although the sense of both definitions is similar, one FIBO concept should have one definition only, and the one from the business dictionary is a more accurate reflection of the intended meaning of this concept.

Note that the original SMER based definition ha been retained in one of the explanatory notes, which should make the intended meaning clear.

Also need to update definitionOrigin to have only one such element, which must be the one that corresponds to the retained definition, namely the one from businessdictionary.com and not the one from Property and Casualty.

Use the first one and delete the second. Remove the text that says (1) from the start of that. Although the sense of both definitions is similar, one FIBO concept should have one definition only, and the one from the business dictionary is a more accurate reflection of the intended meaning of this concept. Note that the original SMER based definition has been retained in one of the explanatory notes, which should make the intended meaning clear.

The definition given for Transferable Contract has been replaced by one from TheBusinessDictionary.com

The definition which was used in place of the one from the EDM Council, is in fact a definition of ʺassignmentʺ and not a definition for ʺTransferable Contractʺ. As such, the definition text reads like narrative about a Transferable Contract and is not in any way definitional of the concept ʺTransferable Contractʺ (for example, it does not state that the concept so defined is that of a kind of contract!)

Also replace the Definition Origin annotation to reflect whatever is the chosen definition (replace this with EDM Council if the original definition is reinstated).

The definition given for Transferable Contract has been replaced by one from TheBusinessDictionary.com ; The definition which was used in place of the one from the EDM Council, is in fact a definition of ʺassignmentʺ and not a definition for ʺTransferable Contractʺ. As such, the definition text reads like narrative about a Transferable Contract and is not in any way definitional of the concept ʺTransferable Contractʺ (for example, it does not state that the concept so defined is that of a kind of contract!); Also replace the Definition Origin annotation to reflect whatever is the chosen definition (replace this with EDM Council if the original definition is reinstated).

isAssetOf (which was formerly hasOwner) incorrectly has "has" as the parent.

This was removed in earlier works (20130722-MGB) while the label was still hasOwner, because this falls outside of the agreed usage of "has" (policy as at July 2013).

The property has subsequently been renamed to reduce potential confusion between two types of ownership property (direct between owner and thing, and indirect between party and asset which is a thing).

If the policy on usage of "has" changes this issue may be impacted.

IsAssetOf should not have a parent

The definition for common law system includes a lot of material which is not definitional but which isnarrative on the concept.

This material should be moved to an Explanatory Note. The first sentence alone defines the concept.

The definition for common law system includes a lot of material which is not definitional but which isnarrative on the concept. This material should be moved to an Explanatory Note. The first sentence alone defines the concept

The definition of WrittenContract is A formal Contract which is written and signed by both parties thereto. Which by using “both” invalidly assumes there are only 2 parties.

The definition of WrittenContract is A formal Contract which is written and signed by both parties thereto. Which by using “both” invalidly assumes there are only 2 parties.

The restriction on the property 'isAssignable' has a contract-specific definition but is given a domain of Thing, with a restriction replacing this definition for Contract itself.

Since the concept of being assignable only has this meaning with regard to contracts of one sort or another, there is no clear value in replacing this property with a restriction. Nor is there any more general kind of assignability concept of which the contract-specific one is a restriction. The definition in place for this property is already the contract-specific definition from the original model, so that did not need to change (but would have been wrong when the domain was Thing).

Review whether the restriction is still needed 9it has the function of stating that a contract always has the property of isAssignable meaning in the open world that a contract is always either assignable or not assignable, which is true.

Add domain of Contract to isAssignable.

The editorial note for isAssignable was missing. This provides important background for the review of the definition, and for the meaning. Also the original "term origin" annotation (given as 'SME Reviews - OTC Derivatives') is relevant, and should be represented by a historyNote .

These changes were made in an earlier version (20130809-MGB) including more detail in the history note. these have been lost.

The editorial note for isAssignable was missing. This provides important background for the review of the definition, and for the meaning. Also the original "term origin" annotation (given as 'SME Reviews - OTC Derivatives') is relevant, and should be represented by a historyNote .These changes were made in an earlier version (20130809-MGB) including more detail in the history note. these have been lost.

The property isOwnedBy has no definition.

Definition was added in earlier works (20130722-MGB) but this has been lost.

The property isOwnedBy has no definition. Definition was added in earlier works (20130722-MGB) but this has been lost.

WrittenContract should have the potential for a link to the resource representing the actual document (e.g. a scanned PDF with signatures etc).

Show a relationship from WrittenContract to written item.

Written contract links to scanned doc or PDF

This is a simple application matter, of putting links in e.g. seeAlso or dct:references

I just noticed that it's http://purl.org/dc/terms/LicenseDocument
Whereas we seem to be treating it as a datatype property – though with different types xs:string or xs:anyURI.
Is this right? Am I missing something?

In fact I found this http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#dcterms:license where it explicitly says that dct:license should NOT be used with a literal: though even in this example it does not seem that the GPL has been declared with rdf:type of LicenseDocument.

Here’s a better example http://code.creativecommons.org/viewgit/license.rdf.git/tree/cc/licenserdf/licenses/creativecommons.org_licenses_MIT_.rdf
In fact since this is the license we use, we could just reference someting like this: http://creativecommons.org/licenses/MIT/ since it subtypes dct:LicenseDocument (and seems to do a neat redirect)

(cc:License inherits from dct:LicenseDocument as here http://code.creativecommons.org/viewgit/license.rdf.git/tree/cc/licenserdf/rdf/schema.rdf

<rdfs:Class rdf:about="http://creativecommons.org/ns#License">
<rdfs:label xml:lang="en-US">License</rdfs:label>
<rdfs:comment xml:lang="en-US">a set of
requests/permissions to users of a Work, e.g. a
copyright license, the public domain, information
for distributors</rdfs:comment>
<rdfs:subClassOf rdf:resource="http://purl.org/dc/terms/LicenseDocument"/>
</rdfs:Class>

If we don’t trust an external URL and we want the full MIT wording in FIBO it should go in a separate element with rdf:type of dct:LicenseDocument.
Perhaps we could just store it once in FIBO Foundations and reference it there. That way, if anything should need to change, it only need be in one place. And it avoids the problems VOM might have in exporting it (we could fix up the type by hand if necessary in the one place it appears).

Wrong use of dct:license

The original set of FIBO FND ontologies included the use of the dct:license property in the headers of every ontology to reflect the actual text of the MIT License (free to use with attribution) as well as a link to the license on the MIT site.

The AB's specification metadata recommendation has been revised to add an individual of type dct:LicenseDocument, whose properties include the license text and a link to the actual license.

FIBO ontologies should be modified to reflect this change, referring to the individual in specification metadata and eliminating the license text altogether.

As a part of the revision to the specification metadata, we have moved the MITLicense named individual to the specification metadata. Further changes to the AnnotationVocabulary to reflect the new strategy of (1) use of Individual ontologies to describe the FIBO specification family, FND specification, and each of the modules, to be posted to the OMG site on the specification family, specification, and relevant machine-readable file pages

Certain address properties are defined as type DataProperty when they should be defined more expressively as type ObjectProperty. The impact of not doing this is to reduce the ability to associate address content with more expansive attributes. The following elements should be redefined as string values by themselves are not very descriptive and prevent further linkage.


a. hasCountryName should be replaced with an ObjectProperty of referencesCountry (where the range is a Country entity). The Country entity can be selected by the user (ISO3166, FAO, or other)


b. hasPostalCode should be replaced with an ObjectProperty of referencesPostalArea (where the range is a PostalArea entity). The PostalArea entity would have various object a data properties that describe its scope and indicators. Specifically it would point to a geographic region, as well as specify postal code identifiers e.g. 5 digit and 9 digit codes, as well as other country specific indicators.
c. hasLocality should be replaced with an ObjectProperty (where the range is an Locality entity). This can be tied to data property that specifies its name.


d. hasStateAbbreviation and hasStateName should not be tied to PostalAddress but instead PostalAddress should be associated with a single ObjectProperty of referencesState (where the range is a State entity). hasStateAbbreviation and hasStateName can be data type properties associated with the State entity.


e. hasPOBox should be replaced with an ObjectProperty of referencesPOBox (where the range is a POBox entity).


f. hasStreetAddress should be replaced with an ObjectProperty of referencesStreetAddress (where the range is an entity called Street Address, which has a set of descriptive data properties pertaining to streetAddress1, streetAddress2, etc., and perhaps ObjectProperties referencing building, floor, suite.

Certain address properties should be ObjectProperty, not DataProperty

A number of properties in the Addresses ontology provided the ability to include address details for a person or organization. The FTF decided that these properties were too constraining, and that differing conceptualizations may have different requirements for address properties. These properties were removed in favor of allowing FIBO users to use their own address standards.

1) The current Addresses.rdf specification does not allow for the temporality of addresses that are associated with an entity. Addresses change over time. For example, a corporate mailing address may change. It would be useful to introduce the ability to define an n-ary relation between an entity and an address, such that the n-ary relation that describes the address relation can include various date values, e.g. effective or start date, termination date or end-date, or even perhaps as-of-date. This would support the ability to track address changes over time. This also is equivalent to the notion that addresses are ìthings in a roleî. The role relation must reflect temporality.

The current Addresses.rdf specification does not allow for the temporality of addresses that are associated with an entity

The FIBO FND specification provides a conceptual model for addresses, not an operational one. Temporality and other features specific to various applications have not been included as they are out of scope, in other words.

Having said this, the FTF agrees that there are a number of data properties that assume certain structures of addresses that are overly constraining, and FIBO FND users should be able to map addresses to any standard or practice used in their organizations. As a result, the resolution to this issue involves elimination of all data properties in the addresses ontology, the addition of two ontologies (Arrangements and IdentifiersAndIndices) in a new module (Arrangements), a new class called AddressingScheme, and creating relationships between address and addressing scheme through property restrictions.

Terms_Agreement: I agree
First_Name: David
Last_Name: vun Kannon
Email: dvunkannon@hotmail.com
Company: Rational Exuberance
CODE: OMG621
B1: Submit

Ontology of Space and Time
While FIBO only concerns itself with the financial industry, it would be a great help if it referred to more generic ontologies where they were available and appropriate, otherwise there will be a large opportunity/danger of re-inventing the wheel. An example would be a time ontology such as OWL-Time. It really is necessary to define that start times come before end times. There is a need to define ëborderí, etc. These are examples of Things that should have definition in other ontologies, and it would help FIBO users if they were pointed to appropriate candidate ontologies.

Adjust Annex B to cater for ontologies already in ODM

This issue is addressed via the mechanism discussed in Annex B, regarding handling of external ontologies. With respect to time in particular, the FIBO development team intends to use the OWL version of OMG's Date Time Vocabulary, which was published with the RTF report in June 2014.
However Annex B does not anticipate an external ontology already being in ODM as DTV is.

Line 188 of file People.rdf has a syntax error, in which the termination of the list, which should be rdf:nil, instead is the string

" rdf:resource=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#nil\">
"
This string is the XML representation of null termination of a list, rather than the null resource itself.

Lines 188-189 should be replaced by the single line

<rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-

Line 188 of file People.rdf has a syntax error, in which the termination of the list, which should be rdf:nil, instead is the string

" rdf:resource=\"http://www.w3.org/1999/02/22-rdf-syntax-ns#nil\">
"
This string is the XML representation of null termination of a list, rather than the null resource itself.

Terms_Agreement: I agree
First_Name: David
Last_Name: Newman
Email: david.newman@wellsfargo.com
Company: Wells Fargo Bank
CODE: OMG621
B1: Submit

Comments:

I do believe that FIBO Foundation ontologies are suitable for adoption as an OMG specification with the inclusion of the below recommendations.
1) PostalAddress should be represented with object properties moreso than data properties. City, country, postal region, etc. are things in their own right and not just strings. We can create FIBO class abstractions to support inclusion of user specified ontologies ( e.g. ISO3166, FAO, user devloped et.al) as subClasses
2) Address should be represented as a temporal relation, which is conceptually equivalent to the notion that addresses are 'things in a role'.
3) The objectProperty ëhasí is too generic and does not provide the level of expressivity needed when associated with Address as a range. Should be 'hasAddress'.
4) Replace the class UrbanCenter with PopulationCenter.

A more detailed set of RFC comments was later raised by David Newman.

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 will be deferred until RTF2 so that there can be more testing.

There is no acceptable solution at this time.

In Contracts.rdf a definition has been introduced for "ContractCounterparty" which is that of counterparty to a transaction not a contract. It is sourced from a definition for "counterparty" not contract counterparty and the editorialNote contains a request from Elisa Kendall that we consider changing the name of this term to simply "counterparty". This would have the effect of changing all three of the name, definition and intended meaning of this concept, to a different concept. As the model stands it has the label and intended semantics of one concept and the definition of a separate concept, which is incorrect.

The original model has a definition for this concept which was replaced by the above without peer review. Recommendation: re-instate the existing definition if a better definition cannot be sourced for the concept which was originally modeled here.

Additional impact: If we plan to use editorialNote for internal exchanges then these should not be reported in the spec (raise a formal change note on the tabular report generation plug-in to eliminate these).

In Contracts.rdf a definition has been introduced for "ContractCounterparty" which is that of counterparty to a transaction not a contract. It is sourced from a definition for "counterparty" not contract counterparty and the editorialNote contains a request from Elisa Kendall that we consider changing the name of this term to simply "counterparty". This would have the effect of changing all three of the name, definition and intended meaning of this concept, to a different concept. As the model stands it has the label and intended semantics of one concept and the definition of a separate concept, which is incorrect. The original model has a definition for this concept which was replaced by the above without peer review. Recommendation: re-instate the existing definition if a better definition cannot be sourced for the concept which was originally modeled here.

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.)

Refinement of Control concept semantics

Can we add more stuff to Control to firm up the meaning? See also Ownership (which does have more relations).

Most of the "definition" elements in people.rdf are way too long for definitions and contain narrative material.

Segregate narrative from definition and put the former in separate explanatoryNote annotations, for almost all classes in people.rdf (review all, segregate text as required). As an example, the definition of BirthCertificate includes discussion of the role of a midwife or doctor in relation to this document, which is not definitional of that kind of document in any way.

Definition should ideally be a single sentence and should set out unambiguously what the class or property is intended to mean. Examples and discussions must always be separate, even though many on line web sources include such run-on text as part of what they call the definition.

Most of the "definition" elements in people.rdf are way too long for definitions and contain narrative material. Segregate narrative from definition and put the former in separate explanatoryNote annotations, for almost all classes in people.rdf (review all, segregate text as required). As an example, the definition of BirthCertificate includes discussion of the role of a midwife or doctor in relation to this document, which is not definitional of that kind of document in any way. Definition should ideally be a single sentence and should set out unambiguously what the class or property is intended to mean. Examples and discussions must always be separate, even though many on line web sources include such run-on text as part of what they call the definition.

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

Use of property domains and ranges

MB proposes we always set the domain and range at the highest appripriate level. EK and DA to work through this at the same time as the Properties.

Additional assertions around Control: an assertion that control is control of some thing.

Currently: the properties and restrictions around ControllingParty include that it acts in the role of being a thing that controls some thing - but the corresponding assertion about control being directed at some thing is not there (and the ControllingParty restrictions about being in the role of a thing controlling a thing, are not necessarily well formed as they stand - see separate issue about misclassification).

introduced as a frist iteration of the lattice pattern

Refinement of Control concept semantics

Restrictions in People appear to conflate textual information with the real things they represent. Specifically for hasPlaceOfBirth but there may be others.

Places versus Text and whether one was born in a string.

The class IndependentParty should really be named PotentialParty or PotentialOwner.

See also separate issue about the definition of this class. As it stands this class has a separate name and a separate definition to that intended in the original models. Specifically, the intended usage of this class is for anything which may be an owner of shares or a party in some other party context (these include transactions, contracts etc.) and is not limited to entities which are deemed contractually capable.

These two issues should be discussed together.

agreed

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.

Add property characteristics to properties

The 'tagged values' AKA Property Axioms

Restriction on property hasAddress, in People, has a minimum of 1 onClass PostalAddress. This is not true in reality.

Property Restriction 03 refers. Also this is a restriction on "has" which flies against the agreed policy on when to use "has" (and would be impacted by any changes on this from later issues).

People exist who do not have addresses, even if a particular application chooses not to track these. As a standard ontology we should frame what is known about the subject matter overall, not what is needed in a specific database.

hasPostalAddress cardinality

The property formerly known as hasStateAbbreviation is now named as StateAbbreviation whereas it should be in lowerCamelCase and should start with has. This seems to have changed from the original name after a spelling correction,.

Incorrect application of naming convention for StateAbbreviation

This was resolved by JIRA issue #9 per "Remain open till 9 is closed and then Dwiz change to Resolved per the 9 resolution"

In People, restriction on property isIdentifiedBy cardinality min=1, onClass NationalIdentificationNumber. This is not true globally, only in countries which have a centralized national identification scheme.

isIdentifiedBy cardinality

Introduce the property "hasOrganizationMember" (range = OrganizationMember).

Needed for Proof of Concept ontologies.

Add hasOrganizationMember

Discussion involved:

Apply the new treatment to extensions of what's in FIBO OMG, similarly to what we agreed for abstractions, i.e. we have a separate namespace with these additional relations in them, similar to the ones with the lattice etc. Unless this adds new meaning to the ontology it would go in those external ontologies.

In Parties.rdf, the relationships hasParty and hasPartyInRole have 'has' as a parent which is against the updated strategy for usage of "has" as agreed in July 2013.

Note that later discussions around "has" may make a difference to the agreed strategy against which this issue was raised.

agreed

For the property hasOrganiztionMember which is requested in the preceding issue, the inverse for this property is also to be added.

note that this is not the hasMember / isMemberOf relationships in Relations.rdf, but a separate pair of relationships attached to the PartyInRole conceot of OrganizationMember

Needed for Proof of Concept ontologies.

Introduce inverse property of hasOrganizationMember

Discussion involved:

Apply the new treatment to extensions of what's in FIBO OMG, similarly to what we agreed for abstractions, i.e. we have a separate namespace with these additional relations in them, similar to the ones with the lattice etc. Unless this adds new meaning to the ontology it would go in those external ontologies.

The property hasPartyInRole in Parties should also have the inverse property asserted. This would be something of the form "isPartyTo" or "definedInContextOf", and should have a range of Thing, but in usage this would most frequently be restricted to types of MediatingThing, including the contexts of Transaction, Contract and Ownership. That is, this defines the context in which something which has its definition purely by virtue of its context (including but not limited to role), is defined.

agreed

The definition given for isConferredBy: ʺis vested byʺ is no more than a synonym.

The definition given for isConferredBy: ʺis vested byʺ is no more than a synonym.

Add a sub-type of explanatoryNote which would be used to provide examples of concepts by way of explanation.

Needs a new construct in AnnotationVocabulary as a child of explanatoryNote.

Use SKOS Example for examples - we don't need to add one in AnnotationVocabulary at all. Close no change

Rename LegalConstruct to something which better reflects the semantics (as labeled currently, it would include things like Juries which are a legal construct but not, as defined for this class, something which is conferred by some legal instrument).

We should rename this to LegalConferral and consider introduction of a broader LegalConstruct which may have other uses in the future.

Original reason is because of things like Juries which are also legal constructs whereas this concept has a conferredOn relation to some agent. Those other contexts need not concern us and the semantics of the concept are clear enough. There is no good label for it. Proposal is to close no change.

Add annotations explaining the distinctions between de jure and de facto control etc.

We would need to elaborate further to make these more explicit, as these are concepts that people are not completely familiar. The test is, would people get it correct is we gave them examples. also add some examples in the annotations. For now, add these examples to the ʺexplanatoryNoteʺ element or several explanatoryNote elements.

Add explanatory annottions for de jure control and de facto control

This is a simple change to the description of how to use these concepts.

Definition of "owns" has two senses: This has: ʺ(1) to have (something) as one's own, possess, (2) to admit or acknowledge that something is the case or that one feels a certain wayʺ.

FIBO classes and properties should each represent one meaning only.

Previously changed SKOS Definition element to:ʺto have (something) as one's own, possessʺ. Change to be re-instated.

Usually if there are two definitions we would also change the Definition Origin to only have one of these, but there is no Definition Origin.

Definition of "owns" has two senses: This has: ʺ(1) to have (something) as one's own, possess, (2) to admit or acknowledge that something is the case or that one feels a certain wayʺ. FIBO classes and properties should each represent one meaning only. Previously changed SKOS Definition element to:ʺto have (something) as one's own, possessʺ. Change to be re-instated. Usually if there are two definitions we would also change the Definition Origin to only have one of these, but there is no Definition Origin

The whole area is very complicated and not something that FIBO need concern itself with as a Financial ontology: for example different jurisdictions could treat the same Person as having different genders, and Facebook recognizes 50 values.

FIBO should not have a list of values for Gender

The People ontology includes a datatype defining values for gender that are insufficient in terms of their conceptual semantics as well as for many applications.

The FIBO FTF team agrees that this datatype should be removed and the range of the property that uses it should simply be "text".

isTenderIn has a definition A region or country in which the currency is exchangeable for goods and services. But the range is defined as Country which excludes regions!

The range is incorrect. Need to expand the Countries ontology to include as a minimum the concept of Region (or the 2 concepts of region - intra and inter-country) in order to support what was modeled in the EA model here. In the short term, re-frame the property such that it may refer to more than one country, and also no countries.

Currently: there is no restriction on the property isTenderIn and the range is still Country. Should have added a restriction giving min=0 (for BitCoin and microcurrencies, and countries which use currency without a concept of legal tender).

isTEnderIn range too specific

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?

*Relocate hasInforce to Jurisdictions.rdf hasInForce*

Meaning may be more general than just jurisdiction but more specific than Thing, so we still need to fin the middle ground on this one. Also the definition is very specific to Jurisdiction and therefore needs to change. So make the concept and definition match!

Some ontologies have rdf:datatype=”xsd:string” in the skos:definition annotation and others do not.

RDF datatype usage for annotations

Resolution is to include the data for all annotations. We don't have a list of which ontologies these have or have not been done for. This automatically happens in Adaptive-generated OWL but not automatically in VOM-generated OWL. So this needed to be done manually in VOM.

VOM now does this automatically.

stockholder’s equity - should the label not have an apostrophe if it’s meant to be for business people?

Proposal
No change in text. A change was made to a table.

MB Suggestion: if there is to be an apostrophe is should be after the s not before it as suggested in the original comment above. It is the equity of stockholders. However, check with SMEs for normal usage before putting an apostrophe in either of those places.

Human Readable label sub task

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.

Replace PhysicalLocation with PopulationCenter

"ISO 3166 covers countries and parts thereof not types of town - suggest GeoNames would be more appropriate for that.

Would need to change the metadata since the definition refers to the same concept of Urban Center - so it's really a matter of whether we need a new concept for any town or city, and whether to deprecate this one."

The objectProperty ëhasí is too generic and does not provide the level of expressivity needed. For example, ìhas min 0 PostalAddressî for an Organization, or a Person, is not descriptive. This should be replaced with ìhas Addressî, which itself can be further specialized. It would be useful, to eliminate the general objectProperty ìhasî with more expressive properties.

objectProperty "has" is too generic

"There are 3 potential treatments: use has for everything, nothing or the previously agreed dispensation where 'has' has only one meaning namely that it is used to talk of properties intrinsic to a thing, and not to talk of posession of a thing by something. We do need to retain distinct meanings in this model.
NOTE: Inthe event that we retain the previously-agreed dispensation, the other JIRA issues about 'has' relate to where this was not completely implemented; those JIRA issues become moot if any other solution is proposed."

Remove the subPropertyOf relationship from hasCurrency to has, in line with previous agreed changes to the usage of has.

This may be impacted by changes in the usage of has - this issue described a change which was made and then lost, based on an agreed usage of 'has' such that it may be used for intrinsic properties of some Thing but not the possession of possessions or attributes.

On reflection, Mike agrees with the original model.

Shouldn’t hasMember (“relates an entity to its members”) be in Organization.owl?

Close no change.

We will also look at ISO 1087 and ISO 11179 and the W3C Organization ontology (for the organizatiojn context of this concept). Need to look into set membership as well; metrology ontologies to see

The definition of datatype Percentage seems logically incorrect: by using equivalentClass of decimal that also, as far as I understand it, creates the absurdity that all decimals (e.g. 567.34) are considered percentages.
(definition elided).
<rdfs:Datatype rdf:about="&fibo-fnd-utl-bt;percentage">
<rdfs:label>percentage</rdfs:label>
<owl:equivalentClass rdf:resource="&xsd;decimal"/>
</rdfs:Datatype>
Can we not use a restriction (RDF syntax looks ugly but came from "personAge" in OLW2 Primer):

<rdfs:Datatype rdf:about="&fibo-fnd-utl-bt;percentage">
<rdfs:label>percentage</rdfs:label>
<owl:equivalentClass >
<rdfs:Datatype>
<owl:onDatatype rdf:resource="&xsd;decimal"/>
<owl:withRestrictions rdf:parseType="Collection">
<rdf:Description>
<xsd:minInclusive rdf:datatype="&xsd;decimal">0</xsd:minInclusive>
</rdf:Description>
<rdf:Description>
<xsd:maxInclusive rdf:datatype="&xsd; decimal ">100</xsd:maxInclusive>
</rdf:Description>
</owl:withRestrictions>
<rdfs:Datatype>
</owl:equivalentClass >
</rdfs:Datatype>

Similar errors also affect other datatypes:

• basisPoints
• restrictedPercentage

Logical error in definitions of BusinessFacingTypes

Several definitions in BusinessFacingTypes appear to be incorrectly specified, including percentage, restrictedPercentage, and basisPoints. All three are declared to be equivalent to xsd:decimal, which seems wrong from a logical perspective.