Table of contents
  1. Financial Industry Business Ontology Foundations
  2. Preface
  3. 0 Submission-Specific Material
    1. 0.1 Submission Preface
    2. 0.2 Copyright Waiver
    3. 0.3 Submission Team
    4. 0.4 General Requirements
      1. 0.4.1 EDM Council Involvement with the OMG
    5. 0.5 Future Changes to this Specification
      1. 0.5.1 What is “Content”?
    6. 0.6 Methodological Aspects
      1. 0.6.1 Current Status
      2. 0.6.2 Operational Ontologies
  4. 1 Scope
    1. 1.1 Overview
    2. 1.2 Applications and Uses of FIBO
    3. 1.3 How FIBO is Different from Operational Ontologies
    4. 1.4 How FIBO is Different from Data Models
    5. 1.5 Definitions
      1. 1.5.1 Definitions Policy
  5. 2 Conformance
    1. 2.1 Overview
    2. 2.3 Conformant Technical Applications of Model Content
      1. 2.3.1 Assessing Model Conformance
        1. 2.3.1.1 Full FIBO Foundations Model Conformance
        2. 2.3.1.2 FIBO Ontology Model Conformance
      2. 2.3.2 Assessing FIBO ODM Conformance
    3. 2.4 Conformant Extensions of FIBO Content
      1. 2.4.1 Labeling
      2. 2.4.2 Model Consistency
      3. 2.4.3 Relationship to Subject Matter
    4. 2.5 Conformant Business Presentation of Model Content
      1. 2.5.1 General Requirements
      2. 2.5.2 Business Diagram Conformance
      3. 2.5.3 Business Table Conformance
        1. 2.5.3.1 Basic Table
        2. 2.5.3.2 Extended Table
  6. 3 References
    1. 3.1 Normative References
    2. 3.2 Non Normative References
    3. 3.3 Changes to Adopted OMG Specifications
  7. 4 Terms and Definitions
  8. 5 Symbols and Abbreviations
    1. 5.1 Symbols
    2. 5.2 Abbreviations
  9. 6 Additional Information
    1. 6.1 How to Read this Specification
      1. 6.1.1 Audiences
        1. 6.1.1.1 Standards Community
        2. 6.1.1.2 The Finance Industry Business Community
        3. 6.1.1.3 The Regulatory Community
        4. 6.1.1.4 Technical Architects
        5. 6.1.1.5 Semantic Modelers
    2. 6.2 Acknowledgements
    3. 6.3 Interpreting the Business Model Content
      1. 6.3.1 Introduction
      2. 6.3.2 The Model
        1. 6.3.2.1 What the Model Contains
        2. 6.3.2.2 Model Views
        3. 6.3.2.3 Business Diagrams
      3. 6.3.3 Interpretation
        1. 6.2.3.1 Thing
        2. 6.2.3.2 Inheritance: the Parent 'is a' relationship
        3. 6.2.3.3 Simple Properties
        4. 6.2.3.4 Relationship Properties
        5. 6.2.3.5 Logical Unions
        6. 6.2.3.6 Mutually Exclusive sets
        7. 6.2.3.7 Relationship Properties hierarchies
        8. 6.2.3.8 Inverse relationships
        9. 6.2.3.9 Selection Lists
        10. 6.2.3.10 Selections of Things
  10. 7 Introduction
      1. 7.1.2 Reading this Standard
    1. 7.3 Usage Scenarios
      1. 7.3.1 Model Driven Development
      2. 7.3.2 Semantic Technology Development
      3. 7.3.3 Integration of systems and/or data feeds
  11. 8 Architecture
    1. 8.1 Ontology Definition Metamodel (ODM) Usage and Adaptations
      1. 8.1.1 Introduction
      2. 8.1.2 ODM Constructs Usage
        1. Table 8-1 ODM Constructs Usage
    2. 8.2 Ontology Architecture and Namespaces
      1. Figure 8.1 Foundations Ontology Architecture
      2. Table 8-2 Prefix and Namespaces for referenced/external vocabularies
      3. Table 8-3 Prefix and Namespaces for FIBO Foundations
    3. 8.4 FIBO-Based Reporting
      1. 8.4.3 Business-Facing Approach
        1. Figure 8.2 Example Business-Facing FIBO Diagram
  12. 9 Additional Metadata
    1. 9.1 Introduction
    2. 9.2 Ontology-Level Metadata
      1. Table 9-1 FIBO Foundations Specification Family Metadata
      2. Table 9-2 FIBO Foundations Specification Metadata
      3. Table 9-3 FIBO Foundations Specification Version Metadata
      4. Table 9-4 FIBO Foundations Specification Curation and Rights Metadata
    3. 9.3 Ontology Entity-Level Metadata
      1. 9.3.1 Definitions, Notes, and Labels
        1. Table 9-5 Definitions, Labeling, and Notes
      2. 9.3.2 Synonymous Terms
      3. 9.3.3 Provenance and Cross-reference Annotation
      4. 9.3.4 Change Management Annotation
  13. 10 Model Content Reports
    1. Table 10-1 Table Guide
    2. 10.1 Module: Utilities
      1. Table 10-2 Utilities Module Metadata
      2. 10.1.1 Ontology: Annotation Vocabulary
        1. Figure 10.1.1.1 Annotation Vocabulary Concepts
        2. Table 10-3 Annotation Vocabulary Metadata
        3. Table 10-4 Annotation Vocabulary Details
      3.  10.1.2 Ontology: Business Facing Types
        1. Figure 10.1.2.1 Business Types Concepts
        2. Table 10-5 Business-Facing Types Ontology Metadata
        3. Table 10-6 Business Facing Types Details
    3. 10.2 Module: Relations
      1. Table 10-7 Relations Module Metadata
      2. 10.2.1 Ontology: Relations
        1. Figure 10.1.1 Relations Concepts
        2. Table 10-8 Relations Ontology Metadata
        3. Table 10-9 Relations Details
    4. 10.3 Module: Goals and Objectives
      1. Table 10-10 Goals and Objectives Module Metadata
      2. 10.3.1 Ontology: Goals
        1. Figure 10.3.1.1 Goals Concepts
        2. Table 10-11 Goals Ontology Metadata
        3. Table 10-12 Goals Details
      3.  10.3.2 Ontology: Objectives
        1. Figure 10.3.2.1 Objectives Concepts
        2. Table 10-13 Objectives Ontology Metadata
        3. Table 10-14 Objectives Details
    5. 10.4 Module: Parties
      1. Table 10-15 Parties Module Metadata
      2. 10.4.1 Ontology: Parties
        1. Figure 10.4.1.1 Parties Concepts
        2. Table 10-16 Parties Ontology Metadata
        3. Table 10-17 Parties Details
      3. 10.4.2 Ontology: Roles
        1. Figure 10.4.2.1 Roles Concepts
        2. Table 10-18 Roles Ontology Metadata
        3. Table 10-19 Roles Details
    6. 10.5 Module: Agents and People
      1. Table 10-20 Agents and People Module Metadata
      2. 10.5.1 Ontology: Agents
        1. Figure 10.5.1.1 Agents Concepts
        2. Table 10-21 Agents Ontology Metadata
        3. Table 10-22 Agents Details
      3. 10.5.2 Ontology: People
        1. Figure 10.5.2.1 People Concepts
        2. Table 10-23 People Ontology Metadata
        3. Table 10-24 People Details
    7. 10.6 Module: Places
      1. Table 10-25 Places Module Metadata
      2. 10.6.1 Ontology: Locations
        1. Figure 10.6.1.1 Locations Concepts
        2. Table 10-26 Locations Ontology Metadata
        3. Table 10-27 Locations Details
      3. 10.6.2 Ontology: Countries
        1. Figure 10.6.2.1 Countries Concepts
        2. Table 10-28 Countries Ontology Metadata
        3. Table 10-29 Countries Details
      4. 10.6.3 Ontology: Addresses
        1. Figure 10.6.3.1 Addresses Concepts
        2. Table 10-30 Addresses Ontology Metadata
        3. Table 10-31 Addresses Details
    8. 10.7 Module: Organizations
      1. Table 10-32 Organizations Module Metadata
      2. 10.7.1 Ontology: Organizations
        1. Figure 10.7.1.1 Organizations Concepts
        2. Table 10-33 Organizations Ontology Metadata
        3. Table 10-34 Organizations Details
      3. 10.7.2 Ontology: Formal Organizations
        1. Figure 10.7.2.1 Formal Organizations Concepts
        2. Table 10-35 Formal Organizations Ontology Metadata
        3. Table 10-36 Formal Organizations Details
      4. 10.7.3 Ontology: Legitimate Organizations
        1. Figure 10.7.3.1 Legitimate and Illicit Organizations Concepts
        2. Table 10-37 Legitimate Organizations Ontology Metadata
        3. Table 10-38 Legitimate and Illicit Organizations Details
    9. 10.8 Module: Agreements
      1. Table 10-39 Agreements Module Metadata
      2. 10.8.1 Ontology: Agreements
        1. Figure 10.8.1.1 Agreements Concepts
        2. Table 10-40 Agreements Ontology Metadata
        3. Table 10-41 Agreements Details
      3. 10.8.2 Ontology: Contracts
        1. Figure 10.8.2.1 Contracts Concepts
        2. Table 10-42 Contracts Ontology Metadata
        3. Table 10-43 Contracts Details
    10. 10.9 Module: Law
      1. Table 10-44 Law Module Metadata
      2.  10.9.1 Ontology: Legal Core
        1. Figure 10.9.1.1  Legal Core Concepts
        2. Table 10-45.  Legal Core Ontology Metadata
        3. Table 10-46 Legal Core Details
      3. 10.9.2 Ontology: Jurisdiction
        1. Figure 10.9.2.1 Jurisdiction Concepts
        2. Table 10-47 Jurisdiction Ontology Metadata
        3. Table 10-48 Jurisdiction Details
      4. 10.9.3 Ontology: Legal Capacity
        1. Figure 10.9.3.1 Legal Capacity Concepts
        2. Table 10-49 Legal Capacity Ontology Metadata
        3. Table 10-50 Legal Capacity Details
    11. 10.10 Module: Ownership and Control
      1. Table 10-51 Ownership and Control Module Metadata
      2. 10.10.1 Ontology: Control
        1. Figure 10.10.1.1 Control Concepts
        2. Table 10-52 Control Ontology Metadata
        3. Table 10-53 Control Details
      3. 10.10.2 Ontology: Ownership
        1. Figure 10.10.1.1 Ownership Concepts
        2. Table 10-54 Ownership Ontology Metadata
        3. Table 10-55 Ownership Details
    12. 10.11 Module: Accounting
      1. Table 10-56 Accounting Module Metadata
      2. 10.11.1 Ontology: Accounting Equity
        1. Figure 10.11.1.1 Accounting Equity Concepts
        2. Table 10-57 Accounting Equity Ontology Metadata
        3. Table 10-58 Accounting Equity Details
      3. 10.11.2 Ontology: Currency Amount
        1. Figure 10.11.1 Currency and Amount Concepts
        2. Table 10-59 Currency Amount Ontology Metadata
        3. Table 10-60 Currency and Amount Details
  14. Annex A Machine Readable Files Part of This Specification (normative)
  15. Annex B Shared Semantics Treatments
    1. B.1 Introduction
    2. B.2 Shared Semantics Treatments
  16. Annex C Logical versus Conceptual Models comparison
    1. C.1 Comparison Table
      1. Table C1.1 Model Comparisons
    2. C.2 Detailed Models Comparison
    3. C.3 Model Partitioning
      1. C.3.1 Independent, Relative and Mediating Things
      2. C.3.2 Concrete and Abstract Things
      3. C.3.3 Continuant and Occurrent Things
  17. Annex D How to extend FIBO ontologies (informative)
    1. D.1 Terminology used in this Annex
    2. D.2 Overview
      1. D.2.1 Classes of Thing
      2. D.2.2 Model relationship to Subject Matter
      3. D.2.3 How to Model New Classes
      4. D.2.4 Declaring Class Disjointness
      5. D.2.5 How to Model New Facts about Things
      6. D.2.6 Inverse Relationships
      7. D.2.7 How and When to Use Enumerations
      8. D.2.8 Foundations Concepts Usage
      9. D.2.9 Content Creation Summary
    3. D.3 Presentation Considerations
      1. D.3.1 Labeling
      2. D.3.2 Ontologies
      3. D.3.3 UML Considerations
        1. UML Diagrams
        2. UML Notation
        3. Diagram Layout
        4. Diagram Notes
        5. UML Diagram Boundaries
        6. UML Packages
  18. Annex E Creating Applications with FIBO (Informative)
    1. E.1 Introduction
      1. E.1.1 Principles
      2. E.1.2 Operational Ontologies
      3. E.1.3 Conventional Applications
  19. References
    1. [1]
    2. [2]
    3. [3]
    4. [4]
    5. [5]
    6. [6]

Financial Industry Business Ontology Foundations

Last modified
Table of contents
  1. Financial Industry Business Ontology Foundations
  2. Preface
  3. 0 Submission-Specific Material
    1. 0.1 Submission Preface
    2. 0.2 Copyright Waiver
    3. 0.3 Submission Team
    4. 0.4 General Requirements
      1. 0.4.1 EDM Council Involvement with the OMG
    5. 0.5 Future Changes to this Specification
      1. 0.5.1 What is “Content”?
    6. 0.6 Methodological Aspects
      1. 0.6.1 Current Status
      2. 0.6.2 Operational Ontologies
  4. 1 Scope
    1. 1.1 Overview
    2. 1.2 Applications and Uses of FIBO
    3. 1.3 How FIBO is Different from Operational Ontologies
    4. 1.4 How FIBO is Different from Data Models
    5. 1.5 Definitions
      1. 1.5.1 Definitions Policy
  5. 2 Conformance
    1. 2.1 Overview
    2. 2.3 Conformant Technical Applications of Model Content
      1. 2.3.1 Assessing Model Conformance
        1. 2.3.1.1 Full FIBO Foundations Model Conformance
        2. 2.3.1.2 FIBO Ontology Model Conformance
      2. 2.3.2 Assessing FIBO ODM Conformance
    3. 2.4 Conformant Extensions of FIBO Content
      1. 2.4.1 Labeling
      2. 2.4.2 Model Consistency
      3. 2.4.3 Relationship to Subject Matter
    4. 2.5 Conformant Business Presentation of Model Content
      1. 2.5.1 General Requirements
      2. 2.5.2 Business Diagram Conformance
      3. 2.5.3 Business Table Conformance
        1. 2.5.3.1 Basic Table
        2. 2.5.3.2 Extended Table
  6. 3 References
    1. 3.1 Normative References
    2. 3.2 Non Normative References
    3. 3.3 Changes to Adopted OMG Specifications
  7. 4 Terms and Definitions
  8. 5 Symbols and Abbreviations
    1. 5.1 Symbols
    2. 5.2 Abbreviations
  9. 6 Additional Information
    1. 6.1 How to Read this Specification
      1. 6.1.1 Audiences
        1. 6.1.1.1 Standards Community
        2. 6.1.1.2 The Finance Industry Business Community
        3. 6.1.1.3 The Regulatory Community
        4. 6.1.1.4 Technical Architects
        5. 6.1.1.5 Semantic Modelers
    2. 6.2 Acknowledgements
    3. 6.3 Interpreting the Business Model Content
      1. 6.3.1 Introduction
      2. 6.3.2 The Model
        1. 6.3.2.1 What the Model Contains
        2. 6.3.2.2 Model Views
        3. 6.3.2.3 Business Diagrams
      3. 6.3.3 Interpretation
        1. 6.2.3.1 Thing
        2. 6.2.3.2 Inheritance: the Parent 'is a' relationship
        3. 6.2.3.3 Simple Properties
        4. 6.2.3.4 Relationship Properties
        5. 6.2.3.5 Logical Unions
        6. 6.2.3.6 Mutually Exclusive sets
        7. 6.2.3.7 Relationship Properties hierarchies
        8. 6.2.3.8 Inverse relationships
        9. 6.2.3.9 Selection Lists
        10. 6.2.3.10 Selections of Things
  10. 7 Introduction
      1. 7.1.2 Reading this Standard
    1. 7.3 Usage Scenarios
      1. 7.3.1 Model Driven Development
      2. 7.3.2 Semantic Technology Development
      3. 7.3.3 Integration of systems and/or data feeds
  11. 8 Architecture
    1. 8.1 Ontology Definition Metamodel (ODM) Usage and Adaptations
      1. 8.1.1 Introduction
      2. 8.1.2 ODM Constructs Usage
        1. Table 8-1 ODM Constructs Usage
    2. 8.2 Ontology Architecture and Namespaces
      1. Figure 8.1 Foundations Ontology Architecture
      2. Table 8-2 Prefix and Namespaces for referenced/external vocabularies
      3. Table 8-3 Prefix and Namespaces for FIBO Foundations
    3. 8.4 FIBO-Based Reporting
      1. 8.4.3 Business-Facing Approach
        1. Figure 8.2 Example Business-Facing FIBO Diagram
  12. 9 Additional Metadata
    1. 9.1 Introduction
    2. 9.2 Ontology-Level Metadata
      1. Table 9-1 FIBO Foundations Specification Family Metadata
      2. Table 9-2 FIBO Foundations Specification Metadata
      3. Table 9-3 FIBO Foundations Specification Version Metadata
      4. Table 9-4 FIBO Foundations Specification Curation and Rights Metadata
    3. 9.3 Ontology Entity-Level Metadata
      1. 9.3.1 Definitions, Notes, and Labels
        1. Table 9-5 Definitions, Labeling, and Notes
      2. 9.3.2 Synonymous Terms
      3. 9.3.3 Provenance and Cross-reference Annotation
      4. 9.3.4 Change Management Annotation
  13. 10 Model Content Reports
    1. Table 10-1 Table Guide
    2. 10.1 Module: Utilities
      1. Table 10-2 Utilities Module Metadata
      2. 10.1.1 Ontology: Annotation Vocabulary
        1. Figure 10.1.1.1 Annotation Vocabulary Concepts
        2. Table 10-3 Annotation Vocabulary Metadata
        3. Table 10-4 Annotation Vocabulary Details
      3.  10.1.2 Ontology: Business Facing Types
        1. Figure 10.1.2.1 Business Types Concepts
        2. Table 10-5 Business-Facing Types Ontology Metadata
        3. Table 10-6 Business Facing Types Details
    3. 10.2 Module: Relations
      1. Table 10-7 Relations Module Metadata
      2. 10.2.1 Ontology: Relations
        1. Figure 10.1.1 Relations Concepts
        2. Table 10-8 Relations Ontology Metadata
        3. Table 10-9 Relations Details
    4. 10.3 Module: Goals and Objectives
      1. Table 10-10 Goals and Objectives Module Metadata
      2. 10.3.1 Ontology: Goals
        1. Figure 10.3.1.1 Goals Concepts
        2. Table 10-11 Goals Ontology Metadata
        3. Table 10-12 Goals Details
      3.  10.3.2 Ontology: Objectives
        1. Figure 10.3.2.1 Objectives Concepts
        2. Table 10-13 Objectives Ontology Metadata
        3. Table 10-14 Objectives Details
    5. 10.4 Module: Parties
      1. Table 10-15 Parties Module Metadata
      2. 10.4.1 Ontology: Parties
        1. Figure 10.4.1.1 Parties Concepts
        2. Table 10-16 Parties Ontology Metadata
        3. Table 10-17 Parties Details
      3. 10.4.2 Ontology: Roles
        1. Figure 10.4.2.1 Roles Concepts
        2. Table 10-18 Roles Ontology Metadata
        3. Table 10-19 Roles Details
    6. 10.5 Module: Agents and People
      1. Table 10-20 Agents and People Module Metadata
      2. 10.5.1 Ontology: Agents
        1. Figure 10.5.1.1 Agents Concepts
        2. Table 10-21 Agents Ontology Metadata
        3. Table 10-22 Agents Details
      3. 10.5.2 Ontology: People
        1. Figure 10.5.2.1 People Concepts
        2. Table 10-23 People Ontology Metadata
        3. Table 10-24 People Details
    7. 10.6 Module: Places
      1. Table 10-25 Places Module Metadata
      2. 10.6.1 Ontology: Locations
        1. Figure 10.6.1.1 Locations Concepts
        2. Table 10-26 Locations Ontology Metadata
        3. Table 10-27 Locations Details
      3. 10.6.2 Ontology: Countries
        1. Figure 10.6.2.1 Countries Concepts
        2. Table 10-28 Countries Ontology Metadata
        3. Table 10-29 Countries Details
      4. 10.6.3 Ontology: Addresses
        1. Figure 10.6.3.1 Addresses Concepts
        2. Table 10-30 Addresses Ontology Metadata
        3. Table 10-31 Addresses Details
    8. 10.7 Module: Organizations
      1. Table 10-32 Organizations Module Metadata
      2. 10.7.1 Ontology: Organizations
        1. Figure 10.7.1.1 Organizations Concepts
        2. Table 10-33 Organizations Ontology Metadata
        3. Table 10-34 Organizations Details
      3. 10.7.2 Ontology: Formal Organizations
        1. Figure 10.7.2.1 Formal Organizations Concepts
        2. Table 10-35 Formal Organizations Ontology Metadata
        3. Table 10-36 Formal Organizations Details
      4. 10.7.3 Ontology: Legitimate Organizations
        1. Figure 10.7.3.1 Legitimate and Illicit Organizations Concepts
        2. Table 10-37 Legitimate Organizations Ontology Metadata
        3. Table 10-38 Legitimate and Illicit Organizations Details
    9. 10.8 Module: Agreements
      1. Table 10-39 Agreements Module Metadata
      2. 10.8.1 Ontology: Agreements
        1. Figure 10.8.1.1 Agreements Concepts
        2. Table 10-40 Agreements Ontology Metadata
        3. Table 10-41 Agreements Details
      3. 10.8.2 Ontology: Contracts
        1. Figure 10.8.2.1 Contracts Concepts
        2. Table 10-42 Contracts Ontology Metadata
        3. Table 10-43 Contracts Details
    10. 10.9 Module: Law
      1. Table 10-44 Law Module Metadata
      2.  10.9.1 Ontology: Legal Core
        1. Figure 10.9.1.1  Legal Core Concepts
        2. Table 10-45.  Legal Core Ontology Metadata
        3. Table 10-46 Legal Core Details
      3. 10.9.2 Ontology: Jurisdiction
        1. Figure 10.9.2.1 Jurisdiction Concepts
        2. Table 10-47 Jurisdiction Ontology Metadata
        3. Table 10-48 Jurisdiction Details
      4. 10.9.3 Ontology: Legal Capacity
        1. Figure 10.9.3.1 Legal Capacity Concepts
        2. Table 10-49 Legal Capacity Ontology Metadata
        3. Table 10-50 Legal Capacity Details
    11. 10.10 Module: Ownership and Control
      1. Table 10-51 Ownership and Control Module Metadata
      2. 10.10.1 Ontology: Control
        1. Figure 10.10.1.1 Control Concepts
        2. Table 10-52 Control Ontology Metadata
        3. Table 10-53 Control Details
      3. 10.10.2 Ontology: Ownership
        1. Figure 10.10.1.1 Ownership Concepts
        2. Table 10-54 Ownership Ontology Metadata
        3. Table 10-55 Ownership Details
    12. 10.11 Module: Accounting
      1. Table 10-56 Accounting Module Metadata
      2. 10.11.1 Ontology: Accounting Equity
        1. Figure 10.11.1.1 Accounting Equity Concepts
        2. Table 10-57 Accounting Equity Ontology Metadata
        3. Table 10-58 Accounting Equity Details
      3. 10.11.2 Ontology: Currency Amount
        1. Figure 10.11.1 Currency and Amount Concepts
        2. Table 10-59 Currency Amount Ontology Metadata
        3. Table 10-60 Currency and Amount Details
  14. Annex A Machine Readable Files Part of This Specification (normative)
  15. Annex B Shared Semantics Treatments
    1. B.1 Introduction
    2. B.2 Shared Semantics Treatments
  16. Annex C Logical versus Conceptual Models comparison
    1. C.1 Comparison Table
      1. Table C1.1 Model Comparisons
    2. C.2 Detailed Models Comparison
    3. C.3 Model Partitioning
      1. C.3.1 Independent, Relative and Mediating Things
      2. C.3.2 Concrete and Abstract Things
      3. C.3.3 Continuant and Occurrent Things
  17. Annex D How to extend FIBO ontologies (informative)
    1. D.1 Terminology used in this Annex
    2. D.2 Overview
      1. D.2.1 Classes of Thing
      2. D.2.2 Model relationship to Subject Matter
      3. D.2.3 How to Model New Classes
      4. D.2.4 Declaring Class Disjointness
      5. D.2.5 How to Model New Facts about Things
      6. D.2.6 Inverse Relationships
      7. D.2.7 How and When to Use Enumerations
      8. D.2.8 Foundations Concepts Usage
      9. D.2.9 Content Creation Summary
    3. D.3 Presentation Considerations
      1. D.3.1 Labeling
      2. D.3.2 Ontologies
      3. D.3.3 UML Considerations
        1. UML Diagrams
        2. UML Notation
        3. Diagram Layout
        4. Diagram Notes
        5. UML Diagram Boundaries
        6. UML Packages
  18. Annex E Creating Applications with FIBO (Informative)
    1. E.1 Introduction
      1. E.1.1 Principles
      2. E.1.2 Operational Ontologies
      3. E.1.3 Conventional Applications
  19. References
    1. [1]
    2. [2]
    3. [3]
    4. [4]
    5. [5]
    6. [6]

  1. Financial Industry Business Ontology Foundations
  2. Preface
  3. 0 Submission-Specific Material
    1. 0.1 Submission Preface
    2. 0.2 Copyright Waiver
    3. 0.3 Submission Team
    4. 0.4 General Requirements
      1. 0.4.1 EDM Council Involvement with the OMG
    5. 0.5 Future Changes to this Specification
      1. 0.5.1 What is “Content”?
    6. 0.6 Methodological Aspects
      1. 0.6.1 Current Status
      2. 0.6.2 Operational Ontologies
  4. 1 Scope
    1. 1.1 Overview
    2. 1.2 Applications and Uses of FIBO
    3. 1.3 How FIBO is Different from Operational Ontologies
    4. 1.4 How FIBO is Different from Data Models
    5. 1.5 Definitions
      1. 1.5.1 Definitions Policy
  5. 2 Conformance
    1. 2.1 Overview
    2. 2.3 Conformant Technical Applications of Model Content
      1. 2.3.1 Assessing Model Conformance
        1. 2.3.1.1 Full FIBO Foundations Model Conformance
        2. 2.3.1.2 FIBO Ontology Model Conformance
      2. 2.3.2 Assessing FIBO ODM Conformance
    3. 2.4 Conformant Extensions of FIBO Content
      1. 2.4.1 Labeling
      2. 2.4.2 Model Consistency
      3. 2.4.3 Relationship to Subject Matter
    4. 2.5 Conformant Business Presentation of Model Content
      1. 2.5.1 General Requirements
      2. 2.5.2 Business Diagram Conformance
      3. 2.5.3 Business Table Conformance
        1. 2.5.3.1 Basic Table
        2. 2.5.3.2 Extended Table
  6. 3 References
    1. 3.1 Normative References
    2. 3.2 Non Normative References
    3. 3.3 Changes to Adopted OMG Specifications
  7. 4 Terms and Definitions
  8. 5 Symbols and Abbreviations
    1. 5.1 Symbols
    2. 5.2 Abbreviations
  9. 6 Additional Information
    1. 6.1 How to Read this Specification
      1. 6.1.1 Audiences
        1. 6.1.1.1 Standards Community
        2. 6.1.1.2 The Finance Industry Business Community
        3. 6.1.1.3 The Regulatory Community
        4. 6.1.1.4 Technical Architects
        5. 6.1.1.5 Semantic Modelers
    2. 6.2 Acknowledgements
    3. 6.3 Interpreting the Business Model Content
      1. 6.3.1 Introduction
      2. 6.3.2 The Model
        1. 6.3.2.1 What the Model Contains
        2. 6.3.2.2 Model Views
        3. 6.3.2.3 Business Diagrams
      3. 6.3.3 Interpretation
        1. 6.2.3.1 Thing
        2. 6.2.3.2 Inheritance: the Parent 'is a' relationship
        3. 6.2.3.3 Simple Properties
        4. 6.2.3.4 Relationship Properties
        5. 6.2.3.5 Logical Unions
        6. 6.2.3.6 Mutually Exclusive sets
        7. 6.2.3.7 Relationship Properties hierarchies
        8. 6.2.3.8 Inverse relationships
        9. 6.2.3.9 Selection Lists
        10. 6.2.3.10 Selections of Things
  10. 7 Introduction
      1. 7.1.2 Reading this Standard
    1. 7.3 Usage Scenarios
      1. 7.3.1 Model Driven Development
      2. 7.3.2 Semantic Technology Development
      3. 7.3.3 Integration of systems and/or data feeds
  11. 8 Architecture
    1. 8.1 Ontology Definition Metamodel (ODM) Usage and Adaptations
      1. 8.1.1 Introduction
      2. 8.1.2 ODM Constructs Usage
        1. Table 8-1 ODM Constructs Usage
    2. 8.2 Ontology Architecture and Namespaces
      1. Figure 8.1 Foundations Ontology Architecture
      2. Table 8-2 Prefix and Namespaces for referenced/external vocabularies
      3. Table 8-3 Prefix and Namespaces for FIBO Foundations
    3. 8.4 FIBO-Based Reporting
      1. 8.4.3 Business-Facing Approach
        1. Figure 8.2 Example Business-Facing FIBO Diagram
  12. 9 Additional Metadata
    1. 9.1 Introduction
    2. 9.2 Ontology-Level Metadata
      1. Table 9-1 FIBO Foundations Specification Family Metadata
      2. Table 9-2 FIBO Foundations Specification Metadata
      3. Table 9-3 FIBO Foundations Specification Version Metadata
      4. Table 9-4 FIBO Foundations Specification Curation and Rights Metadata
    3. 9.3 Ontology Entity-Level Metadata
      1. 9.3.1 Definitions, Notes, and Labels
        1. Table 9-5 Definitions, Labeling, and Notes
      2. 9.3.2 Synonymous Terms
      3. 9.3.3 Provenance and Cross-reference Annotation
      4. 9.3.4 Change Management Annotation
  13. 10 Model Content Reports
    1. Table 10-1 Table Guide
    2. 10.1 Module: Utilities
      1. Table 10-2 Utilities Module Metadata
      2. 10.1.1 Ontology: Annotation Vocabulary
        1. Figure 10.1.1.1 Annotation Vocabulary Concepts
        2. Table 10-3 Annotation Vocabulary Metadata
        3. Table 10-4 Annotation Vocabulary Details
      3.  10.1.2 Ontology: Business Facing Types
        1. Figure 10.1.2.1 Business Types Concepts
        2. Table 10-5 Business-Facing Types Ontology Metadata
        3. Table 10-6 Business Facing Types Details
    3. 10.2 Module: Relations
      1. Table 10-7 Relations Module Metadata
      2. 10.2.1 Ontology: Relations
        1. Figure 10.1.1 Relations Concepts
        2. Table 10-8 Relations Ontology Metadata
        3. Table 10-9 Relations Details
    4. 10.3 Module: Goals and Objectives
      1. Table 10-10 Goals and Objectives Module Metadata
      2. 10.3.1 Ontology: Goals
        1. Figure 10.3.1.1 Goals Concepts
        2. Table 10-11 Goals Ontology Metadata
        3. Table 10-12 Goals Details
      3.  10.3.2 Ontology: Objectives
        1. Figure 10.3.2.1 Objectives Concepts
        2. Table 10-13 Objectives Ontology Metadata
        3. Table 10-14 Objectives Details
    5. 10.4 Module: Parties
      1. Table 10-15 Parties Module Metadata
      2. 10.4.1 Ontology: Parties
        1. Figure 10.4.1.1 Parties Concepts
        2. Table 10-16 Parties Ontology Metadata
        3. Table 10-17 Parties Details
      3. 10.4.2 Ontology: Roles
        1. Figure 10.4.2.1 Roles Concepts
        2. Table 10-18 Roles Ontology Metadata
        3. Table 10-19 Roles Details
    6. 10.5 Module: Agents and People
      1. Table 10-20 Agents and People Module Metadata
      2. 10.5.1 Ontology: Agents
        1. Figure 10.5.1.1 Agents Concepts
        2. Table 10-21 Agents Ontology Metadata
        3. Table 10-22 Agents Details
      3. 10.5.2 Ontology: People
        1. Figure 10.5.2.1 People Concepts
        2. Table 10-23 People Ontology Metadata
        3. Table 10-24 People Details
    7. 10.6 Module: Places
      1. Table 10-25 Places Module Metadata
      2. 10.6.1 Ontology: Locations
        1. Figure 10.6.1.1 Locations Concepts
        2. Table 10-26 Locations Ontology Metadata
        3. Table 10-27 Locations Details
      3. 10.6.2 Ontology: Countries
        1. Figure 10.6.2.1 Countries Concepts
        2. Table 10-28 Countries Ontology Metadata
        3. Table 10-29 Countries Details
      4. 10.6.3 Ontology: Addresses
        1. Figure 10.6.3.1 Addresses Concepts
        2. Table 10-30 Addresses Ontology Metadata
        3. Table 10-31 Addresses Details
    8. 10.7 Module: Organizations
      1. Table 10-32 Organizations Module Metadata
      2. 10.7.1 Ontology: Organizations
        1. Figure 10.7.1.1 Organizations Concepts
        2. Table 10-33 Organizations Ontology Metadata
        3. Table 10-34 Organizations Details
      3. 10.7.2 Ontology: Formal Organizations
        1. Figure 10.7.2.1 Formal Organizations Concepts
        2. Table 10-35 Formal Organizations Ontology Metadata
        3. Table 10-36 Formal Organizations Details
      4. 10.7.3 Ontology: Legitimate Organizations
        1. Figure 10.7.3.1 Legitimate and Illicit Organizations Concepts
        2. Table 10-37 Legitimate Organizations Ontology Metadata
        3. Table 10-38 Legitimate and Illicit Organizations Details
    9. 10.8 Module: Agreements
      1. Table 10-39 Agreements Module Metadata
      2. 10.8.1 Ontology: Agreements
        1. Figure 10.8.1.1 Agreements Concepts
        2. Table 10-40 Agreements Ontology Metadata
        3. Table 10-41 Agreements Details
      3. 10.8.2 Ontology: Contracts
        1. Figure 10.8.2.1 Contracts Concepts
        2. Table 10-42 Contracts Ontology Metadata
        3. Table 10-43 Contracts Details
    10. 10.9 Module: Law
      1. Table 10-44 Law Module Metadata
      2.  10.9.1 Ontology: Legal Core
        1. Figure 10.9.1.1  Legal Core Concepts
        2. Table 10-45.  Legal Core Ontology Metadata
        3. Table 10-46 Legal Core Details
      3. 10.9.2 Ontology: Jurisdiction
        1. Figure 10.9.2.1 Jurisdiction Concepts
        2. Table 10-47 Jurisdiction Ontology Metadata
        3. Table 10-48 Jurisdiction Details
      4. 10.9.3 Ontology: Legal Capacity
        1. Figure 10.9.3.1 Legal Capacity Concepts
        2. Table 10-49 Legal Capacity Ontology Metadata
        3. Table 10-50 Legal Capacity Details
    11. 10.10 Module: Ownership and Control
      1. Table 10-51 Ownership and Control Module Metadata
      2. 10.10.1 Ontology: Control
        1. Figure 10.10.1.1 Control Concepts
        2. Table 10-52 Control Ontology Metadata
        3. Table 10-53 Control Details
      3. 10.10.2 Ontology: Ownership
        1. Figure 10.10.1.1 Ownership Concepts
        2. Table 10-54 Ownership Ontology Metadata
        3. Table 10-55 Ownership Details
    12. 10.11 Module: Accounting
      1. Table 10-56 Accounting Module Metadata
      2. 10.11.1 Ontology: Accounting Equity
        1. Figure 10.11.1.1 Accounting Equity Concepts
        2. Table 10-57 Accounting Equity Ontology Metadata
        3. Table 10-58 Accounting Equity Details
      3. 10.11.2 Ontology: Currency Amount
        1. Figure 10.11.1 Currency and Amount Concepts
        2. Table 10-59 Currency Amount Ontology Metadata
        3. Table 10-60 Currency and Amount Details
  14. Annex A Machine Readable Files Part of This Specification (normative)
  15. Annex B Shared Semantics Treatments
    1. B.1 Introduction
    2. B.2 Shared Semantics Treatments
  16. Annex C Logical versus Conceptual Models comparison
    1. C.1 Comparison Table
      1. Table C1.1 Model Comparisons
    2. C.2 Detailed Models Comparison
    3. C.3 Model Partitioning
      1. C.3.1 Independent, Relative and Mediating Things
      2. C.3.2 Concrete and Abstract Things
      3. C.3.3 Continuant and Occurrent Things
  17. Annex D How to extend FIBO ontologies (informative)
    1. D.1 Terminology used in this Annex
    2. D.2 Overview
      1. D.2.1 Classes of Thing
      2. D.2.2 Model relationship to Subject Matter
      3. D.2.3 How to Model New Classes
      4. D.2.4 Declaring Class Disjointness
      5. D.2.5 How to Model New Facts about Things
      6. D.2.6 Inverse Relationships
      7. D.2.7 How and When to Use Enumerations
      8. D.2.8 Foundations Concepts Usage
      9. D.2.9 Content Creation Summary
    3. D.3 Presentation Considerations
      1. D.3.1 Labeling
      2. D.3.2 Ontologies
      3. D.3.3 UML Considerations
        1. UML Diagrams
        2. UML Notation
        3. Diagram Layout
        4. Diagram Notes
        5. UML Diagram Boundaries
        6. UML Packages
  18. Annex E Creating Applications with FIBO (Informative)
    1. E.1 Introduction
      1. E.1.1 Principles
      2. E.1.2 Operational Ontologies
      3. E.1.3 Conventional Applications
  19. References
    1. [1]
    2. [2]
    3. [3]
    4. [4]
    5. [5]
    6. [6]

