Semantics for Data Architects - Financial Industry Business Data Model

This presentation introduces the ontology-derived Enterprise Data Model for Data Architects and Ontologists.

The deck reflects updates to ontology and data model metrics, the Configurable Ontology to Data Model Transformation (CODT) patent, and other content.

You are welcome to download the PDF version of the PowerPoint and watch the video lecture.

Text of the presentation

Financial Industry Business Data Model (FIB-DM)

Semantics for Data Architects
An introduction to the ontology-derived Enterprise Data Model

Jurgen Ziemer, Ontologist & Data Architect at Jayzed Data Models Inc.

FIBO is the authoritative model of Financial Industry concepts, their definitions, and relations.

The Enterprise Data Management Council (EDMC) is a global association of over 200 Financial Institutions (FIs), teaching

Data Management best practices
Development and implementation of Data Standards.

EDMC members developed the Financial Industry Business Ontology (FIBO) as a business conceptual model.
More than 2,437 classes detail financial instruments, business entities, and processes. (as of release 2025/Q4)
FIBO Conceptualization and Relations are fully applicable for lower-semantic taxonomies, concept maps, object-, and data models. FIB-DM is a perfect conceptual data model.
F Finance key point 2

There is a chasm between semantic conventional data management.

FIBO is comprehensive with detailed coverage of business entities, loans, securities, derivatives, and indicators.
Large financial institutions started implementations on RDF (“triple”) stores
The EDMC specified FIBO in Ontology Web Language (OWL).

and
OWL needs highly specialized ontologists.
IT departments must still support and design conventional databases.
It is difficult for Data Modelers to leverage the industry standard for RDBMS design.
F Finance key point 3

FIB-DM is the bridge across the chasm.

The Industry Standard is available in your Data Modeling tool.
F Finance key point 4

You work at a Financial Institution and already embrace model-driven development, industry standards, and reference models.

Data Architect/Modeler experienced in Enterprise Reference models. You may have used FIBO design patterns and definitions.
An Ontologist with an in-depth understanding of the FIBO, you already use the reference ontology for your design and want to spread adaptation across your enterprise.
Finance business stakeholder or Subject Matter Expert with a working knowledge of Entity-Relationship and Ontology diagrams.
F Finance key point 5

A deep-dive for all Data Architects

FIB-DM releases as a PowerDesigner Conceptual Data Model (CDM)

Enterprise Data Architects and Project Data Modelers.
https://fib-dm.com/semantics-for-project-architects-ppt/
Other data modeling tools, such as ERWin, can import the native model file.
https://fib-um.com/
Data Architect The Path

We teach this Full Model class at licensed FIs.
Open-source users find scope and name changes here:
https://fib-dm.com/open-source/
https://fib-dm.com/house-of-finance-15-business-concepts/

The Path to Becoming an Ontologist

Your Data Architects already know the Bank and Finance Industry.
2026: understand the FIBO Data Model
2027: derive your project and enterprise models from
FIB-DM.
Learn RDF/OWL
2028: Expert in both worlds, semantic and conventional.
Easy to master a new language and tooling if you already know the content and design.

FIB-DM training

You should have completed the Semantics classes for Managers and Project Architects.
Semantics for Finance Users, with its deep dive into the 15 Concepts, is a prerequisite.
Semantics for Extra Large Banks explains the ontology-to-data model transformation.
After this class, study articles II and III, which explain the semantic data model design patterns in detail.
F Finance key point 8

Introduction to the author and publisher.

Jurgen Ziemer has 20 years of industry experience as a data architect and ontologist at leading Financial Institutions and service providers.

Jayzed Data Models
Accenture

Seven years as an IBM Software Group Consultant for the Banking and Financial Markets Data Warehouse (BFMDW) model at 45 banks in North America, Europe, and Asia.

Four years implementing BFMDW at Citi and Deutsche Bank. • Speaker at FIBO conferences
IBM Credit Suisse
Deutsche Bank
Jayzed Data Models Inc. is a US consulting company incorporated in 1999.
Jayzed holds the FIB-DM copyrights and is the assignee of the Configurable Ontology to Data model Transformation (CODT) patent US12038939.
Citi
Reuters
German Stock Exchange
F Finance key point 9

EDMC and OMG collaborate closely

