The Configurable Ontology to Data model Transformation, CODT Tutorial.

The Configurable Ontology to Data Model Transformation (CODT) technology created the 3,074-entity FIBO Data Model. The US Utility Patent #12038939 opens CODT for Financial Institutions that have already customized the industry-standard ontology and need a data model that reflects their extensions (most of them are global banks).

The CODT tutorial addresses challenges for Semantic Centers of Excellence, leveraging ontologies for Data Management. Semantic and conventional data management utilize the same language, eliminating silos. The vision is for a Semantic Enterprise Information Architecture, with ontologies at its apex and derived data, message, process, and object models.

The first part provides an overview of the ontology-derived model, a high-quality conceptual data model that resolves issues with old-style parsing transformation approaches. In detail, we examine the data model’s features, sophisticated mappings, lineage, and ontology annotation properties. We also discuss the Normative and Informative FIB-DM models, the fifteen business concepts, and the comparison between Open Source and commercial licenses.

The second part of the tutorial on the CODT website is a deep dive into the ETL (Extract, Transform, and Load) approach. Patented Metadata Sets for Ontology, a generic Entity-Relationship model, and the specific Data Modeling Tool are self-populating. We extract Ontology metadata using SPARQL queries, MS Power Query, Excel formulas, and Visual Basic for Applications code for transformations. CODT also operates in reverse mode, transforming Data Models into RDF/OWL. The second part closes with an overview of the license, pricing, and the Proof of Concept.

---

After watching the video, review the PowerPoint in MS Office Online and download a PDF of the presentation for your reference.

---

Transcript of the video lecture

Hello, this is Jurgen with the FIBO Data Model training.
Today’s Semantics for eXtra-large banks is an overview of the Semantic Enterprise Information Architecture and model-driven development, with the industry-standard ontology at the apex.
The first part is a dive into the model, and the second covers the Configurable Ontology to Data model Transformation (CODT).
The presentation and this video are new recordings, and they have been updated for OMG Commons and FIBO Loans.

Your Financial Institution embraces RDF/OWL and the FIBO. You have already or are moving towards Semantic technology, Center of Excellence, and RDF Triple stores. You use and support the development of the industry-standard ontology, and you have licensed, downloaded, and evaluated the fiber data model.
The CODT Patent, US12038939, enables full disclosure of the transformation technology.

What are the challenges for a Semantic Center of Excellence?
Many global banks have already implemented, extended, and customized the industry standard ontology. However, 95% of the Bank still runs on RDBMS, and architects are using data models to design relational databases.
The global banks have highly qualified ontologists and data scientists. However, data architects with the FIBO Model can’t leverage their colleagues’ workwith the FIBO Model can’t leverage their colleagues’ work in the semantic center of excellence.
So, the risk is that semantic implementations become yet another data silo, using a different language from the rest of the organization, and impede the integration of semantics with conventional systems.

FIB-DM and CODT are the bridge across that chasm.
We have the customized FIBO, the Ontology Knowledge Graph in your data modeling tool, PowerDesigner or ERWin, and other tools. The vision is Semantic Enterprise Information Architecture (SEIA).
When we look at architecture, we can differentiate by the use: is it for business design development?
By the type of artifact: it is conceptual, logical, physical, or 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 on RDBMS.
You likely have XSD for messages, BPMN for processes, and UML for object models and generating code.
What is new is that we have the FIBO in RDF/OWL, and that deploys on RDF stores.
And for FIB-DM, we have the FIBO as a Conceptual Data Model, and we can also generate other models, like UML, from 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

Bi-directional model transformation enables Semantic Enterprise Information Architecture.
On the left-hand side, we have the owl with the FIBO, other industry ontologies, and our own proprietary ontologies.
On the right-hand side, we have FIB-DM, we have Enterprise, and Project Data Models. And in the middle is Atlantic CODT, the transformation technology.
We generate data models from the industry domain and proprietary ontologies.
We design conceptual models in RDF/OWL.
In reverse, we use our data models to extend the Enterprise and Project Ontologies and the Knowledge Graph.

How does this lesson, Semantics for extra-large banks, fit into the overall FIB-DM training schedule?
You should have completed the first three lessons: Semantics for Managers, for Project Architects, and in particular for Finance Users, which is a deep dive into the 15 FIBO Concepts.
Then here you see it’s branching a little bit. We have three lessons: for midsize, large, and very large banks.
However, the classes are fully applicable to all financial institutions. “Midsize Banks” means smaller banks without semantic technologies yet. “Large Banks” has an Open Banking example.
Our presentation here, Extra Large Banks, is for institutions that plan to customize the FIBO. The titles “for banks” are historical, but the content of all three modules is fully applicable to other Financial Institutions, such as Investment Funds.
Every bank is different, and in practice, we usually cover all three lessons, moving faster when the content repeats or is not critical.

The asset size is a poor proxy for semantic sophistication.
Semantics for Data Architects, the name of the very first FIB-DM education resource, became a catchphrase.
The first part of our presentation today is a shorter dive into the data model.
FIB-DM on the EDMC website was originally for Financial Institutions with less than 200 billion in assets. Hence, Semantics for Midsize Banks. However, some Financial Institutions, such as Hedge Funds, are very advanced, while some larger banks on FIB-DM are just now building out ontology capabilities.
The second part of this class is an overview of the Transformation Technology, CODT, which is for financial institutions that use and extend the FIBO; many, but not all, are very large financial institutions.

Who is this class for? For a general audience: Finance, Management, Business Stakeholders, who have some working knowledge of Entity Relationship and Ontology diagrams. You should be authorized to sign non-disclosure license agreements if you want to do a CODT PoC. You can skim the pages that deep dive into FIB-DM and CODT.
For the PoC in particular, ontologists with an in-depth understanding of the FIBO and in-house ontologies. You want to spread the adoption of the industry standard and of your ontology work across the enterprise, and you’re well-versed in RDF/OWL and SPARQL.
Data Architects with experience in enterprise reference models. You evaluated and want the industry standard FIB-DM. You’re an expert in your data modeling tool and its import functionality.
Finally, Developers, MS Excel Power users, experienced in VBA, Power Query, and the M language.

About myself, I worked in Finance for 20 years as a data architect and ontologist at leading financial institutions and service providers. In particular, for 7 years, I was an IBM Software Group consultant for its Banking and Financial Markets Data Warehouse (BFMDW). And in that capacity, I was teaching the IBM model at some 45 banks in North America, Europe, and Asia. Afterward, I consulted Citi and Deutsche in implementation, and I’ve been a contributor, reviewer, and speaker at FIBO conferences since the beginning.
Jayzed Data Models, my company, is a US consulting business, and it was incorporated 25 years ago.
Jayzed holds the FIB-DM copyright and is a designated assignee of the CODT Patent.

The two standard setters, the EDMC and OMG, collaborate closely.
“The EDM Council is a member-driven trade organization dedicated to data management and analytics as a strategic business priority.”
Founded in 2005, they provide best practices, standards, and education for data and business professionals.
The Object Management Group is a standards development organization. It’s a global nonprofit consortium. Here they say, “our members collaborate to craft technology standards that offer measurable value to a diverse range of vertical industries.”
Notably, the OMG is across all industries, whereas the EDM Council is specialized in F,inance.
And now the EDM Council and Object Management Group have merged.
The EDMC has over 200 financial institutions as members, and it teaches data management best practices and develops data standards. You probably already completed EDMC’s Data Capability Assessment Model (DCAM).
The EDM Council is the publisher of the FIBO
The Object Management Group, with over 220 large member organizations, develops well-known standards like UML, BPML, DDS, and SysML. In particular, the OMG developed the Commons Ontology Library.
Well, and effective October 1st last year, the Enterprise Data Management Council acquired the Object Management Group, and the combined “EDM Association” is the world’s largest nonprofit trade standard-setting body for data management.

FIBO and OMG Commons.
Financial Industry Business Ontology defines things that are of interest in financial business applications and the ways they relate to each other. By doing this, the FIBO gives meaning to any data. no spreadsheets, RDBMS, XML documents that describe the business of finance, and hence the Ontology Knowledge Graph.
The Commons Ontology Library is a set of small ontologies designed to provide modeling constructs that are reusable in different modeling and data deployment environments. OMG Commons is designed as a Foundational or Upper Ontology independent of the domain or industry.
The FIBO imports OMG Commons, deprecating foundational classes in the Foundation modules. In other words, OMG Commons entities have replaced FIB-DM entities in the Foundation, Business Entities, and Finance Business & Commerce modules.

The FIBO is more than a Knowledge Graph. The EDM Council and its members (the Financial Institutions) decided to define their Business Conceptual Model in Ontology Web Language (OWL) because OWL offers superior semantics.
Fiber conceptualizations and relations are fully applicable to lower-level semantic taxonomies, concept maps, and object and data models.
FIB-DM is a perfect Conceptual Data Model for the enterprise and for projects.
You can read more about this statement in the article comparing ontology to data model hierarchies. And the second article explains why Ontology Object Properties should be Associative Entities in a data model.

The EDM Council features FIB-DM on its website, and more than 3,500 users have already downloaded the open-source version of the FIBO Data Model.
Many EDM Association members want to leverage the standard, but don’t have ontology tooling, databases, and human expertise in-house yet. With FIB-DM, data architects no longer manually transcribe ontology graphs and copy and paste definitions um from the ontology into the data modeling tool. However, even with FIB-DM, architects at larger financial institutions must still copy and paste FIBO customizations and extensions that the ontologists in the Center of Excellence developed.

The FIBO is superior to vendor data models.
“Le Roi est mort, vive le Roi” almost 600 years ago. Robert II d’Uzès proclaimed Charles King of France. Still, the Involved Party remains an ultimate supertype across numerous reference models and databases. OMG Commons breaks the commingled entity into two Fundamental Concepts. The Agent (a person or legal entity), and the Role that it performs as customer, counterparty, borrower, employee – one Agent, many Roles.

Here we see the Agent and its Role. Two different Concepts. Altogether, there are 15 Concepts.
They all have a name, an icon, and an abbreviation. These are fundamental to the business of Financial Services. They are the top-level ontology classes defined in OMG Commons. They are ultimate supertypes in the data model. 90% of FIB-DM entities are subtypes of a Concept Entity.
Just a brief rundown: the Situation, including contracts and commitments; Designation of all IDs; and Constituent details of a contract. Collections are used for lists or groupings. For instance, payment schedules are Collections. Aspects are characteristics, Specifications are technical documents, formulas, and expressions. Arrangements are codes, and Measures are what we observe in the real world. Occurrence is the concept under which we have transactions. Temporal Entity: dates and times. Documents, Salar Quantities: dollar amounts or euro amounts, numbers, and percentages. And of course, the Account.

The ontology-derived data model. On the left-hand side, we have an ontology graph from the FIBO. We see here that it shows a Bank Account Identifier, which identifies a Bank Account, and the bank account is provided by a bank, which is a subclass of Depository Institution. And on the right-hand side, we see the derived Conceptual Data Model.
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). Finally, the relationships between Base Entities and Associative Entities, their Cardinalities derive from Class Restrictions, Domain, and Range.
This mapping diagram is Figure 1 of the CODT Patent drawings.

Current tooling for importing RDF/OWL files is not fit for purpose. Some data modeling tools have rudimentary imports for RDF/OWL files, but these imports are usually a one-click black box with no options or diagnostics. Some use the URI as an entity name; some convert data properties into classes; and class restrictions become anonymous pseudo-entities. That doesn’t help the data modeler. There’s no import of annotation properties.

The challenge is that the parsing approach is not scalable.
Traditional transformations parse ontology files. So, they go file-by-file, encounter elements of the ontology, and create elements in the data model. The parsing approach reaches its limits with very large ontologies like the FIBO. The FIBO has 250 RDF/OWL files, and some tools crash. By default, Object Properties transform into model Relationships, and this transformation loses metadata and loses the semantics for object properties with design patterns like subproperties.
The OMG and FIBO have deep hierarchies of object properties that must be transformed into hierarchies of associative entities. Some large Financial Institutions develop rudimentary transformations. However, I invite you to compare FIB-DM with any vendor or in-house FIBO transformation to see the difference.
License the patented technology that created the industry-standard model rather than reinventing the wheel and DIY.

Let’s look at the outcome of the transformation.
We can start with uh package properties. Just a note, you can import the PowerDesigner model into ERWin, and ERWin provides everything you see on these slides as User-Defined Properties.
First, there is the Package Name. That is the rightmost string in the ontology namespace. Here we have Loans with the package code. CODT transformed the ontology prefix into Code, and the Comment derives from the definition in “rdfs:comment” or the “skos:definition.” All ontology classes, properties with the same prefix, in this example, FIBO “Foundation Agreement Agreement”, become model objects in the agreements package. Finally, at the bottom is the URI of the ontology. The Uniform Resource Identifier is a hot link to the source of the model object.
In other words, it points to the FIBO ontology or FIBO class.
And the second part of the overview shows how CODTadds extracts, transforms, and adds these properties to the model.

But let’s continue with the FIB-DM PowerDesigner model Package documentation (or Subject Area documentation in ERWin) derived from the FIBO/OMG ontology Annotation Properties. Here, we have a table of packages and the number of annotation properties each has. We see most packages have a Label, and OMG Commons “Parties and Situations” also provides the Contributor, a Note.
License, Change Note, Copyright, and Maturity are on the lineage tab.

Package Lineage.
The ontology Namespace provides the Resource Name of the data model package. Here, in this case, cmms-pts, that’s Commons Ontology Libraries “Parties and Situations, it’s then a prefix for all entities in that package.
All OMG Commos packages have an Abstract.
The Copyright box lists the Jayzed FIB-DM copyright and all copyright notices in the source ontology. The data model license depicted here for the Full Commercial version is your Intellectual Property License Agreement, whereas the open-source version is licensed under GPL 3.0. The ontologies are licensed under the MIT open-source license.
The open-source licenses and the Jayzed IPLA require that all derived works must include the license in copyright notices. In other words, make sure to include these notes in your FIB-DM migration to other tools, in the generated logical and physical object models, and in all metadata extracts.

Entity Properties.
The Name is derived from the ontology class local name and is converted from the Camel Case notation used in FIBO/OMG to the Logical Data Model naming convention.
We have the first letter capitalized and a space between the words, like we usually do in our data models.
The Code transforms from the ontology class local name. The Comment populates from the class annotation, the rdfs:comment, and skos:definition. There are two tabs here: Annotations and Lineage for a data model entity.

The data model Annotations come from the extensive FIBO documentation.
Here is a chart showing the number of classes with annotated documentation.
We see that almost all have a Label and a Definition, many have an Explanatory Note and an Abbreviation, and some may have a Synonym.
Again, not all Annotation Properties are populated in the FIBO. On the Annotations tab of the data model, some boxes remain empty.

The lineage tab captures the ontology metadata of the source class.
In PowerDesigner, we have extended attributes that provide traceability into the ontology and preserve semantics that we cannot model in the entity-relationship data model.
Just a note, in ERWin, these attributes are on the entity as User-Defined Properties.
We have the resource name, which is a combination of Prefix and Localname.
FIB-DM uses the Resource Name as the entity Code, but you can generate your codes in the modeling tool
The Localname is the rightmost string in the resource name in the URI.
The Prefix is an abbreviation of the URI defined in the ontology.
In this example, “FIBO Foundation Agreement Agreement” is the FIBO ontology that defines the Obligor and the Uniform Resource Identifier of the class.
This is a direct link to the FIBO source ontology. So, we have complete lineage and traceability from our data model into the source ontology.
And finally, Restrictions and Equivalent class axioms formulate our semantics. This is typically something we cannot define in the data model. Here, Obligor is a Role in an Agreement that is a Commitment and played by the Obligor who has that Obligation.

How does CODT transform complex ontology patterns?
Here at the bottom, we see a Loan with a Principal Amount, which is the Loan Principal. So that’s pretty simple because here we just have to deal with Range and Domain.
However, that “hasPrincipalAmount” object property is a subtype of “hasNotionalAmount,” which is a subtype of “hasMonetaryAmount.”
And in the ontology, these parent properties also have relations.
Some can be complex Class Restrictions. For instance, here, the “hasNotionalAmount” is either a MonetaryAmount or a PercentageAmount.
Likewise, here we have a class restriction for the CD (Certificate of Deposit ): the Notional Amount must be a Monetary Amount.
And so that’s where we see: Preserving the full FIBO Semantics is where rudimentary transformation fails. How does FIB-DM represent this ontology?

We need a sophisticated data model transformation.
It is wrong to simply use data model relationships as a result of of a object property transformation.
We must use Associative Entities to preserve and model the hierarchy of Ontology Object Properties, from Principal Amount to Notional to Monetary Amount.

Yeah, the FIBO, how does it work with your vendor and in-house models for Semantic Enterprise Information Architecture?
Our goal is to leverage implementation across databases, code, departments, projects, and individual applications.
And our method is to derive. We add to the industry standard. We use the FIBO Production ontology. We can scope enterprise and project models; we consult the other models that we have. Our customized FIBO, other standards, and in-house data models and ontologies, including vendor models.

DAs should merge the vendor and in-house models into FIB-DM because it offers excellent value. So keep it and harvest the content.
We add to the industry standard: the 15 concepts and the subtype hierarchies. We adopt the FIBO and FIB-DM names and definitions. Then we identify direct entity matches (synonyms). We identify entity matches, and we beware of homonyms, where we have two names for the same thing.
We merge entities that are not already in FIB-DM. We identify the appropriate supertype. For instance, if you have other types of contracts.
Then we merge attributes from your vendor or in-house model into FIB-DM, since FIBO and FIB-DM are conceptual models. The FIBO has very few Data Properties; hence, FIB-DM is largely at the entity level.
A note here, the FIBO Data Model correctly defines Financial Instruments as a subtype of the Contract, an Agreement, not a Product, as some vendor models do.

The Concept Maps, FIB-CM, directly correspond to the data model.
On the left-hand side, we have a Concept Map about Financial Institutions, Depository Institutions registering with the FDIC.
They have a Legal Entity Identifier, a Physical Address, and have Capital.
On the right-hand side, we see the corresponding uh data model. We can use FIB-DM, then scope, grab the entities that we have modeled with the user in the Concept Map.

Also, Ontology and Data Model are in sync.
The data model here about the Stock Corporation and the Address is equivalent to the Ontology Graph.
Beyond object property Range and Domain, the ontology transformation infers relationships from Class Restrictions, here from the OMG Commons Legal Entity.

A brief comparison of the GPL 3.0 versus a customer license.
In the open source, you must “copyleft.” That is, license your derived models and your model migrations to the public.
With the Commercial License, you keep FIB-DM migrations and extensions private. Likewise, all public Education Materials are subject to copyright. With a Commercial License, you’re free to modify, translate, edit, and even lift off images and diagrams as long as they remain within your organization.
Also, we can see that the open-source version is based on FIBO 2018/Q4, whereas the latest Full Version of the data model is from 2025/Q4, and it has 2,000 additional entities.

Okay, in summary, with currently 3,173 entities, it’s the world’s largest reference model for financial institutions. It has a superior design as a Semantic Data Model. It has extensive documentation for the industry-standard ontology. It has a full lineage to the source and facilitates Semantic Enterprise Information Architecture.
We have the same names, definitions, and design patterns across the enterprise.
We put the ontology at the apex and include business-friendly concept maps, derived data, and object models.
With that, we unify Semantic and Conventional Data Management.

Full transparency for your FIB-DM evaluation.
You can download the FIB-DM Core version, which is open-source, and explore the model in your data modeling tool, PowerDesigner, or ERWin.
You can study the extensive Education Resources and watch the other videos in the FIB-DM Training Course on YouTube.
Examine the full 2025/Q4 model content, including definitions of all entities in the data model.
Then, finally, review license, maintenance, and pricing.
Well, thanks for watching. This concludes the first part, and you can continue with the video for part two, which dives into the transformation technology.