Financial Industry Business Ontology Foundations

Request for Comments

____________________________________________________

OMG Document Number:  finance/2013-09-02

Standard document URL:  http://www.omg.org/spec/EDMC-FIBO/FND/PDF (Word)

Associated File(s)*:  as indicated in inventory file finance/2013-08-02

_________________________________________________

Copyright © 2013, EDM Council

Copyright © 2013, Object Management Group, Inc.

USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES

The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice.

LICENSES

The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.

Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

GENERAL USE RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

DISCLAIMER OF WARRANTY

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE.  IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification.

RESTRICTED RIGHTS LEGEND

Use, duplication or disclosure by the U.S. Government  is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 140 Kendrick Street, Needham, MA 02494, U.S.A.

TRADEMARKS

MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered trademarks of the Object Management Group, Inc., and Object Management Group™, OMG™ , Unified Modeling Language™, Model Driven Architecture Logo™, Model Driven Architecture Diagram™, CORBA logos™, XMI Logo™, CWM™, CWM Logo™, IIOP™ , MOF™ , OMG Interface Definition Language (IDL)™ , and OMG SysML™ are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners.

COMPLIANCE

The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials.

Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites.

OMG’s Issue Reporting Procedure

All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page http://www.omg.org, under Documents, Report a Bug/Issue (http://www.omg.org/technology/agreement.)

Preface

About the Object Management Group

OMG

Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry standards consortium that produces and maintains computer industry specifications for interoperable, portable, and reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information Technology vendors, end users, government agencies, and academia.

OMG member companies write, adopt, and maintain its specifications following a mature, open process. OMG’s specifications implement the Model Driven Architecture® (MDA®), maximizing ROI through a full-lifecycle approach to enterprise integration that covers multiple operating systems, programming languages, middleware and networking infrastructures, and software development environments. OMG’s specifications include: UML® (Unified Modeling Language™); CORBA® (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel); and industry-specific standards for dozens of vertical markets.

More information on the OMG is available at http://www.omg.org/.

OMG Specifications

As noted, OMG specifications address middleware, modeling and vertical domain frameworks. A Specifications Catalog is available from the OMG website at:

http://www.omg.org/technology/docume...ec_catalog.htm

Specifications within the Catalog are organized by the following categories:

OMG Modeling Specifications

·         UML

·         MOF

·         XMI

·         CWM

·         Profile specifications

OMG Middleware Specifications
·         CORBA/IIOP

·         IDL/Language Mappings

·         Specialized CORBA specifications

·         CORBA Component Model (CCM)

Platform Specific Model and Interface Specifications

·         CORBAservices

·         CORBAfacilities

·         OMG Domain specifications

·         OMG Embedded Intelligence specifications

·         OMG Security specifications

All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format, may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. at:

OMG Headquarters

140 Kendrick Street
Building A, Suite 300
Needham, MA 02494
USA
Tel: +1-781-444-0404
Fax: +1-781-444-0320
Email: pubs@omg.org

Certain OMG specifications are also available as ISO standards. Please consult http://www.iso.org

Typographical Conventions

The type styles shown below are used in this document to distinguish programming statements from ordinary English. However, these conventions are not used in tables or section headings where no distinction is necessary.

Times/Times New Roman - 10 pt.:  Standard body text

Helvetica/Arial - 10 pt. Bold: OMG Interface Definition Language (OMG IDL) and syntax elements.

Courier - 10 pt. Bold:  Programming language elements.

Helvetica/Arial - 10 pt: Exceptions

NOTE:   Terms that appear in italics are defined in the glossary. Italic text also represents the name of a document, specification, or other publication.

0 Submission-Specific Material

0.1 Submission Preface

The EDM Council, on behalf of its members and other industry participants, is pleased to present a standard set of terms and definitions for financial industry concepts (future, separate documents), and a set of foundational modelling parameters (this document).

Chapter 0 of this document contains information specific to the OMG submission process and is not part of the proposed specification. The proposed specification starts with Clause 1 “Scope”. All clauses are normative unless explicitly marked as informative. The section numbering scheme, starting with Clause 1, represents the final numbering scheme and will remain stable throughout the submission process.

0.2 Copyright Waiver

The entity listed above: (i) grants to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version, and (ii) grants to each member of the OMG a nonexclusive, royalty-free, paid up, worldwide license to make up to fifty (50) copies of this document for internal review purposes only and not for distribution, and (iii) has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used any OMG specification that may be based hereon or having conformed any computer software to such specification.

0.3 Submission Team

The FIBO RFCs are being submitted by the EDM Council, a membership organization in the financial sector, on behalf of its members. There is therefore not a consortium or FIBO-specific submission team; instead all submissions are by the EDM Council as representative of the community of its members.

Contact:

Mike Bennett, Head of Semantics and Standards

EDM Council Inc.,

10101 East Bexhill Drive, Kensington, MD, USA

mbennett@edmcouncil.org

0.4 General Requirements

The FIBO initiative started out as a collaborative project within the Enterprise Data Management Council, with the stated aims of:

(i)  Defining common terms, definitions and business relationships (i.e. common semantics) for the financial services industry, and

(ii)  Presenting this for review, validation, completion and sign-off by industry subject matter experts

The two business requirements for common semantics and for visual and textual presentation of these to industry subject matter experts led to the creation of the “Semantics Repository”, with the additional strong mandate to “keep the philosophy out of sight”, meaning that the repository was built along semantic web principles but with the more technical views of semantic web notations kept out of sight of industry subject matter experts.

This initial Semantics Repository was built using an early version of the Object Management Group’s standard Ontology Definition Metamodel (ODM) which at the time was in draft. Certain features of the then draft of ODM were not amenable to the stated EDM Council requirement to present the subject matter to business experts without the intrusion of technical modeling language constructs, and so considerable modification and customization of that ODM draft was undertaken. The resultant model, which was maintained within the Sparx Enterprise Architect modeling tool, was displayed on a custom-built website in the form of tables and diagrams at varying levels of detail and complexity, but free of semantic web notation.

This project brings the content developed within the above modeling framework and refactors it to the latest version of the ODM standard. Many of the customizations which the EDM Council undertook for the reasons described above have parallels in the most recent versions of ODM and so it was deemed possible to retain the commitments made to business consumers of the content while upgrading the model to a fully conformant rendition of ODM.

0.4.1 EDM Council Involvement with the OMG

The EDM Council is submitting the Semantics Repository as a series of specifications under the FIBO to leverage the OMG to manage these standards within a well-founded process as provided by the OMG.

0.5 Future Changes to this Specification

It is anticipated that aspects of this specification may need to be updated on an ongoing basis, while others may not:

-  Architecture: this is intended to remain relatively static. Updates to this part of the specification shall follow the same principles as normally apply to OMG specifications for modeling languages;

-  Content: the content in this specification is considered foundational to the remaining FIBO specifications and as with the content in those specifications it is expected that this will need to be extended and refined on an ongoing basis;

-  Conformance: the conformance points described in this specification shall follow the same principles as normally apply to OMG specifications for modeling languages, but it is anticipated that additional conformance points may be added to the ones in this specification on a more regular basis as new ways of applying the content of the remaining FIBO specifications are identified, for example in the creation of operational ontologies which may be determined to introduce new ways of applying this content in a way which is determined should be defined as conformant.

0.5.1 What is “Content”?

For the purposes of this and other FIBO specifications, “Content” is defined in Section 4 of this document as "Subject matter or meta-content", while “Subject matter" is defined as "Information about things in the universe of discourse; the essential facts, data, or ideas that constitute the basis of spoken, written, or artistic expression or representation; often : the substance as distinguished from the form especially of an artistic or literary production."

All content in the FIBO specifications is subject matter in the form of ontologies, that is models in which the model content has as its referent some feature of the business world or problem domain. This is described in further detail in the Conformance section of this specification, under “Model Conformance”.

0.6 Methodological Aspects

0.6.1 Current Status

The methodology and tooling for production of FIBO content, business views and OWL files has undergone considerable change. Model content is now maintained in the NoMagic “Cameo” modeling tool where OWL files are generated using the VOM plug-in from Thematix Partners. This ensures that OWL machine readable files produced are in line with the model content as reviewed and approved by the relevant business subject experts for future FIBO standards (Business Entities, Securities etc.).

0.6.2 Operational Ontologies

Operational ontologies are intended to be derived from the content of the various FIBO Business Conceptual Ontologies. These are on a per business requirement basis.

Operational ontologies, being more focused on specific usage requirements, will evolve separately, will involve a choice of rules languages e.g. RIF, RIF-RuleLog, Flora2 and so on. The goal is to be able to operationalize logic that might not be realizable or representable in the BCO.

1 Scope

1.1 Overview

This specification is part of a family of specifications called the Financial Industry Business Ontology (FIBO).

FIBO is a modularized formal model of the concepts represented by finance industry terms as used in official financial organization documents such as contracts, product/service specifications and governance and regulatory compliance documents. This is referred to as a Business Conceptual Model as distinct from models or descriptions of data or IT implementations.

The scope of finance industry encompasses a broad range of organizations that manage money, including credit unionsbankscredit card companies, insurance companies, consumer finance companies, stock brokerages, investment funds and some government sponsored enterprises.

This particular specification defines the Foundations module of FIBO: a set of business concepts which are intended to support the financial industry terms semantics presented in other FIBO specifications.

Foundations is itself segmented into a number of models or ontologies.

The FIBO Foundations models define general concepts that are not unique to the financial industry, but needed to help define the financial concepts. FIBO Foundations therefore includes a number of basic legal, contractual and organizational concepts, among others. Concepts which are available in other industry standards are not included, but in some cases a “Proxy” concept is included for reference, for example for address and country concepts. The rationale for including these is two-fold:

- Concepts in the financial industry are generally specializations of more general, non-financial concepts such as contracts, commitments, transactions, organizations and so on, These are included in FIBO Foundations so that specializations of them may be defined in other FIBO specifications;

- Properties of financial industry concepts frequently need to be framed in terms of relationships to non-financial concepts such as countries, jurisdictions, addresses and the like. These are included in FIBO Foundations so that properties in other FIBO specifications may make reference to them.

FIBO concepts are documented using two forms of definition:

1. a structured ontology specification of the concept, and its relationships to others, represented using the Web Ontology Language (OWL).

2. natural language definitions which represent the concepts in natural language using the vocabulary of the finance industry.

This specification covers both the content of the models, and the underlying architecture employed for producing and presenting the model.

A number of informative annexes are provided to assist potential users with adoption and implementation of this and other FIBO specifications.

1.2 Applications and Uses of FIBO

One of the key benefits of FIBO with respect to data, message or reasoning metamodels is that it can provide a semantic anchor firmly rooted in the concepts as understood and used by people in the finance industry. FIBO enables the creation of logical data models such that those logical models derive their formal semantics from FIBO.

FIBO supports the derivation of ontologies to support semantic reasoning and querying applications. Since FIBO itself is framed using the formal constructs of the OWL language, such operational ontologies may be derived directly from the FIBO conceptual ontologies, with adaptation as necessary to support any application specific constraints.

FIBO allows disambiguation of new and existing regulation. To the extent that regulatory requirements reference the formal concepts in FIBO, terms referred to in these regulatory requirements, or in reports that are mandated, would be semantically unambiguous.

One important goal of FIBO is for the formal business definitions to be used in legal documents such as contracts, terms and conditions of sales and payment, IP protection, compliance reports; and to underpin less formal language used in advertising and customer-facing websites. 

The business terms and definitions in this specification may be used as a reference model to which firms would tie their own proprietary models (semantic models or ontologies); and also as a catalog for all of the relevant data models.

1.3 How FIBO is Different from Operational Ontologies

Intended Audiences: Technical modellers, data architects

An ontology, regardless of how it is to be used, sets out formally a representation of items in a real-world domain of discourse. There are two distinct uses to which this applies:

- A business ontology (business conceptual model) as described in this specification – this uses the full expressive power of the chosen notation to formally define items in the domain of discourse, without taking application technical constraints into account

- An operational ontology is constrained to operate within the parameters of a specific semantic application. Typically, this will contain a sub-set of the constructs in the business conceptual ontology, and that sub-set will typically comprise a decidable ontology.

It is necessarily the case that when something is to be used in an application, there will be technical constraints imposed upon that application. This is just as true when the application includes an ontology, as for other technologies.

The technical constraints that may apply to an operational ontology, necessarily do not apply to a business conceptual ontology. That is, the existence of some technical constraint in the application domain should not in any way influence the way in which business facts are formally captured and modeled in a business conceptual ontology.

1.4 How FIBO is Different from Data Models

FIBO can be distinguished from document/message/data/reasoning schemas of all kinds.

  • FIBO models things in the real or planned world of the finance industry. 
  • FIBO will only contain instances of its own concepts under the specific conditions listed below.  With these exceptions, FIBO contains only concepts - even if those concepts have just single instances in the real or planned world of finance.
    • Instances which are needed in order to define properties which refer to them;
    • Classes of thing which are defined extensionally; and
    • Examples
  • FIBO is not any kind of a data, message or reasoning model, although it adds great value to these.  It does not model document/message/data content or schemas optimized for reasoning. 

FIBO will not include concepts about the structure of content, messages, information or data, even if that data is in turn about the finance industry.

The FIBO model, is referred to here as a "Business Conceptual Model”, corresponding to Level 2 of the Zachman Framework for Information Architecture.

The distinctions between the scope of the FIBO model, and that of both logical and physical models, are further described in Annex C.

1.5 Definitions

The human readable definitions have been constructed by and with the input of business subject matter experts.

Many definitions have been derived from definitions of data elements corresponding to those terms in industry data or messaging standards. These have been adapted where necessary to ensure that they are descriptive of the thing or fact itself and not of data elements for data about those things or facts, and have then been reviewed by industry subject matter experts to ensure that such adaptation accurately captures the sense of the business concept. In cases where the definition in a data or message standard was incomplete, context-specific or tautologous, a fresh definition was framed by the industry subject matter experts who participated in these reviews, or a third party definition was proposed and adopted.

1.5.1 Definitions Policy

In some cases, definitions have been obtained from third party sources. The policy for arriving at definitions for the FIBO industry terms was as follows (and remains so for future iterations and extensions):

1. In the absence of a definition endorsed by the subject matter experts for a term, "Barrons DICTIONARY OF FINANCE AND INVESTMENT TERMS, 8th Edition John Downes and Jordan Elliot Goodman" shall be used.

2. If a term and its acceptable definition is not in the Barrons Dictionary, then http://www.investopedia.com/dictionary/ shall be the authoritative source, subject to licensing requirements being met. 

3. If a term and its acceptable definition is not in either the Barrons Dictionary or the investopedia dictionary, then http://www.bankersalmanac.com/addcon/dictionary/ shall be the authoritative source. 

4. If a term has no acceptable definition in these Financial Industry sources or does not exist in these Financial Industry sources then http://www.merriam-webster.com shall be the authoritative source.

5. When there is a conflict with the definition of a Financial Industry term with the same term in another Industry, the Financial Industry definition will be used within FIBO.

In all cases the source from which the definition was obtained, or from which it was adapted, is recorded in annotation metadata for that concept.

2 Conformance

2.1 Overview

This chapter defines conformance points for the following types of artifacts:

-  Technical applications of FIBO such as logical data models, XML schemas, operational ontologies, code, and other technical artifacts

-  Extensions of FIBO

-   Representations of FIBO for business consumption

o    In diagrams

o    In spreadsheets or tables

Conformance of technical applications of FIBO is the most important conformance point, because it addresses the core issue of what it means to conform to the ontologies that FIBO defines.  In comparison, conformance of extensions and representations, while still important, are somewhat secondary concerns.

Note that in addition to conformant applications, there are a number of scenarios in which someone may make use of the FIBO ontologies as a business conceptual model while applying their own design to meet their requirements. It is not possible to define specific conformance points for each of the possible ways in which one may legitimately develop a conventional database application or an operational OWL ontology that would be a good application. The non-normative annex [Annex E] describes a number of acceptable model architectures which may adequately reflect the material in FIBO Foundations and any of the other FIBO specifications.

2.3 Conformant Technical Applications of Model Content

Technical applications of FIBO content are logical data models, XML schemas, operational ontologies, code artifacts, and other technical artifacts that purport to conform to FIBO.

2.3.1 Assessing Model Conformance

Given that a technical application includes a set of information elements some of which correspond to the concepts in FIBO, then the application is FIBO Model Conformant if and only if:

·  At least one of those information elements corresponds to a concept in the FIBO ontology for which conformance is claimed

·  The application does not permit actual data to exist which would not be valid set of  instances of those corresponding FIBO concepts: in other words if the data is represented as a set of individuals of the corresponding FIBO concepts then they will constitute a valid FIBO model  with no contradictions

It is permissible for the information elements to have additional information or to be more constrained than those in FIBO.

2.3.1.1 Full FIBO Foundations Model Conformance

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

2.3.1.2 FIBO Ontology Model Conformance

If a technical application is FIBO Model Conformant with a particular FIBO Foundations ontology, then the application satisfies FIBO Ontology Conformance for that particular ontology. There is thus a separate compliance point for each ontology in section 10.

2.3.2 Assessing FIBO ODM Conformance

An extension of FIBO is FIBO ODM conformant if it is expressed in ODM (the OMG Ontology Definition Metamodel) and also restricts itself to using only the sub-set of ODM modeling constructs defined in the Architecture section of this specification (Section 8)

If the technical application is not an OWL ontology, then by definition the application is not FIBO ODM Conformant. 

2.4 Conformant Extensions of FIBO Content

This definition of conformance points applies both to extension of the model content for use locally and to the preparation for submission of new model content for FIBO itself.   The following conformance points may be asserted for each ontology that extends FIBO itself:

· FIBO-Full Extension in ODM:  Satisfies FIBO Extension Conformance (see below) and FIBO ODM Conformance

· FIBO-Full Extension in OWL: Satisfies FIBO Extension Conformance (see below) and OWL2 Conformance

In turn, for FIBO Extension Conformance an ontology must satisfy FIBO Model Conformance (see 2.3.1) and the rules in the following three sub-sections related to labeling, model consistency and relationship to subject matter.

2.4.1 Labeling

Business-facing labels shall be provided for all named model constructs. These labels must conform to the following formal requirements:

· Labels shall use normal English expression including spaces and punctuation, using lowercase except for proper nouns.

· Labels shall represent a plain English name (in US English spelling) which is that most commonly used by the finance industry.

· Labels do not need to be unique across the model.

· At least one business-facing label shall be present which is not in the form of, or contain, acronyms (including business acronyms) except where these are the only means by which the concept may be referred in the business domain (for example "CDO Squared").

2.4.2 Model Consistency

Reasoning is the mechanism by which the logical assertions made in an ontology and related knowledge base are evaluated by an inference engine. A logical assertion is simply an explicit statement that declares that a certain premise is true. Such assertions, taken together, form a logical theory, and a consistent theory is one that does not contain any logical contradictions.  This means that there is at least one interpretation of the theory in which all of the axioms contained therein are provably true. The logical assertions expressed in the FIBO Foundations ontologies have been checked using multiple inference engines, designed specifically to support OWL 2, for internal logical consistency (i.e., for consistency within that single ontology), and for logical consistency with imports closure (meaning, consistency including all axioms in any imported ontology in addition to those in the single ontology in question).

In order for any extension to FIBO to be conformant, it must be verified as being logically consistent (internally and with respect to imports) in addition to syntactically correct according to the OWL specifications. Examples of reasoning engines that can be used to verify logical consistency of an OWL 2 ontology are discussed in an article on Wikipedia [1]. Members of the OMG Ontology Special Interest Group (ontology@omg.org) can also make recommendations for tooling that might assist FIBO users in verifying their extensions.

2.4.3 Relationship to Subject Matter

In any extension to FIBO model content each model element which is a class, an object property or a datatype property shall correspond to some item in the real world. No model element shall refer to some technical construct such as a database field, internal identifier, database key and the like.

An exception is made for information constructs which are themselves important and publicly shared parts of the business domain, such as publicly issued identifiers, security identifiers, ratings codes and the like. In each such case, there shall be some formally identified scheme in which the code in question is defined.

A suitable test for types of "Information" to be considered real is whether that information is publicly shared or, if private, made available across the business supply chain. Examples include Legal Entity Identifier, securities prospectuses, published indices, interest rates.

2.5 Conformant Business Presentation of Model Content

There are two conformance points for presentation of FIBO content:

-  FIBO Business Diagram

-  FIBO Business Table

Any tool which asserts support for one or other or both of business presentation conformance points must be able to import the available FIBO content in at least one of the available serialization formats (UML XMI, ODM XMI or OWL), and produce diagrams and/or tables which conform with the requirements defined for the conformance point.

2.5.1 General Requirements

It is a requirement of this specification that content of the models is made available to people in the business domain in one or more of a set of diagrams and tables which are described in this specification.