EDM Association is the member-driven trade association dedicated to elevating data management and analytics as a strategic business priority. Founded in 2005 as the EDM Council, we provide best practices, standards and education to data and business professionals in our data-driven world. https://edmcouncil.org/about/
The Object Management Group® Standards Development Organization (OMG® SDO) is a global, open membership, non-profit consortium. Our members collaborate to craft technology standards that offer measurable value to a diverse range of vertical industries. https://www.omg.org/
F Finance key point 10

EDM Council and Object Management Group

Global Association of over 200 Financial Institutions (FI).

Data Management

Data Standards. DCAM FIBO
Over 220 member organizations. Standards development (UML, BPML, DDS, SysML) CommonsOntology Library
The Enterprise Data Management Council acquired the Object Management Group (OMG) effective 1 October, 2025, creating the world’s largest non-profit trade standard-setting body for data management.
F Finance key point 11

FIBO and OMG Commons

The Financial Industry Business Ontology (FIBO) defines the sets of things that are of interest in financial business applications and the ways that those things can relate to one another. In this way, FIBO can give meaning to any data (e.g., spreadsheets, relational databases, XML documents) that describe the business of finance. https://edmcouncil.org/financial-industry-business-ontology/
The Commons Ontology Library provides a set of small ontologies designed to provide a useful set of modeling constructs that are reusable in different modeling and data deployment environments with minimal commitments.
Commons
OMG Commons is designed as a foundational or upper ontology, independent of the domain or industry.
The FIBO imports the OMG Commons ontologies, deprecating foundational classes in the Foundation module.
F Finance key point 12

The FIBO is superior to vendor data models

Almost six hundred years ago, Robert II d’Uzès proclaimed Charles VII King of France. Yet the “Involved Party” remains an ultimate supertype across numerous reference models and databases.
OMG Commons breaks the comingled entity into two fundamental concepts:

Agent (person or legal entity)
Role (customer, counterparty, borrower, employee …). One Agent, many Roles

Data Architect 13

The Vision: Semantic Enterprise Information Architecture (SEIA)

Use Type FIB-CM RDF FIBO OWL Level
Business Conceptual
FIB-DM

FIB-UM Enterprise
Design Logical

Data Model
Department
Physical
Development RDBMS
Implementation

RDF Project
Data Message Process Object
F Finance key point 14

The ontology, transformed into a data model, leverages the design for relational databases.

FIBO RDF OWL
FIB-DM Data Model
Configurable Ontology to Data-model Transformation
Semantic Triple Store Relational Database
F Finance key point 15

Semantic Model-Driven Development

Conceptual
Logical

FIBO is the domain ontology; FIB-DM is the conceptual data model.

A conceptual business model for the Financial Industry and applied at the enterprise level.

Logical models for data, message, process, and object derive from the ontology

The ontology at the architecture apex ensures common names, definitions and design across the enterprise.
F Finance key point 16

CODT is the superior technology

The patented Configurable Ontology to Data model Transformation
Configured for Logical Data Model naming convention
Scalable to transform very large ontologies like the FIBO

Complex ontology constructs into entities and relationships.
Complete FIBO Documentation in your data modeling tool
Ontologist 17

FIB-DM configuration settings

Source Ontology with connection parameters
Target tool and model • Name translation rules • Ontology module
Anonymous and equivalent classes
Object properties • Data properties
Annotation List
Inverse property list.

Parameter CODT_HOME Source Ontology Platform
File directory File or graph
Excluded modules Excluded classes Target Model Modeling Tool Type
Name Path
Transformation Rules Infer Packages Anonymous class Defined class
Object Properties Data Property Object Naming Rules Code
Name
Unique Names
E/R Comment property

VALUE
D:\FIB-DM\CODT Home
Topbraid Composer
D:\TBC Workspaces\FIBO-PROD_2025_Q3 FIBO\FIBO_DC_SM_LCC_CMNS.ttl
owl:Thing; owl:Nothing
PowerDesigner Conceptual Data Model
CODT\PowerDesigner\PD Models\FIB-DM NORM – 0 Excel Imports & Extensions.cdm
Yes
Do not transform Separate entity Associative Entity Attribute
Qname
Uncamel Localname Yes
skos:Definition, rdfs:comment
F Finance key point 18

Other data modeling tool imports struggle

URIs as entity names Datatype properties become classes
Class restrictions become anonymous pseudo classes
Tools can parse individual RDF/OWL files, but 250 FIBO files cause the import to crash.
Complex semantics require configuration and a holistic view of the source ontology:
Sub property of
Inverse object properties, sub-property hierarchy Duplicate name resolution
Class restrictions, some/all values from and unions
Data Architect Ontologist 19

Financial Industry Business Data Model

FIB-DM = FIBO in PowerDesigner (and other data modeling tools)

Financial Industry Business Data Model of 3,173 Entities, complete definitions, annotations, and axioms (business rules).

Data Architects leverage the full content of the Industry Standard.

Common Language and design patterns for Semantic & Relational databases.
F Finance key point 20

Transformation principles & considerations for the derived data model

The model must be practical.
Overly normalized designs become too abstract for business users and developers.
The model must be complete.
We don’t want to miss information from the ontology
The model has complete documentation. The diagrams depict all subject areas and design patterns.
The model maps back to its source, the ontology
Data Architect 21

From FIBO to FIB-DM, how does CODT work?

The Configurable Ontology to Data-Model Transformation is basic ETL.
RDF OWL
Extract Transform Load
We extract metadata from the source ontology, transform ontology metadata into conceptual data model metadata, and load it into the data modeling tool, PowerDesigner.
The extract process runs SPARQL on the ontology to get the metadata. PowerDesigner imports MS-Excel workbooks. The Transformation in between is a 2-step process using the patent-pending Metadata Sets.
Data Architect Ontologist 22

The CODT Metadata Sets.

The Extract process populates the Ontology Metadata Sets for classes, object-, data properties, and annotations.
Step 1 Step 2
Ontology Metadata Set

Generic EntityRelationship Metadata Set

Tool-specific Metadata Set
Step one transforms the ontology metadata and populates the generic ER representation. The Tool-specific metadata set is in PowerDesigner format. We serialize to MS Excel and load it directly into the tool. Step two is a simple conversion from generic ER to PowerDesigner objects, properties, and extended attributes.
Data Architect Ontologist 23

Transformation settings for Domain Ontologies

CODT, the patented, US12038939, Configurable Ontology to Data Model Transformation enables the ontologist and data architect to control the process and mapping.
To transform a domain ontology into a practical enterprise data model, we set:

Anonymous classes do not transform into entities.
The setting is to remove the clutter of entities that never become physical from the model. FIB-DM preserves anonymous classes used in class restrictions in the documentation.
Names transform from OWL Camel Case to LDM English Names (capitalization and spaces). E.g. fibo-fbc-fct-fse:DepositoryInstitution becomes Depository Institution
Object Properties transform to Associative Entities (not simple relationships).
This preserves the semantically important object property hierarchy and resolves open-world properties. Domain and Range, and Class Restrictions, determine the parent and child entities related to the associative entity.

Ontologist 24

From FIBO to FIB-DM

Ontology graph Transformation/mapping
Class to Entity

Conceptual Data Model
DepositoryInstitution
Subclass to Inheritance (subtype)
Object Property to Associative Entity

DepositoryInstitutionsubtype
Bank
<> Bank – provides (cmns)
<> provides (cmns)
<>
provides (cmns) -Demand Deposit Account
Demand Deposit Account
Class Restrictions, domain and range determine Relationships and Association Links
identifies (cmns) -Demand Deposit Account
<>
identifies (cmns)
<>
Bank Account Identifier – identifies (cmns) (D)
Bank Account Identifier
Ontologist 25

Domain ontology generates a perfect CDM

Ontology graph Conceptual Data Model
This entity-relationship diagram is DepositoryInstitutionsubtype the best representation of the Bank

Account, its provider, and ID. Bank

~
There are no missing or superfluous entitiesprovides (cmns) -Demand Deposit Account or relationships in the design. Demand Deposit Account
<> identifies (cmns)
F Finance key point 26

Ontology and Data Model in sync

MonetaryAmount LegalEntity
MonetaryAmount subtype LegalEntitysubtype
has Issued Capital-MonetaryAmount
Country
has Country-Country
<> has Country LegalEntity- has LegalAddress
Physical Address – has Country
(D)

Beyond owl:ObjectProperty range and domain, the ontology transformation infers data model relationships from class restrictions (here, OMG Commons Legal Entity)
Balance

<>
has Issued Capital Corporation
has LegalAddress
Physical Address
Corporationsubtype Physical Address subtype
Stock Corporation- has Issued Capital

<>
has LegalAddress -ConventionalStreet Address
(D) Stock Corporation ConventionalStreet Address
Data Architect Ontologist 27

A one-thousand-entity open-source model

F Finance key point 28

A self-contained, standalone data model.

Generic OMG Commons OMG Languages, Countries & Currencies Simple Knowledge Organization System Specification Metadata
FIBO Foundation
Domain Core

Free Open Source
FIBO Finance Business & Commerce FIBO Business Entities
FIBO Loans & Mortgages FIBO Business Processes
FIBO Corporate Actions & Events

FIBO Securities
FIBO Derivatives FIBO Indicators
Commercial License
FIBO Market Data FIBO Collective Investment Vehicles
F Finance key point 29

FIB-DM: Two-pronged learning approach

Enterprise Architecture
Focus on hierarchies of the 15 Concepts and Associative Entities

Solution Architecture
Focus on FIB-DM packages (FIBO modules) for the project – not the whole model.
F Finance key point 30

15 Fundamental Business Concepts

The fifteen concepts are extensive ultimate supertypes in the Financial Industry Business Data Model. In other words, they have the most subtypes and the most relationships.
In the FIBO ontology, the fundamental fifteen concepts are direct subclasses of the Thing.
We use abbreviations and icons as mnemonics to teach the concepts to modelers and business users.
F Finance key point 31

The 15 concept names, icons, and abbreviations

SIT Situation
A Agent
OCC Occurrence

R Role
ASP Aspect
TE Temporal Entity

D Designation
SP Specification
DOC Document

CST Constituent
ARR Arrangement
SQ Scalar Quantity

COL Collection
M Measure
ACT Account
F Finance key point 32

Concepts are Ultimate Supertypes in the data model

The table shows the number of subtypes under the ultimate supertype.
Concept Situation Role Designation Constituent Collection Agent Aspect Specification Arrangement Measure Occurrence
TemporalEntity Document ScalarQuantityValue LegalConstruct Reference
Facility Product Account Location Grand Total

Subtypes 1272
604 151 138 136 135 133 132 118 81 78 57 56 53 46 45 31 21 19 13 3319
1400
Concept 1200
1000
800
600
400
200
0
F Finance key point 33

Concept map corresponds to the data model

Legal Entity
Identifier
identifies
Monetary has Issued Capital Amount
has Country
has Legal Address
Stock Corporation
Plays Role

Physical Address
Registration registers Authority
Depository Institution
Is registered In
FDIC Certificate Number
FDIC Registry Entry
Data Architect 34

FIB-DM Packages – folders and dependencies

The PowerDesigner screenshot shows the Base Packages diagram.
The object browser expands the structure of FIBO Loans and Mortgages.
Leaf-level packages, e.g., “Card Accounts”, transformed from FIBO ontologies.
Mid-level packages, e.g., “LOAN-Loan Specific” group related ontologies.
Top-level base packages are containers: 11 FIBO and 2 OMG.
Data Architect 35

Package folder structure

The data model package hierarchy is identical to the FIBO folder structure in the EDMC zip release and on the web. https://spec.edmcouncil.org/fibo/ontology/LOAN/LoansSpecific/Car dAccounts/
The ontology prefix is an abbreviation. For example, in CardAccounts.ttl:
@prefix fibo-loan-spc-
crd:
The data model package name is an “uncamel” of the FIBO ontology name. The package code is the prefix:
Card Accounts, fibo-loan-spc-crd
FIBO Prod zip directory FIB-DM Packages
Data Architect 36

Package dependency diagrams

The package folder structure simply specifies where ontology or data model objects are located. The package diagrams depict the major package dependencies.
The arrows derive from FIBO/OMG owl:imports and from supertype/subtype relations among FIB-DM entities.
On the previous page, the Loans Ontology imports FIBO Foundation, Business Entities, and Finance Business & Commerce (FBC).
The FIB-DM Loan entity is a subtype of the Credit Agreement, defined in FBC.
The Loans & Mortgages package diagram shows 3 mid-level packages and 6 leaf-level packages for Loans in general and specific types of Loans.
Data Architect 37

Release notes: packages vs subject areas

ERWin imports packages in the native PowerDesigner model file as Subject Area.
They don’t have a hierarchy. Hence, we see a flat list of LOANS subject areas.
All FIB-DM entities are at the model level – not within the packages.
FIB-DM package entity diagrams use object links rather than entities directly.
This is because some data modeling tool imports require a flat list.
You can copy entities into the PowerDesigner packages or ERWin subject area if you prefer: switch to physical names, search Card Account entities (starting fibo-loan-spc-crd), and copy them into the Cards package/subject area.
Data Architect 38

Package Entity diagrams

The diagram shows all entities in the FBC Guaranty Package. The FIBO has the package under Finance, Business & Commerce – not under Loan, because Guarantees are also used for Fixed Income Securities
Diagram convention: Associative Entities are blue. Base Entities are yellow.
The stamp shows the Model, Package, and Diagram names, the author, copyright, date, FIB-DM, and FIBO version.
Relationship names the related entities, delimited by a hyphen. The Stereotype is parent or child. We read: Issuer issues a Letter of Credit.
The Base Entity cardinality is typically 0:1, unless the source ontology specifies a minimum or exact cardinality.
Data Architect 39

Package Properties

The Package Name is the rightmost string in the ontology namespace.
CODT transforms the ontology prefix into the package’s unique code.
Note: All ontology classes, properties with the prefix fibo-loan-reln-mtgbecome model objects of the Mortgages package.
The URI is the Uniform Resource Identifier of the ontology. It is a traceability link to the model object’s source.
The Package Properties box has three tabs: Annotations, Lineage, and Extended Attributes
Data Architect Ontologist 40

Package annotations

Ontology Annotation Properties transform into PowerDesigner Extended Attributes (ERWin: User-Defined Properties).
The tab shows the most common package annotations.
Note that only some packages will have annotations.
The example, OMG Commons Roles and Compositions, shows the Label, Contributors, and a Note.
Data Architect Ontologist 41

Package lineage

The Lineage tab shows transformation and FIBO properties.
The Resource Name is the origin for the Package code.
The Resource Type is owl:Ontology.
The Abstract is a brief description in some ontologies.
The Copyright and License the original of the source ontology (as required by the OMG and FIBO open source license).
The FIB-DM license is the Jayzed IPLA for the commercial version and GPL 3.0 for the open-source core.
Please ensure that your derived works retain the Jayzed, OMG, and EDMC copyright and license notes.
Data Architect Ontologist 42

Package extended attributes

The PowerDesigner-generated tab lists all Package Extended Attributes derived from ontology annotation properties.
After migrations into other data modeling tools, the ontology annotations properties may show in their tool-specific representations. For example, ERWin preserves Extended Attributes as User-Defined Properties (UDP).
Data Architect Ontologist 43

Entity properties

The Name is the ontology class Localname, converted from Camel Case to LDM naming convention (capitalized with a space between words).
The Code transforms from the ontology class Prefix:Localname.
The Comment populates from the class annotation RDFS comment and SKOS definition.
There are two tabs for ontology derived data models, Annotations and Lineage.
Data Architect Ontologist 44

Entity annotations

FIBO classes have extensive documentation captured in ontology annotation properties.
Source, Abbreviation, …, to Usage Note are only documented for some classes.
Hence the textboxes are blank for most entities.
A deprecated Entity means that the deprecated FIBO class will be removed in future releases.
Defined By defaults to the source ontology (=the Package code in FIB-DM).
RDFS Comment or SKOS Definition provide the Entity Comment.
Likewise, Label, See Also, Note, Editorial, and Scope Note are only populated for Entities where they are applicable.
Data Architect Ontologist 45

Entity lineage

The Lineage tab captures ontology metadata of the source class. The extended attributes provide traceability into the ontology and preserve semantics beyond the entity-relationship model.
The Resource Name is class Prefix and Localname. FIB-DM uses the resource name as the entity code,
but you can generate your codes in the modeling tool.
The Prefix is an abbreviation of the source ontology URI.
The Resource Type indicates the ontology object that derived the data model object: OWL Class, Datatype Property, Object Property, or Ontology.
The Uniform Resource Identifier of the class is a link into the FIBO source ontology.
Restriction and Equivalent class axioms formulate higher OWL semantics. They are important Business Rules for DBAs and developers.
Individual Labels are example values derived from class instances.
Data Architect 46

Entity Restriction

Class restrictions limit the set of allowable instances. For example, the Obligor must have an Obligation to some Commitment.
fibo-fnd-agr-agr:hasObligation some fibo-fnd-agr-agr:Commitment
Note that the ontology object property hasObligation transformed into an Associative Entity in the data model. The transformation processes the class restriction and creates Relationships from Obligor to the associative entity hasObligation. Class restrictions also determine relationship cardinality. Here, the Obligor must have at least one obligation.
Class restriction can be very complex logical expressions. Even the Obligor restriction below is beyond ERM expressivity. The Obligor plays a role as a party to an agreement.
fibo-fnd-pty-rl:isPlayedBy some (fibo-fnd-pty-pty:isAPartyTo min 0 fibo-fnd-agr-agr:Agreement)
FIB-DM does not transform anonymous classes (= restrictions) into pseudo entities.
However, FIB-DM preserves these business rules for the benefit of downstream physical modelers and application developers.
Data Architect Ontologist 47

Entity Equivalent

Defined Classes in OWL specify conditions for their members. Unlike for the Primitive Class, we don’t CONSTRUCT (~ SQL INSERT) instances of the class. The inference engine, a.k.a. Reasoner, determines the Instances that match the equivalent condition. For example, the FIBO LEI Registered Entity is equivalent to
cmns-id:isIdentifiedBy some fibo-be-le-lei:LegalEntityIdentifier.
FIB-DM has entities transformed from equivalent classes. The Equivalent Lineage attribute is a hint for the physical modeler to consider a VIEW or ALIAS.
Defined classes may have more complex conditions. For example, the Fixed Float Interest Rate Swap has a Fixed and a Floating Leg.
fibo-der-rtd-irswp:InterestRateSwap and (fibo-der-drc-swp:hasLeg some fibo-der-rtd-irswp:FixedInterestRateLeg) and (fibo-der-drc-swp:hasLeg some fibo-der-rtd-irswp:FloatingInterestRateLeg)
Important business rules for ETL architects populating a FIB-DM database.
Data Architect Ontologist 48

Multiple Inheritance

An ontology class can be a subclass of more than one parent class. For example, the Central Bank is both a Bank and a Monetary Authority.
Multiple Inheritance makes sense from a business perspective, and as a conceptual model, FIB-DM keeps multiple supertypes.
However, the LDM permits only one supertype. Note that object models also allow multiple inheritance. The Logical Data Modeler can use these techniques to resolve multiple inheritances:
a) The issue goes away. A logical project model derived from FIB-DM may not include the Monetary Authority in its scope. Then the Central Bank has only one supertype, the Bank.
b) The Logical Modeler changes one or both subtypes into dependent relationships. In the diagram, both Bank and Monetary Authority identifiers constitute the key for the Central Bank.
Bank (D) (D) Monetary Authority
Banksubtype Monetary Authority subtype
Central Bank
Data Architect Ontologist 49

Entity Attributes

The FIBO domain ontology is a Business Conceptual Model that defines concepts using classes and object properties. There are only 232 data properties in the source ontology.
Hence, FIB-DM is an entity-level conceptual data model, sparsely attributed, and has no keys.
The PowerDesigner CDM has Data Items. These are model objects independent of the entity. The Data Item then gets attached to the entity as an attribute. Data Items as a model object disappear when the modeler derives an LDM from the CDM.
Currency
The transformation creates Data Items from source ontology data properties. The property domain and class restrictions determine attributes on an entity.

Currency Name Minor Unit Numeric Code Name

Variable characters Variable characters Variable characters Variable characters
Data Architect Ontologist 50

Associative Entities

CODT transforms Ontology Object Properties into Data Model Associative Entities.
Object Property Domain and Range, and Class Restrictions determine FIB-DM relationships between Base and Associative Entity. The diagram notations are yellow for Base and blue for Associative Entities. A stereotype indicates the relationship role: Parent, Child, or Dual (both).
In the example diagram, a Registrar or Registration Authority registers a Legal Entity Identifier or National Securities Identifying Number.
Object Properties are multi-valued, so Associative Entities may have relationships with many Base Entities.
The Logical Data Modeler applies the appropriate LDM design pattern.
Data Architect Ontologist 51

