Semantics for eXtra large Banks

The Configurable Ontology to Data model Transformation, CODT Tutorial.

The Configurable Ontology to Data Model Transformation (CODT) is the technology that created the 3000-entity FIBO Data Model. The US Utility Patent filed to weeks ago opens CODT for Financial Institutions, who already customized the industry-standard ontology and need a data model reflecting 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 using the same language instead of repeating silos. The vision is Semantic Enterprise Information Architecture with ontologies at the apex and derived data, message, process, and object models.

I recommend to watch the video first, and then download the PowerPoint for your reference. The video demos the screenshots in PowerDesigner and MS-Excel, and the voiceover has twice the word-count because it explains the diagrams.

For full screen click maximize at the bottom of the online viewer.

Then start slide show in MS-PowerPoint online.

Text of the presentation

XLB embraces RDF/OWL and the FIBO
XLB has a Semantic Technologies Center of Excellence (COE) and RDF (Triple) Stores in Production
XLB uses and supports the development of the industrystandard ontology.
XLB downloaded and evaluated the FIBO data model.
The CODT patent filing enables full disclosure of the transformation technology.

Semantic Center of Excellence (COE) challenges

XLB already implemented, extended, and customized industry-standard ontology.
XLB has highly qualified ontologists and data scientists.

However, 95% of the bank still runs
on relational databases, using data models
Data Architects have the FIBO Data Model but can’t leverage the work of their Semantic CEO colleagues.
The risk is that Semantic implementations become yet another data silo, using a different language than the rest of the organization, impeding integration.

The Vision Semantic Enterprise Information Architecture (SEIA)

The way Semantic Model-Driven Development (SMMD)

Asset size is a poor proxy for semantic sophistication
Semantics for Data Architects, the name of the first FIBDM educations resource, became a catchphrase.
FIB-DM on the EDMC website was for financial institutions with less than $200 billion in assets, hence Semantics for Midsize Banks.
However, some financial institutions, hedge funds, for example, are very advanced. Many midsize banks on FIBDM are now building out ontology capabilities.
CODT is for Financial Institutions who are using and extending the FIBO, many but not all are extra-large banks.

Intended Audience & POC Team
Finance, management, or business stakeholder who has a working knowledge of Entity-Relationship and Ontology diagrams. You are authorized to sign nondisclosure and license agreements.
Ontologist with an in-depth understanding of the FIBO and in-house ontologies. You want to spread adaptation across your enterprise. You are well-versed in RDF/OWL and SPARQL.
Data Architect, with experience in Enterprise Reference models. You evaluated and want the industry-standard, FIB-DM. You are an expert in your Data Modeling Tool and its import functionality.
Developer / MS-Excel Power User experienced in VBA, Power Query, and the M-Language.

Inventor and Presenter
Jurgen Ziemer has 20 years of industry experience as a data architect and ontologist at leading Financial Institutions and service providers.
• Seven years as an IBM Software Group Consultant for the Banking and Financial Markets Data Warehouse (BFMDW) model at 45 banks in North America, Europe, and Asia.
• Four years were implementing BFMDW at Citi and Deutsche Bank.
• Contributor, reviewer, and speaker at FIBO conferences
Jayzed Data Models Inc. is a US consulting company incorporated in 1999.
Jayzed holds the FIB-DM copyrights and is the designated assignee of the CODT Patent.

Origins of CODT and FIB-DM
NY Bank needs Schema for a new Security Master System, trying to leverage FIBO for Logical Data Model.
Challenge Data Architects are not familiar with RDF/OWL and have no experience in Protégé or Topbraid Workaround Ontologist writes SPARQL queries to extract metadata into MS-Excel spreadsheets.
CT AIM with Hedge Fund Ontology SEC Form PF assessments needs a relational platform
Challenge Converting operational ontology of some 200 FIBO and hedge fund specific classes
Workaround Manual transcription of graphs into ERWin diagrams. Some metadata extract and import.
Existing tooling chokes on very large ontologies and does not derive a useful Data Model.
Ontologies and Data Architects copy and paste manually.
So, I developed a better transformation and FIBO data model.

Data Architect


Atlantic is the way to Semantic EIA and MDD
4,563 entities
The world’s largest data model.
Configurable Ontology to Data model Transformation (CODT)

FIBO is more than a Knowledge Graph
“The Financial Industry Business Ontology (FIBO) is a business conceptual model developed by our members of how all financial instruments, business entities, and processes work in
the financial industry.” (https// )
The Council and its members correctly decided to define the business conceptual model in Ontology Web Language (OWL), because of the superior semantics of the notation.
FIBO Conceptualization and Relations are fully applicable for lower-semantic taxonomies, concept maps, object-, and data models. FIB-DM is a perfect conceptual data model.
(https// and https//
Finance key point

The FIBO is superior to vendor data models
Almost six hundred years ago, Robert II d’Uzès proclaimed Charles VII King of France. Yet the Involved Party is still an ultimate supertype in numerous reference models and databases.
The FIBO breaks up that comingled entity into two fundamental concepts, the Autonomous Agent (person, legal entity) and Thing in Role (customer, employee, broker). © Jayzed Data Models Inc. 2020
The 15 fundamental business concepts

EDMC support and 800 data model downloads
“Many midsize EDMC members want to leverage the industry standard, but don’t have ontology tooling, databases, and the human expertise inhouse yet.”
With FIB-DM, Data Architects no longer manually transcribe ontology graphs, copy & paste definitions. Eight hundred users downloaded the Open Source version of the FIBO Data Model.
However, even with FIB-DM, Architects at larger Financial Institutions must still c&p their FIBO customizations and extensions manually.
Finance key point

Ontology-derived Data Model

© Jayzed Data Models Inc. 2020
Current tooling imports are not fit for purpose

The parsing approach is not scalable
Traditional transformations parse ontology files. They encounter elements of the ontology and create elements of the data model as they process the source files. The parsing approach reaches its limits with very large ontologies like the FIBO.
Per default, ontology object properties transform into data model relationships. This transformation loses Metadata for object properties with particular design patterns.
XLB and other large Financial Institution developed rudimentary transformations.

Compare FIB-DM to a vendor or in-house transformations of the FIBO and see the difference!
© Jayzed Data Models Inc. 2020
License the technology that created the industry-standard rather than DIY!

Outcome of the transformation Package Properties
The Package Name is the rightmost string in the ontology namespace.
CODT transforms the ontology prefix as the unique code of the package.
Note All ontology classes, properties with the
prefix fibo-fnd-agr-agr become model objects of the Agreements package.
The URI is the Uniform Resource Identifier of the ontology. It is a traceability link to the source of the model object.
The second part of this overview shows how CODT extracts properties, transforms and add them to the data model.
© Jayzed Data Models Inc. 2020
Package extended attributes
The Extended Attributes tab has a list of ontology annotations.
The default transformation configuration uses the Abstract to populate the Package Comment.
Extended attributes of Data Type Text are multi-line. For example, the Copyright attribute lists the Object
Management Group and EDM Council copyrights.
The License attribute lists the FIBO MIT license besides Jayzed and GPL-3.0.
Entity properties
The Name is the ontology class Localname, converted from Camel Case to LDM naming convention (capitalized with space between words).
The Code transforms from the ontology class Prefix Localname.
The Comment populates from the class annotation RDFS comment and SKOS definition.
There are two particular tabs for ontology derived data models, Annotations and Lineage.
Entity annotations
FIBO has extensive documentation captured in annotation properties.
The chart shows the number of classes with annotated documentation.

Entity lineage
The Lineage tab captures ontology metadata of the source class. The extended attributes provide traceability into the ontology and preserve semantics beyond the entity-relationship model.
The Resource Name is class Prefix and Localname. FIB-DM uses the resource name as the entity code, but you can generate your codes in the modeling tool.
The Localname is the rightmost string in the Resource Name and URI.
The Prefix is an abbreviation of the URI defined in the ontology.
The Uniform Resource Identifier of the class is a link to the FIBO source ontology.
Restriction and Equivalent class axioms formulate OWL semantics.

Complex FIBO patterns (e.g. sub-properties) …

https//   © Jayzed Data Models Inc. 2020     

Require a sophisticated data model transformation
See the article of issues resolved for many-to-many relationships, closure axioms, hierarchies, incomplete and inverse object properties.
https// © Jayzed Data Models Inc. 2020

Two models – Normative and Informative

© Jayzed Data Models Inc. 2020
Two data models in PowerDesigner or ERWin

For data modeling tools other than PowerDesigner, you import the two models – just like you did with the 2018-Q4 version.
© Jayzed Data Models Inc. 2020
FIB-DM Informative Packages

© Jayzed Data Models Inc. 2020

FIBO, vendor and in-house models for SEIA

DAs, merge in your vendor and inhouse models
Your vendor model has excellent value. Keep it and harvest the content!
Adhere to the industry-standard 15 concepts and their subtype hierarchies
Adopt the FIBO/FIB-DM names and definitions

  1. Identify indirect entity matches, synonyms
  2. Identify direct entity matches, beware of homonyms
    Robert’s advice
  3. Merge entities that are not already in FIB-DM, identify the appropriate supertype.
  4. Merge attributes from your vendor model.
    Note that the FIBO Data Model correctly defines Financial Instruments as a subtype of the Contract, an Agreement – not a Product as some Vendor model do. © Jayzed Data Models Inc. 2020
    The concept maps, FIB-CM, link to the data model.

FIB-DM General Public 3.0 vs. Customer License
Topic Detail Your current General Public License 3.0 Your upgrade Jayzed Customer License
FIBO Release 2018/Q4 2020/Q2
Domain Public Private
Distribution Original FIB-DM encouraged prohibited
Your FIB-DM derived works Open Source Private, not applicable
Number of
Entities 1029 1,968 (normative)
4,563 (informative)
Normative Foundation ✔ ✔
Business Entities ✔ ✔
Finance, Business & Commerce ✔ ✔
Securities X ✔
Derivatives X ✔
Indexes & Indicators X ✔
Informative LOANS X ✔
Funds X ✔
Corporate Actions X ✔
Market Data X ✔
Business Processes X ✔
Resources PowerPoints X ✔
Videos X ✔
Whitepapers X ✔
Open Source license requires you, to copyleft, that is to license your derived models to the public.
With a commercial license, you keep FIB-DM extensions private.
Likewise, for the public, all Education materials are subject to copyright
With a commercial license, you are free to modify, translate, edit, and even lift off images and diagrams as long
as they remain within your organization.

Financial Industry Business Data Model – summary
• Most comprehensive Enterprise Reference model
1,968 normative and 4,563 informative entities
• Superior Design of a Semantic Data Model
• Extensive documentation of the industry-standard ontology
• Full lineage to the ontology
• Semantic Enterprise Information Architecture
• Same names, definitions, and design pattern across the enterprise
• The ontology at the apex with business-friendly concept maps and derived data and object models.
• Unifies semantic and conventional data management

Transparency for your FIB-DM evaluation

Version 1.0 Atlantic CODT meets MS-PowerQuery

MS-Excel, PowerQuery, and the M-language
The patent-pending technology that created the FIBO Data Model
The old OWL file-parsing-approach doesn’t produce usable data models. It can’t cope with very large ontologies.
The new ETL approach creates high-quality models. The technology is fully scalable and configurable.

Metadata-Sets (MDS) are keyed records holding properties for all objects in the model. (E.g.. all 4,568 entities)
• Ontology metadata sets hold the record extracted from the ontology platform
• Entity-Relationship metadata sets transform ontology into ER.
• PowerDesigner (or another tool) metadata sets are ready to load into the data modeling tool.

Metadata sets are the novel approach.

Transform Ontology Transform the Generic ER The same generic ER Metadata Set is
Metadata into generic into Tool specific the source for both PowerDesigner Entity-Relationship metadata. and Sparx EA metadata sets. metadata

Ontology class to data model entity – a journey

System overview
Component Metadata Set Excel Workbook
Extraction Ontology Metadata Ontology MDS.xlsx
Transformation Generic ER Metadata Entity Relationship MDS.xlsx
Load PowerDesigner PowerDesigner MDS.xlsx
Microsoft Excel is the tool of choice to view and analyze tabular data, and every data architect has Excel and knows how to use it.
Hence, MS-Excel is not only a fast prototyping tool for
the CODT Metadata Sets but also makes the transformation easy to deploy.
Any platform and programming language can implement the system, metadata sets, and method.
CODT patent drawing FIG.2, System (numerals removed for clarity)
Extraction with SPARQL queries

Owl Classes.rq

SELECT ?class ?qname ?namespace ?skos_definition
?class a owlClass .
BIND(afnnamespace(?class) AS ?namespace) .
FILTER (smfisBound(?namespace) ).
BIND (smfqname(?class) AS ?qname ) .
OPTIONAL { ?class skosdefinition ?skos_definition}
FILTER (?class NOT IN (owlNothing, owlThing))
The SPARQL query selects Class, qualified name, namespace, and definition, filtering out unnamed classes.
The result set is a CSV file..

Extraction CSV result set into Ontology MDS
The ontology metadata workbook imports the raw extract and performs simple format conversions from the raw result set.

We have the Class, Qualified Name, Namespace, the CODT configured main descriptive annotation property, Prefix, Localname, and FIBO URI. Other Excel tabs, ontology metadata sets for Object Properties, Domain, Range, Sub-class, and Sub-property.
Excel Power Queries extract into the MDS

Transparent transformation rules

4GL Query and transformation language

Transformation (1) Entity-Relationship MDS

A Power Query with the Ontology MDS as its source populates metadata.

Transformation (2) Tool-specific MDS
The second transformation step converts the generic Entity-Relationship into a data modeling tool-specific metadata set. In this case, PowerDesigner can directly import this MDS.

For entities, the transformation is a simple copy of the Entity-Relationship MDS.
Load The data modeling tool imports the MDS

Stacked queries and ETL master the complexity

CODT Excel Power Query Statistics
Interface Intermediate Total
Ontology 21 20 41
Entity-Relationship 24 58 82
Data Model 23 4 27

    Total       150

The MDS folder holds queries that provide the interface for metadata sets in the next transformation step.
Plus 18 SPARQL query templates
CODT is a white box, an open book. The Excel version software fully discloses all worksheets, queries, and VBA code.
New users and operators can generate with a single click, using default configuration settings.
As a Data Architect, you use CODT as an ETL and development platform, diagnosing results and tweaking transformation rules for your modeling and naming standards.
VBA developers may secure the data sheets, fully automate Extract and Load, or port the application.
CODT Embodiments
The CODT license includes the right to use protected intellectual property, the metadata sets and algorithms.
For full production SEIA, you can automate interfaces, and encode the patent-pending embodiments below.
Ontology Source Transformation System Data Model
Application User Data Model Modeling Tool
Type Subtype Extraction OS type Interface Type Tool Interface
CODT patent Table 14, Embodiments (color added for clarity)
Create a connection to your
RDF Store and run the queries in a batch. Move CODT server-side. Hold the metadata sets on your RDBMS.
Transform with your ETL tooling rather than M. Create a UI for operators and
configuration wizards Generate other models Load directly using your data
modeling tool or repository API
Finance key point
Reverse mode embodiment, claim 13 & 20
The CODT Metadata Sets are bi-directional.
CODT can reverse-engineer ontologies from Data Models!

  1. 2. The Data Modeling generates List Reports matching the Data Modeling tool-specific
    The Power Query populates the Metadata sets, performing basic data cleansing. The Entity-Relationship Metadata Sets populate from tool-specific metadata set. 1.
  2. The Ontology MDS populates from the Entity-Relationship
    Power Queries and formulas break the data set down into triples.
    We load in triples into the ontology platform, using SPARQL CONSTRUCT or bulk insert.

Finance key point

Reverse example Extract from PowerDesigner
Data Architect
Our example is Logical Data Model created from the New York Stock Exchange’s OpenMAMA messaging API.
The PowerDesigner Entity list report has Code, Name, and
Comment. The PowerDesigner MDS sources the list report 
Finance key point
Transform in the Entity-Relationship MDS
The Metadata Set populates from the PowerDesigner Entity MDS

Data Architect
Load into ontology

Triple, “T_” metadata sets break down the class record into subject, predicate, and object.

The triple match the SPARQL SELECT joins
subject predicate skos_definition
subject predicate object Data disseminated during the auction period, i.e. the period of time when there is no automatic execution
fib-omdsAuction rdftype owlClass on an order book. This also includes indicative data and, where
fib-omdsOrderBook rdftype owlClass relevant, imbalance data sent during the
fib-omdsQuote rdftype owlClass skosdefinitio process that matches orders at the end of an auction and determines fib-omdsReferential rdftype owlClass fib-omdsAuction n the final auction price fib-omdsSecurityStatus rdftype owlClass skosdefinitio Represents the state of the order book.
fib-omdsTrade rdftype owlClass fib-omdsOrderBook n
The most current bid or ask prices and quantities at which the instruments can be bought or sold. The bid
quote shows the price and quantity at which a current buyer is willing to purchase the instruments, while

Owl Classes.rq skosdefinitio the ask shows what a current participant is willing to sell the SELECT ?class ?qname ?namespace fib-omdsQuote n instruments for.

?skos_definition    Represents standing data such as symbol, commodity, and exchange 
WHERE {     information and any pertinent

information about the contract terms. Prior trading period
?class a owlClass . closing/settlement prices can also be
skosdefinitio disseminated in this event type. Typically this represents static data. fib-omdsReferential n
OPTIONAL { Data that indicates the current market trading condition of an
individual security, for example, if trading in
?class skosdefinition ?skos_definition} the security is suspended. This identifies phase transitions in the fib- skosdefinitio venue’s market model.
} omdsSecurityStatus n
skosdefinitio Information that belongs to a transaction that involves the selling and
fib-omdsTrade n purchasing of a tradable instrument
Assert the triple in the Ontology Platform

Bi-directional model transformation enables SEIA

US Patent & Trademark Office acknowledgement
With 23 drawings, 19 tables, and 35 pages of specification, the non-provisional patent application fully discloses the invention.
Twenty claims comprehensively cover the method, system, nontransitory storage medium, and all embodiments.
Once granted, the patent protects CODT licensees, and generated models including FIB-DM.

License Agreement
• FIB-DM licensees can purchase CODT as an addon.
• New users can license FIB-DM + CODT bundle.
• (There is no standalone CODT license.)
• Jayzed already holds the copyright to the FIBO Data Model.
• Educations Resources are included.
• You are free to modify, translate, edit, and even lift off images and diagrams as long as they remain within your organization.
• Software deliverable are the MS-Excel CODT Workbooks.
• The site license doesn’t limit the number of users.
• You are free to modify the software and to create new models for internal use.
• Just like your FIB-DM license, you must keep derived models confidential.
• The license covers the intellectual property.
• You are free to leverage metadata sets, queries, formulas and algorithms disclosed in source code, and the specification for internal development.
• You must not share CODT embodiments.

Licenses are priced for institution size, using your EDM Council membership tier as a segment.
Line of Business Metric Tier A Tier B Tier C
Sell Side Consolidated Capital $10B+ $500M-$10B <$500M
Buy Side Assets under Management $200B+ $50B-$200B <$50B
Custody Assets under Custody $1,000B+ $100B-$1,000B <$100B
The add-on price for existing FIB-DM licensees is two-thirds of your data model license. E.g. $10,000 for a Tier C bank. The bundle price for new users is 1.5 times the standalone FIB-DM.
Central Banks, Multilateral Lenders, and other qualifying financial institutions get the Tier C price (without further discounts, irrespective of asset size.
Large commercial lenders and investment companies can get the early adaptor or stimulus discount.
Proof of Concept (POC) – overview
The Proof of Concept is an offer to try, test, and evaluate CODT free of charge.

Scope   SEIA is a huge enterprise transformation.

Objective Prove that CODT works for your FIBO extensions. Test the application
Evaluate the Intellectual Property
Materials MS-Excel Workbooks
Education materials
Patent application (for Legal and Compliance to assess)
Training & Support Two Days Training (online video conference)
Three Days support (emails)
FIB-DM already proves that CODT creates the superior data model.

Assemble your Proof of Concept Team
Management, Finance, or business sponsor. You are authorized to sign nondisclosure and license agreements.
Ontologist with an in-depth understanding of the FIBO and in-house ontologies. You adapt the queries to your SPARQL dialect and produce the raw ontology metadata .
Data Architect, with experience in Enterprise Reference models. You configure CODT to match your naming standards, and load metadata sets into the data modeling tool
Developer / MS-Excel Power User experienced in VBA, Power Query, and the M-Language. You can troubleshoot complex formulas and queries, and explore technical embodiments.

Proof of Concept – technical preparation
• Power PC (32 GB Ram), Windows 10 (64 bit), MS Excel, and MS PowerQuery
• Ontology Platform with SPARQL Query User interface Topbraid Composer, Protégé, or RDF-Store/Semantic Endpoint.
• SAP PowerDesigner (PD) data modeling tool. If you have ERWin or other modeling tools, use PD trial first and import the data model. Later, you may customize CODT to import into your tool.
• The FIBO loaded in you Ontology Platform. Before the POC try the Entity Query and reproduce the raw metadata extract.
• Your proprietary ontology should be an extension of the FIBO. Make sure, to include FIBO modules and have a prefix defined for your namespaces. E.g. @prefix br-bank-model .
• The Entity Query must return FIBO alongside your classes with prefix.

Data Architect


Proof of Concept typical six-week timeline
POCs are rolling with maximal two banks at a time.
Two weeks are for introduction into CODT and transforming the FIBO as a POC.
We repeat the transformation exercise with the addition of your proprietary ontologies.
You can explore configuration changes and other embodiments

Summary and conclusion

Next step Discuss a CODT POC
Send an email to, “CODT POC” to have an overview and discussion with your Q&A. You need a team and executive sponsor to sign off on NDAs.
Find further resources on the FIB-DM website, the YouTube Education Channel and follow the LinkedIn showcase for news, updates, and discussion.

https//  https//  https//