A presentation of FIBO model content is not a conformant FIBO Business Presentation (i.e. a conformant FIBO Business Diagram or a conformant FIBO Business Table) if the only means for the reader to view the model’s terms, definitions and relationships is one which requires some formal understanding of some model language such as UML or OWL, beyond the knowledge conveyed by the annexes to this specification. For the avoidance of doubt, a non-conformant business presentation is any format which contains symbols, whether diagrammatic or textual, which have a meaning other than the meaning which a reasonably educated but non-technical person would ascribe to those items

2.5.2 Business Diagram Conformance

OWL features such as restrictions on properties or classes, where these are present in the model content, shall be rendered in some way that communicates their business intent without reference to the way in which the OWL syntax represents these constructions.

OWL constructs shall be represented by simple constructs which do not require specialist technical training, such as boxes, arrows and lines.

All notation on all diagrams shall only represent features of OWL, except where this is clearly identified as additional annotation (intended to enhance an understanding of the business content of the model and not part of the model itself).

In diagrams generated from OWL tools or other non UML based tooling, no features shall be present which do not represent some feature of OWL except where these are clearly identified as visual decorations intended to enhance an understanding of the business content of the model.

If UML Generalization notation is used, this shall be laid out with the "arrowhead" pointing vertically upwards, in either the vertical tree style or direct style of routing. Generalization relationships may also be represented using more intuitive, non UML notations, in which case this requirement shall not apply.

2.5.3 Business Table Conformance

This section concerns two kinds of tabular presentations: Basic Table and Extended Table.  Conformant FIBO Business Tables may be rendered as spreadsheets or as textual documents in a tabular layout.

2.5.3.1 Basic Table

A conformant FIBO Business Table using the "Basic" tabular format shall show only the following entries:

· Term (preferred label for concept)

o Classes and properties may be in the same column or different columns

· Definition

· Synonym

These shall be labeled as such.

This table shall only show those constructs from the FIBO model content which represent meaningful business concepts, and not the additional constructs which deal with the set theoretic logic of the model. That is, the basic table shall show only (differentiating between them):

· Class

· Relationship Property

· Simple Property

2.5.3.2 Extended Table

A conformant FIBO Business Table using the Extended Tabular format shall conform with the following requirements:

The extended table shall have column entries for each of the basic model features, as follows:

· Term

· Definition

· Synonym

· Range of Simple Properties (titled as "Simple Type")

· Range of Relationship Properties (titled as "Related Thing")

· Property type

· Super (class or property) (can  be labeled as “Parent”)

· Disjoints (labeled "mutually exclusive")

· Additional metadata may or may not be shown, at the discretion of the modeler and as appropriate to the intended usage (for example, review notes annotations).

The following model constructs shall be included in the Extended Table reports, in or near the following order:

· Class

· Union Relationships

o labeled "In Union" when reported for members of the union

o labeled "Union Of" when reported as the relationships from the Union Class

· Relationship Property

· Simple Property

· Union Class

· Individuals

o 'typeOf ' relationships from Individual to Class (labeled "type of")

· Annotations – there are no specific requirements for how these are presented.

Object Properties and Datatype Properties shall only be included once in all reports across the model, and this shall be for the class which is the domain of that property.

The intention of these requirements is that the report shows each type of fact, once only and in a logical order.

3 References

3.1 Normative References

The following normative documents contain provisions which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply.

 

Reference

Description

[Dublin Core]

DCMI Metadata Terms, Issued 2013-06-14 by the Dublin Core Metadata Initiative.  Available at http://www.dublincore.org/documents/dcmi-terms/.

[ISO 1087]

ISO 1087-1:2000 Terminology — Vocabulary — Part 1: Theory and application

[MOF Core]

Meta Object Facility (MOF™) Core, v2.4.1. OMG Available Specification, formal/2011-08-07. Available at http://www.omg.org/spec/MOF/2.4.1/.

[MOF XMI]

MOF 2/XMI (XML Metadata Interchange) Mapping Specification, v2.4.1. OMG Available Specification, formal/2011-08-09. Available at http://www.omg.org/spec/XMI/2.4.1/.

[ODM 1.0]

Ontology Definition Metamodel (ODM), v1.0.  Available Specification, formal/2009-05-01.  Available at http://www.omg.org/spec/ODM/1.0/.

[ODM 1.1]

Convenience Specification for the Ontology Definition Metamodel (ODM), v1.1, available from the ODM 1.1 RTF.

[OMG AB Specification Metadata]

OMG Architecture Board recommendations for specification of ontology metadata, Available at http://www.omg.org/techprocess/ab/Sp...ationMetadata/

[OWL 2]

OWL 2 Web Ontology Language Quick Reference Guide (Second Edition), W3C Recommendation 11 December 2012. Available at http://www.w3.org/TR/2012/REC-owl2-q...ence-20121211/.

[RDF 1.1]

RDF 1.1 Concepts and Abstract Syntax, W3C Last Call Working Draft. Latest version Available at http://www.w3.org/TR/2013/WD-rdf11-concepts-20130723/

[RDF Concepts]

Resource Description Framework (RDF): Concepts and Abstract Syntax. Graham Klyne and Jeremy J. Carroll, Editors. W3C Recommendation, 10 February 2004. Latest version is available at http://www.w3.org/TR/rdf-concepts/.

[RDF Schema]

RDF Vocabulary Description Language 1.0: RDF Schema. Dan Brickley and R.V. Guha, Editors. W3C Recommendation, 10 February 2004. Latest version is available at http:// www.w3.org/TR/rdf-schema/.

[SKOS]

SKOS Simple Knowledge Organization System Reference, W3C Recommendation 18 August 2009.  Available at http://www.w3.org/TR/2009/REC-skos-r...ence-20090818/.

[UML2]

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

[Unicode]

The Unicode Standard, Version 3, The Unicode Consortium, Addison-Wesley, 2000. ISBN 0-201-61633-5, as updated from time to time by the publication of new versions. (See http:// www.unicode.org/unicode/standard/versions/ for the latest version and additional information on versions of the standard and of the Unicode Character Database).

[UTF-8]

RFC 3629: UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF, November 2003, http://www.ietf.org/rfc/rfc3629.txt

[W3C Datatypes in RDF and OWL]

XML Schema Datatypes in RDF and OWL, W3C Working Group Note 14 March 2006, Available at http://www.w3.org/TR/2006/NOTE-swbp-...ypes-20060314/.

[XML Schema Datatypes]

XML Schema Part 2: Datatypes. W3C Recommendation 02 May 2000. Latest version is available  at http://www.w3.org/TR/xmlschema-2/.

 

3.2 Non Normative References

The following informative documents are referenced throughout this text or in parts of the Annexes:

 

Reference

Description

[DOLCE]

A. Gangemi, N. Guarino, C. Masolo, A. Oltramari, and L. Schneider. Sweetening ontologies with DOLCE. In Proceedings of EKAW, Siguenza, Spain, 2002.

[ISO Common Logic]

Information Technology - Common Logic ISO/IEC 24707:2007 http://www.iso.org/iso/iso_catalogue...csnumber=39175

[Knowledge Representation]

Knowledge Representation: Logical, Philosophical and Computational Foundations, Sowa, John F., Brooks/Cole. 2000

[Model Theory]

Mathematical Logic: An Introduction to Model Theory, Lightstone, A. H., New York: Plenum Press, 1978, H. B. Enderton (ed).

[OMV]

Ontology Metadata Vocabulary (OMV) - http://omv2.sourceforge.net/ (a standard giving metadata for ontology-level information)

[C S Peirce]

A Comprehensive Bibliography and Index of the Published Works of Charles Sanders Peirce, with a Bibliography of Secondary Studies, Ketner, K. L. et al., Johnson Associates (Greenwich, Connecticut): 1977

[W3C Organization Ontology]

W3C Organization Ontology. Available at: http://www.w3.org/TR/vocab-org/

[Zachman]

Zachman Framework http://www.zachman.com/

 

3.3 Changes to Adopted OMG Specifications

This specification does not change or replace any OMG specifications. It does, however, depend on pending changes to the Ontology Definition Metamodel (ODM), in support of OWL 2 and RDF 1.1.

4 Terms and Definitions

For the purposes of this specification, the following terms and definitions apply.

Content

Definition: Subject matter or meta-content.

Business conceptual model

Definition: A model which represents and only represents business subject matter without reference to the design of any solution or data model representation.

Business publication

Definition: Representation of a subject matter view in a form that is understandable and usable by business users.

Example: Text document, web page, audio recording, interactive search dialog

Business subject matter

Definition: Subject matter that defines and describes the kinds of people (and the roles they play), organizations and other things that an enterprise has to deal with in the course of its operational business, regardless of how this content is presented to the people in the organization (e.g. in text documents, web pages, audio broadcasts).

Example: Business concepts, such as: OTC derivative, business day

Example: Relationships between business concepts, such as: swap transaction has ISDA confirmation

Example: Constraints, such as: Each ISDA confirmation is of exactly one swap transaction

Example: Descriptions, such as: ISDA is the largest trade organization of participants in the OTC derivatives market.

Example: Business processes (defined in terms of the business concepts), such as:

If a Disputing Party reasonably disputes the Value of any transfer of Eligible Credit Support, then the Disputing Party will notify the other party not later than the close of business on the Local Business Day following.

Note: Business subject matter is mainly about kinds of thing, but may include individuals, in three roles: (1) as one-of-a-kind things referenced in the subject matter, such as ISDA, Dodd-Frank Act, EC Treaty; (2) As types defined by enumeration, such as the currencies in which a trading business maintains accounts; (3) in examples.

Note: Business subject matter is usually scoped by area of business jurisdiction (or something similar), such as, say, derivatives trading. The business subject matter is about the business of derivatives trading.

Other areas of responsibility in the enterprise have different subject matter. For example, the IS department’s subject matter includes information models of things in the operational business (including derivatives trading). The finance department’s subject matter includes financial models of things in the operational business.

From the derivatives trading perspective (the relevant parts of) these information and financial models would be considered meta-content.

Business subject matter view

Definition: Subset of business subject matter that is intended to be presented in some business publication.

Example: Concept definitions; relationship definitions with constraints.

Extension

Definition: The membership of some class of thing. This is distinct from its intension, that is the properties intrinsic to that class of thing. In applying the intension of some class to some collection of individuals, one arrives at the extension of that class for that collection.

Extensional

Definition:  Logic explicable solely in terms of extensions; ignoring differences of meaning that do not affect the extension.

Extensional Definition of Class Membership

Definition: The definition of membership of a class by direct articulation of those members (that is, by articulation of the Extension of that class.

Intension

Definition: The properties intrinsic to some class of thing.

Intensional

Definition: Logic (of a predicate) incapable of explanation solely in terms of the set of objects to which it is applicable; requiring explanation in terms of meaning or understanding.

Intensional Definition of Class Membership

Definition: The definition of membership of a class according to properties intrinsic to members of that class.

Meta-content

Definition: Information about subject matter

Example: Control information, such as: date and author of last update, external source, owner

Example: Connection of subject matter items to content outside the subject matter scope, such as data model elements that correspond to them (and point to the storage of instance data).

Model-Theoretic Conformance

Definition: The manner in which some model conforms with some theory about what it is intended to model and how it is intended to model it.

Ontology

Definition: A formalization of a conceptualization. For the purposes of this specification the formalization is in OWL, using ODM as a means to render this, and the conceptualization is that of business subject matter.

Operational Ontology

Definition: An ontology which is intended for use within some application.

Subject matter

Definition: Information about things in the universe of discourse; the essential facts, data, or ideas that constitute the basis of spoken, written, or artistic expression or representation; often : the substance as distinguished from the form especially of an artistic or literary production.

Taxonomy

Definition: A set of terms which stand in some classification relation to one another.

Terminology

Definition: The overall disposition of ontologies of concepts and vocabularies of terms, in relation to one another.

Vocabulary

Definition:  A set of words, each giving one or more formal definitions which apply to a meaningful concept that is referred to by that word.

5 Symbols and Abbreviations

5.1 Symbols

There are no symbols introduced by this specification.

5.2 Abbreviations

The following abbreviations are used throughout this specification:

· OWL – Web Ontology Language

· ODM – Ontology Definition Metamodel

· RDF – Resource Definition Framework

· SME – Subject Matter Expert

· UML – Unified Modeling Language

· URI – Uniform Resource Identifier

· URL – Uniform Resource Locator

· XMI – XML Metadata Interchange

· XML – eXtensible Markup Language

Additional symbols and abbreviations that are used only in annexes to this specification are given in those annexes.

6 Additional Information

6.1 How to Read this Specification

6.1.1 Audiences

This specification has the following audiences:

· The standards community

· The finance industry business community

· The regulatory community

· Technical architects

· Semantic Modelers

Each section opens with a statement identifying the intended audience for that section. The language in that section is then framed appropriately for readers from that audience. Where “Intended Audience” is not stated the material in that section is intended to be comprehensible to all general readers.

6.1.1.1 Standards Community

This audience is intended to be able to follow and validate the way in which this specification sets out the arrangements for the production and maintenance of model content, and the production of business facing reports and diagrams representing parts of that content.

6.1.1.2 The Finance Industry Business Community

As noted in the section on conformance (section 2) this specification includes detailed requirements for the production of diagrams and reports that are intended for consumption by business subject matter experts. This specification also contains material addressed at this audience, this being an informative annex on “Interpreting Model Content”. This audience is not intended to read and understand the remaining parts of this specification.

6.1.1.3 The Regulatory Community

As for Finance Industry Business Community.

6.1.1.4 Technical Architects

These include but are not limited to:

o Tooling vendors and developers

o Other content providers / enriched content providers

o Business Analysts – anyone who use the model on site, whether they are a modeler, a metadata analyst, etc.

o Technology Management

The bulk of the “Architecture” section is intended to be read and understood by these audiences and by the ‘Semantic Modelers’ audience.

6.1.1.5 Semantic Modelers

Much of the material in this specification is intended to be read and understood by semantic modelers. This includes the 'Conformance' section (Section 2), the ‘Architecture’ section (Section 8) and the non normative Annex D on implementing and extending this model and proposing new model content.

The Semantic modeler audience is not the same as the technical audience, although some individuals may possess skills in both. Sections of this specification which are written for a semantic modeling audience do not require any training in any formal technology in order to understand and act upon their contents. These sections do require a clear understanding of semantics and formal logic. It is not necessarily the case that technical readers are expected to be able to read and understand all aspects of the semantic modeling material. It should also be noted that some terms which have specific meanings in one or more technology environments, may have different (or often only subtly different) meanings to the semantic modeling audience. Where both semantics and technical audiences are intended to read a section, care has been taken to try to use all of the applicable terms and qualify words which have multiple different usages to these audiences. 

6.2 Acknowledgements

The following organization submitted this specification:

· Enterprise Data Management Council

The following companies have provided significant expertise and resources in the development of its content and architecture:

- Adaptive Inc.

- Australia and New Zealand Banking Group

- AVOX/DTCC

- Bank of America

- Barclays Capital

- BBH

- Bloomberg

- Business Semantics

- CIBC

-  Citigroup Inc.

-  Credit Suisse Group AG

-  CUSIP

-  The Federal National Mortgage Association (Fannie Mae)

-  David Frankel Consulting

- FacetApp

-  Fidelity

- GoldenSource Corporation

- HSBC Holdings plc

-  JPMorgan Chase & Co.

-  The Manufacturers Life Insurance Company

-  Michigan State University

- Model Driven Solutions

-  Model Systems

-  Morgan Stanley

-  MphasiS

- National Australia Bank

-  No Magic

- Nomos Software

-  Nordea Bank

-  Oakland University

-  OntoAge

-  OpenFinance

- PricewaterhouseCoopers LLP

- Revelytix

- Sallie Mae

- SAP

- Semantic Arts

- State Street

- Sungard

- SWIFT

- Tahoe Blue

- Thematix Partners LLC

- Thomson Reuters

- UBS AG

- University of British Columbia

- University College Cork

- Wells Fargo

-  Wizdom Systems, Inc.

6.3 Interpreting the Business Model Content

Intended Audiences: Business Subject Matter experts

6.3.1 Introduction

The model content is intended by read and understood by business domain experts with knowledge of business entities and legal concepts. It requires no knowledge of modeling theory, technical modeling languages, technology development  or data modeling.

The following knowledge is required to interpret the model content:

· Set theory

· Logic

·  Business (commerce, law, finance)

6.3.2 The Model

6.3.2.1 What the Model Contains

The model described in this specification contains elements called 'Things', Simple Properties about those things in the form of unstructured information, and Relationship Properties in the form of relationships between one 'Thing' and another. Things, Simple Properties and Relationship Properties all have as a minimum the definition for the term that they represent, plus additional information on usage, review history, sources of terms and definitions and so forth.

6.3.2.2 Model Views

Whereas the information given in this specification conveys all of the model content, the diagrams and tables that are created for a business audience will not show all of this information, but only a sub-set. This sub-section describes those formats and views, and is to be read by a business audience to understand what those views show. This sub-section contains no technical language about OWL or other modeling constructs but uses the plain English alternative terms for those concepts.

The content of the model is rendered in two basic forms: visual information in the form of diagrams, and textual information in the form of tables. The diagrams are available in varying levels of detail and are created to show different sets of terms and relationships across or within sections of the model. The textual information is created as web based tabular reports and as spreadsheets. These contain basic information of term, definition and synonym and in some cases will contain additional information about the types of thing or the types of information to which facts in the model refer. Business tables and spreadsheets do not show relationships between relationships as such information would be difficult to visualize in the tabular format.

Diagrams and tables reflect the information retained in the underlying model repository directly. For example, if two 'Thing' elements have a relationship between them and they appear on the same diagram, the relationship between them will always appear.

6.3.2.3 Business Diagrams

Business diagrams reflect any set of terms in the model, within or across sections of the content. These may be rendered with varying levels of detail. Diagrams created during reviews of the subject matter will typically contain a greater range of terms than diagrams created for presentation to the wider community of potential users.

6.3.3 Interpretation

The model conveys 'Things' and 'Facts'. Facts are in two forms:

· 'Simple Properties': these are a statement about something which is framed in terms of some simple type of information, such as textual entries, yes/no answers, dates, numbers and selections of textual information

·  'Relationship Properties': these are a statement about something which is framed in terms of something else, that other thing also being framed as a kind of 'Thing'.

In addition, there are relationships which represent additional set theory concepts, notably logical unions, mutual exclusivity.

Each 'Thing' also has a 'Parent' relationship, with the sense of 'is a', shown as an upward point arrow on the diagrams. This relationship indicates that the thing from the non-arrowed end is “a kind of” the thing at the end with the arrow.

These concepts are described in the sections which follow.

6.2.3.1 Thing

A Thing is a set theory construct. This is shown on the diagrams as a box with a name. On some diagrams, additional textual entries in the box show the Simple Properties about that thing.

A Thing is defined as the set of individuals which are defined according the facts (properties) given for that kind of thing. Membership of the set is defined in the sense that any individual in the world of which the stated facts are true or applicable, is a member of that set. In terms of logical theory, these sets are defined intensionally. It is also possible to define a set explicitly as a list of its members (in logical theoretic terms, an extensional definition) but this is not used in practice in the model.

6.2.3.2 Inheritance: the Parent 'is a' relationship

Each Thing in the model has one or more parent Things. The relationship between the Thing and its parent may be interpreted as an 'is a' form of relationship, meaning that the thing of which the parent relationship is shown is a kind of the thing to which the arrow in the Parent relationship is pointing.

This relationship formally indicates that the thing that has the Parent, inherits all of the facts about that parent. In addition, this relationship is transitive, meaning that the parent relationships of the parent are passed on to the child term. For example, if a share is a security and a security is a transferable contract then a share is a transferable contract.

The relationships of this type create a formal inheritance structure called a Taxonomy. Taxonomies in this sense may be single inheritance (as is often seen in technical model designs) or multiple inheritance. In the FIBO models these are multiple inheritance, meaning that types of thing (such as types of contract) may be classified in more than one way. So for example an interest rate swap is both a swap and an interest rate derivative.

As an example of multiple inheritance, one might say that in terms of the Linnaeus Taxonomy of Species, a whale is a mammal, while one may also create a set of taxonomic classifications based on habitat, in terms of which a whale may also be a marine animal.

On a technical note, the Parent relationship is functionally identical to the relationship known as 'Generalization' in the UML modeling language.

6.2.3.3 Simple Properties

Simple Properties are assertions about things in a class, which may be framed in terms of some simple type of information.

Types of information about which Simple Properties are asserted are:

· Text

· Date

· Number

· Whole number

· Yes/no answer

· Selection of textual descriptors

To a technical person these may easily be identified with what are called 'datatypes'. However these represent the types of information not data as such. A special case is the selection of possible answers - this refers to a list of entries (see Selection Lists).

6.2.3.4 Relationship Properties

A Relationship Property is defined as a fact about something which is framed in terms of a relationship to some other thing.

These are indicated on the diagrams as a blue arrowed line. Some diagrams additionally show a box attached to this blue line; this is used to indicate relationships between those Relationship Properties, which are shown as lines between those boxes.

Relationship Properties are of the form subject-relationship-object where the subject is the Thing from which the line is drawn and the object is the thing to which the blue arrow points.

The label on the line is the verb itself, while the attached box indicates the full name of the Relationship Property. Relationship Properties are unique across the model and each belongs to one Thing only.

There are additional pieces of information about these Relationship Properties, such as whether they are symmetric, transitive and so on. The use and interpretation of these refinements to Relationship Properties are beyond the scope of this explanatory sub-section.

6.2.3.5 Logical Unions

Logical unions indicate that any individual which is a member of any of the classes of 'Thing' of which the union is a union, are members of that union.

The Union is shown as a box on the diagrams, similar to the boxes used for classes of 'Thing' but without the coloring given for archetypes (no Union has an archetype), that is these have the default gold box appearance of an OWL Class.

Membership of the union is indicated by a purple relationship similar in appearance to the Parent / 'is a' relationship. The Union (set) shown at the top of the arrow is thereby indicated as being a logical union of all the sets indicated as classes of Thing at the bottom of the purple arrows.

Relationship Properties may refer to unions in the same way that they refer to other classes of Thing.

6.2.3.6 Mutually Exclusive sets

Given that each thing is a set of potential members defined by their properties (facts), it is possible for any one thing in the world to be defined as being a member of more than one set, if the properties asserted for one set are not related to the properties asserted for another set.

Where membership of one set necessarily precludes membership of another set (that is, where a set is defined such as to specifically exclude members of another set), this is shown by a red line on the diagrams, labeled 'mutually exclusive'.

Where classes of 'Thing' are not indicated as being mutually exclusive (or have parents which belong to classes of Thing which are mutually exclusive), then any individual in the domain of discourse (the world) may belong to both sets.

This is formally known as a 'disjoint' relationship.

6.2.3.7 Relationship Properties hierarchies

Relationship Properties are themselves disposed in a hierarchy similar to that given for the classes of 'Thing'. These are indicated on more advanced diagrams by a green upward pointing line in the same style as the Parent relationship line. The Relationship Property to which the arrow points represents a more general meaning, of which the Relationship Property at the bottom of the relationship represents a narrower definition of the same meaning.

The narrowing of these meanings frequently occurs in conjunction with the narrowing of the meanings of classes of 'Thing' in the taxonomy. For example, types of bond are classified (a narrowing or specialization of the meaning of 'bond') according to, among other things, a narrowing of the relationship 'issued by' with the latter relationships being distinguished form one another by the nature of the kind of party which is the issuer.

This is formally known as a “sub property of' relationship.

6.2.3.8 Inverse relationships

These are only shown on diagrams that show the Relationship Properties with their boxes, i.e. diagrams that show relationships between relationships.

Relationship Properties in the model are all one-directional, by virtue of their being framed as 'subject-verb-object' triples. In the business domain, meaningful terms and definitions may exist in either direction between one class of thing and another (for example, a bank has a customer versus a person has an account at the bank.

These are indicated as a red dotted arrowed line between one relationship and the relationship to which it is the inverse.

In theoretical terms, this relationship only applies between relationships which are known as 'functional' relationships. An explanation of this is beyond the scope of this sub-section.

6.2.3.9 Selection Lists

A list of possible entries for a simple type is displayed as a box on the diagrams, with a list of the possible entries. These are displayed as text, and generally refer to lists of possible textual values for the Simple Property.

It should be noted that these do not or should not represent lists of kinds of 'Thing' - those would be represented as a taxonomy of actual things. This is an important difference between this and a data model, since many data models have similar selection lists, called 'enumerations' in the data modeling world, which may represent kinds of thing or classifications of the thing which has these as a property.

6.2.3.10 Selections of Things

This is a class or set of things of which the members are explicitly listed (in theoretical terms, an extensional definition of the class).

These are not used at present in the model but are provided for in the modeling notation.

7 Introduction

7.1.2 Reading this Standard

Technical audiences (in both conventional and semantic technology) are directed at the “Architecture” section (Section 8).

Business audiences (financial industry participants, regulators and others) are directed at the section on interpreting model content (Section 6.3) and the model content itself in Section 10.

The business content defined in this standard is intended to be presented both in a business-facing format and in a complete, technical format. The latter is intended for consumption by technical and standards audiences only. This specification defines the content of the standard and the ways in which it is to be presented to business readers.

7.3 Usage Scenarios

Intended Audiences: Technical implementers (conventional and semantic technology); technology management

The model defined in this specification is intended for use as a business conceptual model.

The uses envisaged for the model are as follows:

· Model driven development

o Of database schemas

o Of message schemas

o Of common messaging across a business unit or organization

· Semantic Technology development

· Integration of systems and/or data feeds

In addition, the model may be extended locally to extend the scope of what is modeled, prior to using such local extensions in any of the above usage scenarios.

7.3.1 Model Driven Development

Model Driven Development refers to the top town development of technical artifacts starting with a high level, business view of the requirements (for programs) or the data semantics (for data).

The model defined in this specification is intended to be situated within any model driven development framework, as a conceptual model and potentially extended locally with additional concepts. This is the case whether the development is for databases, messages or a combination of the two.

Analysis of the model and metadata provided may enable the automation or partial automation of the production of logical data models, or at least of a candidate starting point for the development of the logical data model prior to the addition of keys and other database requirements.

The model described and presented within this specification supports multiple inheritance between classes, whereas most logical data models would be developed using a single inheritance taxonomy (as this is often a constraint on the logical or physical models development). This model will contain metadata which defines, for multiple inheritance taxonomies, Such information can be interrogated to extract from the model a suitable single inheritance taxonomy appropriate to the requirements of the development.

If this model is used within a UML tool, users may create formal mappings between logical data model constructs and the semantics corresponding to these in the FIBO model content. This simplifies the validation and verification of technical data model artifacts.

7.3.2 Semantic Technology Development

As part of this specification, model content is made available in the Web Ontology Language (OWL) format, which is the format used in semantic technology applications.

However, semantic technology developers should be aware that the physical and technical constraints, which rightly apply to semantic technology applications, have not been imposed, since its primary purpose is to serve as a conceptual model at the business level.

Similarly, it should be noted that in defining the formal meanings of terms in the business domain, most of those meanings are “grounded” with reference to legal constructs, accounting constructs and so on. This may or may not correspond to instance data in the application. Typically a semantic technology application, like any other application, will operate on actual data.

There is therefore a distinct difference between the terms defined in this model to satisfy the requirements of a business conceptual model, and the terms required or to be found in an ontology that would be used in a semantic technology application.

Semantic Technology developers will therefore need to extract from the model content, some suitable and decidable sub-set of that content.

This specification does not detail exactly how to derive decidable sub-sets of the content, such as OWL-DL. It is left to the semantic technology developer to make the necessary transformations.

Some of the metadata provided with this model may assist in this.

7.3.3 Integration of systems and/or data feeds

The simplest application of this conceptual model is to simply use the terms as a common point of reference when comparing terms within different logical or physical data models. This would be of value for example when integrating different systems.

Many systems may not have a formally stated ontology for the data elements that they use, or the database schema may be considered to be the only record of the meanings of the terms therein. Typically, whenever two or more systems need to be integrated, there is a time consuming and almost open ended “mapping” exercise in which the meanings of each of the terms in each of the databases or message schemas involved in the integration, are guessed and perhaps written down.

In reality, even when the intended meanings of the elements in each database and message schema are known, there is not an easy one-to-one mapping between one system and another. This is typically the result of good design: the more the designs have made use of reusable common data structures, the more efficient that design is, but correspondingly the less explicit is the semantics of the terms.

In an integration project that brings together data elements from more than two systems or data feeds, the number of mappings that need to be carried out between one system or feed and another is a geometrical function of the number of such data sources and feeds. In order to have a mapping exercise which is only arithmetically related to the number of data sources and feeds, it is necessary to have a single “hub” of terms which are able to be used as a common point of reference between each of the data models.

While this can often be achieved using a single data model, in practice the limitations on data models (such as single inheritance taxonomies in many cases, though not all) mean that no one model can be found against which all terms in all data models and feeds may be cross referenced. The model presented as part of this specification, being a semantic model, contains full definitions of the meaningful concepts which may be referred to by any of the data elements in the data sources or feeds that need to be integrated, as long as this model may be extended locally to cover areas of scope which are not part of the current specification.

8 Architecture

Intended Audience: Technical, including Enterprise and Information Architects, Implementers.

This section provides an overview of the ontology architecture and modeling strategies used to develop the Foundations ontology.

· Usage and restriction of the Ontology Definition Metamodel (ODM) standard

· Notional architecture and intended use of the Foundations ontologies

· Application and adaptation of semantic modeling techniques and notations for business presentation.

The technical content, including diagrams, incorporated in Section 10 of this specification, was generated from the same models used to generate the RDF/XML serialized OWL, further ensuring correctness and completeness of the specification itself. 

8.1 Ontology Definition Metamodel (ODM) Usage and Adaptations

8.1.1 Introduction

The model content is developed and maintained using the Unified Modeling Language as a modeling tool framework, but with all model content built using the formal constructs of the Web Ontology Language (OWL). This is achieved using the OMG's Ontology Definition Metamodel (ODM) specification.

The Ontology Definition Metamodel (ODM) specification provides a means to represent OWL constructs using UML tools. This is achieved using UML’s extension capability called 'profiles' for OWL and for RDF Schema. The ODM UML Profiles define a number of stereotypes which apply to standard UML metaclasses and may be used to represent OWL constructs in a consistent and meaningful way. 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.

8.1.2 ODM Constructs Usage

Table 8.1 shows the RDF, RDF Schema and OWL model constructs, the names of the ODM stereotypes and their corresponding UML base classes. Where many stereotypes are listed, the base classes apply in order.

Full details of these stereotypes and how they are used are given in the ODM Specification.

Table 8-1 ODM Constructs Usage

Construct

Stereotype

 

UML Base Class or Element

 

RDF/RDF Schema Constructs

 

 

Vocabulary Reference

references

Dependency

Namespace Definition

namespaceDefinition

InstanceSpecification

Datatype

rdfsDatatype

Class

Instance type relationship (rdf:type)

rdfType

Dependency

Literal Data

literal

InstanceSpecification, LiteralString

URI/IRI

IRI

InstanceSpecification

Simple Property

fact, predicate

InstanceSpecification, Dependency

Sub-class

subClassOf

Generalization

Sub-property

subPropertyOf

Generalization

rdf:about

about

Generalization, Dependency

Cross reference

seeAlso

Dependency

Comment

comment

Dependency

Label

label

tagged value, Dependency

Is Defined By

isDefinedBy

Dependency

OWL Constructs

 

 

OWL Ontology

owlOntology

Package

OWL Import

owlImports

Dependency

Class

owlClass

Class

Complement

ComplementClass, ComplementDatatype, complementOf

Class, DataType, Dependency

Data range

DataRange

DataType

Enumeration (selection list)

EnumerationClass, DataEnumeration, oneOf

Class, DataType, Dependency

Intersection

IntersectionClass, IntersectionDatatype, intersectionOf

Class, DataType, Generalization

Union

UnionClass, UnionDatatype, unionOf, disjointUnionOf

Class, DataType, Generalization, Generalization

Restrictions

 

 

Value Restrictions

owlRestriction, onProperty, allValuesFrom, someValuesFrom, hasValue

Class, Dependency, Dependency, Dependency, Dependency

Number Restrictions on Classes

owlRestriction, onProperty, cardinality, minCardinality, maxCardinality, onClass

Class, Dependency, tagged value, tagged value, tagged value, Dependency

Number Restrictions on Data ranges

owlRestriction, onProperty, cardinality, minCardinality, maxCardinality, onDataRange

Class, Dependency, tagged value, tagged value, tagged value, Dependency

Datatype Restrictions

DatatypeRestriction, onDatatype, langRange, length, maxExclusive, minExclusive, maxInclusive, minInclusive,

maxLength, minLength, pattern

Class, Dependency, tagged value, tagged value, tagged value, tagged value, tagged value, tagged value, tagged value, tagged value, tagged value

Object Property

objectProperty

AssociationClass

Datatype Property

datatypeProperty

AssociationClass

Annotation Property

annotationProperty

AssociationClass

Disjoint relation

disjointWith

Dependency

Equivalent Class

equivalentClass

Dependency

Inverse relationship

inverseOf

Dependency

Named Individual

NamedIndividual

InstanceSpecification

Same As

sameAs

Dependency

Different From

differentFrom

Dependency

Annotation instance

annotationFact

Dependency

8.2 Ontology Architecture and Namespaces

The ontology architecture for FIBO is designed to facilitate reuse and ontology evolution to the degree possible.  It is also designed to facilitate mapping to other standards, in particular, to financial industry domain standards, such as FpML (Financial Products Mark-up Language [2]).  There are countless standards used for financial reporting, many of which are complex and lengthy, with overlap and jurisdiction-specific semantics.  An approach to the foundational terminology that provides very high-level, abstract conceptual knowledge designed to facilitate mapping is an important design goal of FIBO Foundations. 

Proxy concepts for Goal, Objective, Address, and Country, for example, that are included in the Foundations with little embellishment, are designed to provide hooks for mapping to the OMG’s Business Motivation Model, ISO standards for Country code representations, US Publication 28 and other national postal addressing standards, and so forth.  The basic building blocks for the Foundations Ontology are shown in Figure 8-1, below.

As shown in the diagram, the Foundations ontologies are divided up into a number of modules. For example, the Utilities module includes: a general purpose BusinessTypes.owl ontology, a general Relations.owl ontology, and an AnnotationVocabulary.owl ontology, that captures FIBO-specific annotations.

The Foundations modules will ultimately depend on (1) Basic Terminology and Ontology Metadata (in light gray in the figure), and (2) a number of external modules, representing concepts for Natural Language, Geopolitical Entities (for example ISO 3166 Country codes, regional and municipal designations), Postal Addressing (from standards such as US Publication 28), and concepts defining dates, times, calendars, and schedules. A sample set of these anticipated external resources are given in the dark gray layer in the figure. 

In this initial version, the Foundations standard reuses metadata definitions, as highlighted in Figure 8-1 in the Basic Terminology and Ontology Metadata layer, from:

· The Dublin Core Metadata Terms Standard

· The W3C Simple Knowledge Organization System (SKOS)

· The OMG Architecture Board’s Specification Metadata Recommendation

SKOS and the OMG Specification Metadata are explicitly imported, while the Dublin Core is not, due to the fact it is an RDF Vocabulary and only OWL ontologies may be formally imported. 

Figure 8.1 Foundations Ontology Architecture

Figure 8-1 Foundations Ontology Architecture.png

 

The namespaces and their well-known prefixes corresponding to external elements required for use of FIBO Foundations include the following:

Table 8-2 Prefix and Namespaces for referenced/external vocabularies

Namespace Prefix Namespace

rdf

http://www.w3.org/1999/02/22-rdf-syntax-ns#

rdfs

http://www.w3.org/2000/01/rdf-schema#

owl

http://www.w3.org/2002/07/owl#

xsd

http://www.w3.org/2001/XMLSchema#

dct

http://purl.org/dc/terms/

skos

http://www.w3.org/2004/02/skos/core#

sm

http://www.omg.org/techprocess/ab/Sp...ationMetadata/

The namespace approach taken for FIBO is based on OMG guidelines and is constructed as follows:

- A standard prefix http://www.omg.org/spec/

- The family name,  EDMC-FIBO

- The abbreviation for the specification: in this case FND

- The module name

- The ontology name

Note that the URI/IRI strategy for the ontologies in FIBO takes a “slash” rather than “hash” approach, in order to accommodate server-side applications.  Though not technically necessary, this specification does mandate namespace prefixes to be used. These are constructed as follows with the components separate by “-“:

- The specification family name fibo

- The specification abbreviation: fnd

- An abbreviation for the module name

- An abbreviation for the ontology name

The namespaces and prefixes corresponding to FIBO Foundations ontologies are summarized in Table 8-3 for convenience.  These are given in alphabetical order, by module, rather than with any intent to show imports relationships. 

Table 8-3 Prefix and Namespaces for FIBO Foundations

Namespace Prefix

Namespace

fibo-fnd-acc-aeq

http://www.omg.org/spec/EDMC-FIBO/FN...ountingEquity/

fibo-fnd-acc-cur

http://www.omg.org/spec/EDMC-FIBO/FN...urrencyAmount/

fibo-fnd-aap-agt

http://www.omg.org/spec/EDMC-FIBO/FN...People/Agents/

fibo-fnd-aap-ppl

http://www.omg.org/spec/EDMC-FIBO/FN...People/People/

fibo-fnd-agr-agr

http://www.omg.org/spec/EDMC-FIBO/FN...ts/Agreements/

fibo-fnd-agr-ctr

http://www.omg.org/spec/EDMC-FIBO/FN...nts/Contracts/

fibo-fnd-gao-gl

http://www.omg.org/spec/EDMC-FIBO/FN...ectives/Goals/

fibo-fnd-gao-obj

http://www.omg.org/spec/EDMC-FIBO/FN...es/Objectives/

fibo-fnd-law-jur

http://www.omg.org/spec/EDMC-FIBO/FN.../Jurisdiction/

fibo-fnd-law-lcap

http://www.omg.org/spec/EDMC-FIBO/FN...LegalCapacity/

fibo-fnd-law-cor

http://www.omg.org/spec/EDMC-FIBO/FND/Law/LegalCore/

fibo-fnd-org-fm

 http://www.omg.org/spec/EDMC-FIBO/FN...Organizations/

fibo-fnd-org-lg

 http://www.omg.org/spec/EDMC-FIBO/FN...Organizations/

fibo-fnd-org-org

http://www.omg.org/spec/EDMC-FIBO/FN...Organizations/

fibo-fnd-oac-ctl

http://www.omg.org/spec/EDMC-FIBO/FN...ntrol/Control/

fibo-fnd-oac-own

http://www.omg.org/spec/EDMC-FIBO/FN...rol/Ownership/

fibo-fnd-pty-pty

http://www.omg.org/spec/EDMC-FIBO/FN...rties/Parties/

fibo-fnd-pty-rl

http://www.omg.org/spec/EDMC-FIBO/FND/Parties/Roles/

fibo-fnd-plc-adr

http://www.omg.org/spec/EDMC-FIBO/FN...ces/Addresses/

fibo-fnd-plc-cty

http://www.omg.org/spec/EDMC-FIBO/FN...ces/Countries/

fibo-fnd-plc-loc

http://www.omg.org/spec/EDMC-FIBO/FN...ces/Locations/

fibo-fnd-rel-rel

http://www.omg.org/spec/EDMC-FIBO/FN...ons/Relations/

fibo-fnd-utl-av

http://www.omg.org/spec/EDMC-FIBO/FN...ionVocabulary/

fibo-fnd-utl-bt

http://www.omg.org/spec/EDMC-FIBO/FN...ssFacingTypes/

8.4 FIBO-Based Reporting

8.4.3 Business-Facing Approach

There are a number of ways of presenting the ontology to domain experts, and the intent is to standardize two of these.

Diagrammatic Presentation

The FIBO ontologies (model) may be presented to business domain experts in a number of forms, with views that express different levels of detail and different aspects of the model to aid in understanding.  Critical requirements for business-facing diagrams include limiting or eliminating technical detail while retaining it in the underlying model, and hiding, to the degree possible:

· stereotype names on diagrams, although English labels and icons may be used where important to express the meaning of a line or box,

· technical tags, such as visibility, and optionally names, on property endpoints,

· empty partitions in boxes representing classes and association classes, and

· the class in an association class representation of an object, data, or annotation property. 

This does not preclude the incorporation of diagramming elements to represent fundamental concepts from set theory, first order logic, etc., that are needed to understand the ontology.  Other requirements for diagramming style will be forthcoming as the specification achieves broader adoptions.

An example, showing a simplified OWL diagram, is given in Figure 8-2.

Figure 8.2 Example Business-Facing FIBO Diagram

Figure 8.2 Example Business-Facing FIBO Diagram.png

The strategy for representation for subject matter experts may include use of color to highlight certain lines, in addition to labeling them in English, for example, by using blue lines for object properties, green lines for data properties (if they are not shown using an attribute style, inside the class box), dashed red dependency for disjointness, and so forth.

Tabular or Textual Presentation

In addition to the presentation via diagrams, there is a need to provide business domain experts with a more spreadsheet-like view of the terms, relationships, formal definitions, and other annotations in particular, for review, understanding, and use.

There are two levels of detail that shall be made available in reports. These are the 'Basic' view of Term, Definition and Synonym, and an extended view giving most or all of the same information that is seen in the diagrams. This shall include line entries for each thing and each fact (Relationship Property and Simple Property) as well as the set theory constructs and relationships modeled (unions, parent terms etc.). It is not necessary to show relationships between relationships in these tables, such as sub property hierarchies or property inverses.

The constructs shall be represented with an English language name, including spaces between words rather than camel case; those that are substantially different from their OWL language equivalents include: “Is A” for subclass relationships, “Type” for datatypes, “type of” rather than rdfType,  “Simple Property” for datatype properties, “Relationship Property” for object properties, and “mutually exclusive” for disjointness relationships. These names are in US English and may be replaced in reports with definitionally equivalent labels in other natural languages.

GAP

and possibly additional terms that may be added to support parallel, collaborative development processes required for FIBO financial product-specific ontologies.

9 Additional Metadata

9.1 Introduction

As discussed in section 8, the FIBO Foundations and specifications that depend on it reuse existing metadata standards, including:

· The Dublin Core Metadata Terms Standard

· The W3C Simple Knowledge Organization System (SKOS)

· The OMG Architecture Board’s Specification Metadata Recommendation

These metadata definitions are not inherent elements of RDF Schema or OWL, although the standard makes extensive use of rdfs:label in particular. This section of the specification describes the metadata used throughout the standard and provides examples where appropriate for clarification purposes.

9.2 Ontology-Level Metadata

Each Foundations ontology has a set of common metadata which is specified in this section rather than being repeated for each ontology.  This information is included regardless of whether the ontology is serialized as RDF/XML OWL, UML/XMI with the ODM profiles for RDF and OWL applied, or as ODM XMI. 

The use of the “sm” namespace prefix in the abbreviated IRI for the metadata term refers to the Specification Metadata ontology, as described in Table 8-2, above.

Table 9-1 FIBO Foundations Specification Family Metadata

Metadata Term

Value

sm:familyTitle

Financial Industry Business Ontology (FIBO)

sm:familyAbbreviation

FIBO

sm:familyURL

http://www.omg.org/spec/EDMC-FIBO/

sm:familyAbstract

The content that comprises the Financial Industry Business Ontology (FIBO) is documentation, interpretable in formal logic, of the concepts represented by finance industry terms as used in official financial organization documents such as contracts, product/service specifications and governance and regulatory compliance documents.

sm:technologyArea

formal semantics

sm:topicArea

finance

sm:keyword

Financial Industry Business Ontology, FIBO, ontology, vocabulary

Table 9-2 FIBO Foundations Specification Metadata

Metadata Term

Value

sm:specificationTitle

Financial Industry Business Ontology (FIBO) Foundations Specification

sm:specificationAbbreviation

FIBO-FND

sm:specificationURL

http://www.omg.org/spec/EDMC-FIBO/FND/

sm:specificationAbstract

FIBO Foundations is a set of business concepts which are intended to support the financial industry terms semantics presented in other FIBO specifications. 

 

The FIBO Foundations models define concepts which are not unique to the financial services industry. From these, financial industry terms in other FIBO specifications may be derived by extension. Terms are also included which may be referred to by properties of things in those specifications. FIBO Foundations therefore includes a number of basic terms about legal, contractual and organizational concepts, among others.

sm:dependsOn

http://www.omg.org/techprocess/ab/SpecificationMetadata/

 

sm:keyword

Foundational vocabulary

 

Table 9-3 FIBO Foundations Specification Version Metadata

Metadata Term

Value

sm:thisVersion

1.0

sm:publicationDate

2013-08-26T18:00:00

sm:specificationVersionURL

http://www.omg.org/spec/EDMC-FIBO/FND/1.0/

sm:specificationVersionStatus

Request For Comments (RFC)

skos:historyNote

This version of the FIBO Foundations Specification was revised primarily to reflect comments received at the March 2013 OMG Technical Meeting in Reston and reflected in the Errata discussed at the June 2013 OMG Technical Meeting in Berlin.

 

Revisions to FIBO Foundations are managed per the process outlined in the Policies and Procedures for OMG standards, with the intent to maintain backwards compatibility in the ontologies to the degree possible.

 

The RDF/XML serialized OWL for the Foundations ODM/OWL ontologies have been checked for syntactic errors and logical consistency with Protege 4 (http://protege.stanford.edu/), HermiT 1.3.7 (http://www.hermit-reasoner.com/) and Pellet 2.2 (http://clarkparsia.com/pellet/).

sm:addressForComments

http://www.omg.org/issues/

 

Every module will have unique metadata specific to that module, as given in section 10, below.  Additionally, every ontology will include curation metadata.  Explicit use of the MIT License [3] for software (including OWL ontologies, UML models, ODM XMI) is intended to assure users of the ontologies that the ontologies are freely available, for use with attribution, and without warranty.

Table 9-4 FIBO Foundations Specification Curation and Rights Metadata

Metadata Term

Value

sm:copyright

Copyright (c) 2013 EDM Council, Inc.

Copyright (c) 2013 Object Management Group, Inc.

dct:license

The MIT License:  Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE

AND NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

dct:license

http://opensource.org/licenses/mit-license.php

sm:responsibleTaskForce

http://fdtf.omg.org/

Finally, each ontology will also include ontology-specific specific metadata, using the OMG Specification Metadata ontology.  Again, these details are provided with the individual ontologies in section 10.

9.3 Ontology Entity-Level Metadata

This section describes the metadata that are applied to each named concept (Class and Property) in the ontologies.

9.3.1 Definitions, Notes, and Labels

Table 9-5 Definitions, Labeling, and Notes

Term Requirement

Term Type

Annotation

Usage Notes

Definition

Definition

skos:definition

Main formal definition of term. Must always be present

Change history

Note

skos:changeNote

Notes indicating why something was modified

General note, editorial comment

Note

skos:editorialNote

The bulk of the “Further Notes” narrative is expressed this way

Examples

Note

skos:example

Examples

Explanatory note

Note

fibo-utl-av:explanatoryNote

Notes providing additional explanation about the concept

Historical note

Note

skos:historyNote

Notes regarding the history of the concept

Note

Note

skos:note

Used when no specific note annotation is appropriate

Scope note

Note

skos:scopeNote

Clarifying information about the scope of the term or concept

Usage note

Note

fibo-utl-av:usageNote

Used to suggest how a particular concept is intended to be used

Preferred Label

Label

skos:prefLabel

Replaces rdfs:label if there is a preferred label for the concept

Alternate Label

Label

skos:altLabel

Alternate label additional to prefLabel. Should be used instead of rdfs:label for alternatives

9.3.2 Synonymous Terms

Synonyms are fundamental to the reporting required for business domain view and review of the ontologies, which, at a basic level, may only require the concept, a label, its formal definition in text form, and any synonyms.

Fundamentally, an ontology, and any extensions derived from it, should contain only a single element defining a given concept, with synonyms captured using the fibo-utl-av:synonym annotation property.  Within a given ontology, use of separate classes with the same meaning, together with the OWL construct for class equivalence (equivalentClass) is not considered best practice.  Such an approach may be necessary to align or map ontologies to one another, however, where the same concepts exist in different namespaces.  fibo-utl-av:abbreviation may be used to specify abbreviations and acronyms associated with concepts as appropriate. 

9.3.3 Provenance and Cross-reference Annotation

Where possible, every effort is made in the FIBO ontologies to provide references for the origin of terms and their definitions, including cases where those definitions have been adapted for FIBO usage.  While less important for Foundations, any FIBO ontology that includes terminology from a particular standard, such as FpML, ISO 20022, any regulatory publication, and so forth should note it as the source for a given concept or its definition.

Four annotation properties are provided in the FIBO AnnotationVocabulary to facilitate provenance documentation for the terminology and definitions specified in the standard.  These are:

· fibo-utl-av:adaptedFrom – used where the text in the skos:definition  is adapted from the definition of the term defined in the range of this property (range can be a string, URI, or BibliographicCitation).  Note that this initial version of Foundations does not recommend a specific standard for citatations.  There are a number of ontologies that might be considered for this purpose, and the OMG Specification Metadata provides a class called BibliographicCitation that can be used as  the range of this annotation and can be mapped to the preferred citation definition for a given application, organization, or repository.

· fibo-utl-av:definitionOrigin – used where the text in the skos:definition  is a direct copy of the definition of the term defined in the range of this property (range can be a string, URI, or BibliographicCitation).

· fibo-utl-av:termOrigin – which provides the means to document the source of a term, in a standard, in some other document, or by some organization. The range of this property is the document and / or organization from which the term was derived (range can be a string, URI, or BibliographicCitation).

· fibo-utl-av:nameOrigin – which provides the means to document the name of the original term in the standard, other document or organization referenced via the annotation fibo-utl-av:termOrigin

9.3.4 Change Management Annotation

In addition to the version information provided at the specification level for a given FIBO ontology, additional annotations for change management purposes may be appropriate at the concept level.  These may include:

· skos:changeNote

· fibo-utl-av:modifiedBy – identifying the person and/or organization responsible for the change

· fibo-utl-av:modifiedOn – identifying the date and time of the change

10 Model Content Reports

Intended Audience: Business Analysts, other business stakeholders

This section shows the content of the model from a business perspective. Model content is presented both as diagrams and as tables. Readers do not need to be conversant with the Web Ontology Language or other modeling languages in order to be able to interpret what is presented here. However some familiarity with the “set theoretic” interpretation of the model content is required.

This section has a sub-section for each ontology that is automatically generated from the ODM representation of that ontology, and is designed to be more human-readable than the raw OWL file.

The following Table 10.1 explains the headings used and what these mean in terms of the semantics of the model elements presented.

Table 10-1 Table Guide

NOTE: Not all of these entries are provided in every section.

Heading

Description

Name

The formal name of the model element. This is in the “CamelCase” format.

Type of Thing

The name of the class of “Thing” or, for properties, the class of thing for which that is a property. Note that properties which are intended to be widely used will state “anything” in this column, meaning that it is intended to be a property of “Thing”, the set of which everything is a member.

Property

The name of the property (blank for entries which describe a type of thing).

Definition

The formal written definition of the type of thing or the property.

Synonyms

The or any synonyms which are identified for the concept.

Equivalent To

Identifies a class or property restriction which is the same in meaning

Parent

For types of thing, the type of thing for which it is a sub-type, sharing properties of that thing.

Mutually Exclusive With

Indicates that a type of thing is mutually exclusive with the other type of thing identified in this column. This means that no individual thing may be a member of both sets.

Related Thing Or Type

For relationship properties, the type of thing in terms of which the property is framed or (in subject-predicate-object terms) the object of the property. For example a property like “has jurisdiction” would be framed in terms of the type of thing, which is a jurisdiction.

For simple properties, the type of information in terms of which the property is framed (e.g. text, date, yes/no or selection of textual descriptors)

Inverse of Property

Identifies a property which is the opposite or inverse of the one in this line. For example is a customer holds an account, and an account is held by a customer, these properties are the inverse of one another.

Multiples

Indicates where a property may have specific multiples of the item identified as the related thing or simple type. Where properties are reused or refined, this indicates specific limitations on the numbers of the kind of thing identified as the related thing for the reused property.

Concept type

Gives the natural language description of what kind of concept is being reported on in this line of the table, e.g. class (type of thing), Simple Property, Relationship Property and so on.

Explanatory Note

Provides any textual information that has been included about the concept, over and above the formal definition for the concept.

Term Origin

For concepts, which have been included with reference to, some other source (typically an industry standard data model) this column identifies the document, standard or other resource from which the term was derived.

Definition Source

For concepts for which a definition has been taken from some other source this column identifies the document, standard or other resource from which the definition was directly taken.

Adapted From

Where definitions have been taken from other sources but adapted, this column identifies the source of the original definition. This is typically the case when a definition is taken from some technical industry standard, and the description of a data field or message element is re-worded to describe the real world thing to which that element applies.

10.1 Module: Utilities

Table 10-2 Utilities Module Metadata

Metadata Term

Value

sm:moduleName

Utilities

sm:moduleAbbreviation

FIBO-FND-UTL

sm:moduleVersion

1.0

sm:moduleAbstract

Ontologies which provide annotations and business facing datatypes to be used in other ontologies. These ontologies are not expected to be used directly by business stakeholders and are for the definition of material which is used by semantic modelers in Foundations and in other FIBO ontologies.

 

10.1.1 Ontology: Annotation Vocabulary

This vocabulary provides a set of metadata annotations for use in describing FIBO ontology elements.  The annotations extend properties defined in the OMG's Specification Metadata Recommendation, in the Dublin Core Metadata Terms Vocabulary and in the W3C Simple Knowledge Organization System (SKOS) Vocabulary, and have been customized to suit the FIBO specification development process. 

Note that any of the original properties provided in Dublin Core and SKOS can be used in addition to the terms provided herein.  However, any Dublin Core terms that are not explicitly defined as OWL annotation properties in this ontology or in any of its imports must be so declared in the ontologies that use them.

Figure 10.1.1.1 Annotation Vocabulary Concepts

Figure 10.1.1.1 Annotation Vocabulary Concepts.png

Table 10-3 Annotation Vocabulary Metadata

Metadata Term

Value

sm:filename

Annotation Vocabulary

sm:fileAbbreviation

fibo-fnd-utl-av

OntologyIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ionVocabulary/

owl:versionIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ionVocabulary/

 

Table 10-4 Annotation Vocabulary Details

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Simple Type

Related Thing

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

resource

termOrigin

 

 

sm:directSource

 

Literal

 

 

Annotation Property

 

 

 

resource

nameOrigin

 

 

sm:directSource

 

Literal

 

 

Annotation Property

 

 

 

resource

definitionOrigin

 

 

sm:directSource

 

Literal

 

 

Annotation Property

 

 

 

resource

adaptedFrom

 

 

sm:directSource

 

Literal

 

 

Annotation Property

 

 

 

resource

modifiedon

 

 

terms:modified

 

Literal

 

 

Annotation Property

 

 

 

resource

modifiedBy

 

 

sm:contributor

 

Literal

 

 

Annotation Property

 

 

 

resource

abbreviation

 

 

core:altLabel

 

 

resource

 

Annotation Property

 

 

 

resource

synonym

 

 

core:altLabel

 

 

resource

 

Annotation Property

 

 

 

resource

explanatoryNote

 

 

core:note

 

 

resource

 

Annotation Property

 

 

 

resource

usageNote

 

 

core:note

 

 

resource

 

Annotation Property

 

 

 

 10.1.2 Ontology: Business Facing Types

This ontology provides high level definitions for business facing datatypes for use in other FIBO ontology elements. These types are essentially aliases of existing RDF datatypes, and are provided in order to be able to present datatype properties to a business audience with non technical names, for example yes or no in place of boolean and text in place of string. All datatype properties in the FIBO ontologies are framed in terms of these business-facing types and not in terms of the underlying technically-named datatypes.

Figure 10.1.2.1 Business Types Concepts

Figure 10.1.2.1 Business Types Concepts.png

Table 10-5 Business-Facing Types Ontology Metadata

Metadata Term

Value

sm:filename

Business Facing Types Ontology

sm:fileAbbreviation

fibo-fnd-utl-bt

OntologyIRI

http://www.omg.org/spec/EDMC-FIBO/FND/ Utilities/BusinessFacingTypes/

owl:versionIRI

http://www.omg.org/spec/EDMC-FIBO/FND/20130801/ Utilities/BusinessFacingTypes/

sm:dependsOn

http://www.omg.org/spec/EDMC-FIBO/FND/Utilities/AnnotationVocabulary/

 

Table 10-6 Business Facing Types Details

Datatype

Definition

Equivalent Datatype

Concept Type

Definition Source

basisPoints

A basis point is a unit equal to one hundredth of a percentage point, or one part per ten thousand, 1/10000.

Decimal

Datatype

 

negativeWholeNumber

 

negativeInteger

Datatype

 

nonNegativeNumber

 

decimal

Datatype

 

nonNegativeWholeNumber

 

nonNegativeInteger

Datatype

 

number

A number is a mathematical object used to count, label, and measure. In mathematics, the definition of number has been extended over the years to include such numbers as 0, negative numbers, rational numbers, irrational numbers, and complex numbers.

decimal

Datatype

 

percentage

In mathematics, a percentage is a number or ratio as a fraction of 100. It is often denoted using the percent sign, %, or the abbreviation, pct.

decimal

Datatype

 

positiveWholeNumber

 

positiveInteger

Datatype

 

restrictedPercentage

A type defining a percentage specified as decimal from 0 to 1. A percentage of 5% would be represented as 0.05. The maximum value is 100%, i.e., 1.

decimal

Datatype

 

text

In computing, plain text is the contents of an ordinary sequential file readable as textual material without much processing, usually opposed to formatted text and to binary files in which some portions must be interpreted as binary objects (encoded integers, real numbers, images, etc.).

The encoding has traditionally been either ASCII, one of its many derivatives such as ISO/IEC 646 etc., or sometimes EBCDIC. Unicode-based encodings such as UTF-8 and UTF-16 are gradually replacing the older ASCII derivatives limited to 7 or 8 bit codes.

String

Datatype

 

URI

In computing, a uniform resource identifier (URI) is a string of characters used to identify a name or a web resource. Such identification enables interaction with representations of the web resource over a network (typically the World Wide Web) using specific protocols. Schemes specifying a concrete syntax and associated protocols define each URI.

anyURI

Datatype

 

wholeNumber

 

integer

 

 

yesOrNo

 

boolean

 

 

 

 

10.2 Module: Relations

Table 10-7 Relations Module Metadata

Metadata Term

Value

sm:moduleN6me

Relations

sm:moduleAbbreviation

FIBO-FND-REL

sm:moduleVersion

1.0

sm:moduleAbstract

This module contains an ontology defining a number of reusable relationships. These are used, refined or restricted to define relationships among more specific concepts in other FIBO ontologies. Some of these relationships stand in for relationships which are defined in external standards ontologies.

 

10.2.1 Ontology: Relations

This ontology defines a set of general-purpose relations for use in other FIBO ontology elements.  These include a number of properties required for reuse across the foundations and business entities models.

Figure 10.1.1 Relations Concepts

Figure 10.1.1 Relations Concepts.png

Table 10-8 Relations Ontology Metadata

Metadata Term

Value

sm:filename

Relations Ontology

sm:fileAbbreviation

fibo-fnd-rel-rel

OntologyIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ons/Relations/

owl:versionIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ons/Relations/

sm:dependsOn

http://www.omg.org/spec/EDMC-FIBO/FND/Utilities/AnnotationVocabulary/

http://www.omg.org/spec/EDMC-FIBO/FND/Utilities/BusinessFacingTypes/

 

 

Table 10-9 Relations Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

Thing

anything

was formerly known as

A name by which the entity was known in the past

 

has name

 

text

 

Simple Property

 

 

 

Thing

anything

uses

relates an entity to another entity that has the ability to employ it in some way

 

 

 

anything

is used by

Relationship Property

 

 

 

Thing

anything

represents

relates an  entity (which is some textual or other symbol or some set of words) to some entity or concept that has the sense or meaning the representation is intended to convey

 

 

 

anything

has representation

Relationship Property

 

 

 

Thing

anything

provides

makes something available to

 

 

 

anything

is provided by

Relationship Property

 

 

 

Thing

anything

manages

relates an entity to another entity that it directs in some way

 

 

 

anything

is managed by

Relationship Property

 

 

 

Thing

anything

is used by

relates an entity to another entity that has the ability to employ or deploy that entity as appropriate

 

 

 

anything

uses

Relationship Property

 

 

 

Thing

anything

is provided by

is made available by

 

 

 

anything

provides

Relationship Property

 

 

 

Thing

anything

is a part of

relates a given entity to another that it is some component or portion of, regardless of how that whole-part relationship is manifested, i.e., attached to the remainder or detached; cognitively salient or arbitrarily demarcated; self-connected or disconnected; homogeneous or gerrymandered; material or immaterial; extended or unextended; spatial or temporal; the most generic part relation, reflexive, asymmetric, and transitive.

 

 

 

anything

has part

Relationship Property

 

 

 

Thing

anything

is member of

belonging, either individually or collectively, to a group

 

 

 

anything

has member

Relationship Property

 

 

 

Thing

anything

is mandated by

relates a responsibility, capacity, or action to the entity that requires it

 

is conferred by

 

anything

 

Relationship Property

 

 

 

Thing

anything

is managed by

relates an entity to another entity that has some role in directing its affairs

 

 

 

anything

manages

Relationship Property

 

 

 

Thing

anything

is issued by

identifies an office or organization responsible for circulating, distributing, or publishing something

 

 

 

anything

 

Relationship Property

 

 

 

Thing

anything

is in force in

identifies a jurisdiction in which something (e.g. a law or policy) has effect

 

 

 

anything

has in force

Relationship Property

 

 

 

Thing

anything

is identified by

provides a unique identifier for an entity

 

 

 

anything

identifies

Relationship Property

 

 

 

Thing

anything

is held by

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

 

 

 

anything

holds

Relationship Property

 

 

 

Thing

anything

is governed by

 

 

 

 

anything

governs

Relationship Property

 

 

 

Thing

anything

is controlled by

is influenced, managed, or directed by

 

 

 

anything

controls

Relationship Property

 

 

 

Thing

anything

is constrained by

identifies the policy, rule, regulation, contract, or other thing that compels or obliges someone to act in some way

 

 

 

anything

constrains

Relationship Property

 

 

 

Thing

anything

is conferred on

that on which the conferred thing is conferred

 

 

 

anything

 

Relationship Property

 

 

 

Thing

anything

is conferred by

is vested by

 

 

 

anything

confers

Relationship Property

 

 

 

Thing

anything

is classified by

indicates the classification scheme used to classify an entity

 

 

 

anything

classifies

Relationship Property

 

 

 

Thing

anything

is caused by

is the relationship between an event (the effect) and a second event (the cause), where the first event is understood as a consequence of the second; also, the relationship between a set of factors (causes) and a phenomenon (the effect)

 

 

 

anything

causes

Relationship Property

 

 

 

Thing

anything

is appointed by

indicates the individual or group that has assigned or appointed someone to an office or position

 

 

 

anything

appoints

Relationship Property

 

 

 

Thing

anything

involves

(of a situation or event) includes (something) as a necessary part or result

 

 

 

anything

 

Relationship Property

 

 

 

Thing

anything

identifies

is the relationship between an entity and another that provides a unique reference for it

 

 

 

anything

is identified by

Relationship Property

 

 

 

Thing

anything

holds

is the relationship between an entity and something it possesses, or over which it exercises some ownership or control or has at its discretion the ability to dispose of it as it sees fit

 

 

 

anything

is held by

Relationship Property

 

 

 

Thing

anything

has unique identifier

links an entity to a unique identifier for that entity; may be associated with anything.  With reference to a given (possibly implicit) set of objects, a unique identifier (UID) is any identifier which is guaranteed to be unique among all identifiers used for those objects and for a specific purpose.

 

 

 

text

 

Simple Property

 

 

 

Thing

anything

has representation

relates a concept to some textual or other symbol which is intended to convey the sense of that concept or to some form of words which sets out the meaning of that concept

 

has

 

anything

represents

Relationship Property

 

 

 

Thing

anything

has part

indicates any portion of a given entity, regardless of whether the portion itself is attached to the remainder or detached; cognitively salient or arbitrarily demarcated; self-connected or disconnected; homogeneous or gerrymandered; material or immaterial; extended or unextended; spatial or temporal

 

has

 

anything

is a part of

Relationship Property

 

 

 

Thing

anything

has name

that by which some thing is known; may apply to anything

 

 

 

text

 

Simple Property

 

 

 

Thing

anything

has member

relates an entity, typically a group or organization, to some discrete entity identified as a part (member) of that entity

 

 

 

anything

is member of

Relationship Property

 

 

 

Thing

anything

has legal name

the name used to refer to an entity in legal communications

 

has formal name

 

text

 

Simple Property

 

 

 

Thing

anything

has in force

relates a jurisdiction or situation to a policy, rule, regulation or law that is currently in force in that situation or jurisdiction

 

 

 

anything

is in force in

Relationship Property

 

 

 

Thing

anything

has identity

provides a means for identifying something that fills a particular role

 

has

 

anything

 

Relationship Property

 

 

 

Thing

anything

has formal name

a name by which the entity is known for some official purpose or context, or which is structured in some way such as to always follow the same format regardless of usage.

 

has name

 

text

 

Simple Property

 

 

 

Thing

anything

has expiration date

links something, typically an agreement, contract, document, or perishable item, with an expiration date

 

 

 

xsd:dateTime

 

Simple Property

 

 

 

Thing

anything

has effective date

the date a contract, relationship, or policy comes into force

 

 

 

xsd:dateTime

 

Simple Property

 

 

 

Thing

anything

has disposition date

links something, such as an asset or its owner/controller/controllee to the date something was sold, transferred, destroyed, etc.

 

 

 

xsd:dateTime

 

Simple Property

 

 

 

Thing

anything

has designation

relates an individual or entity to a position, role, or other designation

 

has

 

anything

designates

Relationship Property

 

 

 

Thing

anything

has denotation

relates a concept (or something else, but typically a concept) to a representation or denotation for that concept

 

has representation

 

anything

denotes

Relationship Property

 

 

 

Thing

anything

has definition

specifies a form of words that conveys the meaning associated with an entity

 

has representation

 

anything

defines

Relationship Property

 

 

 

Thing

anything

has date of issuance

links something, typically an agreement, contract, or document, with the date it was issued

 

 

 

xsd:dateTime

 

Simple Property

 

 

 

Thing

anything

has context

provides a context in which something is defined, expressed, or represented

 

has

 

anything

 

Relationship Property

 

 

 

Thing

anything

has common name

a name by which the entity is frequently referred, without reference to any formal usage or structure

 

has name

 

text

 

Simple Property

 

 

 

Thing

anything

has alias

Any other name by which an individual or entity is known

 

has name

 

text

 

Simple Property

Added at SME Review, to meet AML requirements

 

 

Thing

anything

has acquisition date

links an asset or owner/controller/controllee to the date of acquisition

 

 

 

xsd:dateTime

 

Simple Property

 

 

 

Thing

anything

has

indicates that someone (or something) possesses something, as a characteristic, attribute, feature, capability, and so forth

 

 

 

anything

 

Relationship Property

As used in FIBO, this definition of has specifically excludes possession in the sense of ownership.

 

 

Thing

anything

governs

prevails or has decisive influence over; exercises authority

 

 

 

anything

is governed by

Relationship Property

 

 

 

Thing

anything

embodies

is an expression of, or gives a tangible or visible form to (an idea, quality, or feeling), makes concrete and perceptible 

 

 

 

anything

 

Relationship Property

 

 

 

Thing

anything

designates

to name something officially or appoint someone to a position officially

 

 

 

anything

has designation

Relationship Property

 

 

 

Thing

anything

denotes

represents, calls by a distinctive title, term, or expression

 

represents

 

anything

has denotation

Relationship Property

 

 

 

Thing

anything

defines

determines or identifies the essential qualities or meaning of, discovers and sets forth the meaning of, fixes or marks the limits of, demarcates

 

represents

 

anything

has definition

Relationship Property

 

 

 

Thing

anything

controls

exercises authoritative or dominating influence over; directs

 

 

 

anything

is controlled by

Relationship Property

 

 

 

Thing

anything

constrains

forces, compels, or obliges

 

 

 

anything

is constrained by

Relationship Property

 

 

 

Thing

anything

confers

grants or bestows by virtue of some authority

 

 

 

anything

is conferred by

Relationship Property

 

 

 

Thing

anything

comprises

includes, especially within a particular scope, is made up of

 

 

 

anything

 

Relationship Property

 

 

 

Thing

anything

classifies

arranges in classes; assigns to a category

 

 

 

anything

is classified by

Relationship Property

 

 

 

Thing

anything

characterizes

describes the character or quality of

 

 

 

anything

 

Relationship Property

 

 

 

Thing

anything

causes

the relationship between an event (the cause) and a second event (the effect), where the second event is understood as a consequence of the first; also, the relationship between a set of factors (causes) and a phenomenon (the effect)

 

 

 

anything

is caused by

Relationship Property

 

 

 

Thing

anything

appoints

assigns a job or role to someone, selects or designates to fill an office or a position, fixes or sets by authority or by mutual agreement

 

designates

 

anything

is appointed by

Relationship Property

 

 

 

 

 

10.3 Module: Goals and Objectives

Table 10-10 Goals and Objectives Module Metadata

Metadata Term

Value

sm:moduleName

Goals and Objectives

sm:moduleAbbreviation

FIBO-FND-GAO

sm:moduleVersion

1.0

sm:moduleAbstract

This module includes ontologies for goals and objectives which may be pursued by people or organizations. Goals form the basis for the definition of an organization, and objectives and related concepts are required for describing business plans.

 

10.3.1 Ontology: Goals

This ontology defines the concept of a goal, for use in other FIBO ontology elements. Goal is defined in general terms and forms one of the basic properties of organizations.

Figure 10.3.1.1 Goals Concepts

Figure 10.3.1.1 Goals Concepts.png

Table 10-11 Goals Ontology Metadata

Metadata Term

Value

sm:filename

Goals Ontology

sm:fileAbbreviation

fibo-fnd-gao-gl

OntologyIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ectives/Goals/

owl:versionIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ectives/Goals/

sm:dependsOn

http://www.omg.org/spec/EDMC-FIBO/FND/Utilities/AnnotationVocabulary/

 

 

Table 10-12 Goals Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

Goal

goal

 

(2) An observable and measurable end result having one or more objectives to be achieved within a more or less fixed timeframe.
(1) A goal is a desired result a person or a system envisions, plans and commits to achieve a personal or organizational desired end-point in some sort of assumed development. Many people endeavor to reach goals within a finite time by setting deadlines.

 

 

 

 

 

Class

 

 

(2) http://www.businessdictionary.com/de...tion/goal.html
(1) http://en.wikipedia.org/wiki/Goal

 

 10.3.2 Ontology: Objectives

This ontology defines the concept of an objective, for use in other FIBO ontology elements. Objectives are defined as being distinct from goals, in that they constitute time limited and measurable targets which some entity may seek to attain in pursuit of its goals.

Figure 10.3.2.1 Objectives Concepts

Figure 10.3.2.1 Objectives Concepts.png

Table 10-13 Objectives Ontology Metadata

Metadata Term

Value

sm:filename

Objectives Ontology

sm:fileAbbreviation

fibo-fnd-gao-obj

OntologyIRI

http://www.omg.org/spec/EDMC-FIBO/FN...es/Objectives/

owl:versionIRI

http://www.omg.org/spec/EDMC-FIBO/FN...es/Objectives/

sm:dependsOn

http://www.omg.org/spec/EDMC-FIBO/FND/Utilities/AnnotationVocabulary/

 

 

Table 10-14 Objectives Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

Objective

objective

 

An objective is a statement of a quantitative, measurable result that defines strategy. It provides an attainable, time-limited, and measurable target that a person, organization, or system seeks to meet in order to achieve its goals.

 

 

 

 

 

Class

 

 

Forrester Research

10.4 Module: Parties

Table 10-15 Parties Module Metadata

Metadata Term

Value

sm:moduleName

Parties

sm:moduleAbbreviation

FIBO-FND-PTY

sm:moduleVersion

1.0

sm:moduleAbstract

This module includes ontologies defining concepts that are highly contextual in nature, such as the meaning of a party in a role, an agent playing a role, and so on. Also covers independent roles themselves.

 

The definitions for agents and parties in roles provide general, reusable patterns for talking about agents performing roles in specific contexts. For example the same person in the context of aviation could be a pilot, and in the context of family could be a mother.  These pattern will be refined in other FIBO ontologies to define concepts such as issuer, counterparty, underwriter, etc.

 

10.4.1 Ontology: Parties

This ontology defines the high-level concepts of parties in roles, for use in other FIBO ontology elements. The concept of a party in a role describes some entity defined specifically in terms of some role which it performs in some formal contractual or transactional relationship. The ontology includes one or more basic party in role concepts. The ontology also includes one or more logical combinations of types of autonomous entity which may perform some of the party roles defined elsewhere in this ontology, such as the role of ownership.

Figure 10.4.1.1 Parties Concepts

Figure 10.4.1.1 Parties Concepts.png

Table 10-17 Parties Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

hasPartyInRole

anything

has party in role

identifies a party acting in a specific role as related to the particular agreement, contract, policy, regulation, or other business relationship

 

has

 

party in role

 

Relationship Property

 

 

 

hasParty

anything

has party

identifies an independent party associated with an agreement, contract, policy, regulation, or other business arrangement

 

has

 

party

is a party to

Relationship Property

 

 

 

PartyInRole

party in role

 

A party-in-role defines is a relative concept that ties an independent party to a specific role they are standing in, for example, an organization member, issuer, owner, partner in a partnership, shareholder, etc., and is effective as of some date.

 

property restriction 02
agent in role
property restriction 01

 

 

 

Class

 

 

 

fibo-fnd-pty-pty-01

property restriction 01

 

Set of things that must have property "has identity" exactly 1 "party"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-pty-pty-02

property restriction 02

 

Set of things that must have property "has effective date" exactly 1 "dateTime"

 

 

 

 

 

Property Restriction

 

 

 

OrganizationMember

organization member

 

identifies an entity that has a membership role in some organization

 

party in role
property restriction 04

 

 

 

Class

 

 

 

fibo-fnd-pty-pty-04

property restriction 04

 

Set of things with property "has role" some "property restriction 03"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-pty-pty-03

property restriction 03

 

Set of things with property "is member of" only "organization"

 

 

 

 

 

Property Restriction

 

 

 

IndependentParty

party

 

An independent party is an independent person, organization or group that can enter into a contract or other legal proceeding.

 

 

 

 

 

Class

 

 

 

isAPartyTo

party

is a party to

identifies an agreement, contract, policy, regulation, or other business transaction that an independent party is associated with

 

 

 

anything

has party

Relationship Property

 

 

 

 

10.4.2 Ontology: Roles

This ontology defines some high-level concepts of roles for use in other FIBO ontology elements. These concepts include the basic property whereby something has some role, along with the high-level concept of an agent in a role. The agent in role concept provides the basis for party in role concepts in the PartyRoles ontology and is framed as some entity defined specifically in respect to some role which it performs in some context.

Figure 10.4.2.1 Roles Concepts

Figure 10.4.2.1 Roles Concepts.png

Table 10-19 Roles Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

hasRole

anything

has role

provides a means for relating a person, organization, group, or other entity to a role that entity plays in some relationship and context

 

has

 

role

 

Relationship Property

 

 

 

Role

role

 

A role is a set of connected behaviours, rights, obligations, beliefs, and norms as conceptualised by actors in the context of some situation.

 

 

 

 

 

Class

 

 

 

AgentInRole

agent in role

 

An agent-in-role is a relative concept that ties an autonomous agent to a role they are playing in a given situational context.

 

property restriction 02
property restriction 01

 

 

 

Class

 

 

 

fibo-fnd-pty-rl-01

property restriction 01

 

Set of things that must have property "has identity" exactly 1

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-pty-rl-02

property restriction 02

 

Set of things that must have property "has role" at least 1 taken from "role"

 

 

 

 

 

Property Restriction

 

 

 

 

 

10.5 Module: Agents and People

Table 10-20 Agents and People Module Metadata

Metadata Term

Value

sm:moduleName

Agents and People

sm:moduleAbbreviation

FIBO-FND-AAP

sm:moduleVersion

1.0

sm:moduleAbstract

This module contains ontologies of concepts relating to types of autonomous entity, that is things in the world which are able to determine their own behavior. Includes ontologies for people and for autononomous entities in general.

 

10.5.1 Ontology: Agents

This ontology defines the concept of autonomous agent for use in other FIBO ontology elements. As defined here, autonomous agent corresponds to what is often referred to as "agent" in software and other systems. It is defined as any entity which is able to act on its own part, and embraces all such things, including people, animals, software agents organizations and all forms of legal persons, although not all of these concepts are elaborated in FIBO as not all are relevant to financial services.

Figure 10.5.1.1 Agents Concepts

Figure 10.5.1.1 Agents Concepts.png

 

 

Table 10-22 Agents Details

Name

Type Of Thing

Property

Definition

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Definition Source

AutonomousAgent

autonomous agent

 

An agent is an autonomous individual that can adapt to and interact with its environment.

 

 

 

 

Class

 

fibo-fnd-aap-agt-01

property restriction 11.5.1-2

 

 

 

 

 

 

Other

 

fibo-fnd-aap-agt-02

property restriction 11.5.1-1

 

 

 

 

 

 

Other

 

 

10.5.2 Ontology: People

This ontology defines concepts for people and human related terms, for use in other FIBO ontology elements. People as defined here are human persons only. This ontology sets out a number of basic properties that are held by people or are definitive of a small number of specific types of people such as minors or adults. Primary use cases for determining the set of personal information definitions included are the common elements required to (1) open a bank account, (2) identify a sophisticated investor, and (3) establish foreign account ownership for money laundering purposes.

Figure 10.5.2.1 People Concepts

Figure 10.5.2.1 People Concepts.png

Table 10-24 People Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

Person

Person

 

A person; any member of the species homo sapiens.

 

property restriction 05
property restriction 06
property restriction 03
property restriction 04
property restriction 02
property restriction 01
property restriction 07
autonomous agent

 

 

 

Class

 

 

 

fibo-fnd-aap-ppl-01

property restriction 01

 

Set of things that must have property "has date of birth" exactly 1 taken from "dateTime"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-02

property restriction 02

 

Set of things that must have property "has gender" exactly 1 taken from "gender"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-03

property restriction 03

 

 Set of things that must have property "has" at least 1 taken from "postal address"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-04

property restriction 04

 

Set of things that must have property "has place of birth" exactly 1 taken from "string"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-05

property restriction 05

 

Set of things that must have property "has citizenship" at least 1 taken from "country"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-06

property restriction 06

 

Set of things that must have property "is identified by" at least 1 taken from "identity document"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-07

property restriction 07

 

Set of things that must have property "is identified by" at least 1 taken from "national identification number"

 

 

 

 

 

Property Restriction

 

 

 

hasSurname

Person

has surname

the patronymic or family name of a person

 

has person name

 

text

 

Simple Property

 

 

 

hasPlaceOfBirth

Person

has place of birth

links a person with their place of birth

 

 

 

text

 

Simple Property

 

 

 

hasPersonName

Person

has person name

links any sort of name to an individual person

 

has name

 

text

 

Simple Property

 

 

 

hasMiddleNameOrInitial

Person

has middle name or initial

 

 

has person name

 

text

 

Simple Property

 

 

 

hasMaidenName

Person

has maiden name

the patronymic or family name which a person was born with and which predates any changes of name due to marriage

 

has person name

 

text

 

Simple Property

 

 

 

hasLastName

Person

has last name

the patronymic or family name of a person

 

has person name

 

text

 

Simple Property

 

 

 

hasGivenName

Person

has given name

the given name or first name of a person, that is the name chosen for them at birth or changed by them subsequently from the name given at birth

 

has person name

 

text

 

Simple Property

 

 

 

hasGender

Person

has gender

links a particular gender value with a person

 

 

 

gender

 

Simple Property

 

 

 

hasFullLegalName

Person

has full legal name

the legally complete name of a person, as used in formal dealings of a legal or contractual nature

 

has person name

 

text

 

Simple Property

 

 

 

hasFirstName

Person

has first name

the given name or first name of a person, that is the name chosen for them at birth or changed by them subsequently from the name given at birth

 

has person name

 

text

 

Simple Property

 

 

 

hasFamilyName

Person

has family name

the patronymic or family name of a person

 

has person name

 

text

 

Simple Property

 

 

 

hasDateOfBirth

Person

has date of birth

links a person with their date of birth

 

 

 

xsd:dateTime

 

Simple Property

 

 

 

hasCitizenship

Person

has citizenship

links a person to their country of citizenship

 

has

 

country

 

Relationship Property

 

 

 

Passport

passport

 

A passport is a document, issued by a national government, which certifies the identity and nationality of its holder for the purpose of international travel. The elements of identity contained in all standardized passports include information about the holder, including name, date of birth, gender and place of birth.

 

identity document

 

 

 

Class

 

 

https://en.wikipedia.org/wiki/Passport

NationalIdentificationNumber

national identification number

 

A national identification number, national identity number, or national insurance number is used by the governments of many countries as a means of tracking their citizens, permanent residents, and temporary residents for the purposes of work, taxation, government benefits, health care, and other governmentally-related functions. The number will appear on an identity document issued by a country.  The ways in which such a system is implemented are dependent on the country, but in most cases, a citizen is issued an identification number at birth or when they reach a legal age (typically the age of 18). Non-citizens may be issued such numbers when they enter the country, or when granted a temporary or permanent residence permit.  Many countries issued such numbers ostensibly for a singular purpose, but over time, they become a de facto national identification number. For example, the United States originally developed its Social Security number system as a means of disbursing Social Security benefits. However, due to function creep, the number has become utilized for other purposes to the point where it is almost essential to have one to, among other things, open a bank account, obtain a credit card, or drive a car.

 

property restriction 14
property restriction 13
property restriction 15

 

 

 

Class

 

 

http://en.wikipedia.org/wiki/Nationa...ication_number

fibo-fnd-aap-ppl-13

property restriction 13

 

Set of things that must have property "identifies" exactly 1 taken from "person"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-14

property restriction 14

 

Set of things that must have property "is issued by" exactly 1 taken from "formal organization"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-15

property restriction 15

 

Set of things that must have property "has unique identifier" exactly 1 taken from "literal"

 

 

 

 

 

Property Restriction

 

 

 

Minor

minor

 

In law, a minor is a person under a certain age, usually the age of majority, which legally demarcates childhood from adulthood. The age depends upon jurisdiction and application, but is generally 18.

 

Person

 

 

 

Class

 

 

https://en.wikipedia.org/wiki/Minor_(law)

IncapacitatedAdult

incapacitated adult

 

Individuals may have an inherent physical condition which prevents them from achieving the normal levels of performance expected from persons of comparable age, or their inability to match current levels of performance may be caused by contracting an illness. Whatever the cause, if the resulting condition is such that individuals cannot care for themselves, or may act in ways that are against their interests, those persons are vulnerable through dependency and require the protection of the state against the risks of abuse or exploitation. Hence, any agreements that were made are voidable, and a court may declare that person a ward of the state and grant power of attorney to an appointed legal guardian.

 

adult

 

 

 

Class

 

 

https://en.wikipedia.org/wiki/Capacity_(law)

IdentityDocument

identity document

 

An identity document is any document which may be used to verify aspects of a person's personal identity. If issued in the form of a small, mostly standard-sized card, it is usually called an identity card (IC). Countries which do not have formal identity documents may require informal documents.  In the absence of a formal identity document, driving licences can be used in many countries as a method of proof of identity, although some countries do not accept driving licences for identification, often because in those countries they don't expire as documents and can be old and easily forged. Most countries accept passports as a form of identification.  Most countries have the rule that foreign citizens need to have their passport or occasionally a national identity card from their country available at any time if they do not have residence permit in the country.

 

property restriction 12
property restriction 10
property restriction 11
property restriction 08
property restriction 09

 

 

 

Class

 

 

https://en.wikipedia.org/wiki/Identification_card

fibo-fnd-aap-ppl-08

property restriction 08

 

Set of things that must have property "identifies" exactly 1 taken from "person"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-09

property restriction 09

 

Set of things that must have property "is issued by" exactly 1 taken from "formal organization"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-10

property restriction 10

 

Set of things that must have property "has expiration date" exactly 1 taken from "dateTime"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-11

property restriction 11

 

Set of things that must have property "has unique identifier" exactly 1 taken from "literal"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-aap-ppl-12

property restriction 12

 

Set of things that must have property "has date of issuance" exactly 1 taken from "dateTime"

 

 

 

 

 

Property Restriction

 

 

 

EmancipatedMinor

emancipated minor

 

An emancipated minor is a minor who is allowed to conduct a business or any other occupation on his or her own behalf or for their own account outside the influence of a parent or guardian. The minor will then have full contractual capacity to conclude contracts with regard to the business. Whether parental consent is needed to achieve emancipated status varies from case to case. In some cases, court permission is necessary. Protocols vary by jurisdiction.

 

minor

 

 

 

Class

 

 

https://en.wikipedia.org/wiki/Emancipated_minor

DriversLicense

driver's license

 

A driver's license or driving licence is an official document which states that a person may operate a motorized vehicle, such as a motorcycle, car, truck or a bus, on a public roadway.

 

identity document

 

 

 

Class

 

 

https://en.wikipedia.org/wiki/Non-dr...fication_cards

BirthCertificate

birth certificate

 

A birth certificate is a vital record that documents the birth of a child.  The term, birth certificate, can refer to either the original document certifying the circumstances of the birth or to a certified copy of or representation of the ensuing registration of that birth. Depending on the jurisdiction, a record of birth might or might not contain verification of the event by such as a midwife or doctor.

 

identity document

 

 

 

Class

 

 

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

Adult

adult

 

Biologically, an adult is a human being or other organism that is of reproductive age (sexual maturity). In human context, the term adult additionally has meanings associated with social and legal concepts; for example, a legal adult is a legal concept for a person who has attained the age of majority and is therefore regarded as independent, self-sufficient, and responsible (contrast with minor). In addition, human adulthood encompasses psychological adult development.

 

Person

 

 

 

Class

 

 

https://en.wikipedia.org/wiki/Adult

 

 

10.6 Module: Places

Table 10-25 Places Module Metadata

Metadata Term

Value

sm:moduleName

Places

sm:moduleAbbreviation

FIBO-FND-PLC

sm:moduleVersion

1.0

sm:moduleAbstract

This module includes ontologies defining concepts to do with real or virtual places and the addresses to such places.  Note that most of these terms are proxies for terms which exist or which are expected to be published in the future in formal ontologies for those concepts (e.g. geophysical, geopolitical, as well as the address components in physical standards like VCard).

 

10.6.1 Ontology: Locations

This ontology provides a placeholder for use in mapping geographic location-oriented concepts to the appropriate standards.

Figure 10.6.1.1 Locations Concepts

Figure 10.6.1.1 Locations Concepts.png

Table 10-26 Locations Ontology Metadata

Metadata Term

Value

sm:filename

Locations Ontology

sm:fileAbbreviation

fibo-fnd-plc-loc

OntologyIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ces/Locations/

owl:versionIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ces/Locations/

sm:dependsOn

http://www.omg.org/spec/EDMC-FIBO/FND/Utilities/AnnotationVocabulary/

 

Table 10-27 Locations Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

RealEstate

real estate

 

Land plus anything permanently fixed to it, including buildings, sheds and other items attached to the structure. Although, media often refers to the "real estate market" from the perspective of residential living, real estate can be grouped into three broad categories based on its use, namely residential, commercial and industrial. Examples of real estate include undeveloped land, houses, condominiums, townhomes, office buildings, retail store buildings and factories.

 

physical location

 

 

 

Class

 

 

http://www.investopedia.com/terms/r/realestate.asp

PhysicalLocation

physical location

 

A location in physical space

 

location

 

 

 

Class

 

 

 

Location

location

 

Anything that can be defined as the answer to a question of the form, Where is...?

 

 

 

 

 

Class

 

 

 

 

 

10.6.2 Ontology: Countries

This ontology provides a very high level definition of country related concepts, essentially a placeholder for use in mapping countries and intra-country concepts to the appropriate regional standards or to some as yet undefined global address ontology, for use in other FIBO ontology elements. A minimal set of geopolitical and geophysical terms are included as required for financial risk management and other application use cases, and these are all to be considered as placeholders for suitable standard ontologies for these concepts as these become available. These terms may also be mapped to controlled vocabulary standards such as ISO 3166.

Figure 10.6.2.1 Countries Concepts

Figure 10.6.2.1 Countries Concepts.png

Table 10-28 Countries Ontology Metadata

Metadata Term

Value

sm:filename

Countries Ontology

sm:fileAbbreviation

fibo-fnd-plc-cty

OntologyIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ces/Countries/

owl:versionIRI

http://www.omg.org/spec/EDMC-FIBO/FN...ces/Countries/

sm:dependsOn

http://www.omg.org/spec/EDMC-FIBO/FND/Utilities/AnnotationVocabulary/

http://www.omg.org/spec/EDMC-FIBO/FND/Places/Locations/

 

Table 10-29 Countries Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

UrbanCenter

urban center

 

a large and densely populated urban area

 

physical location

 

 

 

Class

 

 

http://www.thefreedictionary.com/urban+center

GeopoliticalEntity

geopolitical entity

 

Any country, federal province, city or other entity which is both geographical and political in its identity.

 

physical location

 

 

 

Class

 

 

 

FederalState

federal state

 

A self-governing geopolitical entity which forms part of a wider geopolitical entity recognized as a country. This type of entity, variously referred to as a state, province or canton, has a level of self government including its own legal system and court jurisdiction, but cedes a level of autonomy to the federation of which it forms a part.

 

geopolitical entity

 

 

 

Class

 

 

 

FederalCapitalArea

federal capital administrative area

 

The capital administrative region of a country which is a federation, if the physical area of this region does not form a part of any of the states or pronvinces which make up the federal country.

 

geopolitical entity

 

 

 

Class

 

 

 

Country

country

 

A self-governing geopolitical entity that is recognized as a country by the United Nations

 

geopolitical entity

 

 

 

Class

 

 

 

 

10.6.3 Ontology: Addresses

This ontology provides a very high level definition of address, essentially a placeholder for use in mapping addresses to the appropriate regional standards or to some as yet undefined global address ontology, for use in other FIBO ontology elements. A minimal set of address related terms are included as required for financial risk management and other application use cases, and these are all to be considered as placeholders for suitable global address standards as these become available.

Figure 10.6.3.1 Addresses Concepts

Figure 10.6.3.1 Addresses Concepts.png

Table 10-31 Addresses Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

PostalAddress

postal address

 

A physical and postal address where communications can be addressed, papers served or representatives located for any kind of business or legal entity

 

property restriction 03
address

 

 

 

Class

There are existing international and regional standards for defining postal addresses.  This is a place holder for mapping to regional standards for postal address representation

 

 

fibo-fnd-plc-adr-03

property restriction 03

 

Set of things that must have property "identifies" exactly 1 taken from "physical location"

 

 

 

 

 

Property Restriction

 

 

 

hasStreetAddress

postal address

has street address

Address element giving the building name or number and the street in which the address is situated.

 

has address component

 

address element

 

Simple Property

 

 

 

hasStateName

postal address

has state name

Address element giving the name of the state or province (in federal countries) in which the address is situated.

 

has address component

 

address element

 

Simple Property

 

 

 

hasPostalCode

postal address

has postal code

The postal code for an address, in a format recognized by the postal authorities in the country in which the address is situated.

 

has address component

 

address element

 

Simple Property

 

 

 

hasPOBox

postal address

has post office box

Address element giving the Post Office Box number in the form of digits or letters plus digits.

 

has address component

 

address element

 

Simple Property

 

 

 

hasLocality

postal address

has locality

That part of a written address which uniquely references some town, city or other urban area within the overall address.

 

has address component

 

address element

 

Simple Property

 

 

 

hasCountryName

postal address

has country name

The name of the country in which the address is situated, in some format which may be recognized in that or other countries.

 

has address component

 

address element

 

Simple Property

 

 

 

StateAbbreviation

postal address

state abbreviation

Address element giving the formal abbreviation of the state or province (in federal countries) in which the address is situated.

 

has address component

 

address element

 

Simple Property

 

 

 

PostCodeArea

post code area

 

The physical area uniquely identified by some postal code.

 

physical location

 

 

 

Class

 

 

 

Address

address

 

An index to a location to which communications may be delivered

 

property restriction 02
property restriction 01

 

 

 

Class

This came from FDTF Address Reviews Aug/Sept 2011. It represents a place holder for mapping to other standards, such as those for email, network, and other electronic addresses as well as physical and mailing addresses.

 

 

hasAddressComponent

address

has address component

The postal address has as part of it some distinct textual element which performs some distinct function within the overall address such as referring to some specific physical place, built property feature or post office box.

 

 

 

address element

 

Simple Property

 

 

 

fibo-fnd-plc-adr-01

property restriction 01

 

Set of things that may have property "has address component" taken from "address element"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-plc-adr-02

property restriction 02

 

Set of things that must have property "identifies" exactly 1 taken from "location"

 

 

 

 

 

Property Restriction

 

 

 

10.7 Module: Organizations

Table 10-32 Organizations Module Metadata

Metadata Term

Value

sm:moduleName

Organizations

sm:moduleAbbreviation

FIBO-FND-ORG

sm:moduleVersion

1.0

sm:moduleAbstract

This module includes several ontologies defining organizations, features of an organization and different types of organization. These include formal versus informal organizations, legitimate and illicit organizations and so on.  They are purposefully underspecified to facilitate mapping to specific organization ontologies, such as the emerging W3C organization and formal organization ontologies, organization from a BMM or BPMN perspective, organization from a records management (RMS) perspective, and so forth.

 

10.7.1 Ontology: Organizations

This ontology defines high-level concepts for organizations and related terms, for use in other FIBO ontology elements.  It is purposefully underspecified to facilitate mapping to specific organization ontologies, such as the emerging W3C organization ontology, organization from a BMM or BPMN perspective, organization from a records management (RMS) perspective, and so forth.

Figure 10.7.1.1 Organizations Concepts

Figure 10.7.1.1 Organizations Concepts.png

Table 10-34 Organizations Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

Organization

organization

 

A social unit of people, systematically structured and managed to meet a need or pursue collective goals on a continuing basis.

 

property restriction 04
autonomous agent
property restriction 01
property restriction 03
property restriction 02

 

 

 

Class

 

 

http://www.BusinessDictionary.com/

fibo-fnd-org-org-04

property restriction 04

 

Set of things that may have property "has" taken from "postal address"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-org-org-03

property restriction 03

 

Set of things that must have property "has" at least 1 taken from "goal"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-org-org-02

property restriction 02

 

Set of things that may have property "has part" taken from "organization"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-org-org-01

property restriction 01

 

Set of things that must have property "has member" at least 2 taken from "autonomous agent"

 

 

 

 

 

Property Restriction

 

 

 

 

10.7.2 Ontology: Formal Organizations

This ontology defines the high level concept of formal organization for use in other FIBO ontology elements.  It is purposefully underspecified to facilitate mapping to other formal organization ontologies, such as the emerging W3C formal organization ontology, or others defined for specific business and financial services standards. The concepts in this ontology extend those in the Organizations ontology.

Figure 10.7.2.1 Formal Organizations Concepts

Figure 10.7.2.1 Formal Organizations Concepts.png

Table 10-36 Formal Organizations Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

InformalOrganization

informal organization

 

An organization which is not formally constituted in some way.

 

organization

formal organization

 

 

Class

 

 

 

Group

group

 

A group of autonomous entities

 

property restriction 01

 

 

 

Class

 

 

 

fibo-fnd-org-fm-01

property restriction 01

 

Set of things with property "has member" only "autonomous agent"

 

 

 

 

 

Property Restriction

 

 

 

FormalOrganization

formal organization

 

Any organization some formal contractual standing, and with which another such organization may transact business or engage in some activity.

 

organization

informal organization

 

 

Class

W3C Definition - An Organization which is recognized in the world at large, in particular in legal jurisdictions, with associated rights and responsibilities. Examples include a Corporation, Charity, Government or Church.

 

 

 

10.7.3 Ontology: Legitimate Organizations

This ontology defines the concepts of legitimate and illicit organizations for use in other FIBO ontology elements. These distinctions are provided in order to facilitate modeling of concepts relevant to money laundering. Legitimate organizations such as clubs are defined. These, along with the distinctions of formal versus informal organizations, provide the universe of possible kinds of organizations which may perform specific roles such as holding shares, having control of assets of companies and so on.

Figure 10.7.3.1 Legitimate and Illicit Organizations Concepts

Figure 10.7.3.1 Legitimate and Illicit Organizations Concepts.png

Table 10-38 Legitimate and Illicit Organizations Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

LegitimateOrganization

legitimate organization

 

An organization that exists to serve some lawful purpose

 

organization

illegal organization

 

 

Class

 

 

 

IllegalOrganization

illegal organization

 

A kind of organization which has been set up specifically to perform illegal acts or has become such

 

organization

legitimate organization

 

 

Class

 

This is not to do with performing illicit acts.  We can narrow down on a definition for Illicit Organization - one which has been set up specifically to perform illicit acts or has become such. This relates to the purpose of the organization, and the purposes of the entities which control that entity. And the acts which the entity may perform.   (definition adopted from the above note, with Illicit changed to Illegal for clarity).   Typically, a money laundering entity may perform (will perform) legal acts and is explicitly set up for such, but will also perform illicit acts.   The definition of illicit is framed entirely with respect to law and not morality.

 

IllegalCartel

illegal cartel

 

A collection of companies that come together to manipulate the market in some way, e.g. price fixing

 

property restriction 01
illegal organization

 

 

 

Class

 

 

 

fibo-fnd-org-lg-01

property restriction 01

 

Set of things with property "has member" only "formal organization"

 

 

 

 

 

Property Restriction

 

 

 

CrimeSyndicate

crime syndicate

 

An informal grouping formed for the purposes of organized criminal activities

 

illegal organization

 

 

 

Class

 

 

 

Club

club

 

An informal organization formed to pursue some common interest among its members

 

legitimate organization

 

 

 

Class

 

 

 

 

 

 

10.8 Module: Agreements

Table 10-39 Agreements Module Metadata

Metadata Term

Value

sm:moduleName

Agreements

sm:moduleAbbreviation

FIBO-FND-AGR

sm:moduleVersion

1.0

sm:moduleAbstract

This module includes ontologies describing agreements between parties and contracts that formalize those agreements.  These cover written and verbal contracts, including contracts which may be transferred from one party to another. The latter form the basis for financial securities contracts.  The Contracts ontology also describes fundamental properties of contracts such as contractual terms, contract parties and so on, many of which form the basis for more specialized financial industry concepts such as interest payment terms, bond issuers and so on.

 

10.8.1 Ontology: Agreements

This ontology defines concepts for agreements, for use in other ontology elements. Agreements as defined here are the actual agreements between parties, and this ontology is intended to be referred to in conjunction with the contracts ontology which defines the actual contracts which formalize such agreements. The concepts of agreement and contract are intended to be kept distinct in the FIBO ontologies, that is neither is intended to be regarded as a sub type of the other.

Figure 10.8.1.1 Agreements Concepts

Figure 10.8.1.1 Agreements Concepts.png

Table 10-41 Agreements Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

UnilateralCommitment

unilateral commitment

 

A commitment made by one party without reference to the party to which the commitment is made.

 

commitment

 

 

 

Class

 

 

 

MutualCommitment

mutual commitment

 

A commitment between two or more parties

 

commitment

 

 

 

Class

 

 

 

MultilateralAgreement

multilateral agreement

 

An agreement between three or more parties

 

agreement
property restriction 03

 

 

 

Class

 

 

 

fibo-fnd-agr-agr-03

property restriction 03

 

Set of things that must have property "has party in role" at least 3 taken from "party in role"

 

 

 

 

 

Property Restriction

 

 

 

Commitment

commitment

 

A legal construct which represents the undertaking on the part of some party to act or refrain from acting in some manner.

 

 

 

 

 

Class

The undertaking by some party to act or refrain from acting results in an obligation on the part of that party, and usually results in the existence of some corresponding right on the party of some other party, in the event that the commitment is to such party. Thus Obligations and Rights are considered as reciprocal aspects of this Commitment concept.

 

 

BilateralAgreement

bilateral agreement

 

An agreement between two parties

 

property restriction 04
agreement

 

 

 

Class

 

 

 

fibo-fnd-agr-agr-04

property restriction 04

 

Set of things that must have property "has party in role" exactly 2 taken from "party in role"

 

 

 

 

 

Property Restriction

 

 

 

Agreement

agreement

 

(1) A negotiated and usually legally enforceable understanding between two or more legally competent parties.  Although a binding contract can (and often does) result from an agreement, an agreement typically documents the give-and-take of a negotiated settlement and a contract specifies the minimum acceptable standard of performance.
(2) An agreement provides language that defines the terms and conditions of a legally binding contract among the identified parties, ordinarily leading to a contract.

 

property restriction 01
property restriction 02

 

 

 

Class

 

Some mutual undertaking or set of undertakings between two or among several parties.
An agreement may be formalized in the form of a Contract or other formal instrument, or it may not. In either case, the agreement is that which may be referred to as the agreement between or among the parties, and the contract is framed as defining (and usually as exclusively defining) the agreement between two parties.

(2) OMG Property and Casualty Information Models, dtc/12-01-04, Annex A, Glossary of Data Model Terms and Definitions
(1) http://www.businessdictionary.com/de...agreement.html

fibo-fnd-agr-agr-01

property restriction 01

 

Set of things that may have property "confers" taken from "mutual commitment"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-agr-agr-02

property restriction 02

 

Set of things that must have property "has party in role" at least 2 taken from "party in role"

 

 

 

 

 

Property Restriction

 

 

 

 

10.8.2 Ontology: Contracts

This ontology defines concepts relating to contracts, for use in other FIBO ontology elements. These include written contracts which are the concrete evidence of agreements between parties, along with verbal contracts. Contracts are further broken down into bilateral and transferable contracts, the latter being the basis for most financial instruments. Properties of contracts are also defined, in particular contractual terms and contract parties. These concepts all form the basis of concepts in the financial services industry, for example interest payment terms are a kind of contract terms set, and security holders are a kind of contract counterparty.

Figure 10.8.2.1 Contracts Concepts

Figure 10.8.2.1 Contracts Concepts.png

Table 10-43 Contracts Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing orType

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

isAssignable

anything

 

indicates whether the contract and the rights thereunder may be assigned by one of the signatories to some other party

 

 

 

yes or no

 

Simple Property

 

 

 

WrittenContract

written contract

 

A formal Contract which is written and signed by both parties thereto.

 

contract

verbal contract

 

 

Class

 

 

 

supersedes

written contract

supersedes

The or any earlier contract which this written contract supersedes, whether that earlier contract is written or verbal or implied.

 

 

 

contract

 

Relationship Property

 

 

 

VerbalContract

verbal contract

 

A contract which exists as a result of some verbal exchange.

 

contract

written contract

 

 

Class

 

 

 

TransferableContractHolder

transferable contract holder

 

The party which holds a transferable contract and enjoys the benefits defined in that contract while they hold it.

 

contract counterparty

 

 

 

Class

This party may transfer the contract to another party without reference to the issuer, for example by selling it in some marketplace.

 

 

TransferableContract

transferable contract

 

An assignment (Latin cessio) is a term used with similar meanings in the law of contracts and in the law of real estate. In both instances, it encompasses the transfer of rights held by one party, the assignor, to another party, the assignee. The details of the assignment determines some additional rights and liabilities (or duties). Typically a third-party is involved in a contract with the assignor, and the contract is in effect transferred to the assignee.

property restriction 06

property restriction 07
written contract

 

 

 

Class

 

 

http://en.wikipedia.org/wiki/Assignment_(law)

fibo-fnd-agr-ctr-06

property restriction 06

 

Set of things that must have property "has principal" at least 1 taken from "contract originator"

transferable contract

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-agr-ctr-07

property restriction 07

 

Set of things that must have property "has counterparty" at least 1 taken from "transferable contract holder"

 

 

 

 

 

Property Restriction

 

 

 

PromissoryNote

promissory note

 

A promissory note is a written, signed, unconditional, and unsecured promise by one party (the maker or promisor) to another (the payee or promisee) that commits the maker to pay a specified sum on demand, or on a fixed or a determinable date. Promissory notes (such as bank or currency notes) are negotiable instruments.

 

written contract

 

 

 

Class

Unlike a contract, a Promissory Note does not need to be signed by both parties. It is essentiually a promise from one party to the holder, of some good or benefit. Promissory notes would generally by fully fungible. These are modeled as a kind of contract but are essentially a kind of unilateral contract between the issuer and the holder, and some authorities might not see this as a contract at all. Cash is a kind of promissory note, with the issuer being a central bank.

 

 http://www.businessdictionary.com/de...sory-note.html

NonBindingTermsSet

non-binding terms set

 

Terms which do not have binding legal standing on the Issuer or Holder.

 

contract terms set

 

 

 

Class

 

 

 

ContractualRelationship

contractual relationship

 

A contractual relationship is evidenced by (1) an offer, (2) acceptance of the offer, and a (3) valid (legal and valuable) consideration. Each party to a contract acquires rights and duties relative to the rights and duties of the other parties. However, while all parties may expect a fair benefit from the contract (otherwise courts may set it aside as inequitable) it does not follow that each party will benefit to an equal extent. Existence of contractual-relationship does not necessarily mean the contract is enforceable, or that it is not void (see void contract) or voidable (see voidable Contract).

 

 

 

 

 

Class

 

 

 http://www.businessdictionary.com/de.../contract.html

ContractualElement

contractual element

 

Anything which relates to contracts.

 

 

 

 

 

Class

The concept "contractual element" does not exist in any dictionary I could find. Can we change this to ContractElement? (efk)

 

 

ContractualDefinition

contractual definition

 

The definition of something in some contract or other legal instrument.

 

contractual element

 

 

 

Class

These are agreed definitions which are then referred to in terms in contracts or other legal instruments.
The concept "contractual definition" does not exist in any dictionary I could find. Can we change this to ContractTermOrDefinition? (efk)

 

 

ContractThirdParty

contract third party

 

Someone who may be indirectly involved but is not a principal party to an arrangement, contract, deal, lawsuit, or transaction.

 

party in role

 

 

 

Class

The concept "contract third party" does not exist in any dictionary I could find, however "third-party" does, and could be used for this purpose. Can we change this to ThirdParty? (efk)

 

 http://www.businessdictionary.com/de...ird-party.html

ContractTermsSet

contract terms set

 

The conditions of a contract include the terms and conditions that set the rights and obligations of the contracting parties when a contract is awarded or entered into.  These include general conditions which are common to all types of contracts, such as general and special arrangements, provisions, requirements, rules, specifications, and standards that form an integral part of an agreement or contract, as well as special conditions which are peculiar to a specific contract (such as, contract change conditions, payment conditions, price variation clauses, penalties).

 

property restriction 01
contractual element

 

 

 

Class

The concept "contract terms set" does not exist in any dictionary I could find, however "terms and conditions" does, and could be used for this purpose. Can we change this to TermsAndConditions? If TermsAndConditions have parts, I would suggest creating a class called TermOrCondition, which would then provide the range for hasPart, and which could be specialized for various kinds of clauses, as appropriate.(efk)

 

 http://www.businessdictionary.com/de...-contract.html
 http://www.businessdictionary.com/de...onditions.html

fibo-fnd-agr-ctr-01

property restriction 01

 

Set of things with property "has part" only "contract terms set"

 

 

 

 

 

Property Restriction

 

 

 

ContractPrincipal

contract principal

 

The party identified as being the principal or first party to a contract, in the event that the contract distinguishes any party as the principal. In law, the principal is the party that has the primary responsibility in a liability or obligation, as opposed to an endorser, guarantor, or surety.

 

party in role

 

 

 

Class

 

 

 http://www.businessdictionary.com/de...principal.html

ContractOriginator

contract originator

 

The party which originates the transferable contract and acts as the Principal in that contract regardless of the owner or counterparty.

 

contract principal

 

 

 

Class

 

 

 

ContractCounterparty

contract counterparty

 

A counterparty is the other party that participates in a financial transaction.  Every transaction must have a counterparty in order for the transaction to go through. More specifically, every buyer of an asset must be paired up with a seller that is willing to sell and vice versa.

 

party in role

 

 

 

Class

This term in Investopedia is named "counterparty" not "contract counterparty". Can we simplify this to "counterparty"? (efk)

 

 http://www.investopedia.com/terms/c/counterparty.asp

Contract

contract

 

A voluntary, deliberate, and legally binding agreement between two or more competent parties. Contracts are usually written but may be spoken or implied, and generally have to do with employment, sale or lease, or tenancy.

 

property restriction 04
 property restriction 03
property restriction 02

 

 

 

Class

 

 

 http://www.businessdictionary.com/de.../contract.html

fibo-fnd-agr-ctr-02

property restriction 02

 

Set of things that must have property "has party in role" at least 2 taken from "party in role"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-agr-ctr-03

 property restriction 03

 

Set of things that must have property "has effective date" exactly 1 taken from "dateTime"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-agr-ctr-04

property restriction 04

 

Set of things that must have property "is assignable" exactly 1 taken from "yes or no"

 

 

 

 

 

Property Restriction

 

 

 

hasThirdParty

contract

has third party

identifies a party which is not signatory to the party but has some role in the overall context defined by the contract.

 

has party in role

 

contract third party

 

Relationship Property

 

 

 

hasTerms

contract

has terms

identifies a set of terms that form part of the contract. These are generally grouped for convenience as definitions, such as debt repayment terms, and may or may not equate to a formal clause, section, paragraph or other textual construct of the contract.

 

has

 

contract terms set

 

Relationship Property

 

 

 

hasPrincipal

contract

has principal

identifies the main or principal party to a contract

 

has party in role

 

contract principal

 

Relationship Property

 

 

 

hasNonBindingTerms

contract

has non-binding terms

refers to terms that are included in the contract but are not considered binding. In other words, a breach of such terms in the future would not be considered to be a breach of the contract.

 

has terms

 

non-binding terms set

 

Relationship Property

 

 

 

hasGoverningJurisdiction

contract

has governing jurisdiction

identifies the jurisdiction governing the contract, as agreed by all parties. In a written contract this is generally identified, for example, as Governing Law, namely the jurisdiction in which any disputes arising from the contract are to be resolved.

 

is governed by

 

jurisdiction

 

Relationship Property

As modeled, this relationship combines two slightly different senses in which a Jurisdiction may be named in some Contract: the jurisdiction under whose laws the contract is deemed to be in force, and the jurisdiction under which the parties agree to submit in the event of any dispute resolution. Scope Note: One thing to tease out is whether "Dispute Resolution" and other forms of "Governing Law" are one and the same thing or not. Dispute Resolution is uncontroversial, the question is whether there are other implications to Governing Law or if it's the same thing. For instance I may undertake to behave as though I were responsible to a particular authority i.e. a particular set of statutes.

 

 

hasCounterparty

contract

has counterparty

identifies a counterparty to a contract

 

has party in role

 

contract counterparty

 

Relationship Property

 

 

 

definesTermsFor

contract

defines terms for

the contract sets out the terms for the something

 

 

 

anything

 

Relationship Property

 

 

 

ConditionsPrecedent

conditions precedent

 

Conditions precedent on some obligation. These are conditions which would alter the Obligation as it is otherwise stated.

 

contract terms set

 

 

 

Class

Introduced for ISDA Master Agreement. It is likely that the Conditions Precedent defined for OTC Derivatives Master Agreements are actually applicable more widely. However, they are defined within the ISDA terms for now. Modeling note / review question: Modeled as a kind of Terms Set, combining terms and conditions. Should consider whether terms and conditions are distinct (Condition would then be a separate archetype).

 

 

BilateralContract

bilateral contract

 

A contract between two specific named parties. The rights and obligations pertaining to either party cannot be transferred to another party without prior written permission or a change to the contract itself.

 

property restriction 05
contract

 

 

 

Class

 

 

 

fibo-fnd-agr-ctr-05

property restriction 05

 

Set of things that must have property "has party in role" exactly 2 taken from "party in role"

 

 

 

 

 

Property Restriction

 

 

 

 

 

10.9 Module: Law

Table 10-44 Law Module Metadata

Metadata Term

Value

sm:moduleName

Law

sm:moduleAbbreviation

FIBO-FND-LAW

sm:moduleVersion

1.0

sm:moduleAbstract

This module includes several ontologies defining legal concepts, including constitutions, laws and jurisdictions. It also includes the definition of legal capacities such as signatory capacity, contractual capability and the like.

 

 10.9.1 Ontology: Legal Core

This ontology defines high-level legal concepts for use in other FIBO ontology elements. These concepts include law and constitution, both of which are framed at a more abstract level than national or state laws and constitutions, so that law forms the basis both for statutes and for company by-laws, and constitution forms the basis both for national or state constitutions and for instruments which are constitutive of incorporated legal entities. This ontology also defines some of the variants of these such as governmental constitutions and ordinances. Other types of law are provided in the Jurisdictions ontology as extensions of concepts in this ontology. Court of Law is also defined here.

Figure 10.9.1.1  Legal Core Concepts

Figure 10.9.1.1 Legal Core Concepts.png

 

 

Table 10-46 Legal Core Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

Ordinance

ordinance

 

An authoritative rule or law; a decree or command; a public injunction or regulation, such as a city ordinance against excessive horn blowing. (Source: Dictionary.com)

 

law

 

 

 

Class

 

 

 

Law

law

 

Law is a term which does not have a universally accepted definition, but one definition is that law is a system of rules and guidelines which are enforced through social institutions to govern behavior. Laws are made by governments, specifically by their legislatures.  The formation of laws themselves may be influenced by a constitution (written or unwritten) and the rights encoded therein.  The law shapes politics, economics and society in countless ways and serves as a social mediator of relations between people.

 

 

 

 

 

Class

Any law or body of law, which may have force in some context, including national laws, company bylaws and the like.

 

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

GovernmentalConstitution

governmental constitution

 

Most commonly, the term constitution refers to a set of rules and principles that define the nature and extent of government.  Most constitutions seek to regulate the relationship between institutions of the state, in a basic sense the relationship between the executive, legislature and the judiciary, but also the relationship of institutions within those branches.  For example, executive branches can be divided into a head of government, government departments/ministries, executive agencies and a civil service/administration.  Most constitutions also attempt to define the relationship between individuals and the state, and to establish the broad rights of individual citizens. It is thus the most basic law of a territory from which all the other laws and rules are hierarchically derived; in some territories it is in fact called Basic Law.

 

constitution

 

 

 

Class

This defines the framework in which laws are made and in which they have force.

 

http://en.wikipedia.org/wiki/Constit..._constitutions

CourtOfLaw

court of law

 

A court of law is a court that hears cases and decides them on the basis of statutes or the common law.

 

formal organization

 

 

 

Class

 

 

Merriam-Webster Online Dictionary

Constitution

constitution

 

A constitution defines the basic principles and laws of a nation, state, or social group that determine the powers and duties of the government and guarantee certain rights to the people in it.

 

property restriction 01

 

 

 

Class

This defines the framework in which laws (for a country constitution), rules and regulations (for a party or organization constitution) or contractual commitments are made and in which they have force.

 

Merriam-Webster Online Dictionary

fibo-fnd-law-cor-01

property restriction 01

 

Set of things with property "governs" only "law"

 

 

 

 

 

Property Restriction

 

 

 

 

10.9.2 Ontology: Jurisdiction

This ontology defines high level concepts relating to jurisdictions for use in other FIBO ontology elements. This includes a general definition of jurisdiction along with some basic types of jurisdiction, along with the factors which distinguish one type of jurisdiction from another. This ontology also defines basic types of legal system, and extends the basic concept of law which is in the LegalCore ontology.

Figure 10.9.2.1 Jurisdiction Concepts

Figure 10.9.2.1 Jurisdiction Concepts.jpg

Table 10-48 Jurisdiction Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

appliesIn

anything

applies in

indicates the jurisdiction in which a particular legal system applies

 

governs

 

anything

 

Relationship Property

 

 

 

StatuteLaw

statute law

 

Statutory law or statute law is written law (as opposed to oral or customary law) set down by a legislature (as opposed to regulatory law promulgated by the executive or common law of the judiciary) or by a legislator (in the case of an absolute monarchy). Statutes may originate with national, state legislatures or local municipalities. Statutory laws are subordinate to the higher constitutional laws of the land.

 

Law
property restriction 09

 

 

 

Class

 

 

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

fibo-fnd-law-jur-09

property restriction 09

 

Set of things with property "is in force in" only "jurisdiction"

 

 

 

 

 

Property Restriction

 

 

 

LegalSystem

legal system

 

The contemporary legal systems of the world are generally based on one of three basic systems: civil law, common law, and religious law, or combinations of these. However, the legal system of each country is shaped by its unique history and so incorporates individual variations.
a system of law

 

property restriction 03
property restriction 04

 

 

 

Class

This is a Mediating Thing, that is some context in which things have their meaning and existence - in this case, laws and the interpretation thereof by courts.

 

http://en.wikipedia.org/wiki/Legal_s...s_of_the_world

fibo-fnd-law-jur-03

property restriction 03

 

Set of things with property "applies in" only "jurisdiction"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-law-jur-04

property restriction 04

 

Set of things with property "is governed by" only "governmental constitution"

 

 

 

 

 

Property Restriction

 

 

 

Jurisdiction

jurisdiction

 

the limits or territory within which authority may be exercised; the power, right, or authority to interpret and apply the law

 

property restriction 02
property restriction 01

 

 

 

Class

 

 

Merriam-Webster Online Dictionary

fibo-fnd-law-jur-01

property restriction 01

 

Set of things with property "has reach" some "geopolitical entity"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-law-jur-02

property restriction 02

 

Set of things with property "is governed by" only "legal system"

 

 

 

 

 

Property Restriction

 

 

 

 

jurisdiction

has reach

indicates the geopolitical entity (country, federal province or municipality) in which the jurisdiction has effect

 

 

 

geopolitical entity

 

Relationship Property

 

 

 

CommonLawSystem

common law system

 

Common law, also known as case law or precedent, is law developed by judges through decisions of courts and similar tribunals.  By contrast, civil law (codified/continental law) is set on statutes adopted through the legislative/parliamentary process and/or regulations issued by the executive branch on base of the parliamentary statutes.  A common law system is a legal system that gives great potential precedential weight to common law, on the principle that it is unfair to treat similar facts differently on different occasions. The body of precedent is called common law and it binds future decisions. In cases where the parties disagree on what the law is, a common law court looks to past precedential decisions of relevant courts. If a similar dispute has been resolved in the past, the court is bound to follow the reasoning used in the prior decision (this principle is known as stare decisis). If, however, the court finds that the current dispute is fundamentally distinct from all previous cases (called a matter of first impression), judges have the authority and duty to make law by creating precedent. Thereafter, the new decision becomes precedent, and will bind future courts.

 

legal system
property restriction 06

 

 

 

Class

A jurisdiction which is based in Common Law will also have alongside a legislature that passes statutes.

 

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

fibo-fnd-law-jur-06

property restriction 06

 

Set of things with property "applies in" some "common law jurisdiction"

 

 

 

 

 

Property Restriction

 

 

 

CommonLawJurisdiction

common law jurisdiction

 

a jurisdiction based on common law

 

property restriction 08
jurisdiction

 

 

 

Class

 

 

 

fibo-fnd-law-jur-08

property restriction 08

 

Set of things with property "is governed by" only "common law system"

 

 

 

 

 

Property Restriction

 

 

 

CivilLawSystem

civil law system

 

Civil law (or civilian law) is a legal system originating in Europe, intellectualized within the framework of late Roman law, and whose most prevalent feature is that its core principles are codified into a referable system which serves as the primary source of law.  This can be contrasted with common law systems whose intellectual framework comes from judge-made decisional law which gives precedential authority to prior court decisions on the principle that it is unfair to treat similar facts differently on different occasions (doctrine of judicial precedent).

 

property restriction 05
legal system

 

 

 

Class

 

 

http://en.wikipedia.org/wiki/Civil_law_(legal_system)

fibo-fnd-law-jur-05

property restriction 05

 

Set of things with property "applies in" some "civil law jurisdiction"

 

 

 

 

 

Property Restriction

 

 

 

CivilLawJurisdiction

civil law jurisdiction

 

a civil law jurisdiction

 

property restriction 07
jurisdiction

 

 

 

Class

 

 

 

fibo-fnd-law-jur-07

property restriction 07

 

Set of things with property "is governed by" only "civil law system"

 

 

 

 

 

Property Restriction

 

 

 

 

 

10.9.3 Ontology: Legal Capacity

This ontology defines high-level legal concepts, especially those related to legal responsibilities, for use in other FIBO ontology elements. The ontology defines things which are conferred upon some entity by some legal instrument, and elaborates this into a number of specific capacities, responsibilities and powers, each of which forms the basis for many of the concepts used elsewhere in FIBO in defining legal personhood, executive powers and the like.

Figure 10.9.3.1 Legal Capacity Concepts

Figure 10.9.3.1 Legal Capacity Concepts.png

Table 10-50 Legal Capacity Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

hasCapacity

anything

has capacity

identifies an entity that has some capability to carry out certain actions, or has certain rights or obligations

 

has

 

legal capacity

is capacity of

Relationship Property

 

 

 

StatutoryResponsibility

statutory responsibility

 

An obligation which is defined under some body of law (statute).

 

duty
property restriction 03

 

 

 

Class

 

 

 

fibo-fnd-law-lcap-03

property restriction 03

 

Set of things that must have property "is mandated by" at least 1 taken from "statute law"

 

 

 

 

 

Property Restriction

 

 

 

SignatoryCapacity

Signatory Capacity

 

The capacity of some natural person to sign agreements on the part of some entity.

 

legal capacity

 

 

 

Class

 

 

 

LiabilityCapacity

Liability Capacity

 

The ability to be sued at law

 

legal capacity

 

 

 

Class

Note that for the purposes of this model, this is distinct from culpability (the ability to commit criminal acts). That would be a separate and analogous term but with grounding in criminal rather than civil law.

 

 

LegalConstruct

legal construct

 

Something which is conferred by way of law or contract, such as a right.

 

property restriction 02
property restriction 01

 

 

 

Class

Obligations are an aspect of this category of thing, as are rights.

 

 

fibo-fnd-law-lcap-01

property restriction 01

 

Set of things that may have property "is conferred on" taken from "autonomous agent"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-law-lcap-02

property restriction 02

 

Set of things that may have property "is conferred by" taken from "logical union 01"

 

 

 

 

 

Property Restriction

 

 

 

LegalCapacity

legal capacity

 

The capacity to carry out certain actions or to have certain rights.

 

legal construct

 

 

 

Class

suggested definition only

 

 

isCapacityOf

legal capacity

is capacity of

identifies an entity on which a given legal capacity has been conferred

 

is conferred on

 

autonomous agent

has capacity

Relationship Property

 

 

 

Duty

duty

 

Some obligation which exists and is imposed on some individual.

 

legal construct

 

 

 

Class

This can also be thought of as an obligation - not in the sense in which an obligation and a right are the converse aspects of one another, but in and of itself, independent of the perspective from which it is considered. Examples include statutory obligations, reporting obligations and so on.

 

 

DelegatedLegalAuthority

delegated legal authority

 

Authority in the context of corporate governance means institutionalized and legal power inherent in a particular job, function, or position that is meant to enable its holder to successfully carry out his or her responsibilities. It may also mean (and does in the context of executive authority, for example), power that is delegated formally. It includes a right to command a situation, commit resources, make legally binding commitments, give orders and expect them to be obeyed, and, most importantly, it is always accompanied by an equal responsibility for one's actions or a failure to act.

 

legal capacity

 

 

 

Class

Such authority is delegated contractually.

 

 http://www.businessdictionary.com/de...authority.html

ContractualCapability

contractual capability

 

The capacity to enter into legally binding contracts.

 

legal capacity

 

 

 

Class

This is the capacity which defines Contractually Capable Entity (sometimes labeled as 'Legal Entity') as distinct from 'Legal Person'. In the latter case the liabilities incurred in the contract accrue also to the Legal Person. In the case of contractual capability, the entity has the authority to enter into contracts, whether or not the liabilities accrue to that same entity (which they do if it is also a Legal Person). For Legal Entities which are not Legal Persons, the liability unwinds to some legal person within the structure of the entity, for example a General Partner or a Trustee.

 

 

 

 

10.10 Module: Ownership and Control

Table 10-51 Ownership and Control Module Metadata

Metadata Term

Value

sm:moduleName

Ownership and Control

sm:moduleAbbreviation

FIBO-FND-OAC

sm:moduleVersion

1.0

sm:moduleAbstract

This module includes ontologies defining the meanings of ownership, asset and owner, and of types of control such as de jure and de facto control.  These form the basis of ownership and control relationship hierarchies as well as what it means to own or to control something.

 

10.10.1 Ontology: Control

This ontology defines high-level, control-related concepts for use in other FIBO ontology elements.  The ontology covers basic concepts around control, along with a distinction between de jure and de facto control, the former being derived with reference to terms in the LegalCapacity ontology.

Figure 10.10.1.1 Control Concepts

Figure 10.10.1.1 Control Concepts.png

 

Table 10-53 Control Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

DeJureControl

de jure control

 

control that is formalized in law, or codified in some legal instrument

 

legal construct
control

de facto control

 

 

Class

 

 

 

DeFactoControl

de facto control

 

control that is understood, due to condition or situation treated as standard or official, even if not explicitly stated (or actually standardized)

 

control

de jure control

 

 

Class

 

 

 

ControllingParty

controlling party

 

Party which exercises some form of control in some context.

 

property restriction 02
party in role

 

 

 

Class

At this level of abstraction it is not defined whether the control is some degree of controlling interest, or some level of actual control (asserted or calculated) in some entity.

 

 

fibo-fnd-oac-ctl-02

property restriction 02

 

Set of things with property "has role" some "property restriction 01"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-oac-ctl-01

property restriction 01

 

Set of things that must have property "controls" at least 1

 

 

 

 

 

Property Restriction

 

 

 

Control

control

 

The term control (including the terms controlling, controlled by and under common control with) means the possession, direct or indirect, of the power to direct or cause the direction of the management and policies of a person, whether through the ownership of voting shares, by contract, or otherwise.

 

property restriction 03

 

 

 

Class

 

 

 

fibo-fnd-oac-ctl-03

property restriction 03

 

Set of things that must have property "involves" at least 1 taken from "controlling party"

 

 

 

 

 

Property Restriction

 

 

 

 

10.10.2 Ontology: Ownership

This ontology defines high-level, ownership-related concepts for use in other FIBO ontology elements. These include the concept of owner, asset and ownership along with relationships between them whereby an asset is something owned by some owner.

Figure 10.10.1.1 Ownership Concepts

Figure 10.10.1.1 Control Concepts.png

Table 10-55 Ownership Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

takesForm

anything

takes form

identifies the form the entity takes

 

has identity

 

anything

 

Relationship Property

 

 

 

owns

anything

owns

(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

 

 

 

anything

is owned by

Relationship Property

 

 

 

isOwnedBy

anything

is owned by

 

 

 

 

anything

owns

Relationship Property

 

 

 

isAssetOf

anything

is an asset of

identifies the party that owns the asset

 

has

 

anything

 

Relationship Property

 

 

 

Ownership

ownership

 

Ownership is the context in which some Party is said to own some Independent Thing. The Party is defined as such due to its being the owning party to that Thing.

 

property restriction 05

 

 

 

Class

 

 

 

fibo-fnd-oac-own-05

property restriction 05

 

Set of things that must have property "involves" at least 1 taken from "owner"

 

 

 

 

 

Property Restriction

 

 

 

Owner

owner

 

A party in the ownership role; one that owns something. The thing owned is an Asset to that Party.

 

party in role
property restriction 06

 

 

 

Class

 

 

 

fibo-fnd-oac-own-06

property restriction 06

 

Set of things with property "has role" some "property restriction 04"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-oac-own-04

property restriction 04

 

Set of things that must have property "owns" at least 1

 

 

 

 

 

Property Restriction

 

 

 

Asset

asset

 

A thing held by some party and having some value.

 

property restriction 02
property restriction 03
property restriction 01

 

 

 

Class

 

 

 

fibo-fnd-oac-own-03

property restriction 03

 

Set of things that must have property "is asset of" at least 1 taken from "owner"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-oac-own-02

property restriction 02

 

Set of things that must have property "takes form" exactly 1

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-oac-own-01

property restriction 01

 

Set of things that must have property "has acquisition date" exactly 1 taken from "dateTime"

 

 

 

 

 

Property Restriction

 

 

 

 

 

10.11 Module: Accounting

Table 10-56 Accounting Module Metadata

Metadata Term

Value

sm:moduleName

Accounting

sm:moduleAbbreviation

FIBO-FND-ACC

sm:moduleVersion

1.0

sm:moduleAbstract

This module contains ontologies of general accounting concepts including debt, equity, interest and so on, as well as currency amounts.

 

10.11.1 Ontology: Accounting Equity

This ontology defines equity-related concepts for use in defining other FIBO ontology elements. These are based on basic accounting principles as they relate to equity, debt, assets and liabilities of a firm. Equity forms the basis for ownership of certain forms of corporate body.

Figure 10.11.1.1 Accounting Equity Concepts

Figure 10.11.1.1 Accounting Equity Concepts.png

 

 

Table 10-58 Accounting Equity Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

representsAnInterestIn

anything

represents an interest in

Equity always represents an interest in some business organization. This is the organization, company or venture in which the holder of the equity has a stake in by virtue of holding that equity

 

 

 

anything

 

Relationship Property

 

 

 

StockholdersEquity

stockholders equity

 

equity held in an entity by stockholders

 

equity

 

 

 

Class

When total assets are greater than total liabilities, stockholders have a positive equity (positive book value). Conversely, when total liabilities are greater than total assets, stockholders have a negative stockholders equity (negative book value, also sometimes called stockholders deficit.
paid in capital, donated capital, and retained earnings less the liabilities of a corporation (Barron's)

 

 

RetainedEarnings

retained earnings

 

In accounting, retained earnings refers to the portion of net income which is retained by the corporation rather than distributed to its owners as dividends. Similarly, if the corporation takes a loss, then that loss is retained and called variously retained losses, accumulated losses or accumulated deficit. Retained earnings and losses are cumulative from year to year with losses offsetting earnings.

 

equity

 

 

 

Class

 

 

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

OwnersEquity

owners equity

 

Equity owned in the entity as recorded on the books of that entity.

 

property restriction 05
property restriction 04
equity

 

 

 

Class

 

 

 

fibo-fnd-acc-aeq-05

property restriction 05

 

 Set of things with property "has part" some "capital surplus"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-acc-aeq-04

property restriction 04

 

Set of things with property "has part" some "stockholders equity"

 

 

 

 

 

Property Restriction

 

 

 

IssuedEquity

issued equity

 

externally-held stockholders equity that may be transferred from one party to another

 

stockholders equity

 

 

 

Class

 

 

 

FinancialAsset

financial asset

 

An asset consisting of one or more financial instruments, treated as an asset

 

asset

 

 

 

Class

 

 

 

Equity

equity

 

the value of an ownership interest in property, including shareholders equity in a business

 

property restriction 01
property restriction 02

 

 

 

Class

 

 

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

fibo-fnd-acc-aeq-02

property restriction 02

 

Set of things with property "takes form" only "money amount"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-acc-aeq-01

property restriction 01

 

Set of things that must have property "represents an interest in" exactly 1 taken from "formal organization"

 

 

 

 

 

Property Restriction

 

 

 

CapitalSurplus

capital surplus

 

Capital surplus is a term that frequently appears as a balance sheet item as a component of shareholders equity. Capital surplus is used to account for that amount which a firm raises in excess of the par value (nominal value) of the shares (common stock).

 

equity

 

 

 

Class

 

 

http://en.wikipedia.org/wiki/Additio...aid_in_capital

Capital

capital

 

Financial capital, which represents obligations, and is liquidated as money for trade, and owned by legal entities. It is in the form of capital assets, traded in financial markets. Its market value is not based on the historical accumulation of money invested but on the perception by the market of its expected revenues and of the risk entailed.

 

property restriction 03

 

 

 

Class

 

 

http://en.wikipedia.org/wiki/Capital_(economics)

fibo-fnd-acc-aeq-03

property restriction 03

 

Set of things with property "takes form" only "money amount"

 

 

 

 

 

Property Restriction

 

 

 

 

 

10.11.2 Ontology: Currency Amount

This ontology defines monetary amount related concepts for use in defining other FIBO ontology elements. There are two distinct kinds of concepts that correspond to money and amounts: a concrete, actual amount of money, and the monetary measure of something denominated in some currency. These are dimensionally the same but whereas "money amount" is defined as an amount of money, "monetary amount" is an abstract monetary measure. This ontology also defines related terms such as currency.

Figure 10.11.1 Currency and Amount Concepts

Figure 10.11.1 Currency and Amount Concepts.png

Table 10-60 Currency and Amount Details

Name

Type Of Thing

Property

Definition

Equivalent to

Parent

Mutually Exclusive With

Related Thing or Type

Inverse Of Property

Concept Type

Editorial Note

Explanatory Note

Definition Source

hasPercentageAmount

anything

has percentage amount

a number or quantity represented as a percentage

 

 

 

percentage

 

Simple Property

 

 

 

hasNotionalAmount

anything

has notional amount

has a notional value expressed as some monetary amount, that is a number and a currency in which that number is denominated

 

has

 

monetary amount

 

Relationship Property

 

 

 

hasCurrency

anything

has currency

the currency in which the monetary amount is defined

 

has

 

currency

 

Relationship Property

 

 

 

hasBaseMoneyUnit

anything

has base money unit

the currency in which the money amount is denominated

 

has

 

currency

 

Relationship Property

 

 

 

hasAmount

anything

has amount

a total number or quantity

 

 

 

xsd:decimal

 

Simple Property

 

 

 

PercentageMonetaryAmount

Percentage Monetary Amount

 

A measure of some amount of money expressed as a percentage of some other amount, some notional amount or some concrete Money Amount.

 

property restricton 01
monetary measure

 

 

 

Class

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.

 

 

fibo-fnd-acc-cur-01

property restricton 01

 

Set of things with property "has percentage amount" only "percentage"

 

 

 

 

 

Property Restriction

 

 

 

MoneyAmount

money amount

 

A sum of money.

 

property restricton 04

 

 

 

Class

This is an actual sum of money, not the measure of a sum of money in monetary units, although it has the same basic properties (decimal number with a currenct unit). Update 14 June 2011: Renamed from "Monetary Amount" to "Money Amount" to make this perhaps clearer. This term here should not be the Referenceable Archetype used to denote monetary amounts as a measure. ACTION: Across the model, all references to "Money Amount" (which was called 'Monetary Amount' when these were entered), so be the abstract quantity "Monetary Amount".

 

 

fibo-fnd-acc-cur-04

property restricton 04

 

Set of things with property "has currency" only "currency"

 

 

 

 

 

Property Restriction

 

 

 

MonetaryMeasure

monetary measure

 

Some measure of some sum of money.

 

 

 

 

 

Class

This may be a measure expressed in terms of decimal plus currency, or it may be a measure expressed in terms of a percentage amount with reference to some other monetary amount or to some Money Amount (actual amount of money).

 

 

MonetaryAmount

monetary amount

 

the measure which is an amount of money specified in monetary units

 

monetary measure
property restricton 02
property restricton 03

 

 

 

Class

This is an abstract concept, not to be confused with a sum of money (Money Amount).

 

 

fibo-fnd-acc-cur-02

property restricton 02

 

Set of things with property "has amount" only "decimal"

 

 

 

 

 

Property Restriction

 

 

 

fibo-fnd-acc-cur-03

property restricton 03

 

Set of things with property "has currency" only "currency"

 

 

 

 

 

Property Restriction

 

 

 

Currency

currency

 

medium of exchange value, defined by reference to the geographical location of the authorities responsible for it

 

 

 

 

 

Class

 

 

Codes for the representation of currencies and funds, ISO 4217, Sixth edition, 2001-08-15, section 3.1.

isTenderIn

currency

is tender in

A region or country in which the currency is exchangeable for goods and services. Commonly referred to also as legal tender, however this definition does not hold literally in some countries e.g. Scotland.

 

 

 

country

 

Relationship Property

 

 

 

 

Annex A Machine Readable Files Part of This Specification (normative)

The FIBO ontologies are delivered as (1) RDF/XML serialized OWL (normative and definitive), (2) UML XMI, serialized from UML with the ODM profiles for RDF and OWL applied (normative), (3) ODM XMI, serialized based on the ODM MOF metamodels for RDF and OWL (normative), and (4) Visual Ontology Modeler (VOM) model files, based on the VOM plug-in to MagicDraw (informative).  If there are differences between the OWL files, ODM XMI, and UML XMI, the OWL files take precedence, followed by the UML XMI, and finally the ODM XMI.

Regardless of their form, each of the ontologies included in Foundations makes normative reference to the DCMI Dublin Core Metadata Terms [4], W3C Simple Knowledge Organization System (SKOS) Recommendation [5], and the OMG Architecture Board’s Specification Metadata Recommendation [6], which are not part of this specification.

The individual RDF/XML files are organized by module (directory), and within a given module, alphabetically by name, as shown in the URI structure for each individual OWL file.  These files are UTF-8 conformant XML Schema files that are also OWL 2 compliant, and may be examined using any text editor, XML editor, or RDF or OWL editor.  They have been verified for syntactic correctness via the W3C RDF Validator and University of Manchester OWL 2 Validator.  They have also been checked for logical consistency using the Pellet OWL 2 reasoner from Clark & Parsia as well as the HermiT OWL 2 reasoner from Oxford University. It is anticipated that the OWL ontologies will be dereference-able, together with technical documentation (HTML) from the OMG site once the specification is adopted.

Note that the ontologies use features of the OWL 2 language and other ODM revisions that will not be available in the Ontology Definition Metamodel (ODM) until the ODM 1.1 specification is published.  The ODM RTF has published a convenience document, available to OMG members, that incorporates specification changes required for FIBO that have already been resolved by the working group, and which we anticipate will be available later this year once the report and related specification is published.

Annex B Shared Semantics Treatments

(normative)

B.1 Introduction

Intended Audiences:  Semantic Modelers; Technical architects

The model content is grounded in terms which come from outside the realm of business entities of financial services. These are maintained in the Foundations ontology. Wherever possible, terms in this section are cross referenced to terms set out by suitable standards bodies and academic bodies, so that the meanings of these terms are grounded in a broader community of semantics modeling.

Some of these external standards are in the form of formal ontologies, modeled typically but not necessarily in the Web Ontology Language (OWL) and in any case grounded in formal first order logic. In addition, some terms are derived from models which are not formally grounded in first order logic but which in some way or another are identified as meaningful concepts, either by explicit mark-up of the model content, by some separate theory of meaning, or by some statement at the level of the model identifying it as a semantic model. Such models are typically in the Unified Modeling Language (UML) or some other formalism such as that of the eXtensible Business Reporting Language (XBRL).

Some of the models are only referred to in part, for example because the scope of the standard, as identified by its business requirement, is very different to the scope of the concepts in the Foundations ontologies, or because the ontology contains formal axioms or facts which are at odds with Foundations.

This section describes the range of treatments by which such external standards are cross referenced in the Foundations ontologies. A number of such treatments have been identified, depending on the nature of the standard or vocabulary referred to in FIBO Foundations, the language in which it is framed or the extent to which we are confident of making direct formal reference to it. For example, for some ontologies we wish to make direct, explicit reference, whereas for others we may have less visibility or confidence in the maintenance arrangements of that model's content and so have elected to create a local 'snapshot' of that ontology with its own namespace.

B.2 Shared Semantics Treatments

Case 1: Complete, stable OWL Ontologies

Treatment: Create a surrogate of the ontology using ODM.

Because this is in ODM, it shall have the actual URIs of the external standard. The material in FIBO represents a direct use of that ontology with its original namespace.

Case 2: Ontology Snapshot

If the external ontology is in OWL but we want to make a snapshot of it at a point in time

Treatment:

· Create clone copy of the ontology in our repository

· Allocate a URI which identifies this as a clone (to include the elements of the original URI plus "/fiboclone/")

· Use OWL equivalentClass, to point from an element in the FIBO clone to the corresponding element in that ontology.

When to use snapshot

This is used when for any reason we don't want to reference changes to the external ontology.

Case 3: Partial Snapshot

This treatment is for when the external ontology has a broader or different business requirement and range of concepts, such that we may not wish to refer to or replicate them all.

Treatment: Create a clone of only those the parts of the ontology we wish to refer to.

Otherwise the treatment is the same as for Case 2, except that in place of the URI fragment “/fiboclone”, the fragment “/fibopartialclone” should be used.

Annex C Logical versus Conceptual Models comparison

(informative)

Intended Audiences: Technology Management

C.1 Comparison Table

The principal differences between a logical data model and a semantic model are shown in Table C1.1.

Table C1.1 Model Comparisons

Logical Data Model

Semantic Model

Represents elements in a database design

Should not include design information but is a model of business concepts

Represents data model design components (Classes in OO design; tables in relational database design)

Represents "Things" using set theory concepts

Combines common data structures for reuse and efficiency

No efficiency considerations because it is not a design; reiterates concepts as they apply

Single inheritance hierarchy

Multiple inheritance

May define a number of optional properties of a class, such that the application developer would know whether these apply or not

Defines what facts are applicable to a given type of thing.

Uses enumerations to quality classes

Enumerates classes ("Things")

Closed World Assumption (CWA)

Open World Assumption (OWA)

These are explained further in the sections which follow.

C.2 Detailed Models Comparison

Design Elements versus Business Concepts

A logical data model represents the design of some data structure such as a database or a message design. This differs from a physical data model in that it is not specific to any one implementation or platform. That is, a logical data model is a kind of "Platform Independent Model" or PIM, as distinct from a "Platform Specific Model" or PSM.

While a logical data model is not specific to any one physical implementation, it does represent some design. That is, the logical data model, like any logical design, represents the results of some design effort by some designer.

A semantic model does not represent any design of any solution, but explicitly represents facts about the problem domain.

If a designer sets out to design something, there should normally be something that they are working from. In the design of software, designers work from formal business requirements statements, such as "Use Case" models or a requirements specification document. For data, the equivalent is a semantic model. That is to say, a designer of a data model should be expected to work from some source of knowledge of the items which are to be catered for in the database or messages for which they are carrying out the design.

Components that are Represented (Classes, Tables or Things)

In order to create a model which represents the logical design of some database or message scheme, the modeler will create a model which represents components of that design. For example, in a relational database they will create a model of database tables, along with relationships between those tables, public and private keys and so on. A logical representation of the design is therefore a representation of database constructs, namely tables, relationships, keys and so forth. The logical data model design is therefore couched in a notation which has formal representations of those elements. This may take the form of an Entity Relationship Model (ERM) or an object oriented model in the form of a Class Model in the UML design notation.

Depending on the model notation chosen by the developer therefore, the model may be an ERM model of data entities and relationships, or a UML class model of classes, associations, composition relationships and so on. These are the items to which elements of the model refer.

By contrast, a semantic model does not represent a logical design, and the things in the semantic model represent instead the real world entities in the business domain itself.

For example, a logical data model for securities may contain a representation of data tables for data about shares, bonds and so on, whereas a semantic model of the securities domain will contain representations of shares and bonds themselves, as kinds of "Thing".

The relationship between a semantic model element and the things it represents is made explicit in the Semantic Web "Web Ontology Language" or OWL notation. In an OWL model, every kind of "Thing" in the model (also known as "Classes") is a set theory construct which defines membership of the set in terms of the properties of its members. All classes in an OWL ontology model are sub-classes of a class known as the "Universal" set, commonly labeled as "Thing". This is the set of which everything is a member. In this way it is made explicit that everything in the model is some thing.

Reuse

It is sensible when carrying out data model design, to identify similar sets of terms and combine these into reusable sets. A semantic model may end up combining common concepts if the concept can be described as a more general, more abstract variant of the kind of thing. However, this is not a requirement for model design - things may be combined according to similarity in the data structures without reference to their meaning.

This is really another aspect of the basic fact that, since a semantic model is not a design, it has no design constraints (note this may not the case for an individual semantic technology application, where constraints are rightly applied but are very different to those for relational database or message design).

Single versus Multiple Inheritance

A limitation of some (though not all) relational design environments and notations is that the classes would be arranged in a hierarchy of classes. These would be in a single inheritance "tree" i.e. each class has only one parent class of which it is a specialization (ignoring polymorphism for now).

Semantic models more closely reflect the real world dispensation of taxonomies of kinds of thing, namely that a set of classes may defined according to more than one property. For example, a whale is both a marine animal and a mammal according to two different kinds of classification hierarchy, and an individual whale, being a member of the class of things which are a whale, is classified as both kinds of thing.

This is particularly valuable in modeling of kinds of security for different applications. For example risk management and securities trading performance analysis have different requirements, based on asset types, cash flow behaviors and so on. One application would need to classify things according to one set of requirements. Regulators have different requirements to traders, and even different regulators or different areas of regulatory analysis and systemic risk analysis may dictate different ways in which the universe of instruments may be "sliced" for analysis.

Optionality

In standards, particularly message standards, it is good practice to have a number of properties that may or may not apply to a given category of data element (for example, for a data element for a debt security), and make all of these optional. This is practical: for any debt instrument, not all the properties necessarily apply, but someone wanting to send a message from one point to another will be able to populate the message with those properties that exist for that security.

This, by definition, does not represent the knowledge that business practitioners may have about what facts necessarily must apply for a given instrument of a given type. In order to provide a message which is complete and correct, the sending party needs to apply knowledge from outside the model, about what facts necessarily apply to a given instrument. This intelligence would typically need to be built into the application that builds the message which is sent according to that schema. The knowledge is not represented in the schema.

At base this is simply another way of saying that the logical design of the message is not a representation of the knowledge about the instrument. Needless to say, this is not a criticism of such a message, it is simply a statement of why the message schema is not a record of the knowledge about the instruments.

Enumerations

A valid and good design approach to different kinds of thing is to provide a single data element which is an enumeration, containing entries for each of a number of entries that distinguish these things.

In a semantic model, each thing in the enumeration is a separate class of "Thing". The presence of enumerations in a model indicates that this is a logical model.

Note that for simplicity is it sometimes the practice to provide an enumeration (of textual strings, or 'literals') in a semantic model. However this is usually a pointer to the need to develop the semantics of the model further.

Open versus Closed World Assumption

· Open World Assumption: Absence of evidence is not evidence of absence

· Closed World Assumption: Absence of evidence is evidence of absence

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.

What this means in practice is that facts can be asserted about a thing in a semantic model without consideration to whether these facts are represented by actual data. For example, a fact about any event is that it has a cause, however causes of events need not be known or represented.

On a more detailed level, a semantic model can describe and represent facts about things without those facts being represented as data. Very often the facts, which define the nature of a thing, may not correspond directly to data. For example, many financial instrument types are defined in terms of the legal rights and obligations that they represent to one or other party to the contract. These rights and obligations may correspond indirectly to data elements, but the legal facts themselves may be more abstract, i.e. a fact stated in terms of "has right to" or "commits to" may refer to the abstract concept of a right, while the data may contain details of those rights and obligations, which may be regarded as a sort of signature revealing the existence of those rights and obligations.

This would be true of anything which is defined and classified according to facts which are themselves abstract. This would include most legal concepts.

C.3 Model Partitioning

The FIBO Foundations concepts are partitioned into several non-mutually exclusive categories, in the sense in which the term “partition” is used in the semantic modeling community. These are:

· Independent, Relative and Mediating things

· Concrete and Abstract things

· Continuant and Occurrent things.

Each partition is represented as a class of OWL Thing and as a sub-type of the OWL Thing class, without additional archetype indications.

Terms defined in the model in this specification, and any terms defined in future additions to this specification or in local ontologies derived by extension of this specification, may not have a direct parent class of 'OWL Thing'. All classes of thing in the model described in this specification are given a parent which is either an archetype class of Thing or has an archetype as an ancestor, and all archetypes are given a parent from each of the three partitions listed above, with the exception of temporal terms which exist in a separate partition to the above.

Users of parts of this model may optionally ignore the above partitions in order to dispose model content under separate partitions of their own.

C.3.1 Independent, Relative and Mediating Things

This set of partitions provides a division into the model according to categories which have been arrived at through a considerable body of philosophical literature, notably that of C. S. Peirce. This partitioning relies on the claim in that literature that all things which can be named and classified fall into one and only one of these categories. This principle is reflected in the model described in this specification.

An independent thing is something which is defined in its own right and without reference to any context. For example, a business entity is an independent thing.

A relative thing is something the definition and meaning of which is specific to some specific context. That which is defined in that context is itself identified as some independent thing, or in some cases some other kind of relative thing, which stands in the role or relationship defined as the relative thing. For example a party to a contract is a relative thing, being itself some independent thing, in this case some business entity.

A mediating thing is the context in which some thing is defined as being some relative thing. For example, the context of contractual relationships, or of the context in which some specific kind of contract is entered into, is the mediating thing in which the business entity is identified as being some contract party. The term 'Mediating Thing' is synonymous with 'context' in the broadest sense of that term.

Relative things always have a relationship of 'identity' with some thing which may stand in the role identified by the relative thing. This is usually but not always some independent thing. In some cases the identity relationship may refer to some other relative thing, for example a securities issuer may be a 'Special Purpose Vehicle' which itself is defined as a kind of relative entity, the identity of which may be a company incorporated by the issue of shares, a limited liability partnership or some other form of legal entity. For this reason, while relative things should normally have an identity relationship to some independent thing, the most general application of this relationship is to the universal class 'Thing'.

C.3.2 Concrete and Abstract Things

This partition simply identifies whether something is a concrete item with weight and mass, or an abstract construct. Many of the concepts formally identified in the financial services industry are by their nature abstract.

Archetypes may only be identified as concrete or abstract if this is necessarily the case for all things of that archetype.

Note that things which have legal standing and which may be either provided on paper or in a dematerialized form are identified in this model as concrete. The intention of the Abstract partition is to define things which by their very nature are abstractions, such as goals.

One important class of abstract things is those things that are made up of information. According to the modeling principals, only things which are real may be represented in this model. This necessarily excludes things like database keys and locally defined identifiers. A common sense test needs to be applied to any kind of information before it is considered to be real and therefore able to be modeled here. Public information constructs such as security identifiers, business entity identifiers, credit ratings and the like pass this test because they are published by some party. In addition, documents and messages and the like which are passed between entities or parties in the course of carrying out some business process are equally real even though they are not published. The test for their reality is passed because information constructs such as documents have some real business, legal or financial import, that is some impact on something which is itself modeled as being part of the real world and not part of the technical design of some data or application.

C.3.3 Continuant and Occurrent Things

This partition segregates things which by their nature have some existence of a period of time, with a beginning and an end to their existence, and things which by their nature occur at a point in time. The precise timescales on which a thing may be said to occur or to have an ongoing existence is itself dependent on the domain being modeled, in this case all concepts relating to business entities and more broadly to the carrying out of business activities in the human world. So for example a human being would be considered on an astronomical scale as an occurrent thing, the difference in granularity in the time scales being determined according to the context in which the ontology is to be used. More precisely, a human being could still be considered as a Continuant Thing, with a human life being the corresponding Occurrent Thing, so in many cases it is reasonable to try to frame definitions of things which are clearly either continuant or occurrent.

For the avoidance of doubt, the partitioning of continuant from occurrent things is not formally represented by any axioms, and is definitional only. This means that terms in this model may be cross referenced to terms in models which use different formal ways of distinguishing continuant from occurrent things, for example what are called four dimensional, three dimensional, and similar modeling arrangements. The partitioning given in the model described in this specification contains no such assertions and is provided to enable the problem domain to be partitioned according to the basic nature of what is defined. This enables the model to contain concepts to do with events, processes, states and the like, though these are not utilized in the business entities semantic model.

Annex D How to extend FIBO ontologies (informative)

Intended Audiences: The intended audience for this Annex is semantic modelers, who are expected to have some familiarity with the basic principles of semantic modeling but not necessarily with the principles specific to FIBO. Basic OWL principles are also reiterated here. This section is not intended for purely business audiences or purely technical audiences.

This Annex should be read in conjunction with the section on Conformance (Section 2).

D.1 Terminology used in this Annex

There are several sets of terminology in use throughout this specification, and the meanings of some terms (such as 'thing') may be different in different specialized usages. Here the intended sense of these words, unless otherwise stated, is the sense used for business communication of the ontology content, and not the sense used in technical modeling or conventional Semantic Web terminology. If a formal definition of a term is not given or referred to via the "Definitions" section of this specification (Section 4), the normal, English language sense of a word should be assumed, and not that of any technical body of knowledge or community of practice.

The model described in this specification follows the principles of the Web Ontology Language (OWL). This defines the concept of a 'Class' as a set theory construct and is not to be confused with the usage of the word ‘Class’ in the UML modeling paradigm. In descriptions aimed as business audiences, we usually use the word ‘Thing’ in place of this, and on the basis that the OWL library class “Thing” is the ultimate parent of all classes in an OWL model (so they are all things). This also precludes having to explain to a business audience the very nuanced distinctions between UML and OWL Classes. The specialized technical usage of the word 'Thing' to refer to an OWL individual is not the sense used in this Annex.

In this Annex, the term 'class' and 'thing' will be used interchangeably to describe the OWL classes as set theory constructs, that is in the natural language (dictionary) sense in which one speaks of classes of thing (for example in the sentence "what class of locomotive is this?" or "what class of animal is a fish?"). This corresponds to the OWL usage of the term but not (or not without some qualification) to the UML usage of the term.

D.2 Overview

D.2.1 Classes of Thing

In OWL and therefore in FIBO models, membership of a class may be defined intensionally by way of properties which define the membership (the extension) of that class, or extensionally by way of listing the members of the set which makes up that class.

In the model described in this specification, all classes are defined intensionally except where extensional models are unavoidable. The modeling notation employed here supports the definition of extensional classes but this is discouraged except for the definition of classes which are necessarily extensional such as days of the week.

D.2.2 Model relationship to Subject Matter

The formal statement by which everything in the model has an ultimate super-class which is the universal set of 'Thing' is the means by which this model is formally identified as being a business conceptual model and not a data model representation.

In order to preserve the integrity of the model as a model of business concepts, all classes which are added to the model must:

1.  Be given a superclass (a class with which the new class has a sub-class relationship) from one of the existing classes in the model;

2. Represent something in the business domain itself, and

3. Represent a set of possible members which in all cases would also be members of the set defined by the superclass in (1)

D.2.3 How to Model New Classes

In modeling semantics, it is a requirement to model each new kind of "Thing" (hereafter referred to as 'classes') in the model according to the following two criteria:

· What kind of thing is this?

· What facts distinguish it from other things?

The consequence of addressing these questions is that for each kind (or class) of thing in the domain of discourse (in this case business entities and legal entities), this will be defined in terms of the following question:

"What is the simplest kind of thing that this is one of?"

By defining classes in terms of simpler kinds of thing, future changes will be additive. This benefit only applies if each class in the model is adequately generalized into some more abstract concept.

Failure to adequately generalize classes of "Thing" in the taxonomic hierarchy will have the result that future additions to that part of the taxonomy may prove to be disruptive. When the model is extended in the future to cover additional concepts, if the model components are not adequately abstracted then it will become necessary to break the existing chain of generalization to interpose new terms to support these new concepts. It is therefore important that modelers exercise imagination in this regard.

D.2.4 Declaring Class Disjointness

A disjointness relationship indicates that two classes of thing are mutually exclusive, that is that members of one may not also be members of the other.

Class disjointness refers to the situation whereby the members of one class may not also be members of another class when there is a disjoint relationship between the two. In OWL this relationship uses the 'isDisjoint' construct.

New 'isDisjoint' relationships should be labeled with the natural language label of "mutually exclusive"

Classes may have several separate sets of sub-classes which are mutually disjoint.

Note that disjointness is inherited through sub-class relationships. If a disjoint is misapplied this may cause inconsistencies. Conversely, if there is an inconsistency and disjointness has been correctly applied, then somewhere in the model there is an incorrect statement which would assert that some individual may be a member of more than one mutually disjoint class. The application of disjoint relationships therefore provides a useful diagnostic for subsequent extensions to the model, provided it is implemented correctly.

D.2.5 How to Model New Facts about Things

There are two kinds of "fact" in the model (in formal modeling terms, two kinds of "Property"):

1. Relationship Properties (known in OWL as Object Properties);

2. Simple Properties (known in OWL as Datatype Properties)

These are similar in their intent, in that they assert something about the class of which they are a property, but are shown differently in model diagrams.

Facts (properties) should be presented in the model only at the level of the class to which they apply. If a fact is not always applicable or relevant to the meaning of some concept, it should be applied to one or more sub-types of that class where it would be applicable. Similarly a property should not be applied to sub-classes where they would not always be true.

As an example, vertebrates are a class of things which are an animal and which have a backbone. It would not be appropriate to model the term "has backbone" as an optional property of all animals. Nor would it be sensible to say, for each class of things which is a vertebrate, that this class of vertebrates also has a backbone.

Note that there is a difference here from data modeling. In a data model it may be more efficient to assign a property to a class, make it optional, and then have some sub-classes which use that property and some which do not. This is appropriate for a data model because such a model is not intended to convey the meanings of those classes; rather, the user of the model has to know which sub-classes would have data for that property and which of them would not. In contrast, the semantic model in FIBO is intended to convey the knowledge that such a user would need to have. For this reason, considerations of efficiency which would be brought to bear on a data model design exercise, should not be considered when extending FIBO models.

· Impact on Sub-classes

When adding a new Relationship Property or Simple Property to an existing class, ensure that this fact would be true of all the classes that are sub-classes of this class, and that are sub-classes of their classes and so on. If the meaning asserted by the addition of the new property is not necessarily true of all the descendent classes of thing, then it would not be correct to add it to this class. Instead it should be added to those of the sub-classes to which it does apply (that is, those to which it contributes something of the meaning of what it is to be a member of that class).

If there is a clearly identifiable group of those sub-classes for which the property is applicable, then it is possible that these could be grouped together as a new sub-class with that property. However, the addition of such a class, being as it would be interposed into an existing class hierarchy, should be handled with care - this constitutes a disruptive rather than an additive change, and will have different and more stringent change management requirements.

· Adding a Relationship Property

Wherever possible, a Relationship Property should be a specialization of another Relationship Property which is already in the model. When adding the Relationship Property, the RDF construct "subPropertyOf" should be used to assert what is the parent property.

The new property should extend or refine the meaning of the parent property in some way.

It is also allowable to have more than one parent property. This is appropriate in cases where the meaning of one Relationship Property is recognizably derivable from the meanings of two or more other Relationship Properties. This construction should be used sparingly and with care.

· Types of Relationship Property

In terms of the OWL language, there are a number of distinctions between kinds of relationship which may be asserted in this model. For example, it is possible to assert that a relationship is symmetric, or that it is 'functional'. Functional relationships are relationships where only one individual of the type that's shown as the range of the property, may be that thing.

In the UML modeling environment, the information about what kind of relationship a given relationship is, is provided by means of tagged values.

At present the terms distinguishing different types of relationship are not widely used in the model. If in doubt, relationships should be added without attempting to populate this information.

When adding a new relationship and making it a sub-property of some existing relationship, modelers should check the parent relationship and any of its parents, to verify whether these are defined as being one of these specialized types of OWL object property. If they are, then the new relationship will also take on this type, so modelers must ensure that this would be correct for the relationship being added.

· Adding a Simple Property

Simple Properties may only have a range (the object of the predicate) which is a simple information type or an enumerated data range.

The simple information types may be found in the model section "Business Types". These include concepts such as text, numbers, dates and yes/no answers.

Simple Properties should not have ranges which are technical datatypes (the XML primitive datatype set or the datatypes made available within a UML modeling framework). XML primitive datatypes are allowable in RDF/XML based OWL ontologies, and would be used in an operational ontology derived from these models, but for the purposes of business understanding of the model these are all either given aliases (like 'yes/no' for boolean), or have more detailed types derived from them such as the various kinds of number.

There are no "Complex Types" in FIBO. For presentation purposes in different UML editing environments it is possible to consider rendering certain Relationship Properties (OWL object properties) as if they were simple types, i.e. using the UML "attribute" construct, but this is not formally supported in the sub-set of ODM defined in this specification. If this technique is used, such properties must be formally identified as OWL object properties; datatypes properties may not refer to classes which themselves have properties, such as monetary amounts or dated values.

D.2.6 Inverse Relationships

Whenever two relationships are in an inverse pair, this must be indicated by adding a relationship between those relationships, using the OWL construct 'inverseOf'. This should be labeled with the natural language label of 'inverse'.

Many Relationship Properties about things in the real world come in pairs, where one is the inverse of the other. For example "Account held by Account Holder" and "Account Holder holds Account" are two ways of saying the same thing, from the two perspectives of the Account and the Account Holder.

All relationships in the semantic notation used here and in the Semantic Web are unidirectional, that is they are 'triples' of the form Sub verb Object.

This is different to the way relationships are treated in data modeling. The 'ends' of a relationship in a data modeling format may be considered as being analogous to the separate relationships in a semantic model.

When to add these: Where it is considered relevant in defining the meanings of concepts,  Relationship Properties (other than symmetric ones - see 'Types of Relationship Property') may also be given an inverse. It is not a formal requirement to indicate all the inverses that may possibly exist. Such relationships should be present in the model and extensions to the model if the two senses are in common use, if they correspond to a named term for which there is a formal definition in use in the financial industry, or if Relationship Properties that are commonly defined for sub-types of the class that they are a fact about, are commonly specified or referred to in the opposite direction to the one which has already been specified.

For this reason, the addition of new classes of thing in the model, given that these specialize existing things, may sometimes require the addition of the inverse of some existing Relationship Property, which was previously implied but not present as a property in the model.

D.2.7 How and When to Use Enumerations

There are two kinds of enumeration in the modeling notation:

· Enumerated Data Range

· Enumerated Class

Enumerated data ranges look a lot like enumerated datatypes in data models. However, these are used differently and will not usually correspond.

The 'Enumerated Data Range' construct should be used to enumerate possible data literals, that is pieces of text, numbers and so on, any one and only one of which may be the literal value of that datatype property for one instance of that class.

Where a data model enumerations may enumerate types of real thing and are frequently used to "flag" some class to say what kind of thing this is, this arrangement cannot be used in the FIBO semantic model. If a class of thing may be of several types, then these should be modeled as distinct classes, each of them a sub-class of the class of thing that they are all types of.

Where a class is to be defined by enumerating its members (extensional definition of the class), then the class itself should be modeled not as an OWL Class but as an OWL Enumeration Class.

D.2.8 Foundations Concepts Usage

Because it was a requirement that classes of thing be abstracted to their simplest possible types, the modeling already carried out in FIBO necessarily required the creation of a set of classes which, by their nature, are not unique to business entities or financial services terms and definitions.

There is a second scenario in which terms are required which are not unique to financial services. This is when a relationships fact (OWL object property) about some business entity has a relationship to something which is not itself a concept unique to the context of the financial services sector.

The terms which are not unique to the financial services sector are maintained in a separate part of the model repository and are given a separate namespace. These are packaged as the FIBO Foundations ontologies. Use of the appropriate terms in these ontologies is normative for this specification, but in many cases these ontologies are being evolved, improved upon and better aligned with other publicly available standard ontologies and with relevant academic work.

In Semantic Web terms, these are mid level ontologies. These are additionally supplemented by the inclusion of an "Upper Ontology" consisting of three sets of underspecified, high level partitions into which all model content is divided.

When adding new classes or Relationship Properties, modelers should seek out and select concepts from within the Foundations ontologies which represent the terms they need to specialize or refer to. They should also recognize and adequately respect the 'Archetype' of that term, as described in Section 8.4.1. In particular, the ontology partitions under which the required archetype term resides should be inspected and understood, in order not to give rise to inconsistencies in the resultant ontology.

New general terms should not be added without first seeking the appropriate terms in these Foundations ontologies or in some recognized external ontology, which must itself be cross referenced using one of the methods described in Annex C (Shared Semantics Treatments), in order to create the necessary relationships.

D.2.9 Content Creation Summary

In summary, there are two scenarios where classes of thing are needed in any ontology for business entities, for financial securities, loans, derivatives and so on:

· The kind of "Thing" which something is;

· Things which are referred to in facts about things.

The first question will lead the modeler to find a more general class of thing of which to make the new class a sub-class. This should be sought initially in the ontology which is being extended, and after exhausting this, in the appropriate Foundations ontology, which must be inspected and fully understood before implementing the new sub-class ('is a') relationship.

The second question will lead the modeler to seek out the appropriate class of thing to which they need to refer. Often, but not necessarily, this will require the creation of some new class of thing. For example, a new class of 'Interest Payment Terms' might be appropriate in order to define a property of a new class of interest-bearing instrument which is defined by way of unique interest payment terms.

Modelers should look in the first instance for some class of thing which is exactly appropriate to the new relationship. For example, concepts like "Monetary Amount" or "Dated Monetary Amount" may be appropriate targets ("Ranges" in Semantic Web parlance) for more than one Relationship Property about more than one class of thing.

In the absence of such a class, modelers should add a suitable sub-class of some existing class of thing which is broader in meaning but otherwise identical to the class to which the new Relationship Property is to refer. In the interest payment terms example above, they would add a new sub-type of the class which is 'Interest Payment Terms Set' or perhaps 'Fixed Interest Payment Terms Set' or 'Bond Fixed Interest Payment Terms Set' as appropriate. This should be labeled with a suitably business-facing label which uniquely describes it within that ontology and which as far as possible reflects what is unique about its meaning (note that meanings do not follow from these labels, but that business comprehension of the model follows from their allocation).

Where a term is not available for specialization within the ontology which the modeler is extending, these are to be found in the FIBO Foundations ontologies, which have been created for the purpose of providing such terms. These are ontologies of things which are not specific to financial services. These include legal concepts like contracts, business concepts such as service provision, as well as an extensive set of concepts for times, dates, mathematical constructs, events and activities, and so on.

If a suitable general term cannot be found then it may be necessary to extend one of the FIBO Foundations ontologies. This should be undertaken as a collaborative effort since this term will almost certainly be needed again in the future and by others. Such terms should be defined with formal reference to other, publicly available ontologies (these being defined either in Semantic Web formats or in some presentation, notation of theoretical grounding which makes it unambiguously clear that the terms in question are not part of a data model or other logical design).

D.3 Presentation Considerations

The presentation conformance requirements described in this specification are mainly a consideration for those creating or setting up editing environments in different modeling tools, and are not covered in this Annex. However, in the course of creating extensions to the model content there are a number of considerations which the modeler should keep in mind, as described in this section.

D.3.1 Labeling

All classes, Relationship Properties and Simple Properties should be given natural language labels. These should be rendered with spaces just as normal text is written.

These labels should conform to the following style requirements:

· Classes: Names should be in Upper Sentence Case

o Abbreviations (if used) should be in their normal upper case rendition e.g. ABC.

o Small words (of, and etc.) should also be capitalized (this is to enable technical users to compress the names without loss of sense)

· Relationship Properties: Names should take the form Subject predicate Object with the casing as shown

o Subject and Object to have the full name of the classes themselves except where this is cumbersome

o The predicate (verb part) of the relationship name should be in all lower case, with spaces

If possible, relationship lines (which are displayed in 'simple' diagrams that don't have the boxes that come with the Relationship Properties), should be labeled with only the predicate.

· Simple Properties: Names should be in Upper Sentence Case

· Other types of "Thing" construct (OWL Union Classes, Intersection Classes, Enumerated Classes and Enumerated Data Ranges) should follow the same naming convention as classes.

In addition to the above constructs, which define the terms in the business domain, there are a number of built in constructs which make additional statements, in set theory terms, about the classes and properties. These should be labeled as follows:

· Logical Union relationships: these are rendered using the UML construct of a generalization set (UML "GeneralizationSet"). Such sets have one name. This name should be a natural language label, with spaces and in lower case. The label should make clear the sense that it is a union relationship defining the logical union of the classes which participate in the generalization set, for example by ending the label with the word 'union'.

· Disjoints (OWL disjointWith): should always have the label "mutually exclusive"

· Inverses of relationships (OWL inverseOf): should always have the label "inverse"

D.3.2 Ontologies

These are implemented using the UML base class of 'Package'. Names for these should be in Upper Sentence Case. Wherever possible short or one word names should be considered.

D.3.3 UML Considerations

UML Diagrams

Diagrams are not transferred from any modeling environment into or out of the model repository. Diagrams are to be created by the modeler for presentation to business domain experts in the area in which they are working, or in the case of new submissions of the model content for future updates, to the wider community, and must be designed to be readable by business domain experts.

UML Notation

No explicitly UML notation should be present on any diagram.

The guiding principle here is one of language: any diagram which includes anything which belongs in or looks as though it belongs in some technical notation, will signal to the business reviewer that this diagram is in a language for which they have had no formal training. No matter how obvious the meaning of a diagram appears to be, the appearance of any technical notation means that it will appear to be something that requires some technical training to parse its meaning.

This means that

· no repurposed punctuation marks may be present on the diagrams. For example:

o no curly braces and therefore no OCL

o no guillemets - so stereotype indications must be disabled

o no plus signs at the ends of relationships or next to attribute names

· UML class partitions that are unused (such as the operations partition) must be made invisible - either by manually resizing the class box until the extra line disappears, or by some other means;

· Exceptions may be made for relationship multiplicities, but the implications of these must be clearly explained to business domain experts who are expected to review the model content

· The Generalization arrowhead is an exception to the above: although this represents a technical notation (Generalization in UML), its meaning is more universal and can be explained to business domain experts ahead of any review. Such explanations must either reference Aristotelian syllogisms or be described in terms of the "is a" relationship with examples from natural taxonomy, depending on the knowledge of the business audience, but should not make reference to UML or words like Generalization or transitivity.

· Namespace indications: in some tools these are indicated with a double colon, which breaks the first rule above. Diagrams with these on may be created and maintained so that maintainers of the content can keep track of what is in what ontology, but these diagrams should not be considered as suitable for general business domain distribution.

Diagram Layout

Modelers should take care to lay out these in a clear and consistent way.

Generalization relationships should be laid out with the "arrowhead" pointing vertically upwards, in either the vertical tree style or direct style of routing. This is because this relationship, while technology neutral (it represents a basic Aristotelian syllogism), has to be explained to business domain experts and should therefore be presented in the same visual layout in which it has been explained, namely to represent taxonomic hierarchies with the most general terms at the top and the most specific at the bottom. These generalization relationships should never be drawn or found pointing downwards or sideways.

Where possible, the physical arrangement of the concepts in a diagram should try to follow the layout of the corresponding concepts in the archetype diagrams for those concepts.

Where large numbers of concepts are found in the same ontology, modelers should try to create separate diagrams which emphasize separate aspects of the subject matter (for example segregating contractual terms from legal obligations, or events from parties).

The relationship sub-property relationships are a particular hazard to creating clear, clean diagrams. However, these should rarely be shown to business domain experts. Where practicable, modelers are encouraged to create, for each separate thematic diagram, a set of three diagrams: one with all the material that needed to be modeled, one without the class component of the Relationship Properties, and one without the Simple Properties (compressing the class glyph as needed to remove the appearance of the attributes partition boundary).

Diagram Notes

Diagrams may also be decorated with informative notes. However, nothing of substance to the model content should be included in these, since these will not be retained when the model is transferred into the model repository or into other modeling environments.

UML Diagram Boundaries

As with notes, these may be included in business diagrams to aid in readability, but these UML boundaries do not form part of the model content and are not retained when the model content is transferred between environments.

UML Packages

UML Packages do not form part of the model, unless the package is stereotyped as an OWL Ontology.

OWL ontology packages may not be nested within other OWL ontology packages.

Modelers may arrange packages as appropriate for the usage to which they intend to put the model, and as part of this they may elect to make hierarchical structures of packages. Packages which are not stereotypes as OWL ontologies may be used for the purposes of such organization. Such packages may only contain other such packages or OWL ontology packages (that is, they should contain no loose classes or other constructs). Such packages do not form part of the model content, and will not be retained when the model content is transferred between environments.

No relationships between packages should be interpreted as, or created to imply, any relationship between ontologies.

All ontology imports must be explicitly modeled using the ODM "owlImports" construct. Each ontology should contain a diagram showing the full set of OWL imports required for that ontology, up to and including the "Lattice" ontology.

Annex E Creating Applications with FIBO (Informative)

E.1 Introduction

This annex contains guidelines on the production of operational applications that take the various FIBO Business Conceptual Ontologies as a point of reference. Such applications include operational OWL ontologies and applications based on conventional data models. The sections below set out the overarching principles for creating such applications, and itemize the things to consider when deriving operational ontologies or logical data models from the content in those FIBO specifications.

E.1.1 Principles

These are the basic principles in order to avoid making assertions which contradict those assertions already made in FIBO:

1. It is not necessary to include all the ancestor classes but disjoints asserted between those ancestor classes must be respected

2. Two classes cannot be introduced into the same logical class hierarchy which have ancestors which are disjoint in FIBO. This is because otherwise it becomes possible to introduce contradictions or data structures which correspond to contradictory or untrue (or absurd) facts about the world.

3. Relationships which have restrictions defined for them (for example functional object properties) may not be extended to have looser multiplicity in logical data models but they may be further restricted.

4. New facts or relationships should not be introduced which directly contradict some fact in the FIBO terms which are used, or in any FIBO terms which are not directly used but which have a bearing on the terms which are used.

E.1.2 Operational Ontologies

The following questions are to be considered when creating an operational OWL ontology using terms set out in one or more of the FIBO Business Conceptual Ontologies:

- When to replace an object property with a Boolean

- Shortening the inheritance hierarchy

- Using independent things without relative things

- Redefining Relative Things as Independent Things

o This is valid when the context of the application matches the “Mediating Thing” that is the context in which the Relative Thing is defined

o Example: Legal Entity is a relative thing but for an application whose scope is constrained to one jurisdiction or LEI issuer, it can be treated as an Independent Thing

- Use of property chains

- Extraction of single-inheritance (monohierarchical) taxonomy

o May also be conformant, as a sub-set of the FIBO material

-  OWL Restrictions versus rdfsSubPropertyOf relations between multiple object properties.

-         

E.1.3 Conventional Applications

The following questions are to be considered when creating a logical data model using terms set out in one or more of the FIBO Business Conceptual Ontologies:

- Possible architectures

o Use of semantically under-specified classes, with enumerations to identify semantics

o Other styles –e.g. a direct rendition of the ontology with addition of database keys

- General

o Enumerations – don’t have mixed semantics in one enumerated datatype (causes combinational explosions)

o Text: when to collapse a chain of properties that end in a text field, with just an attribute that has text as a datatype

o Combining pairs of object properties into one association – with the object property names as the labels of the ends of the association

- UML considerations

o When to render object properties with a specific archetype, as UML Associations or Generalizations

o Multiplicity

- Relative Things

o These may be treated as independent classes when the context of the application matches the “Mediating Thing” that is the context in which the Relative Thing is defined

o Example: Legal Entity is a relative thing but for an application whose scope is constrained to one jurisdiction or LEI issuer, it can be treated as an Independent Thing

- Localization within a part of the taxonomy

o Patterns for taking a starting point within the hierarchy (e.g. MBS versus Bond versus Security), and navigating each of the object properties that apply at that level, navigating downwards (but not upwards) in the taxonomy of things that are the range of the object property, and defining these as the full possible scope of the model

- Extraction via Context

o From a given “Mediating Thing”, navigate to each of the “Relative Things” defined in that context, and each of the “Independent Things” that may take on the “identity” property of those relative things – this should result in a set of all and only those things needed for the application

Page statistics
3473 view(s) and 31 edit(s)
Social share
Share this page?

Tags

This page has no custom tags.
This page has no classifications.

Comments

You must to post a comment.

Attachments