${taskforce.name} Avatar
  1. OMG Task Force

FIBO Foundations 1.0 FTF2 — Closed Issues

Open Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
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

Issues Descriptions

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

  • Status: closed  
  • Source: Thematix Partners LLC ( Mrs. Elisa F. 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 ( Mrs. Elisa F. 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 ( Mrs. Elisa F. 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: Adaptive ( Mr. 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: Object Management Group ( Mr. 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 ( Mrs. Elisa F. 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: Enterprise Knowledge Graph Foundation ( 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Enterprise Knowledge Graph Foundation ( 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: Enterprise Knowledge Graph Foundation ( 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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: Adaptive ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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 ( Mrs. Elisa F. 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 ( Mrs. Elisa F. 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 ( Mrs. Elisa F. 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 ( Mrs. Elisa F. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: Object Management Group ( Mr. 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: