FIBO Foundations Avatar
  1. OMG Specification

FIBO Foundations — Closed Issues

  • Acronym: EDMC-FIBO/FND
  • Issues Count: 153
  • 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
FIBOFND12-1 Inability to import UML-XMI files into generic UML EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.2 Deferred closed
FIBOFND12-10 Several FND about files have incorrect prefixes EDMC-FIBO/FND 1.1 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-9 Move StructuredCollection from IND to FND EDMC-FIBO/FND 1.1b2 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-8 Not all transferable contracts are unilateral EDMC-FIBO/FND 1.1 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-7 Revise and refactor ContractTermsSet and its relationship to Contract EDMC-FIBO/FND 1.1 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-6 Several additional concepts are needed in the Business Dates ontology to support specific schedule definitions EDMC-FIBO/FND 1.1 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-5 Schedule in FND/DatesAndTimes should be a child of Collection EDMC-FIBO/FND 1.1b2 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-4 comprises needs an explanatory note and inverse property EDMC-FIBO/FND 1.1b2 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-3 The domain of the "uses" and range of "isUsedBy", added in FND 1.1, cause reasoning errors EDMC-FIBO/FND 1.1b2 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND12-2 Definition of property 'provides' implies a specific audience EDMC-FIBO/FND 1.1b2 EDMC-FIBO/FND 1.2 Resolved closed
FIBOFND11-46 Revise the about files for FND to include the new ontologies added by FBC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-45 Section 8.1 limits usage of ODM constructs EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-44 Resolve issues with Monetary Amount and Amount of Money EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-43 Introduce the concept of Litigation Capacity into the LegalCapacity ontology EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-42 Incorporate the description of the new table notation and revise table structure for those that have not been revised in other issue resolutions EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-41 Update the Conformance section in line with changes in FBC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-40 Update UML References to Version 2.5 EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-29 Missing a generic "hasAddress" property in the Addresses ontology EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-4 Correct errors, including section references, in the conformance section of the specification EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-3 Several properties involving dates require revision to leverage the FinancialDates ontology EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-2 The definition of isDomiciledIn is inadequate EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-26 Incorrect XML file locations in specification cover pages, and incorrectliy listed About files EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-62 Then change in which PostalAddress was renamed to PhysicalAddress is not backwardly compatible EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-58 Replace renamed MoneyAmount concept with a deprecated concept EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-56 Revise the two products and services ontologies to reflect the name change made to MoneyAmount EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-27 The Agreements ontology does not match the FND 1.0 Specification for the definition of Agreement EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-6 Add a new Classification Schemes ontology to FND as required by the FBC RFC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-20 A definition for rate is missing from FND/Utilities/Analytics, required to represent interest rate, payment rate, and market rate EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-14 Revise the Legal Capacity Ontology as required by FIBO FBC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-12 Add a new Products and Services Module to FND as required by FIBO FBC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-10 Revise the Currency Amount Ontology and add ISO Currency Codes as required by FIBO FBC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-8 Add a new Quantities and Units Ontology to FND as required by FIBO FBC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-16 Revise Sections 8.1 and 8.2 of the Specification with additional changes made by FBC EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-18 The currency code for the New Israeli Sheqel is misspelled in the ISO4217-CurrencyCodes ontology EDMC-FIBO/FND 1.0 EDMC-FIBO/FND 1.1 Resolved closed
FIBOFND11-1 Inability to import UML-XMI files into generic UML EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.1 Deferred 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-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-19 Conformance point for extension may be too open EDMC-FIBO/FND 1.0b1 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-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-11 hasPercentageAmount is semantically flawed EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF2-10 Use of property domains and ranges 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-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-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-6 Allow for percentage notional amounts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-5 Segregate takesForm concepts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged 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-4 Add property characteristics to properties EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Duplicate or Merged closed
FIBOFTF2-3 Relocate hasInforce to Jurisdictions.rdf 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-1 Inability to import UML-XMI files into generic UML EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0 Deferred 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-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-22 Integrate Financial Dates ontology into FIBO FND Utilities 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-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-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-85 Ontology imports not updated to reflect new policy or recent changes 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-69 Changes needed in Facilities to use new roles pattern EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved 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-64 Implement FinancialDates for a number of properties EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Duplicate or Merged 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-82 Financial Dates incorrect properties usage EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0 Resolved closed
FIBOFTF-126 BilateralContract is too limiting -- rename to MultilateralContract EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-127 Additional over-long definitions EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-152 FIBO does not cover concept of UnilateralContract EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-129 Final version of all diagrams for the FND FTF 1 should be provided in SVG form EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-128 Replace the <> stereotype with <> or <> as appropriate EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-130 Need the addition of LegallyCapableAdult and LegallyCapablePerson EDMC-FIBO/FND 1.0b2 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-82 Errors in Table 10-4 EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-81 Incorrect label "synonym" for &fibo-fnd-utl-av;abbreviation EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-73 Need the property "isDomiciledIn" to be moved from BE/CorporateBodies to FND/FormalOrganizations EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-83 Definition of "number" inconsistent with its equivalent datatype EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-72 Add ContractParty as superClass to ContractParties EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-68 hasPercentageAmount is semantically flawed EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-87 hasUniqueIdentifier should not be Functional EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-86 hasAcquisitionDate incorrectly defined EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-85 yesOrNo is not the same as Boolean EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-84 No abbreviation for percentage EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-70 Inconsistent use of "entity" in definitions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-69 The property takesForm is in wrong ontology and with inadequate definition EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-63 OWA vs CWA EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-66 Where to stop EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-65 US/British definitions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-64 Some people are color blind EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-67 Ontology names too unwieldy and indistinguishable EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-56 Add ControlledThing EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-55 Add ThingInRole EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-53 Misclassification of PartyInRole and Role EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-52 Align with W3C Organizations Ontology EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-49 FormalOrganization definition incorrect EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-50 RealEstate definition overcrowded EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-48 isGovernedBy definition missing. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-47 Allow for percentage notional amounts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-46 Segregate takesForm concepts EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-57 Make Control a kind of ControlRelation EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-51 Duplicate annotation property "definitionOrigin" in BusinessFacingTypes EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-54 Introduce partitions for firstness, secondness, thirdness EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-30 Incorrect definition for IndependentParty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-29 There are two definitions for Goal. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-28 There are two definitions for Agreement. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-32 TansferableContract incorrect definition EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-27 isAssetOf incorrectly has as parent EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-25 Undue narrative material in definitin for CommonLawSystem EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-24 Definition for WrittenContract too specific EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-31 isAssignable incorrect domain and missing label EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-33 Missing annotations for isAssignable EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-26 No definition for isOwnedBy EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-23 Show a relationship from WrittenContract to written item. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; Out Of Scope closed
FIBOFTF-8 Wrong use of dct:license property EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-9 Certain address properties should be ObjectProperty, not DataProperty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-1 The current Addresses.rdf specification does not allow for the temporality of addresses that are associated with an entity EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-3 Relationship of FIBO to other ontologies EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-2 Possible Syntax error in People.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-5 Issues with how Address Properties are represented EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Duplicate or Merged closed
FIBOFTF-4 Inability to import UML-XMI files into generic UML EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-60 Incorrect definition for ContractCounterparty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-59 Add intersection of Control and Ownership EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-61 Overpopulated definitions in People.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-62 Use of property domains and ranges EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-58 Refinement of Control concept semantics EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-42 Conflation of real things with text EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-41 Naming of IndependentParty EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-40 Add property characteristics to properties EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-43 Incorrect cardinality in hasAddress EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-45 Incorrect application of naming convention for StateAbbreviation EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-44 Incorrect cardinality on isIdentifiedBy EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-37 Add hasOrganizationMember EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-36 Properties hasParty and hasPartyInRole have has as parent EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-38 Introduce inverse property of hasOrganizationMember EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-39 Add inverse property for hasPartyInRole EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-35 Weak definition for isConferredBy EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-34 Add new annotation for examples EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-17 Rename LegalConstruct to LegalConferral EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-16 Add explanatory annottions for de jure control and de facto control EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-15 Definition of 'owns' covers two meanings EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-13 FIBO should not have a list of values for Gender EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-20 Range for isTenderIn EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-19 Relocate hasInforce to Jurisdictions.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-22 RDF datatype usage for annottions EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-21 Human readable label should have apostrophe EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed
FIBOFTF-11 Replace PhysicalLocation with PopulationCenter EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Deferred closed
FIBOFTF-10 objectProperty ëhasí is too generic EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-14 hasCurrency should not inherit from has. EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-18 Relocate hasMember to Organizations.rdf EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Closed; No Change closed
FIBOFTF-7 Logical error in definitions of BusinessFacingTypes EDMC-FIBO/FND 1.0b1 EDMC-FIBO/FND 1.0b2 Resolved closed

Issues Descriptions

Inability to import UML-XMI files into generic UML

  • 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.2
  • Disposition Summary:

    Inability to import UML-XMI files into generic UML

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

  • Updated: Mon, 16 Oct 2017 15:45 GMT

Several FND about files have incorrect prefixes

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.1 — Sun, 12 Feb 2017 01:14 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

    Several FND about files have incorrect prefixes

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

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

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

Move StructuredCollection from IND to FND

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

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

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

  • Reported: EDMC-FIBO/FND 1.1b2 — Sun, 12 Feb 2017 01:06 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

    Move StructuredCollection from IND to FND

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

Not all transferable contracts are unilateral

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

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

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

  • Reported: EDMC-FIBO/FND 1.1 — Sun, 12 Feb 2017 01:02 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

    Not all transferable contracts are unilateral

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

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

    This resolution depends on the resolution of FIBOFND12-7.

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

Revise and refactor ContractTermsSet and its relationship to Contract

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

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.1 — Sun, 12 Feb 2017 00:59 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

    Revise and refactor ContractTermsSet and its relationship to Contract

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

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

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

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

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

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.1 — Sun, 12 Feb 2017 00:51 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

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

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

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

Schedule in FND/DatesAndTimes should be a child of Collection

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

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

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.1b2 — Sun, 12 Feb 2017 00:43 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

    Schedule in FND/DatesAndTimes should be a child of Collection

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

comprises needs an explanatory note and inverse property

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

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

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

  • Reported: EDMC-FIBO/FND 1.1b2 — Sun, 12 Feb 2017 00:38 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

    comprises needs an explanatory note and inverse property

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

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

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

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.1b2 — Sun, 12 Feb 2017 00:32 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

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

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

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

Definition of property 'provides' implies a specific audience

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

    provides: makes something available to

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

  • Reported: EDMC-FIBO/FND 1.1b2 — Sun, 12 Feb 2017 00:27 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.2
  • Disposition Summary:

    Definition of property 'provides' implies a specific audience

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

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

  • Updated: Thu, 22 Jun 2017 16:43 GMT
  • Attachments:

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 12 Feb 2016 21:47 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Section 8.1 limits usage of ODM constructs

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 12 Feb 2016 21:44 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Amend Clause 8 to reflect possible use of all ODM constructs

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Resolve issues with Monetary Amount and Amount of Money

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 12 Feb 2016 21:42 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Resolve issues with Monetary Amount and Amount of Money

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Introduce the concept of Litigation Capacity into the LegalCapacity ontology

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 12 Feb 2016 21:40 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Introduce the concept of Litigation Capacity into the LegalCapacity ontology

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Incorporate the description of the new table notation and revise table structure for those that have not been revised in other issue resolutions

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 12 Feb 2016 21:35 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Update the Conformance section in line with changes in FBC

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 12 Feb 2016 21:30 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Changes to wording in Conformance clause

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

    To

    2.2.1 Assessing FIBO Model Conformance

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

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

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

    So that the clause which reads:

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

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

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

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

    6. Rename heading 2.4.3.2 to read:

    “2.4.3.2 Extended Tables”

    7. In 2.4.3.2

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

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Update UML References to Version 2.5

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 12 Feb 2016 21:27 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Update UML Reference in Section 3.1 Table

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Missing a generic "hasAddress" property in the Addresses ontology

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Wed, 10 Feb 2016 22:53 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Missing a generic "hasAddress" property in the Addresses ontology

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Tue, 5 Jan 2016 20:02 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT

Several properties involving dates require revision to leverage the FinancialDates ontology

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Tue, 3 Mar 2015 17:00 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Several properties involving dates require revision to leverage the FinancialDates ontology

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

The definition of isDomiciledIn is inadequate

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Tue, 3 Mar 2015 16:51 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    The definition of isDomiciledIn is inadequate

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Incorrect XML file locations in specification cover pages, and incorrectliy listed About files


Then change in which PostalAddress was renamed to PhysicalAddress is not backwardly compatible

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Thu, 3 Mar 2016 16:25 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Replace renamed MoneyAmount concept with a deprecated concept

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Mon, 15 Feb 2016 17:56 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Replace renamed MoneyAmount concept with a deprecated concept

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Sun, 14 Feb 2016 20:48 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Sat, 6 Feb 2016 03:05 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Tue, 5 Jan 2016 20:25 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Tue, 19 Jan 2016 18:42 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Revise the Legal Capacity Ontology as required by FIBO FBC

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 8 Jan 2016 00:08 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

    Revise the Legal Capacity Ontology as required by FIBO FBC

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Thu, 7 Jan 2016 23:13 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Thu, 7 Jan 2016 21:45 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Thu, 7 Jan 2016 20:05 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Fri, 8 Jan 2016 00:32 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

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

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

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

  • Reported: EDMC-FIBO/FND 1.0 — Mon, 11 Jan 2016 21:05 GMT
  • Disposition: Resolved — EDMC-FIBO/FND 1.1
  • Disposition Summary:

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT
  • Attachments:

Inability to import UML-XMI files into generic UML

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

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

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

  • Updated: Tue, 12 Jul 2016 14:46 GMT

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

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


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

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

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:

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:

Use of property domains and ranges


Add intersection of Control and Ownership

  • Key: FIBOFTF2-9
  • Status: closed  
  • Source: IOTA Foundation ( 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:

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:

Misclassification of PartyInRole and Role

  • Key: FIBOFTF2-8
  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( 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

Allow for percentage notional amounts

  • Key: FIBOFTF2-6
  • Status: closed  
  • Source: IOTA Foundation ( 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

Segregate takesForm concepts

  • Key: FIBOFTF2-5
  • Status: closed  
  • Source: IOTA Foundation ( 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

Add Temporality for Contextual terms such as Ownership and Control


Add property characteristics to properties

  • Key: FIBOFTF2-4
  • Status: closed  
  • Source: IOTA Foundation ( 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

Relocate hasInforce to Jurisdictions.rdf

  • Key: FIBOFTF2-3
  • Status: closed  
  • Source: IOTA Foundation ( 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

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

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

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

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

  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( 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:

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:

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:

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:

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:

Ontology imports not updated to reflect new policy or recent changes

  • Status: closed  
  • Source: IOTA Foundation ( 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:

Issues uncovered in lint tests and reviews

  • Status: closed  
  • Source: IOTA Foundation ( 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:

Changes needed in Facilities to use new roles pattern

  • Status: closed  
  • Source: IOTA Foundation ( 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:

Transferable contract model element should be renamed to TransferableContract

  • Status: closed  
  • Source: IOTA Foundation ( 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:

Implement FinancialDates for a number of properties

  • Status: closed  
  • Source: IOTA Foundation ( 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

equivalentClass relationship between Organization and sm:organization is unwarranted

  • Status: closed  
  • Source: IOTA Foundation ( 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:

Financial Dates incorrect properties usage

  • Status: closed  
  • Source: IOTA Foundation ( 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:

BilateralContract is too limiting -- rename to MultilateralContract

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

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

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

    BilateralContract is too limiting – rename to MultilateralContract

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

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

Additional over-long definitions

  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

FIBO does not cover concept of UnilateralContract


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Need the addition of LegallyCapableAdult and LegallyCapablePerson

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

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

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

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

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

Errors in Table 10-4

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

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

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

    Errors in Table 10-4

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Doing FIBO-BE surfaced this issue.

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

Definition of "number" inconsistent with its equivalent datatype

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

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

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

    Inconsistent number definition

    Unclear semantics.

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

Add ContractParty as superClass to ContractParties

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

    Missing ContractParty as superclass to ContactParties, ContractCounterParty, and ContractPrinciple

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

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

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

hasPercentageAmount is semantically flawed

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

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

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

    hasPercentageAmount is semantically flawed

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

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

hasUniqueIdentifier should not be Functional

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

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

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

    hasUniqueIdentifier should not be Functional

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

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

hasAcquisitionDate incorrectly defined

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

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

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

    *hasAcquisitionDate incorrectly defined *

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

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

yesOrNo is not the same as Boolean

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

    The lexical space for xs:boolean is

    {true, false, 1, 0}

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

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

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

    YesOrNo is a no go

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

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

No abbreviation for percentage

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

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

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

    No abbreviation for percentage

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

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

Inconsistent use of "entity" in definitions

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

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

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

    inconsistent use of the word Entity.

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

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

The property takesForm is in wrong ontology and with inadequate definition

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

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

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

    hasPercentageAmount is semantically flawed

    Percentage semantically flawed

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

OWA vs CWA

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

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

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

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

    remove and add

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

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

Where to stop

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

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

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

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

    agreed

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

US/British definitions

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

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

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

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

    Definitions should have no borders

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

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

Some people are color blind

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

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

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

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

    New SW is being used that standardizes colors.

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

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

Ontology names too unwieldy and indistinguishable

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

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

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

    Ontology names too unwieldy and indistinguishable

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

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

Add ControlledThing

  • Key: FIBOFTF-56
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

    Introduce ControlledThing, which is a kind of ThingInRole

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

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

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

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

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

Add ThingInRole

  • Key: FIBOFTF-55
  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( 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: IOTA Foundation ( Mike Bennett)
  • Summary:

    We should more formally align with the W3C Organizations ontology.

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

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

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

    Align with W3C Organizations Ontology

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

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

FormalOrganization definition incorrect

  • Key: FIBOFTF-49
  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( 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: IOTA Foundation ( 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: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

    Percentage notional amounts

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

Segregate takesForm concepts

  • Key: FIBOFTF-46
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

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

Make Control a kind of ControlRelation

  • Key: FIBOFTF-57
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    Introduced as a first iteration of the lattice pattern

    Make Control a kind of ControlRelation

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

Duplicate annotation property "definitionOrigin" in BusinessFacingTypes

  • Key: FIBOFTF-51
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    Rogue copies of annotations.

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

Introduce partitions for firstness, secondness, thirdness

  • Key: FIBOFTF-54
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

    agreed

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

Incorrect definition for IndependentParty

  • Key: FIBOFTF-30
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

There are two definitions for Goal.

  • Key: FIBOFTF-29
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

There are two definitions for Agreement.

  • Key: FIBOFTF-28
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

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

TansferableContract incorrect definition

  • Key: FIBOFTF-32
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

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

isAssetOf incorrectly has as parent

  • Key: FIBOFTF-27
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

    IsAssetOf should not have a parent

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

Undue narrative material in definitin for CommonLawSystem

  • Key: FIBOFTF-25
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

Definition for WrittenContract too specific

  • Key: FIBOFTF-24
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

isAssignable incorrect domain and missing label

  • Key: FIBOFTF-31
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

    Add domain of Contract to isAssignable.

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

Missing annotations for isAssignable

  • Key: FIBOFTF-33
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

No definition for isOwnedBy

  • Key: FIBOFTF-26
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

    The property isOwnedBy has no definition.

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

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

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

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

Show a relationship from WrittenContract to written item.

  • Key: FIBOFTF-23
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    Show a relationship from WrittenContract to written item.

    Written contract links to scanned doc or PDF

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

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

Wrong use of dct:license property

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

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

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

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

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

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

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

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

    Wrong use of dct:license

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

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

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

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

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

Certain address properties should be ObjectProperty, not DataProperty

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

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

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

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


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


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

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

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

    Certain address properties should be ObjectProperty, not DataProperty

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

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

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

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

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

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

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

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

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

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

Relationship of FIBO to other ontologies

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

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

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

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

    Adjust Annex B to cater for ontologies already in ODM

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

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

Possible Syntax error in People.rdf

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

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

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

    Lines 188-189 should be replaced by the single line

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

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

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

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

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

Issues with how Address Properties are represented

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

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

    Comments:

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

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

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

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

Inability to import UML-XMI files into generic UML

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

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

    Comments:

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

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

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

    There is no acceptable solution at this time.

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

Incorrect definition for ContractCounterparty

  • Key: FIBOFTF-60
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

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

Add intersection of Control and Ownership

  • Key: FIBOFTF-59
  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

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

Use of property domains and ranges

  • Key: FIBOFTF-62
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

    The entire model should be reviewed for such occurrences

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

    Use of property domains and ranges

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

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

Refinement of Control concept semantics

  • Key: FIBOFTF-58
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

    introduced as a frist iteration of the lattice pattern

    Refinement of Control concept semantics

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

Conflation of real things with text


Naming of IndependentParty

  • Key: FIBOFTF-41
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

    The class IndependentParty should really be named PotentialParty or PotentialOwner.

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

    These two issues should be discussed together.

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

    agreed

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

Add property characteristics to properties

  • Key: FIBOFTF-40
  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

    hasPostalAddress cardinality

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

Incorrect application of naming convention for StateAbbreviation

  • Key: FIBOFTF-45
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    Incorrect application of naming convention for StateAbbreviation

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

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

Incorrect cardinality on isIdentifiedBy

  • Key: FIBOFTF-44
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    isIdentifiedBy cardinality

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

Add hasOrganizationMember

  • Key: FIBOFTF-37
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

    Needed for Proof of Concept ontologies.

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

    Add hasOrganizationMember

    Discussion involved:

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

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

Properties hasParty and hasPartyInRole have has as parent

  • Key: FIBOFTF-36
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

    agreed

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

Introduce inverse property of hasOrganizationMember

  • Key: FIBOFTF-38
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    Needed for Proof of Concept ontologies.

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

    Introduce inverse property of hasOrganizationMember

    Discussion involved:

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

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

Add inverse property for hasPartyInRole

  • Key: FIBOFTF-39
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    agreed

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

Weak definition for isConferredBy

  • Key: FIBOFTF-35
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

Add new annotation for examples

  • Key: FIBOFTF-34
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

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

Rename LegalConstruct to LegalConferral

  • Key: FIBOFTF-17
  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

    Add explanatory annottions for de jure control and de facto control

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

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

Definition of 'owns' covers two meanings

  • Key: FIBOFTF-15
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

    FIBO classes and properties should each represent one meaning only.

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

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

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

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

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

FIBO should not have a list of values for Gender

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

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

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

    FIBO should not have a list of values for Gender

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

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

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

Range for isTenderIn

  • Key: FIBOFTF-20
  • Status: closed  
  • Source: IOTA Foundation ( 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: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    *Relocate hasInforce to Jurisdictions.rdf hasInForce*

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

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

RDF datatype usage for annottions

  • Key: FIBOFTF-22
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    RDF datatype usage for annotations

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

    VOM now does this automatically.

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

Human readable label should have apostrophe

  • Key: FIBOFTF-21
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

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

    Human Readable label sub task

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

Replace PhysicalLocation with PopulationCenter

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

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

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

    Replace PhysicalLocation with PopulationCenter

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

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

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

objectProperty ëhasí is too generic

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

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

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

    objectProperty "has" is too generic

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

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

hasCurrency should not inherit from has.

  • Key: FIBOFTF-14
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

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

    On reflection, Mike agrees with the original model.

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

Relocate hasMember to Organizations.rdf

  • Key: FIBOFTF-18
  • Status: closed  
  • Source: IOTA Foundation ( Mike Bennett)
  • Summary:

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

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

    Close no change.

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

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

Logical error in definitions of BusinessFacingTypes

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

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

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

    Similar errors also affect other datatypes:

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

    Logical error in definitions of BusinessFacingTypes

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

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