FIBO Foundations Avatar
  1. OMG Specification

FIBO Foundations — Closed Issues

  • Acronym: EDMC-FIBO/FND
  • Issues Count: 118
  • 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
FIBOFTF2-19 Conformance point for extension may be too open EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-20 Integrate a new Codes and Coding Schemes ontology with FIBO FND in support of SEC/Securities EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-24 Integrate the changes made to FIBO FND by FIBO IND with the baseline FND specification EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-56 Change Ownership and Control to complete the ownership and control “Lattice” pattern implementation EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-55 Changes in Agreements and Contracts in response to legal SME review EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-27 Revise section 8.2 in the FND spec document to reflect the new ontology architecture and namespace prefixes EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-28 Revise section 9 of the FND specification to reflect new metadata strategy EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-13 Inconsistent use of "entity" in definitions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-12 The property takesForm is in wrong ontology and with inadequate definition EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-14 FIBO does not cover concept of UnilateralContract EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-6 Allow for percentage notional amounts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-8 Misclassification of PartyInRole and Role EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-7 Align with W3C Organizations Ontology EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Closed; Out Of Scope closed
FIBOFTF2-11 hasPercentageAmount is semantically flawed EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-9 Add intersection of Control and Ownership EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-5 Segregate takesForm concepts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-10 Use of property domains and ranges EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-3 Relocate hasInforce to Jurisdictions.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-1 Inability to import UML-XMI files into generic UML EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Deferred closed
FIBOFTF2-4 Add property characteristics to properties EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-2 Replace PhysicalLocation with PopulationCenter EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-15 Several properties and classes in Ownership and Control are missing definitions, and some do not conform to FIBO naming conventions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-16 Diffing surfaced that there is not agreement on Make Contract a subclass of Agreement EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-17 Add Temporality for Contextual terms such as Ownership and Control EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-18 Four of the RDF/XML serialized OWL files for Foundations misspell rdf:type EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-22 Integrate Financial Dates ontology into FIBO FND Utilities Module EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-21 Integrate Facilities and Virtual Places ontologies into the FIBO FND Places module EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-23 Augment the Analytics ontology (originally from FIBO IND) with Expression, Formula, and Variable EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-70 equivalentClass relationship between Organization and sm:organization is unwarranted EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-69 Changes needed in Facilities to use new roles pattern EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-64 Implement FinancialDates for a number of properties EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-68 Transferable contract model element should be renamed to TransferableContract EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-82 Financial Dates incorrect properties usage EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-77 Issues uncovered in lint tests and reviews EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-85 Ontology imports not updated to reflect new policy or recent changes EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF-152 FIBO does not cover concept of UnilateralContract EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-130 Need the addition of LegallyCapableAdult and LegallyCapablePerson EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved 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-127 Additional over-long definitions EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-126 BilateralContract is too limiting -- rename to MultilateralContract EDMC-FIBO/FND 1.0b2 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-87 hasUniqueIdentifier should not be Functional 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-86 hasAcquisitionDate incorrectly defined EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-82 Errors in Table 10-4 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-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-72 Add ContractParty as superClass to ContractParties EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved 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-68 hasPercentageAmount is semantically flawed EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-67 Ontology names too unwieldy and indistinguishable EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-65 US/British definitions 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-64 Some people are color blind EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-63 OWA vs CWA 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-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-58 Refinement of Control concept semantics EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-57 Make Control a kind of ControlRelation EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-60 Incorrect definition for ContractCounterparty 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-54 Introduce partitions for firstness, secondness, thirdness EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change 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-51 Duplicate annotation property "definitionOrigin" in BusinessFacingTypes EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved 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-45 Incorrect application of naming convention for StateAbbreviation 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-46 Segregate takesForm concepts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-44 Incorrect cardinality on isIdentifiedBy 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-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-39 Add inverse property for hasPartyInRole EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-37 Add hasOrganizationMember 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-33 Missing annotations for isAssignable EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-35 Weak definition for isConferredBy EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved 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-32 TansferableContract incorrect definition 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-31 isAssignable incorrect domain and missing label 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-30 Incorrect definition for IndependentParty 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-27 isAssetOf incorrectly has as parent 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-25 Undue narrative material in definitin for CommonLawSystem EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-22 RDF datatype usage for annottions 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-24 Definition for WrittenContract too specific 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-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-18 Relocate hasMember to Organizations.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-15 Definition of 'owns' covers two meanings EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved 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-14 hasCurrency should not inherit from has. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change 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-10 objectProperty ëhasí is too generic EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-9 Certain address properties should be ObjectProperty, not DataProperty 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-8 Wrong use of dct:license property EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-7 Logical error in definitions of BusinessFacingTypes 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-2 Possible Syntax error in People.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved 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-3 Relationship of FIBO to other ontologies 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

Issues Descriptions

Conformance point for extension may be too open

  • Legacy Issue Number: 19601
  • Status: closed  
  • Source: Citi ( Ian Maung)
  • Summary:

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 17 Sep 2014 04:00 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Integrate a new Codes and Coding Schemes ontology with FIBO FND in support of SEC/Securities


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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 23 Sep 2014 18:00 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Change Ownership and Control to complete the ownership and control “Lattice” pattern implementation

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Thu, 6 Nov 2014 23:31 GMT
  • Disposition: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Changes in Agreements and Contracts in response to legal SME review

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Thu, 6 Nov 2014 22:57 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Implement minor changes in Agreement and Control for FIBOFTF55

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Revise section 8.2 in the FND spec document to reflect the new ontology architecture and namespace prefixes

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

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Sat, 25 Oct 2014 17:58 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Updates to Architecture section 8 to reflect new modules and ontologies

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Revise section 9 of the FND specification to reflect new metadata strategy

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

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Sat, 25 Oct 2014 18:01 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Inconsistent use of "entity" in definitions

  • 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: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    New definitions for terms that had the word entity in them

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

The property takesForm is in wrong ontology and with inadequate definition

  • 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: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Will be merged with issue 5 - its doppleganger.

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

FIBO does not cover concept of UnilateralContract

  • Status: closed  
  • Source: 88solutions ( Pete Rivett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Mon, 18 Aug 2014 15:54 GMT
  • Disposition: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Allow for percentage notional amounts

  • Key: FIBOFTF2-6
  • Status: closed  
  • Source: EDM Council ( 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: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Merge issue for percentage notional amounts with iffue FIBOFTF2-11

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Misclassification of PartyInRole and Role

  • Key: FIBOFTF2-8
  • Status: closed  
  • Source: EDM Council ( 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: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Change range of hasRole to ThingInRole; other changes to OrganizationMember

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

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

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

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

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

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

    This is retained.

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

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

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Align with W3C Organizations Ontology

  • Key: FIBOFTF2-7
  • Status: closed  
  • Source: EDM Council ( 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: Closed; Out Of Scope — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

hasPercentageAmount is semantically flawed

  • 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: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

    This Issue Resolution covers the following issues:

    Issue 11: “hasPercentageAmount is semantically flawed”

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Add intersection of Control and Ownership

  • Key: FIBOFTF2-9
  • Status: closed  
  • Source: EDM Council ( 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: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Add new OwnershipAndControl ontology in module OwnershipAndControl

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Segregate takesForm concepts

  • Key: FIBOFTF2-5
  • Status: closed  
  • Source: EDM Council ( 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: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Merge with issue 17 because this issue involves ownership.

    Merge with issue 17 because this issue involves ownership.

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Use of property domains and ranges


Relocate hasInforce to Jurisdictions.rdf

  • Key: FIBOFTF2-3
  • Status: closed  
  • Source: EDM Council ( 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: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Merged with issue ten.

    Issue 3 is a subset of issue 10.

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Inability to import UML-XMI files into generic UML

  • Key: FIBOFTF2-1
  • 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.0
  • Disposition Summary:

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

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

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Add property characteristics to properties

  • Key: FIBOFTF2-4
  • Status: closed  
  • Source: EDM Council ( 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: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Replace PhysicalLocation with PopulationCenter

  • Key: FIBOFTF2-2
  • 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: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Rename class urban center to populated place

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Several properties and classes in Ownership and Control are missing definitions, and some do not conform to FIBO naming conventions

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 14 Oct 2014 21:42 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Add missing definitions for Ownership and Control and rename some properties

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

    Add/change skos:definition as appropriate

    Changes are relative to the version submitted for FTF2

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Diffing surfaced that there is not agreement on Make Contract a subclass of Agreement

  • Status: closed  
  • Source: EDM Council ( Dennis Wisnosky)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Wed, 8 Oct 2014 15:16 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

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

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

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Add Temporality for Contextual terms such as Ownership and Control


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

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

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Fri, 26 Sep 2014 22:13 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Integrate Financial Dates ontology into FIBO FND Utilities Module

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

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

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 23 Sep 2014 18:44 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Additions in Countries; Addition of DatesAndTimes module and 3 ontologies

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

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

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 23 Sep 2014 18:51 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

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

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

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

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

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

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

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Augment the Analytics ontology (originally from FIBO IND) with Expression, Formula, and Variable

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

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

  • Reported: EDMC-FIBO/FND 1.0b1 — Tue, 23 Sep 2014 18:34 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Changes in Analytics for JIRA issue 23

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

equivalentClass relationship between Organization and sm:organization is unwarranted

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Thu, 13 Nov 2014 00:03 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Remove equivalence relation between Organization and sm:Organization

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Changes needed in Facilities to use new roles pattern

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

    Update the Facilities ontology to use isPlayedBy in place of hasRole

  • Reported: EDMC-FIBO/FND 1.0b2 — Wed, 12 Nov 2014 23:58 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Change facililties ontology to use new Roles pattern

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

    Update the Facilities ontology to use isPlayedBy in place of hasRole

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Implement FinancialDates for a number of properties

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Wed, 12 Nov 2014 23:09 GMT
  • Disposition: Duplicate or Merged — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT

Transferable contract model element should be renamed to TransferableContract

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Wed, 12 Nov 2014 23:50 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Renaming of Negotiable Contract

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Financial Dates incorrect properties usage

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

    Following the tightening up of domains and ranges in FIBOFTF2-10, some of the usages of one property in the Dates and Times module cause incorrect classification. Three classes that have restrictions on the property “designates” are now reclassified as Autonomous Agents because the property in Relations now has a domain of AutonomousAgent.

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

    Discussion
    From Elisa Kendall:
    There are three places where 'designates' is used in FinancialDates:
    AdHocScheduleEntry, RegularSchedule, and ScheduleStub. The sense that Mark had originally was that a schedule entry would designate an
    occurrence kind, so that an occurence of that schedule entry would be of
    exactly that occurrence kind. We have two options here:

    (1) remove AutonomousAgent as the domain of designates, or (2) use a
    different property in FinancialDates in these restrictions, revising the
    definitions appropriately.

    My preference is that we do (1), since I think the usage is in keeping
    with the definition of designates before AutonomousAgent was added as
    its domain, but if you were to do (2), an alternate property would be
    denotes.

    Investigation
    The restrictions are actually in the ontology “Occurrences” where there are additional assertions applied to the three classes named above (via three proxy classes in VOM). The three applications of this property are therefore all in the Occurrences ontology.

    The semantics of “designates’ was significantly overhauled in FIBOFTF2-10 (the ‘Property Domains and Ranges’ issue resolution). The original dispensation of designates, hasDesignation and the child property ‘appoints’ and its inverse ‘isAppointedBy’ were inconsistent with each other and with the stated definition, which explicitly referred to the deliberate act of designating (therefore by some person), some other person to some role or position.

    The suggested alternative above is to use ‘denotes’.

    The property ‘denotes’ is a child of ‘represents’ and links a class of “Representation” to a class of thing which it represents – that is, this is a relationship between some form of representation and something which it is a representation of, the form of representation in this case being denotation.

    The use of ‘denotes’ would work if it is OK to regard AdHocScheduleEntry, RegularSchedule, and ScheduleStub as kinds of representation, which will be OK if the semantics of “Schedule” (being the parent of RegularSchedule, and ScheduleStub) is intended to refer to the data representation of a set of dates and events, and not to the set of dates and events itself.

    There are two possible meanings of “Schedule” in general: it may mean a set of dates and events or it may mean the representation of those. Given the split between ad hoc and regular schedules, this would suggest the latter. That is, the real thing in the world which is a set of dates on which events occur, may be represented by one of two means: as an ad hoc listing of dates with an event for each, or as a parametric representation from which the individual occurrences of the event may be calculated.
    This would make the use of ‘denotes’ appropriate.

    On the other hand, Schedule itself has a property ‘hasOverallPeriod’ which is described as a date period, and the third class in the above, AdHocScheduleEntry has a property ‘hasDate’ which takes the Range of ‘Date’. These suggest that Schedule and AdHocScheduleEntry are really intended to be real things that are a schedule or schedule entry and that have a duration or a date (otherwise the properties would be ‘definesOverallPeriod’ and ‘definesDate’) which they are not. These properties are themselves sub properties of ‘has’, meaning that they are an actual characteristic of a thing and not a data representation of a characteristic of a thing.

    That being the case, it would be wrong to cause the model to infer that a Schedule or an ad hoc schedule entry are really kinds of representation, and therefore it would be wrong to use the property ‘denotes’. What is needed instead is an assertion that a schedule, stub or ad hoc entry each includes as part of it, some event (the OccurrenceKind which is the target of the required property as restricted in each case).

    It would also be optimal to use an existing property in Relations if there is one.

    Therefore the best solution is to use the property ‘comprises’ from Relations. This has a domain and range of Thing and has the definition: “includes, especially within a particular scope, is made up of”.
    This has the effect of saying that a regular schedule, a schedule stub and an ad hoc schedule entry each comprises (among other things e.g. the date or regular period), some kind of occurrence i.e. some event.

  • Reported: EDMC-FIBO/FND 1.0b2 — Mon, 24 Nov 2014 14:32 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

    Replace usages of the property 'designates' in Occurrences and references thereto in FinancialDates annotations

    Replace the references to the property 'designates' in three restrictions in the Occurrences ontology, with identicatl references to the property 'comprises', from Relations.

    Edit references to these in the annotations in the FinancialDates ontology.

    Discussion and Rationale:

    Discussion
    From Elisa Kendall:
    There are three places where 'designates' is used in FinancialDates:
    AdHocScheduleEntry, RegularSchedule, and ScheduleStub. The sense that Mark had originally was that a schedule entry would designate an
    occurrence kind, so that an occurence of that schedule entry would be of
    exactly that occurrence kind. We have two options here:

    (1) remove AutonomousAgent as the domain of designates, or (2) use a
    different property in FinancialDates in these restrictions, revising the
    definitions appropriately.

    My preference is that we do (1), since I think the usage is in keeping
    with the definition of designates before AutonomousAgent was added as
    its domain, but if you were to do (2), an alternate property would be
    denotes.

    Investigation
    The restrictions are actually in the ontology “Occurrences” where there are additional assertions applied to the three classes named above (via three proxy classes in VOM). The three applications of this property are therefore all in the Occurrences ontology.

    The semantics of “designates’ was significantly overhauled in FIBOFTF2-10 (the ‘Property Domains and Ranges’ issue resolution). The original dispensation of designates, hasDesignation and the child property ‘appoints’ and its inverse ‘isAppointedBy’ were inconsistent with each other and with the stated definition, which explicitly referred to the deliberate act of designating (therefore by some person), some other person to some role or position.

    The suggested alternative above is to use ‘denotes’.

    The property ‘denotes’ is a child of ‘represents’ and links a class of “Representation” to a class of thing which it represents – that is, this is a relationship between some form of representation and something which it is a representation of, the form of representation in this case being denotation.

    The use of ‘denotes’ would work if it is OK to regard AdHocScheduleEntry, RegularSchedule, and ScheduleStub as kinds of representation, which will be OK if the semantics of “Schedule” (being the parent of RegularSchedule, and ScheduleStub) is intended to refer to the data representation of a set of dates and events, and not to the set of dates and events itself.

    There are two possible meanings of “Schedule” in general: it may mean a set of dates and events or it may mean the representation of those. Given the split between ad hoc and regular schedules, this would suggest the latter. That is, the real thing in the world which is a set of dates on which events occur, may be represented by one of two means: as an ad hoc listing of dates with an event for each, or as a parametric representation from which the individual occurrences of the event may be calculated.

    This would make the use of ‘denotes’ appropriate.

    On the other hand, Schedule itself has a property ‘hasOverallPeriod’ which is described as a date period, and the third class in the above, AdHocScheduleEntry has a property ‘hasDate’ which takes the Range of ‘Date’. These suggest that Schedule and AdHocScheduleEntry are really intended to be real things that are a schedule or schedule entry and that have a duration or a date (otherwise the properties would be ‘definesOverallPeriod’ and ‘definesDate’) which they are not. These properties are themselves sub properties of ‘has’, meaning that they are an actual characteristic of a thing and not a data representation of a characteristic of a thing.

    That being the case, it would be wrong to cause the model to infer that a Schedule or an ad hoc schedule entry are really kinds of representation, and therefore it would be wrong to use the property ‘denotes’. What is needed instead is an assertion that a schedule, stub or ad hoc entry each includes as part of it, some event (the OccurrenceKind which is the target of the required property as restricted in each case).
    It would also be optimal to use an existing property in Relations if there is one.

    Therefore the best solution is to use the property ‘comprises’ from Relations. This has a domain and range of Thing and has the definition: “includes, especially within a particular scope, is made up of”.
    This has the effect of saying that a regular schedule, a schedule stub and an ad hoc schedule entry each comprises (among other things e.g. the date or regular period), some kind of occurrence i.e. some event.

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Issues uncovered in lint tests and reviews

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

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

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

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

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

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

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

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

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

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

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

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

    Implement recommendations from lint tests and review

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

Ontology imports not updated to reflect new policy or recent changes

  • Status: closed  
  • Source: EDM Council ( Mike Bennett)
  • Summary:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0b2 — Sun, 14 Dec 2014 02:06 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.0
  • Disposition Summary:

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

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

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

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

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

  • Updated: Tue, 21 Apr 2015 01:18 GMT
  • Attachments:

FIBO does not cover concept of UnilateralContract


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:

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

Additional over-long definitions

  • Status: closed  
  • Source: EDM Council ( 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:

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:

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

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

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

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

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:

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

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:

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:

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

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

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

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

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

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

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

Use of property domains and ranges

  • Key: FIBOFTF-62
  • Status: closed  
  • Source: EDM Council ( 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

Add intersection of Control and Ownership

  • Key: FIBOFTF-59
  • Status: closed  
  • Source: EDM Council ( 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: EDM Council ( 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

Refinement of Control concept semantics

  • Key: FIBOFTF-58
  • Status: closed  
  • Source: EDM Council ( 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:

Make Control a kind of ControlRelation

  • Key: FIBOFTF-57
  • Status: closed  
  • Source: EDM Council ( 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:

Incorrect definition for ContractCounterparty

  • Key: FIBOFTF-60
  • Status: closed  
  • Source: EDM Council ( 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 ControlledThing

  • Key: FIBOFTF-56
  • Status: closed  
  • Source: EDM Council ( 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:

Introduce partitions for firstness, secondness, thirdness

  • Key: FIBOFTF-54
  • Status: closed  
  • Source: EDM Council ( 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

Add ThingInRole

  • Key: FIBOFTF-55
  • Status: closed  
  • Source: EDM Council ( 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: EDM Council ( 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: EDM Council ( 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

Duplicate annotation property "definitionOrigin" in BusinessFacingTypes

  • Key: FIBOFTF-51
  • Status: closed  
  • Source: EDM Council ( 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:

FormalOrganization definition incorrect

  • Key: FIBOFTF-49
  • Status: closed  
  • Source: EDM Council ( 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: EDM Council ( 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: EDM Council ( 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: EDM Council ( 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

Incorrect application of naming convention for StateAbbreviation

  • Key: FIBOFTF-45
  • Status: closed  
  • Source: EDM Council ( 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

Naming of IndependentParty

  • Key: FIBOFTF-41
  • Status: closed  
  • Source: EDM Council ( 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

Segregate takesForm concepts

  • Key: FIBOFTF-46
  • Status: closed  
  • Source: EDM Council ( 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

Incorrect cardinality on isIdentifiedBy

  • Key: FIBOFTF-44
  • Status: closed  
  • Source: EDM Council ( 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:

Conflation of real things with text


Add property characteristics to properties

  • Key: FIBOFTF-40
  • Status: closed  
  • Source: EDM Council ( 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: EDM Council ( 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:

Add inverse property for hasPartyInRole

  • Key: FIBOFTF-39
  • Status: closed  
  • Source: EDM Council ( 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

Add hasOrganizationMember

  • Key: FIBOFTF-37
  • Status: closed  
  • Source: EDM Council ( 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

Introduce inverse property of hasOrganizationMember

  • Key: FIBOFTF-38
  • Status: closed  
  • Source: EDM Council ( 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

Missing annotations for isAssignable

  • Key: FIBOFTF-33
  • Status: closed  
  • Source: EDM Council ( 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

Weak definition for isConferredBy

  • Key: FIBOFTF-35
  • Status: closed  
  • Source: EDM Council ( 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

Properties hasParty and hasPartyInRole have has as parent

  • Key: FIBOFTF-36
  • Status: closed  
  • Source: EDM Council ( 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

TansferableContract incorrect definition

  • Key: FIBOFTF-32
  • Status: closed  
  • Source: EDM Council ( 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

Add new annotation for examples

  • Key: FIBOFTF-34
  • Status: closed  
  • Source: EDM Council ( 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

isAssignable incorrect domain and missing label

  • Key: FIBOFTF-31
  • Status: closed  
  • Source: EDM Council ( 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:

There are two definitions for Goal.

  • Key: FIBOFTF-29
  • Status: closed  
  • Source: EDM Council ( 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

Incorrect definition for IndependentParty

  • Key: FIBOFTF-30
  • Status: closed  
  • Source: EDM Council ( 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 Agreement.

  • Key: FIBOFTF-28
  • Status: closed  
  • Source: EDM Council ( 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

isAssetOf incorrectly has as parent

  • Key: FIBOFTF-27
  • Status: closed  
  • Source: EDM Council ( 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:

No definition for isOwnedBy

  • Key: FIBOFTF-26
  • Status: closed  
  • Source: EDM Council ( 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

Undue narrative material in definitin for CommonLawSystem

  • Key: FIBOFTF-25
  • Status: closed  
  • Source: EDM Council ( 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

RDF datatype usage for annottions

  • Key: FIBOFTF-22
  • Status: closed  
  • Source: EDM Council ( 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

Show a relationship from WrittenContract to written item.

  • Key: FIBOFTF-23
  • Status: closed  
  • Source: EDM Council ( 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

Definition for WrittenContract too specific

  • Key: FIBOFTF-24
  • Status: closed  
  • Source: EDM Council ( 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

Human readable label should have apostrophe

  • Key: FIBOFTF-21
  • Status: closed  
  • Source: EDM Council ( 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

Range for isTenderIn

  • Key: FIBOFTF-20
  • Status: closed  
  • Source: EDM Council ( 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: EDM Council ( 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

Relocate hasMember to Organizations.rdf

  • Key: FIBOFTF-18
  • Status: closed  
  • Source: EDM Council ( 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

Definition of 'owns' covers two meanings

  • Key: FIBOFTF-15
  • Status: closed  
  • Source: EDM Council ( 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

Rename LegalConstruct to LegalConferral

  • Key: FIBOFTF-17
  • Status: closed  
  • Source: EDM Council ( 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: EDM Council ( 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

hasCurrency should not inherit from has.

  • Key: FIBOFTF-14
  • Status: closed  
  • Source: EDM Council ( 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

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:

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

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

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

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:

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:

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

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:

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

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

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: