FIBO Foundations Avatar
  1. OMG Specification

FIBO Foundations — Closed Issues

  • Acronym: EDMC-FIBO/FND
  • Issues Count: 83
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
FIBOFTF-126 BilateralContract is too limiting -- rename to MultilateralContract EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-127 Additional over-long definitions EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-152 FIBO does not cover concept of UnilateralContract EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-129 Final version of all diagrams for the FND FTF 1 should be provided in SVG form EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-128 Replace the <> stereotype with <> or <> as appropriate EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-130 Need the addition of LegallyCapableAdult and LegallyCapablePerson EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-82 Errors in Table 10-4 EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-81 Incorrect label "synonym" for &fibo-fnd-utl-av;abbreviation EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-73 Need the property "isDomiciledIn" to be moved from BE/CorporateBodies to FND/FormalOrganizations EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-83 Definition of "number" inconsistent with its equivalent datatype EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-72 Add ContractParty as superClass to ContractParties EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-68 hasPercentageAmount is semantically flawed EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-87 hasUniqueIdentifier should not be Functional EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-86 hasAcquisitionDate incorrectly defined EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-85 yesOrNo is not the same as Boolean EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-84 No abbreviation for percentage EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-70 Inconsistent use of "entity" in definitions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-69 The property takesForm is in wrong ontology and with inadequate definition EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-63 OWA vs CWA EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-66 Where to stop EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-65 US/British definitions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-64 Some people are color blind EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-67 Ontology names too unwieldy and indistinguishable EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-56 Add ControlledThing EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-55 Add ThingInRole EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-53 Misclassification of PartyInRole and Role EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-52 Align with W3C Organizations Ontology EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-49 FormalOrganization definition incorrect EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-50 RealEstate definition overcrowded EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-48 isGovernedBy definition missing. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-47 Allow for percentage notional amounts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-46 Segregate takesForm concepts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-57 Make Control a kind of ControlRelation EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-51 Duplicate annotation property "definitionOrigin" in BusinessFacingTypes EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-54 Introduce partitions for firstness, secondness, thirdness EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-30 Incorrect definition for IndependentParty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-29 There are two definitions for Goal. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-28 There are two definitions for Agreement. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-32 TansferableContract incorrect definition EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-27 isAssetOf incorrectly has as parent EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-25 Undue narrative material in definitin for CommonLawSystem EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-24 Definition for WrittenContract too specific EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-31 isAssignable incorrect domain and missing label EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-33 Missing annotations for isAssignable EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-26 No definition for isOwnedBy EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-23 Show a relationship from WrittenContract to written item. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; Out Of Scope closed
FIBOFTF-8 Wrong use of dct:license property EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-9 Certain address properties should be ObjectProperty, not DataProperty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-1 The current Addresses.rdf specification does not allow for the temporality of addresses that are associated with an entity EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-3 Relationship of FIBO to other ontologies EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-2 Possible Syntax error in People.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-5 Issues with how Address Properties are represented EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Duplicate or Merged closed
FIBOFTF-4 Inability to import UML-XMI files into generic UML EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-60 Incorrect definition for ContractCounterparty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-59 Add intersection of Control and Ownership EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-61 Overpopulated definitions in People.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-62 Use of property domains and ranges EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-58 Refinement of Control concept semantics EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-42 Conflation of real things with text EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-41 Naming of IndependentParty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-40 Add property characteristics to properties EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-43 Incorrect cardinality in hasAddress EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-45 Incorrect application of naming convention for StateAbbreviation EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-44 Incorrect cardinality on isIdentifiedBy EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-37 Add hasOrganizationMember EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-36 Properties hasParty and hasPartyInRole have has as parent EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-38 Introduce inverse property of hasOrganizationMember EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-39 Add inverse property for hasPartyInRole EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-35 Weak definition for isConferredBy EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-34 Add new annotation for examples EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-17 Rename LegalConstruct to LegalConferral EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-16 Add explanatory annottions for de jure control and de facto control EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-15 Definition of 'owns' covers two meanings EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-13 FIBO should not have a list of values for Gender EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-20 Range for isTenderIn EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-19 Relocate hasInforce to Jurisdictions.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-22 RDF datatype usage for annottions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-21 Human readable label should have apostrophe EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-11 Replace PhysicalLocation with PopulationCenter EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-10 objectProperty ëhasí is too generic EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-14 hasCurrency should not inherit from has. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-18 Relocate hasMember to Organizations.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-7 Logical error in definitions of BusinessFacingTypes EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed

Issues Descriptions

BilateralContract is too limiting -- rename to MultilateralContract

  • Status: closed  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b2 — Tue, 15 Jul 2014 16:18 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Additional over-long definitions

  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b2 — Tue, 15 Jul 2014 17:41 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

FIBO does not cover concept of UnilateralContract


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

  • Status: closed  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b2 — Tue, 22 Jul 2014 19:04 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Replace the <> stereotype with <> or <> as appropriate

  • Status: closed  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b2 — Tue, 22 Jul 2014 18:41 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Need the addition of LegallyCapableAdult and LegallyCapablePerson

  • Status: closed  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b2 — Tue, 22 Jul 2014 19:16 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Errors in Table 10-4

  • Key: FIBOFTF-82
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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)

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 21 May 2014 00:39 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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)

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Incorrect label "synonym" for &fibo-fnd-utl-av;abbreviation

  • Key: FIBOFTF-81
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 21 May 2014 00:11 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

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

  • Key: FIBOFTF-73
  • Status: closed  
  • Source: Thematix Partners LLC ( Elisa Kendall)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 15 May 2014 16:18 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

    Doing FIBO-BE surfaced this issue.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Definition of "number" inconsistent with its equivalent datatype

  • Key: FIBOFTF-83
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 21 May 2014 00:47 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Inconsistent number definition

    Unclear semantics.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add ContractParty as superClass to ContractParties

  • Key: FIBOFTF-72
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    Missing ContractParty as superclass to ContactParties, ContractCounterParty, and ContractPrinciple

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 13 May 2014 22:52 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

hasPercentageAmount is semantically flawed

  • Key: FIBOFTF-68
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 22 Apr 2014 17:56 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

hasUniqueIdentifier should not be Functional

  • Key: FIBOFTF-87
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 21 May 2014 01:51 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

hasAcquisitionDate incorrectly defined

  • Key: FIBOFTF-86
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 21 May 2014 01:30 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

yesOrNo is not the same as Boolean

  • Key: FIBOFTF-85
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    The lexical space for xs:boolean is

    {true, false, 1, 0}

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 21 May 2014 01:20 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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:

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No abbreviation for percentage

  • Key: FIBOFTF-84
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 21 May 2014 01:11 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inconsistent use of "entity" in definitions

  • Key: FIBOFTF-70
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 24 Apr 2014 14:36 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

The property takesForm is in wrong ontology and with inadequate definition

  • Key: FIBOFTF-69
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 24 Apr 2014 14:27 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    hasPercentageAmount is semantically flawed

    Percentage semantically flawed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

OWA vs CWA

  • Key: FIBOFTF-63
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 7 Apr 2014 20:31 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Where to stop

  • Key: FIBOFTF-66
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 7 Apr 2014 20:38 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

US/British definitions

  • Key: FIBOFTF-65
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 7 Apr 2014 20:35 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Definitions should have no borders

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Some people are color blind

  • Key: FIBOFTF-64
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 7 Apr 2014 20:33 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Ontology names too unwieldy and indistinguishable

  • Key: FIBOFTF-67
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 17 Apr 2014 20:59 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Ontology names too unwieldy and indistinguishable

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add ControlledThing

  • Key: FIBOFTF-56
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    Introduce ControlledThing, which is a kind of ThingInRole

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:20 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Add ThingInRole

  • Key: FIBOFTF-55
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:18 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Misclassification of PartyInRole and Role

  • Key: FIBOFTF-53
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:11 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Misclassification of PartyInRole and Role

    Reasoner misclassifies PartyInRole and Role

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Align with W3C Organizations Ontology

  • Key: FIBOFTF-52
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:09 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

FormalOrganization definition incorrect

  • Key: FIBOFTF-49
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:04 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RealEstate definition overcrowded

  • Key: FIBOFTF-50
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:05 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isGovernedBy definition missing.

  • Key: FIBOFTF-48
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:03 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Allow for percentage notional amounts

  • Key: FIBOFTF-47
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:01 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    *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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Segregate takesForm concepts

  • Key: FIBOFTF-46
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:00 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    *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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Make Control a kind of ControlRelation

  • Key: FIBOFTF-57
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:22 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Introduced as a first iteration of the lattice pattern

    Make Control a kind of ControlRelation

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Duplicate annotation property "definitionOrigin" in BusinessFacingTypes

  • Key: FIBOFTF-51
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:06 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Rogue copies of annotations.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Introduce partitions for firstness, secondness, thirdness

  • Key: FIBOFTF-54
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:16 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect definition for IndependentParty

  • Key: FIBOFTF-30
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:32 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are two definitions for Goal.

  • Key: FIBOFTF-29
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:29 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

There are two definitions for Agreement.

  • Key: FIBOFTF-28
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:28 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

TansferableContract incorrect definition

  • Key: FIBOFTF-32
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:44 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isAssetOf incorrectly has as parent

  • Key: FIBOFTF-27
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 20:30 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    IsAssetOf should not have a parent

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Undue narrative material in definitin for CommonLawSystem

  • Key: FIBOFTF-25
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 20:24 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition for WrittenContract too specific

  • Key: FIBOFTF-24
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 20:23 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

isAssignable incorrect domain and missing label

  • Key: FIBOFTF-31
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:37 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Add domain of Contract to isAssignable.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Missing annotations for isAssignable

  • Key: FIBOFTF-33
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:47 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

No definition for isOwnedBy

  • Key: FIBOFTF-26
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    The property isOwnedBy has no definition.

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 20:27 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Show a relationship from WrittenContract to written item.

  • Key: FIBOFTF-23
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 20:21 GMT
  • Disposition: Closed; Out Of Scope — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Wrong use of dct:license property

  • Key: FIBOFTF-8
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 27 Feb 2014 20:16 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Certain address properties should be ObjectProperty, not DataProperty

  • Key: FIBOFTF-9
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 17 Mar 2014 20:14 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

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

  • Key: FIBOFTF-1
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Feb 2014 20:44 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Relationship of FIBO to other ontologies

  • Key: FIBOFTF-3
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Feb 2014 19:33 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Possible Syntax error in People.rdf

  • Key: FIBOFTF-2
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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-

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Feb 2014 18:44 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Issues with how Address Properties are represented

  • Key: FIBOFTF-5
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Feb 2014 19:55 GMT
  • Disposition: Duplicate or Merged — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Inability to import UML-XMI files into generic UML

  • Key: FIBOFTF-4
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Feb 2014 19:46 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    This issue will be deferred until RTF2 so that there can be more testing.

    There is no acceptable solution at this time.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect definition for ContractCounterparty

  • Key: FIBOFTF-60
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:32 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add intersection of Control and Ownership

  • Key: FIBOFTF-59
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:27 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Overpopulated definitions in People.rdf

  • Key: FIBOFTF-61
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:34 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Use of property domains and ranges

  • Key: FIBOFTF-62
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 17:06 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Refinement of Control concept semantics

  • Key: FIBOFTF-58
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 02:24 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    introduced as a frist iteration of the lattice pattern

    Refinement of Control concept semantics

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Conflation of real things with text


Naming of IndependentParty

  • Key: FIBOFTF-41
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:52 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add property characteristics to properties

  • Key: FIBOFTF-40
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:49 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Add property characteristics to properties

    The 'tagged values' AKA Property Axioms

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect cardinality in hasAddress

  • Key: FIBOFTF-43
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:56 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    hasPostalAddress cardinality

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Incorrect application of naming convention for StateAbbreviation

  • Key: FIBOFTF-45
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:58 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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"

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Incorrect cardinality on isIdentifiedBy

  • Key: FIBOFTF-44
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:57 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    isIdentifiedBy cardinality

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Add hasOrganizationMember

  • Key: FIBOFTF-37
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

    Needed for Proof of Concept ontologies.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:33 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Properties hasParty and hasPartyInRole have has as parent

  • Key: FIBOFTF-36
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:53 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Introduce inverse property of hasOrganizationMember

  • Key: FIBOFTF-38
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:35 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add inverse property for hasPartyInRole

  • Key: FIBOFTF-39
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 21 Mar 2014 01:44 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    agreed

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Weak definition for isConferredBy

  • Key: FIBOFTF-35
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:50 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add new annotation for examples

  • Key: FIBOFTF-34
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 21:49 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Rename LegalConstruct to LegalConferral

  • Key: FIBOFTF-17
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 19:45 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Add explanatory annottions for de jure control and de facto control

  • Key: FIBOFTF-16
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 19:42 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Definition of 'owns' covers two meanings

  • Key: FIBOFTF-15
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 19:38 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

FIBO should not have a list of values for Gender

  • Key: FIBOFTF-13
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 18 Mar 2014 18:35 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Range for isTenderIn

  • Key: FIBOFTF-20
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 19:52 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    isTEnderIn range too specific

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments:

Relocate hasInforce to Jurisdictions.rdf

  • Key: FIBOFTF-19
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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?

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 19:48 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    *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!

  • Updated: Fri, 6 Mar 2015 20:58 GMT

RDF datatype usage for annottions

  • Key: FIBOFTF-22
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 20:20 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Human readable label should have apostrophe

  • Key: FIBOFTF-21
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 20:18 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    Human Readable label sub task

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Replace PhysicalLocation with PopulationCenter

  • Key: FIBOFTF-11
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 17 Mar 2014 20:20 GMT
  • Disposition: Deferred — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

objectProperty ëhasí is too generic

  • Key: FIBOFTF-10
  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 17 Mar 2014 20:19 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

hasCurrency should not inherit from has.

  • Key: FIBOFTF-14
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

    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.

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 19:55 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    On reflection, Mike agrees with the original model.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Relocate hasMember to Organizations.rdf

  • Key: FIBOFTF-18
  • Status: closed  
  • Source: Object Management Group ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 20 Mar 2014 19:46 GMT
  • Disposition: Closed; No Change — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Logical error in definitions of BusinessFacingTypes

  • Key: FIBOFTF-7
  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

    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
  • Reported: EDMC-FIBO/FND 1.0b1 — Thu, 27 Feb 2014 20:08 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0b2
  • Disposition Summary:

    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.

  • Updated: Fri, 6 Mar 2015 20:58 GMT
  • Attachments: