The class is an advanced deep-dive into the FIBO Data Model. The 57-page PowerPoint deck takes 3 hours in a class with follow-along, questions, and discussion.

The 1 ½ hour lecture video has two parts:

This first half covers the challenges Data Architects face when adopting and leveraging the industry-standard Financial Industry Business Ontology (FIBO). The class is for all Data Architects, project or enterprise modelers. It is the PowerPoint deck used in Financial Institutions that have licensed the Full Model, but it is fully applicable to open-source users. We look at the FIB-DM source ontologies FIBO and OMG Commons and their creators, independent industry trade organizations and standard-setters, the Enterprise Data Management Council, and the Object Management Group. The vision is Semantic Enterprise Information Architecture and Semantic model-driven development. The class shows where data modeling tool transformations lack, and why the Configurable Ontology to Data model Transformation (CODT) is superior. We show that the older, smaller FIB-DM Core is a good standalone model and what content the Full version adds. 15 Fundamental FIBO/OMG concepts are ultimate supertypes in the data model. The FIB Concept maps provide simplified diagrams for design and scoping with business users.

The second part of the class is about the FIBO Data Model structure. We review FIB-DM packages derived from the FIBO/OMG ontology folder structure and the package dependencies depicted in the diagrams. The video explores Base and Associative Entities with their design patterns and documentation properties. Relationships connect the Base to the Associative Entity. The PowerDesigner Extended Attributes (ERWin User-Defined Properties) preserve the extensive FIBO/OMG documentation. We explain semantic model design patterns and considerations when generating Logical and Physical data models from FIB-DM.

Review the PowerPoint on MS Office Online and download a PDF here.

The Transcript of the lecture.

Part 1

Welcome back to the FIBO Data Model training. This is Jurgen. Today, Semantics for Data Architects is a deep dive into the structure of the ontology-derived enterprise data model.

The FIBO is the authoritative standard of financial industry concepts, their definitions, and relations. The Enterprise Data Management Council, the EDMC, is a global association of more than 200 financial institutions. They teach data management best practices, and they develop and implement industry standards.
EDMC members, in other words, banks and investment companies, developed the Financial Industry Business Ontology, the FIBO, as a business conceptual model.
It has more than 2,400 classes that detail Financial Instruments, Business Entities, and processes. (as of release 2025/Q4)
Now, because it is the business conceptual model, the FIBO conceptualization and relations are fully applicable to lower-level semantic taxonomies, concept maps, object and data models. And one of these is the FIB-DM, which is a perfect Conceptual Data Model.

There’s a chasm between semantic and conventional data management. FIBO is comprehensive with detailed coverage of Business Entities, Loans, Securities, Derivatives, and Indicators. However, the EDM Council specified the FIBO in Ontology Web Language (OWL). Large financial institutions started implementations on specialized databases, RDF “Triple” Stores. OWL needs specialized ontologists, and IT departments must still support and design conventional databases.
And as I found out when I first looked at the FIBO 7 years ago, it is difficult for even senior data modelers to leverage the industry standard for relational database management system design.

FIB-DM is the bridge across the chasm. The FIBO in PowerDesigner and other tools. The industry standard becomes available in your data modeling tool.

You work at a Financial Institution that already embraces model-driven development, industry standards, and reference models.
This class is primarily for data architects/data modelers with experience in enterprise reference models. You may have used FIBO design patterns and definitions.
It’s also for ontologists. If you have an in-depth understanding of the FIBO and already use the reference ontology in your design, it’s a way to spread adaptation across the enterprise.
And finally, Finance users, Business Stakeholders, and Subject Matter Experts with a working knowledge of entity-relationship and ontology diagrams.

This class is a deep dive for all data architects, and it’s also a path for you to use FIB-DM and build up semantic skills and ontology knowledge.
FIB_DM is released as a PowerDesigner Conceptual Data Model CDM. However, other data modeling tools can import the native model file. In particular, ERWin does a great job importing. It’s straightforward and completely takes in the PowerDesigner model without any loss of structure or documentation.
The class is also for both Enterprise Data Architects who look at FIB-DM top-down and Project Data Modelers who have a more middle-out approach, exploring individual model packages. There is also a class, Semantics for Project Architects.
A word here: throughout this deck, there are links, and on the FIB-DM website, you can download a PDF of this PowerPoint. So, you don’t have to stop the video and write down links.
This deck is what I teach at licensed Financial Institutions. However, open-source users can find the scope and name changes here: There’s a page about the open-source version, and this “House of Finance 15 Business Concepts” list actually shows the new OMG names and their previous FIBO names that are still in the open-source version.
And of course, on FIB-DM.com, you can download the FIB-DM Core model.

This is what I mean about the path of becoming an ontologist. And for managers, I say your data architects already know the bank and finance industry, and they will make the best ontologist at your financial institution. The path means: In this year, understand the FIBO Data Model. Then next year, derive your project and enterprise models from FIB-DM. And as you do that, study and learn RDF/OWL. With that, you will become an expert in both worlds, the Semantic and Conventional.
It’s easy to master a new language and tooling if you already know the content and design.

Here’s a chart of the complete FIB-DM training course. You should have completed the classes for Managers and Project Architects. Semantics for Finance Users really is a deep dive into the 15 Concepts. I would say that’s a prerequisite for understanding this advanced class, Semantics for Data Architects. Also, you should have learned about the Semantics for Midsize, Large, and Very Large Banks. They’re all flavors of the same thing, and it is worth studying all three decks. Um, in particular, the “Very Large Banks” explain the ontology-to-data model transformation. It’s kind of like a better understanding of what we are looking at today.
And after this class, you should study the articles, in particular article two, “Ontology versus Data Model Hierarchy,” and, probably, the most important one, “Object Properties are Associative Entities. Because they explain the Semantic Data Model design patterns in detail.

About myself, I um worked in Finance for 20 years. In particular, I was an IBM Software Group consultant for their data model, the Banking and Financial Markets Data Warehouse, and in that capacity, I trained architects on the model and advised them on implementation in North America, Europe, and Asia. Yeah.
After that, I consulted Citi and Deutsche Bank on the IBM Model implementation. Since its beginning 7 years ago, I have been a speaker at FIBO conferences. My company, Jaysed Data Models, is a US corporation and has been in business since 1999.
Jayzed holds the FIB-DM copyright and is the assignee of the Configurable Ontology to Data Model Transformation (CODT) patent US12038939.

The EDMC and OMG have been collaborating very closely for several years now.
The EDM Council is, in its own words, a member-driven trade association dedicated to data management and analytics. It was founded in 2005, and as I said before, they teach best practices, standards, and education to business professionals.
The OMG is a standards development organization. It’s global, and I think there are over 200 large companies that are members. It’s nonprofit, and uh, they craft technology standards.

EDM Council Object Management Group
Global association of over 200 financial institutions, and you are probably a member of the EDMC. They teach data management, and you have probably taken out that exercise now with the EDM council, the Data Management Capability Assessment Model. Well, EDMC has developed the FIBO, and the Object Management Group is well known. More than 220 member organizations. We all know their standards, the Unified Modeling Language and Business Process Modeling Language.
Three years ago, they published the first version of the Commons Ontology Library. And now the two have merged. The Enterprise Data Management Council acquired OMG effective October 1st, 2025, and the combined EDM association is the world’s largest nonprofit trade organization and standard-setting body for data management.

FIBO and OMG Commos.
The Financial Industry Business Ontology defines the set of things of interest in Financial Business and how they relate to one another.
With that, the FIBO gives meaning to data in the organization. That is the OKG, the Ontology Knowledge Graph.
Data in the organization can be spreadsheets, relational databases, XML documents, and so on. Here’s a link to the FIBO page on the EDM Council website.
The OMG Commos Library has a set of small related ontologies that provide useful generic modeling constructs and can be used across different modeling and data deployment environments.

So, OMG Commos is designed as a Foundational or Upper Ontology. It is independent of the domain or industry, and the FIBO imports OMG Commons ontologies. And with that, the FIBO deprecated foundational classes in the FIBO Business Entities, Business Finance & Commerce, and Foundation modules.

“Le roi est mort, vive le roi!”

The vision is Semantic Enterprise Information Architecture (SEIA).
When we look at Architecture, we can differentiate by the use: Is it for Business, Design, or Development?
By the type of the artifact: Is it Conceptual, Logical, Physical, or is it an implementation?
And we can look at the level where it applies: Is it enterprise-wide, departmental, or for individual projects?
Today, we already have Conceptual and Logical Data Models that we physicalize and deploy in RDBMS.
We have XSD for messages, BPMN for processes, and UML for object models and code generation.
What is new is that we have the FIBO in RDF/OWL, and that deploys on RDF stores.
With FIB-DM, we use FIBO as the Conceptual Data Model. And we can also generate other models, like UML, out of the FIBO.
Finally, there is FIB-CM, the Concept Maps. They are a simplified diagram for business users that we keep in sync with the data model and ontology.

The way to SEAI is model-driven development.
We have relational databases and now also semantic “Triple stores” (RDF stores).
We have the industry-standard FIBO in RDF/OWL, and we have always had data models that deploy on RDBMS.
With CODT, the Configurable Ontology to Data model Transformation, we have the sibling of the FIBO, FIB-DM, as a conceptual data model.

How do we derive in Semantic Model-Driven Development?
At the conceptual level, we have FIBO as the domain ontology and FIB-DM as its conceptual data model. It’s for the Financial Industry, for the Bank or Investment Company, and applied at the Enterprise-level.
Then, at the logical level, we scope the Data, Message, Process, and Object models from the ontology or FIB-DM.
Finally, at the physical level, we deploy the design across relational databases, other architectural artifacts, applications, messages, XML, and so on.
So the ontology is at the apex of the architecture, ensuring common names, definitions, and design across the enterprise.

CODT is the superior technology, and it’s patented.
The Configurable Ontology to Data model Transformation.
“Atlantic CODT” is a version of it that really became production-grade.
You can learn more about the Atlantic version in Semantics for Extra-large Banks.
So, it’s configured for a Logical Data Model naming convention.
It’s scalable to transform very large ontologies like the FIBO. If you remember, the FIBO has almost 2500 classes, and the FIBO download on the EDM Council website has 250 RDF files.
CODT can process very complex oncology constructs into entities and relationships. So it goes way beyond the simplistic approach of class-to-entity and object property-to-relationship.
Also, CODT transforms the complete FIBO documentation. You have it in your data modeling tool, in PowerDesigner as Extended Attributes, and in ERWIn as User-Defined Properties.

Here are the configuration settings for the latest FIB_DM version. They determine what the model looks like.
We have information about the source ontology, which can be either an ontology development platform such as Topbraid or Protégé, or an RDF/Triple Store.
Typically, we exclude the owl:Thing sync and owl:Nothing. So that they don’t generate an entity.
We have a target model, and in that case, that’s only PowerDesigner because PowerDesigner has very sophisticated import functionality for MS Excel spreadsheets. We can specify the type in our case, FIB-DM releases, as a conceptual data model. Give it a name, a destination path, and transformation rules.
We infer packages. In other words, FIBO/OMG ontologies become packages in the PowerDesigner model and Subject Areas in ERWin. We do not transform Anonymous Classes. Anonymous classes are defined classes that do not get instantiated (loaded with triples) on the ontology platform. And a named defined class becomes a separate entity. This is important because in some cases, we have an alias in the FIBO. So the Equivalent Class means that an instance of class A is also an instance of class B. And in FIB-DM, it becomes a separate entity marked as a Defined Class.
Object Properties become Associative Entities – not relationships.
Data Properties are Attributes.
For the names, we can say where the code comes from, that’s a Qualified Name, and the name is basically an “uncamel” of the Local Name.
There are some more rules to configure how to deal with duplicate names.
And finally, the PowerDesigner Comment Property and (in ERWin, that’s the definition) we derive it from uh the skos:Definition or rdfs:Comment on the ontology class.

Data modeling tool imports struggle.
For example, some would create entity names from URIs, which doesn’t help the data modeler, and would create classes from Data Properties.
Some imports would take class restrictions and create anonymous pseudo-entities from them.
A data modeling tool can pass individual RDF/OWL files, but with 250 FIBO files, a very large data model, it can simply cause the import to crash.
Complex semantics in OMG, and the FIBO require configuration and also a holistic view of the source ontology.
Holistic means we must look at all 2,500 FIBO classes. We must look at all 700 FIBO Object Properties.
An example is how you treat Inverse Object Properties.
The simple transformation that tools do is from Object Property to Relationship.
Here we see a loan has a Principal Amount, the CD has a Notional, and the Fund has a Monetary Amount. In the FIBO, these object properties are a hierarchy.
The Principal is a subproperty of the Notional Amount. The correct way to transform this is to use Associative Entities and a data model subtype to model the hierarchy. Another issue: Inverse Object Properties. That’s where you have the opposite object property. So in the FIBO, you find “manages” and “is managed by”. However, in a data model, we do not draw two lines between the entities. Now that would be wrong.
In order to identify inverse object properties and to resolve them:
First, we must have that holistic view of all object properties,
And second, we need configuration rules that tell how we deal with inverse object properties. The configuration in CODT is simple: we use the active form of the object property.
Also, sometimes, we may have to resolve duplicate names. So, we need a configuration rule that helps us to create a unique name in CODT. Typically, that is adding the source ontology code to the entity name.
Yeah, and then there are complex class restrictions. “Some Values” of “All Values from,” Unions. It is important that an ontology-derived data model contains all associations, not simply Domain and Range. And CODT is the only transformation that fully harvests all relations in the FIBO.

The Financial Industry Business Data Model (FIB-DM), the FIBO in PowerDesigner, and other modeling tools.

It has 3,173 entities as of the latest version (Q4/2025), with complete definitions, annotations, and axioms (the business rules).
Data Architects leverage the full content of the industry standard.
We achieve a common language and design patterns for semantic and relational databases.

Some of our principles and considerations:
The derived data model must be practical and complete.
We don’t want to miss any information or metadata from the source ontology.
It must include complete documentation and diagrams depicting the subject areas and design patterns. And finally, the model makes maps back to its source, the ontology.

How does CO work from the FIBO to FIB-DM?
The Configurable Ontology to Data model Transformations is basic ETL.
On the left-hand side, we have the owl. On the right-hand side, we have the PowerDesigner data modeling tool. We Extract, Transform, and Load.
We extract metadata from the source ontology, transform ontology metadata into Conceptual Model metadata, and load it into PowerDesigner. The extraction process runs SPARQL on the ontology platform to retrieve metadata. PowerDesigner imports MS Excel workbooks, and then the transformation becomes a simple two-step process using the patented Metadata Sets. This is a two-step process with the CODT Metadata Sets. An extraction process populates the Ontology Metadata Set for classes, object properties, data properties, and annotations.
And step one transforms metadata and populates the generic Entity-Relationship representation.
And the Tool-Specific Metadata Set is in PowerDesigner format. We create an MS Excel that we can directly import into PowerDesigner. Step two is a simple conversion from generic, entity-relationship to PowerDesigner Objects, Properties, and Extended Attributes. One note here, PowerDesigner has a very sophisticated import for Excel spreadsheets that can create entities, relationships, and so on. ERWin doesn’t have that functionality. So, if you want to create an ERWin Tool-Specific Metadata Set, you have to code the API. That is the reason why the FIB-DM master file is in PowerDesigner. Even for CODT licenses, I don’t recommend coding a direct import, since it can easily import a PowerDesigner file. So that means the easiest way is to take one PowerDesigner license and then import it into ERWin.

Transformation settings for industry-domain ontologies such as FIBO.
The CODT patent US12038939, Configurable Ontology to Data model Transformation, enables the ontologist and data architect to control the process and mapping and to create a practical, usable Enterprise Data Model. We set:
Anonymous classes do not transform into entities. Instead, FIB-DM harvests all entity associations that are stipulated in the defined class. And the full Class Restriction is preserved in the entity documentation. Names transform from our “camel case” to logical data model English names. Basically, capitalize the first letter and insert a space.
Here, the Finance, Business & Commerce “DepositoryInstitution” becomes “Depository Institution.”
Object properties transform to Associative Entities, not simple relationships. That preserves the semantically important object property hierarchy, and it resolves open-world properties. Domain, Range, and Class Restrictions determine the parent and child entity related to the Associative Entity. In other words, they determine the relationships in the FIBO Data Model.

The ontology-derived data model.
On the left-hand side, we have an ontology graph from the FIBO. It shows a Bank Account Identifier, which “identifies” a Bank Account. The Bank Account is “provided by” a Bank, which is a subclass of a Depository Institution.
On the right-hand side, we see the derived Conceptual Data Model.
We see Classes transform into Entities.
The Subclass in the ontology transforms into a data model, Inheritance, or Subtype.
Object Properties transform into Associative Entities (not relationships).
And finally, the relationships between Base Entities and Associative Entities: The Cardinalities derive from Class Restrictions, Domain, and Range. This mapping diagram actually is Figure 1 of the CODT Patent Drawings.

The Domain Ontology generates a perfect Conceptual Data Model.
This entity-relationship diagram is the best representation of the Bank Account, its provider, and ID that a senior data architect would come up with.
There are no missing entities, no unnecessary entities or relationships in the design.

Ontology and data model are the same, 100% in sync.
Here, we see a FIBO ontology graph. A Stock Corporation with a class restriction that it has to have Issued Capital, which must be one Monetary Amount. The Monetary Amount has a child, Balance.
Furthermore, the Stock Corporation is a Corporation which is a Legal Entity, and the Legal Entity has a Street Address, which is a Physical Address, and has some Country.
The generated data model shows the Stock Corporation, a subtype of Corporation, which is a subtype of Legal Entity.
The Stock corporation has an Associative Entity “has Issued Capital” pointing to the Monetary Amount, and it is a subtype of the Balance.
The Legal Entity has a Legal Address, the Street Address, a subtype of Physical Address, which has a country.
Beyond Object Property Range and Domain, the ontology transformation infers data model Relationships from Class Restrictions. Here, the OMG Commons Legal Entity, which has a Class Restriction, drives Associative Entities and Relationships in the data model.
That is what makes a CODT superior to other transformation attempts.

The open-source version is a 1,000-entity model derived from FIBO 2018/Q4. It has more than a thousand entities, comprising FIBO Foundation, Finance, Business & Commerce, and Business Entities.
Here’s a chart showing the Full Commercial Version as of 2025/Q4: 3,173 entities
We see the major changes, including the addition (the import) of OMG Commons, which replaced entities in FIBO Foundation and Finance Business & Commerce.
We see the new Loans package with over 100 entities.
But there’s far more in the FIBO than just Loans. That is because anything shared between Loans and Fixed Income Securities, such as the Guarantee, as we will later see, has moved to FIBO Finance Business & Commerce. Both Loans and Securities import the same upper-level constructs. The huge package in the FIBO has always been Derivatives. Indicators include market and economic indicators. We have Corporate Actions.
Here, we see SKOS and Semantic Metadata, which don’t generate many entities. It’s mainly for annotation properties that are transformed into data model documentation items.
We have OMG Languages, Codes, and Countries that are also present in the open-source version.
The direction OMG is taking is that more and more of its LCC content is being incorporated into Commos.

FIB-DM open-source is a self-contained, standalone, quality data model.
We can look at the level of detail here. The utmost level generic is where the ultimate supertypes in the data model are.
We have a Domain Core and a Domain Detail. Generic packages are OMG Commons; in the open-source section, the white area includes OMG, LCC, SKOS, and Specification Metadata.
And then we have the Domain Core FIBO Foundation and its specializations, Finance, Business & Commerce, and FIBO Business Entities.
And then in the Commercial License, shaded in green, we have Domain Detail, FIBO Loans, Securities, Corporate Actions, Derivatives, Indicators, Market Data, and Collective Investment Vehicles. In other words, Funds.

The key to the industry standard is a two-prong learning approach.
Enterprise Architecture focuses on the hierarchy, the 15 Fundamental Concepts, and Associative Entities.
Whereas Solution Architecture, Project Modelers, and Application Architects focus on FIB-DM packages, the FIBO modules for the project, not the whole model.
Here, for example, they may pick FIBO Loans & Mortgages rather than rationalizing the whole 3,000 entities top-down.

We learned the 15 Fundamental Business Concepts in “Semantics for Finance Users.” Here is a picture of all of them, the 15 Major Concepts and the Minor Concepts at the bottom. It kind of resembles a house.
All 15 Concepts are extensive Ultimate Supertypes in FIB-DM. In other words, they have the most subtypes and the most relationships.
In the ontology, the Fundamental 15 Concepts are direct subclasses of The Thing.
And we use abbreviations and icons to teach the Concepts to modelers and business users. In other words, you use the icons, the conformed names, and arrows to communicate your design with the user rather than a complicated E-R diagram or ontology graph. So, 15 Concepts all with a name, an icon, and an abbreviation.
Let’s do a 10-second rundown:
Situation = Contracts and Agreements.
The Agent is what Concept is: the Person or a Legal Entity.
The Role is what it does as an Employee, Borrower, Lender, Regulator, and so on. designation mainly used for IDs. Constituent details um contracts.
Collections are groupings or lists of things.
Aspects are dimensions of other concepts.
Specifications can be Technical Documents or Expressions and Formulas.
Arrangements are mainly used for Codes and Code Sets.
Measures are what we observe in the real world, Economic measures, Market measures, and so on.
Occurrence is Events including Transactions.
The temporal entity has Dates and Times.
Documents are documents.
Scalar Quantities can be Currency Amounts, Numbers, Quantities, or Percentages.
And of course, we want to have the Account.
All FIBO Concepts are Ultimate Supertypes in the Data Model.
The table and chart show the number of subtypes under the ultimate super type. And we see the biggest one is Situation, followed by Role, Designation, Constituent, the Agent, and so on.

The Concept Map corresponds one-to-one to the Data Model.
Here’s an example of a concept map for a Regulatory Report to the FDIC, the US Federal Deposit Insurance Corporation.
We see here that our Bank is a Depository Institution, and it’s identified by an FDIC Certificate Number (the license to do banking), and that ID is registered in the FDIC Registry.
The Authority, here, the FDIC, in its role as a Regulator, registers the ID.
Furthermore, the Depository Institution is a Stock Corporation. It has a Legal Entity Identifier. It has Issued Capital and a Physical Address.
This corresponds directly to the data model. In other words, you can leverage the 15 concept and design a Concept Map with your business user or subject matter expert. Then, as you return to your workplace, you can directly map concept map symbols to entities in the data model.
Arrows are Associative Entities, and with that, you can derive a scope, a subset model from FIB-DM.
For the 15 Concepts and Concept maps, revisit “Semantics for Finance Users,” and about scoping from FIB-DM, this here, I’ll explain in greater detail in the next lesson, “Scoping a Data Model from FIB-DM.
This concludes the first part of “Semantics for Data Architects.”
The second part looks at the data model structure of Entities, Relationships, and Associative Entities, and design considerations for derived Logical Models are in a separate video.
Okay, thanks for attending this class. Watch the next lesson.

Part 2

Welcome back to the FIBO Data Model training.
This is Jurgen, and here is part two of Semantics for Data Architects. Make sure you watched part one, which sets the stage: FIB-DM origins, the FIBO ontology, and the transformation considerations.
So part two is about the data model structure. In this lesson, we look at Packages (or subject areas), Base and Associative Entities, Relationships, the FIBO documentation transformed into the data model, Design Patterns for Semantic Models, and considerations when scoping and generating Logical and Physical models from FIB-DM.

This is what we see when we open the model in PowerDesigner.
First, every quarterly FIB-DM release has a diagram of the Base Packages. Here we see the generic packages, in particular OMG Commons, Language, Countries, Currencies, and the FIBO Foundations, Loans, Securities, Derivatives, and so on.
You can open the Base Packages diagram. Here we see the main folders. There are 11 FIBO folders, and here is OMG Commons. Now, OMG Commons has a two-level hierarchy. We have OMG Commons and then the individual ontologies, and the leaf level, the lowest level in the package hierarchy, which is an individual ontology.
Here, Business Authorizations was released with OMG Commons 1.3 in December last year, and it is included in the January release. So, there’s a diagram.
The FIBO has a three-level hierarchy. So if we look at Loans & Mortgages, we see Loans General, Loan Specific, Real Estate Loans, and under Loan Specific, here we see the individual FIBO ontologies, Cards, Commercial Loans, Student Loans, and so on. Again, the lowest level in the hierarchy is an individual FIBO/OMG ontology. OMG Commons has two levels. The FIBO has three levels.

Okay, let’s look at the Package folder structure. On the right-hand side, we see the FIB-DM um package hierarchy, and we can see that it’s identical to the one on the left-hand side, the unzipped FIBO download from the EDM Council website, and it’s also identical to the folder structure, as well as the folders of the URI.
Here, we see a FIBO LOAN, Loan Specific, Card Accounts.
In FIB-DM, we have the major root packages for the FIBO subject areas. Then we see Loans & Mortgages, Loan Specific, and the individual loan types.
The ontology prefix is an abbreviation defined in the FIBO. Here, for example, for Card Accounts, we see that the URI is abbreviated as fibo-loan-spc-crd (not shown in the screenshot), which is also the physical name of the data model package.
The Logical Name is simply an “uncamel.” We take the ontology name and uncamel, basically inserting the space here.

Some more details about the package diagrams, which depict dependencies between the packages. The folder structure simply specifies where ontology or data model objects are located, whereas the package diagram shows uh um the dependencies. So the arrows derive from FIBO/OMG owl imports and from superype/subtype relations among FUIB-DM entities.
Before, we looked at the Loans ontology, which imports FIBO Foundation, Business Entities, and Finance Business & Commerce. The Loan entity is actually a subtype of the Credit Agreement defined in FBC (Finance Business & Commerce).
The Loans and Mortgages package diagram shows three mid-level packages, Loans General, Loan Specific, and Real Estate Loans, and six leaf-level packages for Loans in General and the Specific types of loans: Commercial Loans, Consumer, Student, and Card Accounts.

A note about Packages versus Subject Areas. On the left-hand side, we see a PowerDesigner screenshot of the data model Packages, and on the right-hand side, the model migrated to ERWin, with the packages imported as Subject Areas.
So, ERWin imports the PowerDesigner file package as a subject area. ERWin Subject Areas don’t have a hierarchy. We just see a flat list of Loan Subject Areas.
FIB-DM entities are at the model level, not within packages.
So, under entities, we see a list of 3,200 individual entities.
The reason is that some data modeling tool imports require a flat list. When I tried it with entities within the packages, the import couldn’t process them.
So, to make it easy for everyone, entities are listed flat under the model. However, you can copy entities into PowerDesigner Packages or ERWin Subject Areas.
It’s very easy: You switch to physical names, search card account entities (they all start with the same prefix), and then you copy them into the Cards Package or Subject area.

Every FIB-DM quarterly release has Package Entity Diagrams of the new FIBO additions. For example, the diagram shows all entities in the Guarantee package. The FIBO has the package under Finance, Business & Commerce, at a higher-level module, not under Loans, because Guarantees are also used for Fixed Income Securities.
So that’s shared content between FIBO Securities and FIBO Loans.
There is a diagramming convention. We have a stamp that shows the model package diagram name, author, copyright, date, and the FIB-DM and FIBO versions.
Base Entities are in yellow – that’s a general FIB-DDM diagram notation convention – and Associative Entities are in blue.
I recommend using this color for your extensions because it makes the design fairly easy to read the design.
Relationship names have the connected entities delimited by a hyphen. Here, we see the relationship name “issues” dash “Letter of Credit.”
“Issues” is the Association, and the Letter of Credit is the Base Entity. Also very important is a stereotype that’s “parent” or “child.”
This is what data modelers see in a relationship as well. This one here reads as “Issuer issues a Letter of Credit.”
The cardinality of the Associative Entity is generally one or zero to many, and on the base entity, typically it’s an optional one or zero, unless the source ontology specifies a minimum or exact cardinality.
So, whenever you see a mandatory relationship, that means there is some class constraint that got transformed into a cardinality.

Package Properties.
Here is the Mortgage Package: fibo-loan-reln-mtg. The package name is the rightmost string in the ontology namespace, and CODT transforms the prefix into a package unique code. All ontology classes and properties with the prefix fibo-loan-reln-mtg become objects in the model package.
In other words, all Mortgage entities have codes that start with fibo-loan-reln-mtg. The URI is the Uniform Resource Identifier of the ontology. This is a hot link.
You have the tracability, you can click on it, and you are in the FIBO.
The package properties box has three tabs: Annotations, Lineage, and Extended Attributes

Package Annotations
They derive from ontology annotation properties and are transformed into PowerDesigner Extended Attributes; in ERWin, you find them as User-Defined Properties.
Here, for example, we have the package property annotation for OMG Commons Roles & Compositions. The um tab shows the most common populated package annotations. So, only some packages will have certain annotations. For example, OMG Commos Roles & Compositions shows a label Contributors and the Note, but for Roles and Compositions, annotations like File Name, See Also, and Depends On are not documented
They’re not needed, but some other packages may have a particular package annotation.

The Package Lineage tab shows transformation and FIBO properties rather than documentation items.
Here, for the same Roles and Compositions Package, we see the Resource Name, and that is simply the ontology Prefix.
The Resource Type on all ontologies and on entities may be Data Property, Object Property, or Class
The Abstract is a brief description in some ontologies. Again, OMG Commos defines an Abstract, and that is what we use for a package comment or definition.
Copyright and License Notes are copied from the original source ontology. With that, FIB-DM fulfills an OMG FIBO MIT license requirement.
If you have the FIB-DM Commercial version, your license is the Jayzed Intellectual Property License Agreement (IPLA). If you have the open-source version, it’s GPL 3.0. Important: Just like FIB-DM does with the FIBO source, ensure that your derived work retains the Jayzed, OMG, EDMC copyright and license notes.

The package Extended Attributes tab.
That’s uh just a PowerDesigner-generated tab that lists all Extended Attributes on the package. There is a complete list of the ontology Annotation Properties, and after migration into other data modeling tools, the ontology annotation may show in a tool-specific representation. For example, in ERWin, you have a tab listing the User-Defined Properties.

Entity Properties.
The name is the ontology Class Localname, a simple “camel case” to logical data modeling naming convention. So we have the first letter of a word capitalized, and we have a space between words. The code transforms from the ontology class. It is a Prefix, a colon, and a Localname. The Comment populates from class annotations, the rdfs:Comment, or the skos: Definition.
The FIBO uses either of the two to document an entity.
For entities, there are two more tabs in the PowerDesigner model for Annotations and for Lineage

Entity Annotations.
FIBO classes have extensive documentation. They are captured in Ontology Annotation Properties. The Source, Abbreviation, Adapted From, Definition, Explanatory Note, all the way down to Scope Note, they are uh documented only for some classes.
Hence, the text boxes may be blank for most entities. In this example, the Commercial Loan includes an Explanatory Note. Most entities have a synonym. But you don’t need an Editorial Note or an Example for this one.
Important here, Deprecated Entity means that the deprecated FIBO class will be removed in future releases. This is how the FIBO manages refactoring for design changes. When OMG Commons was incorporated, some of the like-named FIBO Foundation entities became deprecated, which means you should use the Equivalent class in OMG Commons, not the FIBO Foundation class. In a future release, these Foundation classes will disappear from the model. In short, if it’s deprecated, don’t use that entity for your modeling; use its Equivalent entity instead.
Defined By defaults to the source ontology, and that is the FIBO code, the Package code in FIB_DM.
RDFS Comment or SKOS Definition provides the entity Comment.
Likewise, here, Label, See Also, the notes, Editorial, and Scope Notes are populated only for applicable entities.

The Entity Lineage tab captures ontology metadata for the Source Class, and the Extended Attributes provide traceability into the ontology while preserving semantics beyond the entity-relationship model.
These are not plain ontology annotations but rather information CODT captured during the transformation process. So the Resource Name is Class and Localname delimited by a column. So we use the resource name as the entity code, but you can generate your own codes in the modeling tool.
The Prefix is an abbreviation of the source ontology URI.
The Resource Type again indicates the source object type. That can be OWL class, Data Type Property, Object Property, or Ontology.
The URI, the Uniform Resource Identifier of the class, is a link into the FIBO ontology. Now here restrictions and equivalent class axioms formulate higher owl semantics and they are important business rules for DBAs and for for developers and uh here for example uh on the commercial loan we see a class restriction which means the uh that uh entity has a borrower and that is a role played made by some legal entity and now uh rules like this uh we cannot uh model them in in urban or power designer. No. And that is where the ontology has higher semantics in actually formulating these business rules.
What CODT does is process the class restrictions and derive associations from them.
So, finding this class restriction CODT creates the Association to Borrower and to Legal Entity, and it documents the original class restriction text h in the lineage as an extended attribute.
Likewise, the Individual Labels you have for many FIBO classes are instances in the source ontology. For example, Country Codes, Currencies.
What CODT does is: Well, we don’t have instances or examples formally in the data model. However, we list them here at this entity lineage as an extended attribute.

The class restriction limits the set of allowable instances for a class. So here, for example, the Obliger must have an obligation to some commitment.
And, uh, note that in the ontology, the Object Property “hasObligation” is transformed into an Associative Entity in FIB-DM, and in the transformation processes, the class restriction creates relationships from Obligation to the Associative Entity “has Obligation.”
Class Restrictions also determine relationship cardinality. Here, “some” means that the Obliger must have at least one Obligation.
Class Restrictions can be very complex. Even the Obligor restriction below is beyond the entity-relationship model expressivity: The obligor plays a Role as a Party to some Agreement. FIB-DM does not transform class restrictions, which are anonymous classes, into pseudo entities. However, FIB-DM preserves these business rules for the benefit of downstream physical modelers and application developers.
You, as a DBA, can take up the class restriction in the FIB-DM model and instantiate it as a check constraint. An ETL developer would check this constraint before populating records in the Obligor table. Application developers also know what the allowable values for a certain entity are.

Entity Equivalent
Defined classes in OWL specify conditions for their members. So, unlike for the Primitive class, we don’t CONSTRUCT (SQL INSERT) equivalent instances into the class. Instead, the Inference Engine, also known as a Reasoner, determines the instances that match the equivalent condition. In this example, the fibo-be-le-lei Legal Entity Identifier Registered Entity is equivalent to OMG Commons isIdentifiedBy some FIBO Legal Entity Identifier.
FIB-DM has entities transformed from equivalent classes. The equivalent lineage attribute is for the physical modeler to consider a view or alias.
Defined classes may have more complex conditions. For example, a Fixed Float Interest Swap has a Fixed and a Floating Leg. And these are important business rules for ETL architects populating a FIB-DM database.

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.
That makes sense from a business perspective and in a Conceptual Model. We have it not only in ontologies but also in UML. You can have multiple inheritance. However, in a data model, in a logical and physical model, we can only have one supertype.
So, the Logical Modeler can use some techniques to resolve multiple inheritances in the Conceptual Data Model, FIB-DM.
There are two ways: number one, the issue goes away. Let’s say we have our Central Bank in FIB-DM. It’s a subtype of Bank and Monetary Authority. However, when we attribute the model, the Monetary Authority may not have attributes, or it may not be within scope. In that way case, the issue goes away. We are only left with one supertype of the Central Bank.
If both supertypes are valid, in scope, and attributed, then in the LDM, the modeler changes the supertype to Dependent Relationships.
So, here, the top Conceptual diagram becomes an LDM, with both the Bank and the Monetary Authority providing identifiers that constitute the Central Bank’s key.

Entity Attributes.
The FIBO domain ontology is a Business Conceptual Model that defines concepts using Class and Object Property. So there are only 332 data properties in the source ontology. Therefore, FIB-DM is an entity-level Conceptual Data Model that is sparsely attributed and doesn’t have keys.
The PowerDesigner CDM has Data Items. These are model objects independent of the entity. The Data Item gets attached to the entity as an Attribute. Data Items, as model objects, disappear when the modeler derives an LDM from the CDM. In the LDM, we only see Attributes on an entity.
Likewise, if we import FIB-DM, the CDM into ERWin, we will only see Entity Attributes – not Data Items.
Yeah. And then the transformation creates data items from source ontology data properties. The property Domain and Class Restrictions determine attributes on an entity.

Associative Entities.
CODT transforms ontology Object Properties into data model Associative Entities.
The relationships between a Base and Associative Entities are transformed from the Object Property Domain, Range, and Class Restrictions.
Again, the diagram notation in FIB-DM is yellow for Base and blue for Associative Entities. The stereotype on the relationship line indicates a role: whether it’s a parent, a child, or both ways, “dual.”
Here, in our example, a Registrar or Registration Authority, , registers , a Legal Entity or a National Security Identifying Number.
In most cases, a class restriction on the child entity would tell us which parent is registering it.
Object properties are multi-valued. So, the Associative Entity may have relationships with many Base Entities.
As we will see, in the Logical Model, you may convert class restrictions and restrict the parent-to-child relationship.

Associative Entities in FIB-DM have a hierarchy, which is why they are entities rather than mere relationships.
This is an essential OWL construct and widely used in the FIBO. Virtually all FIBO Object Properties are in hierarchies.
The default configuration for transforming a domain ontology into an enterprise data model, therefore, creates subtypes of Associative Entities derived from rdfs:subPropertyOf.
Here, in our case, the Associative Entity “governs” its subtypes: governs Payment Of, Supply Of, has Jurisdiction, and Governing Jurisdiction.
Typically, I recommend that an LDM scope the most specific level, the lowest in the hierarchy. So if your Base entity applies to a Governing Jurisdiction, use that Associative Entity in your scope, and not the generic “governs”.

Yeah, some may look like a Star Schema. The context diagram here shows the “identifies” Association and some of its participating entities.
On the left-hand side are the parents. You see the various Legal Entity Identifiers, Customer IDs, Account IDs, Currencies, and Securities.
And on the right-hand side are the identified Legal Persons, Customers, Accounts, Currencies, Securities, and Trades. It looks like a Star Schema with a factless fact table in the center. This is fine for a Dimensional Data Model, and the model integrity check in PowerDesigner doesn’t complain.
But the denormalized design may not be appropriate in an LDM for an operational database. However, as we have seen with multiple inheritance, we prioritize clarity of the design for business users over third-normal-form correctness.
Then, in the Logical Data Model, you would rename relationships. You can role-name them; for example, say “identifies Currency,” or add a type of identification with the value “currency identification.”

We can resolve multi-valued associations as we move from the FIB-DM Conceptual and derive a Logical Data Model.
Now, the LDM rule number one applies: in your LDM, you attribute data items from your source system feeds. And then the issue may disappear, because we remove entities that do not have attributes.
If you want to control and prevent incorrect entries in an “identifies” table, then you can follow the normal data modeling pattern.
You can create a selector type, and you can create subtypes that narrow down the allowable values and relations.
Here, for instance, we can create a subtype “identifies Bank” with a Bank Identifier and the Bank.
We can actually look up the class restriction on the Entity Lineage tab. No.
There’s a restriction, “Bank Identifier identifies Bank,” and we can create a subtype if we want to control the values and prevent data integrity issues.
The Physical Modeler can decide to roll up or down the “identifies” subtypes.
As I said before, FIB-DM does not prescribe how the data modeler resolves the design in the LDM. FIB-DM is 100% FIBO, nothing added. You, as a Logical and Physical Modeler, decide how you instantiate FIB-DM.

Relationships.
FIB-DM uses Associative Entities to model Ontology Object Properties; therefore, Relationship model objects merely connect Base Entities to Associative Entities.
They transform the Object Property Domain, Range, and Class Restriction.
The naming convention in FIB-DM is simple: parent entity child entity.
For example, we have the FIBO Foundation Accounts Currency: Currency Identifier, which identifies the cms-id: Identifies Associative Entity.
Likewise, the Relationship Name and Comment are generated per the CODT configuration settings.
The stereotype indicates the relationship role

One specialty: ONLY Associative Entities.
They derive from like-named Class Restrictions. ONLY Associative Entity limits the participating Base Entities.
For example, the OMG Commons “hasMember” Object Property has numerous related classes. However, the Organization has a class restriction: Commons “hasMember” only applies to a Party. 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.
We see the Associative Entity “has Member” in Commons, and FIB-DM has “Organization only has Member” as a subtype, with Organization as the and Party as the . This concludes the structural overview.

Yeah, this concludes our FIB-DM deep-dive.
Here are some resources for your further study.
Diagrams of the data model are in your delivery zip folder and are also published on the FIB-DM website. There are over 50 diagrams.
To be clear, not all diagrams are in the quarterly FIB-DM releases simply because the model file would become too big for import and handling, even on a PowerPC.
Typically, the FIB-DM release has maybe a dozen diagrams and new ontology modules, but not all of them. This keeps the history, and you would do the same if you adopt FIB-DM and customize it as an Enterprise Data Model.
Open-source users can review this PowerPoint in MS Office online and also download a PDF. And if you have the Full Model Version, you will find the original PowerPoint files in your delivery folder
You should study the articles for a deeper understanding of hierarchies and associative entities. And you can watch the next lesson in the YouTube course, which is about scoping a submodel from FIB-DM.
Thank you for attending the class.