The Configurable Ontology to Data model Transformation, CODT Tutorial.

The Configurable Ontology to Data Model Transformation (CODT) technology created the 3,173-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 video provides an overview of the ontology-derived model, a high-quality conceptual data model that addresses 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 15 Business Concepts, compare open-source and commercial licenses, outline the goals of a “perfect” ontology-derived data model, and detail the outcome of the transformation: the FIBO Data Model.

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.

Part 2

Hello, welcome back to the second part of Semantics for Extra Large Banks.
This is Jurgen.
If you remember, in the first part, I spoke about the challenges for Semantic Centers of Excellence and the vision of Semantic Enterprise Information Architecture, with the FIBO at the apex and derived data, object, and message models.
I showed you the source ontologies, the FIBO and OMG Commons.
We looked at the Financial Industry Business Data Model.
How is it structured?
How does it preserve the extensive FIBO/OMG documentation?
Now, in the second part, we will look at how the Configurable Ontology to Data model Transformation CODT achieves its results.
“Atlantic” was the nickname for the first version, which used MS Excel Power Query and the M language.

The way to um SEIA’s Model-Driven Development.
We have relational databases, and now also semantic Triple Stores or RDF Stores.
We have the industry-standard FIBO in RDF/OWL, and we have always had data models that deploy on RDBMS.
And with CODT, the Configurable Ontology to Data model Transformation, we have the sibling of the FIBO, FIB-DM as a Conceptual Data Model.
Atlantic is the way to Semantic Enterprise Information Architecture and Model-Driven Development.
The FIB-DM Full version, as of Q4 last year, has over 3,000 entities. It’s the world’s largest data model.
And Atlantic CODT, the Configurable Ontology to Data model Transformation, created FIB-DM from the industry-standard ontologies.

The patented technology that created the FIBO Data Model and that’s US patent 1238939.
And in the first part, we learned that the old file-parsing approach doesn’t produce usable data models, and it cannot cope with very large ontologies like the FIBO.
The new ETL approach in CODT creates high-quality models.
The technology is fully scalable and configurable.
And what it really is is what we’ve done for 30 years.
From the RDF/OWL, it’s ETL, Extract, Transform, and Load into the data modeling tool. Metadata sets are keyed records that hold properties for all objects in a model. Ontology metadata sets hold the record extracted from the ontology platform.
Entity-Relationship metadata sets transform ontology into entity-relationship representation.
PowerDesigner (or other tools) metadata sets are ready to load into the data modeling tool.

Metadata sets are a radically different new approach.
They are metadata stored in data sets. That’s similar to system tables on your relational database. Just like they store metadata about tables, columns, and foreign keys.
CODT metadata sets are isomorphic representations of Ontology, Entity-Relationship, and data-modeling tool-specific metadata.
And then the transformation is a simple two-step process.
From the ontology metaset data set in step one, we transform it into generic entity-relationship metadata sets, and then, in the second step, we transform the generic ER into tool-specific metadata, such as here for PowerDesigner.
So, the same generic ER metadata set is the source for both PowerDesigner and Sparx EA metadata sets.

Let’s look at CODT as a system.
This is a UML component diagram and is actually Figure 2 of the CODT Patent drawings.
In the box is the Configurable Ontology to Data model Transformation. It interfaces with two external systems: the Ontology Platform, an ontology editor, or an RDF or Triple Store.
And the Data Modeling Tool, for example, PowerDesigner.
Then we have 3 core components: Extraction interfaces with the ontology platform. Transformation, and finally, we Load into the data modeling tool.
MS Excel for version Atlantic is the tool of choice to view and analyze tabular data. Every data architect has Excel and knows how to use it.
Therefore, MS Excel is a fast prototyping tool for the CODT Metadata Sets, and it makes it easy to deploy the transformation. Here, this little table shows the Components and the Metadata Sets. In CODT Atlantic, there are different Excel workbooks for ontology, entity-relationship, and PowerDesigner.
But any platform and programming language can implement the CODT system, the metadata sets, and the method.

From ontology class to data model entity, we follow the journey.
Here at the top, we have the Ontology MDS in Excel. It shows us the Classes tab.
At the bottom, we have the outcome, the PowerDesigner MDS for Entities.
PowerDesigner can import this Excel spreadsheet directly.
We will see how classes transform into entity Code, and how the SKOS Definition becomes a Comment on an entity, and how the Local Name transforms to the Entity Name.

The Extraction works with SPARQL queries.
That is the novelty. CODT doesn’t parse RDF/OWL files; instead, it uses SPARQL to extract the ontology metadata.
Here’s an example query that selects the class, qualified name, namespace, and definition, and filters out unnamed classes. We don’t need “owl:Nothing,” and we don’t need “owl:Thing.”
The result of that query is a CSV file.

Extraction loads the CSV result set into the Ontology MDS. The Ontology Metadata workbook imports the raw extract and performs simple format conversions from the raw result.
So, we have the Class, we have the Qualified Name, the Namespace, and the SKOS Definition. Other tabs load Ontology Metadata Sets for Superclasses, Subclasses, Equivalent Classes, Data-, and Object Properties.

Throughout CODT, Excel Power Queries extract into the Meterdata Sets.
Here is our Classes Metadata Set again. We see here a comment from the Commons Ontology, Authorization, Code Elements, Code sets, Classifiers, and so on.
These are all ontology classes. If we select “Get Data,” the Excel Power Query ribbon opens, and the Metadata Sets self-populate.
So, every worksheet has a query. We see the Queries & Connections for Class, Superclass, and Subclass here. We can “refresh,” meaning load individual or all Metadata Sets. The Queries & Connections pane shows the load status, any errors, and the number of records in the Metadata Set. For example, FIBO/OMG has 2,436 classes.

Excel Power Query makes the transformation rules very transparent.
Here, we have the Power Query editor, and on the left-hand side, we see all the Ontology Metadata Sets. And here, for the Class Metadata Set, it shows us the steps and transformation rules, and gives us a preview of the result set.

It shows us the editor of the Power Query M language. That’s a 4GL language.
We see the data source is the raw SPARQL query result set. It shows us the code for the steps that it applies.

Transformation step one into the Entity-Relationship MDS
We see the Entity tab and the Code um is populated from the Class Qualified Name. The URI is the Uniform Resource Identifier of the FIBO class.
A VBA function transforms the local name into an entity name as per the naming convention. There is basically an uncamel: changing the Camel Code into Logical Data Model names, and you can configure that.
Power Query, using the Ontology MDS as a source, populates the Entity tab in the Entity-Relationship MDS.

Transformation step two into the Tool-specific Metadata Set. There, we convert the generic E/R into a Data Modeling tool-specific meter data, in this case, for PowerDesigner, and PowerDesigner can directly import this spreadsheet.
For entities, the transformation is a simple copy of the record in the E/R Metadata Set.

Load into the data modeling tool.
Here we have PowerDesigner, and PowerDesigner imports the meter data set.
On the left-hand side, we see all the Excel imports defined in PowerDesigner. We have 25 of them.
And we see the Metadata Set Column mapping to PowerDesigner model objects.

Stacked queries and ETL master the complexity of the transformation.
We can see the query dependencies in MS Power Query.
On the left-hand side, we have the Ontology Metadata Sets, and on the right-hand side, the Entity-Relationship Metadata Sets. They are implemented in two Excel workbooks.
For example, if we look at Entity Subtypes, we see that this Excel worksheet is populated from the Ontology Metadata Set for Subclasses.
Just a note here about Intermediate Metadata Sets. How do we populate Associative entities? For example, in the OMG Commons and in the FIBO, an Object Property can have an Inverse Property. For example, OMG Commons Business Authorizations have “authorizedBy” and “authorizes.” We don’t want to have two Associative Entities in the data model. So, we configure transformation rules to merge these two, and then we derive Association Subtypes from both the Ontology Object Property and its Inverse.

Some statistics about CODT Atlantic.
The MDS folders contain the queries that provide the interface for Metadata Sets in the next transformation step. We can see the biggest piece is the entity relationship Metadata Sets, which has 80 tabs and 84 Power Queries.
In total, across the three CODT workbooks, we have 142 worksheets and 158 Power Queries. We have 18 SQL queries and 25 Excel imports into Power Designer.
So, CODT is a white box, an open book. Also, in the Excel version, the software fully discloses all worksheets, queries, and VBA code.
New users and operators can generate with a single click using the default configuration settings.
As a data architect, you use CODT as an ETL development platform, diagnosing results and tweaking transformation rules for your modeling and naming standards. And if you want, VBA developers can secure the data sheets and fully automate the ETL. Or you can port CODT to your ETL environment.

Let’s take a look at the CODT embodiments.
Here is the patent table 14. The shaded area in blue, that is Atlantic CODT on MS Excel.
The license includes the Patent Rights to use the Intellectual Property, to use the Metadata Sets and algorithm for full production Semantic Enterprise Information Architecture. You can automate interfaces and encode the patented embodiment below.
For example, you can create a connection to your RDF store and run the queries in a batch.
You can move the CODT server-side. You can migrate the ETL to your environment, or use your ETL language rather than M, and store the Metadata Sets on your relational database.
You can create a user interface for operators. You can create configuration wizards. And you can generate other models, such as object, message, or physical models. And finally, you can load directly using your data modeling tool or model repository API.

The Reverse Mode means transforming your Data Models into RDF/OWL to leverage your design of Enterprise Ontologies and Knowledge Graphs.
I said before, the CODT Metadata Sets are bi-directional. No matter what direction we go, it’s the same Excel tab. With that, we can reverse-engineer ontologies from data models.
Again, it’s ETL. Only here on the left-hand side, we have the Data Model, for example, in PowerDesigner.
We Extract, Transform, and Load into our RDF store. The first step is to generate list reports matching the Data Modeling Tool-specific Metadata Sets.
Power Query populates the Metadata Sets, performs basic data cleansing, and then the Tool-specific MDS populates the Entity-Relationship Metadata Sets; finally, the Ontology Metadata Sets populate from the Entity-Relationship Metadata Sets. Power Queries and formulas break the dataset down into Triples, and we load the Triples into the Ontology Platform using SPARQL CONSTRUCT or a bulk insert.

Here’s an example with a very simple model. The New York Stock Exchange OpenMAMA messaging API. This data model has some tables for Auction, Order Book, Quotes, and Trades.
The PowerDesigner entity list report has a Code, Name, and Comment. The Power Designer MDS sources this list report. We create this report in the modeling tool, then load the result set into our PowerDesigner MDS.

And then, we transform the Entity-Relationship MDS. The Meterdata Set here populates from the PowerDesigner Entity MDS. We have the same columns for the entity: Code, Name, Comment, Prefix, Local Name, and URI.
Prefix and URI are configuration settings matching the designated Prefix and Namespace in the ontology. In other words, I tell CODT that I want to use this prefix here for my generated um ontology.
The Entity Name transforms into a Local Name with a “camel code” string function. So, from the logical naming standard “Order Book”, we get the camel code. The Resource Name is simply a concatenation of Prefix, the colon as a delimiter, and the Local Name.

And then we can load into the Ontology Metadata Set.
There we have Class, Namespace, SKOS Definition, and the other properties.
This helper sheet, Triple Metadata Set, breaks down the Class record set into Triples: Subject, Predicate, and Object.
The triples that we assert in the ontology actually match the SPARQL SELECT joins.
We have triples that we want to construct, assert in the ontology: Subject, Predicate, Object – auction, RDF type, owl class. And that matches what we did to create FIB-DM: we queried Class, Qualified Name, Namespace, and SKOS Definition.
And then the Definition here is the same. Here we want to CONSTRUCT fib-omds:SecurityStatus, OMDs Security Status as SKOS Definition, and here’s the definition text.

Yeah, and finally, we assert the triples on the ontology platform.
Here we are in Topbraid, with several classes and our SPARQL CONSTRUCT statement. We see the Auction class with its SKOS Definition.

The United States Patent and Trademark Office has granted the CODT patent and published it with its 23 drawings, 19 tables, and 35 pages of specification, which fully disclose the invention.
You can read about the patent on the codt.net website.
16 claims comprehensively cover the method, system, non-transitory storage medium, and all embodiments. The patent protects CODT licenses and generated models, including FIB-DM.

About licensing CODT.
FIB_DM licensees can purchase CODT as an add-on, and new users can license CODT and FIB-DM as a bundle. There is no standalone CODT license, because Jayzed already holds the copyright to the FIBO Data Model.
Software deliverables are the MS Excel CODT workbooks. The license doesn’t limit the number of users. You’re free to modify the software and to create new models for internal use. Just as with your FIB-DM license, you must keep derived models confidential. So you cannot use CODT and publish your own FIB_DM.
Educational resources are included, and you’re free to modify, translate, add, lift off images and diagrams as long as they remain within your organization.
And the license fully covers the Intellectual Property, the patent rights. So you’re free to leverage Metadata Sets, queries, formulas, and algorithms disclosed in the source code and the specification for internal development. But you must not share CODT embodiments outside your organization.

As with FIB-DM, licenses are priced by institution size.
It started as per your EDM Council membership tier as a pricing segment.
The add-on price for existing FIB-DM licensees is 2/3 of the price of your data model license. For example, around $40,000 for a Tier B bank.
The bundle price for new users is 1.5 times the standalone FIB-DM.
And, as with FIB-DM, central banks, multilateral lenders, and other qualifying financial institutions receive the Tier-C price regardless of asset size.

CODT Proof of Concept.
That’s an offer to try, test, and evaluate CODT. The scope of Semantic Enterprise Information Architecture is quite a big undertaking.
FIB-DM already proves that CODT creates a superior data model. So, the objective for the PoC is simply to show that CODT works for your FIBO extensions, to test the application, and to evaluate the intellectual property.
The materials for the PC are the Excel workbooks, education material, and the Patent for Legal & Compliance to assess. It contains two days of training and three additional days of offline support (in emails and calls).

Who should be in a PoC team?
Management, Finance,, your business sponsor who’s authorized to sign nondisclosure and license agreements.
The Ontologist with an in-depth understanding of the FIBO and in-house ontologies, because you are the one responsible for adapting the queries to your SPARQL dialect. You produce the raw ontology metadata.
A Data Architect with experience in enterprise reference models. You configure CODT to match your naming standards, and you load Metadata Sets into the modeling tool. The developer or MS Excel power user with some experience in VBA, Power Query and the M language. You can troubleshoot complex formulas and queries and explore other technical embodiments.

Technical preparation for the PoC.
You should have a Power PC. I recommend Windows 11 64-bit with some 32 GB of RAM. MS Excel, Power Query, the Data Modeling Tool, and an interface to the RDF Platform are installed.
You need the platform where you have the FIBO ontology, the platform or ontology editor with a SPARQL query user interface.
That can be Toopbraid, Protégé, or any RDF Store semantic endpoint.
You should use the SAP PowerDesigner data modeling tool. If you have ERWin or other modeling tools, use the PowerDesigner trial first, and import the data model. Later, you can customize CODT to import into your tool.
You need the FIBO loaded into your ontology platform. You should try entity queries and reproduce the raw meter data extract. Your proprietary ontology should be an extension of the FIBO. Make sure to include FIBO modules and to define a prefix for your namespace. Here, for example, is the Bank ontology. There, we just have another TTL (turtle) file. The entity query must return FIBO alongside your classes with the prefix. So, this all means your FIBO extension or other in-house ontologies must be well-formed.

The Proof of Concept would typically take six weeks.
We have two weeks for the introduction to CODT and the transformation of the FIBO as a PoC, and then we repeat that exercise, adding your proprietary ontologies. You can explore configuration changes and other embodiments.

Next steps: if you want to discuss a CODT PoC, you can find further resources on the FIB-DM and CODT websites and on this video on the YouTube Education channel. You’re welcome to send me an email to schedule an overview and discussions with your questions and answers.

Summary and conclusion.
The Semantic Center of Excellence must not become another silo.
Our vision is Semantic Enterprise Information Architecture with the ontology at the apex.
FIBO is the industry standard, and FIB-DM is the superior industry standard data model.
CODT leverages the ontology for data management.
Copyrights and Patents protect your investment.
Well, thanks for watching.