Associative Entity hierarchy

Hierarchies of object properties are an essential OWL construct and widely used in the FIBO.
The default configuration to transform a domain ontology into an EDM, therefore, creates subtypes of Associative Entities from rdfs:subPropertyOf.
<> governs
governssubtype
governsPayment Of
regulatesSupply Of
hasJurisdiction
hasGoverning Jurisdiction
For the LDM, we recommend scoping the most specific level (the lowest in the hierarchy).
Data Architect Ontologist 52

Associations, a Star Schema?

The context diagram below shows the identified Association and some participating entities.
Indeed, the diagram looks like a Star Schema (with a “factless” fact table in the center). While this is perfectly fine for a dimensional data model, and the model check doesn’t complain, the denormalized design would not be appropriate in a logical data model.
However, as with multiple inheritance, we prioritize clarity of the design for business users over 3rd Normal Form correctness. The Logical data modeler would
a) Rolename relationship (e.g., identifies Currency)
b) Add a type of identification (e.g., with value Currency_Identification)
Data Architect 53

Multi-valued association resolved.

After scoping and attribution, the logical data modeler can resolve to 3NF:

Once the modeler removes entities without attributes, the issue may disappear.
The standard 3NF resolution breaks down the “identifies” association with role-named associations (a subtype of identifies). E.g., Bank Identifier identifies Bank. The entity Lineage tab Restriction on Bank Identifier shows the class restriction.
A relationship Role can be added to stipulate the identifier. For example, a Security Identifier Type can indicate whether the application should look for a Security Identifier or a National Securities Identifying Number.
The Physical modeler can decide to roll up or roll down the “identifies” subtypes.

As said before, FIB-DM does not prescribe how the data modeler resolves the design.
identifies IdentifiesSelector identifies identifiesSelector Type
identifiesSubtypes
identifiesCurrency identifiesBank identifiesAccount
Currency isIdentified by Currency Currency Identifier identifiesCurrency
BankisIdentified by BankIdentifier BankIdentifier identifiesBank Account isIdentified by Account Identifier AccountIdentifier identifiesAccount
Currency Currency Identifier Bank BankIdentifier Account Account Identifier
Data Architect 54

Relationships

FIB-DM uses Associative Entities to model ontology object properties.
Hence, Relationship model objects are merely connecting entities to associative entities. They transform from object property domain, range, and class restriction.
The code’s naming convention is “parent entity – child entity.” For example:
ibo-fnd-acc-cur:CurrencyIdentifier_cmns-id:identifies
Likewise, Relationship Name and Comment are generated as per the CODT configuration settings. The stereotype indicates the relationship role.
Data Architect 55

“ONLY” Associative Entities.

Derived from the like named class restriction, “only” Associative Entity limits the participating Base Entities.
The OMG cmns-col:hasMember object property, for example, has numerous related classes.
However, the Organization has a class restriction:
cmns-col:hasMember only cmns-pts:Party
Organization(cmns)
Organization(cmns) – Organization(cmns) onlyhas Member (cmns)
<> has Member (cmns)
has Member (cmns) onlysubtype
Organization(cmns) onlyhas Member (cmns)
In other words, only a Party (nothing else) can be a member of an Organization.
FIB-DM models the business rule by creating a subtype of has Member with only Organization and Party as related Base Entities.
This concludes the structural overview of the model.
Party- Organization(cmns) onlyhas Member (cmns)
Party
Data Architect 56

Resources for further study

Find selected diagrams on the FIB-DM website or your Full Model delivery zip folder.

Open-source users can review the PowerPoint in MS Office Online and download a PDF.
Full Model licensees find the PPTX file in their delivery folder.
https://fib-dm.com/diagrams/
Study the articles for a deeper understanding of hierarchies and Associative Entities.
https://fib-dm.com/ontology-object-property-data-model-associative-entities/
https://fib-dm.com/semantics-for-data-architects/
https://www.youtube.com/@FIBDM/courses
Watch the YouTube Course with this and other lectures:
Data Architect 57