The FIBO Data Model was the topic of the DAMA Johannesburg Chapter session on 7 September 2020. One hundred forty-seven people registered for the event, and despite the public holiday in the US and red-eye for East Asia, the ZOOM meeting had fifty-four people concurrent participants.

This page has the FIB-DM overview PPT, and the Zoom video recording, and a transcript of Q&A and discussion.

DAMA International is the world’s largest organization of data management professionals. The South African chapter holds a data modeling meeting every first Monday of the month.

Topic and Presentation

The Enterprise Data Management Council and its institutional members created The Financial Industry Business Ontology (FIBO) as an open business conceptual reference model.

The Financial Industry Business Data Model (FIB-DM) is a complete transformation of the ontology into a conceptual data model. Eight hundred users downloaded the 1029-entity Open Source version. With 2,048 normative and 4,062 informative entities, the commercial version is by far the most extensive Enterprise Reference Data Model for Banks, Investment Companies, and their Regulators.

The session provides an overview and demo of the FIBO Data Model and the patent-pending transformation technology that derived it.

---

Jurgen Ziemer is an Ontologist and Data Architect with twenty years of experience gained Global Financial Institutions and Consultancies. He designed enterprise model and warehouse solutions at the German Stock Exchange, Credit Suisse, CITI, and forty IBM client locations in North America, Europe, and Asia.

Learning about the Financial Industry Business Ontology at Deutsche Bank, Jurgen became a FIBO contributor and reviewer and presented at Enterprise Data World conferences.

You can download the PDF, PowerPoint, or the transcript.

---

Presentation, questions, and discussion (rough transcript)

The FIBO Data Model was the topic of the DAMA Johannesburg Chapter session on 7 September 2020. One hundred forty-seven people registered for the event. This document is a rough transcript of the presentation, Q&A, and discussion.

Presentation

Introduction

Let me let me start. I called it Semantics for DAMA International, the Global Data Management Community.

Those of you who looked at FIB-DM, on the website, the YouTube Channel, there is a whole series of “Semantic for … ” videos and presentations. It started all with “Semantics for Data Architects” almost a year ago, and that catchphrase caught on. Then came “Semantics for Business/Finance users,” for Managers, then the whole bank semantics series, Semantics for mid-size, large, and extra-large banks.

That’s why we call it Semantics for DAMA International.

How did we come to meet today?

The FIBO, the Financial Industry Business Ontology, is the most extensive domain ontology schema. What I mean by that is: Certainly, there are other very large ontologies. You all know the Gene Ontology – it has millions of triples. However, that is data. If you look at industry or domain ontologies, and you consider their schemas, the number of classes, FIBO is by far the most extensive one available for any industry or domain.

FIB-DM, the Financial Industry Business Data Model, is a complete model transformation of

the industry-standard into a conceptual data model. As of today, 850 users downloaded the FIBO data model.

Many of you remember in June; DAMA hosted a meeting about managing huge data models in PowerDesigner. George McGeachie [the presenter] chose FIB-DM as an example of a large PowerDesigner model. After the meeting, participants wanted to learn more about that finance model. So Howard asked me if I would like to present it. This presentation – I think Howard already shared the download link. On the FIB-DM website, you can find the deck, and after the meeting, the video recording.

You, the audience, I understand work at a Financial Institution, and your FI already embraces model-driven development, reference models, and industry standards. As a Data Architect, you have experience in these, and you want to get started on the new industry standard. As an ontologist with FIBO experience, semantic technologies are still emerging at your bank, and you want to promote FIBO concepts across your organization. Finally, for Finance folks, the business side, and management, you want to improve information management with a strategic path to semantic excellence.

About myself, I worked in Finance as a Data Architect for 20 years at Global Financial Institutions and

consulting service providers. In particular, for seven years, I was an IBM Software Group consultant for the Banking Data Warehouse Model. In that capacity, I went to 45 banks in North America, Europe, and Asia to teach about the IBM  model, to advice on customization and implementation. Alas, they never sent me to Africa or South America, and never to Australia, but everywhere else. After that, in New York, I was for four years, BFMDW related, at CITI and Deutsche Bank. At Deutsche Bank, somebody pointed me to the FIBO. That was seven years ago when I became a fan and expert. Since then, even today, I’m

still a contributor, reviewer for new FIBO releases, and a speaker at FIBO conferences.

My company um is 20 years old and holds the FIB-DM copyrights and is the designated assignee of the Configurable Ontology to Data Model Transformation patent.

Challenge, vision, and path

The challenge: There is a Chasm between Semantic and Conventional Data Management. The big Global Financial Institutions already implemented the FIBO. However, many mid-size and large banks face high barriers in tooling and human expertise. That is because the industry model is specified in Ontology Web Language. I fully support the Enterprise Data Management Council’s decision. It is the best way to specify a Business Model or a Conceptual Model. However, OWL is quite a complex language, far complex than E/R modeling, and it needs highly specialized ontologists. When you want to instantiate, it runs on specialized databases, the so-called RDF-Stores or Triple Stores. IT departments must still support and design relational databases. So, there’s a chasm between the big Multinational Banks

and smaller domestic organizations. There is a chasm within a Financial Institution between the ontology/semantic technology center of excellence and the rest of the bank.

FIB-DM is the bridge across that chasm, which unites ontologists and data architects. The industry-standard is available in your data modeling tool.

The vision is Semantic Enterprise Information Architecture, SEIA. When we look at architecture, we

can look at it by the Use, the Type, and the Level that it applies. We have done architecture for 20 years now on the data side: We have Conceptual, Logical Data Models, we transform them into Physical Models, and deploy on relational database management systems.

Nowadays, we also have ontologies expressed in RDF/OWL. They deploy on RDF databases. FIB-DM is a model derived from the ontology. The sibling FIB-UM was initially developed because some data modeling tools cannot import native PowerDesigner files. The UML version of the model you would use it to generate a class model, you can generate Java/C++ code out of it.

The latest entrant is FIB-CM, the Concept Maps – a simplified model that is simpler than the data model or the ontology for our interactions with the Business Users. In mine and probably your experience, a data model is becoming far too complicated, too abstract for them, likewise, even more so,  an Ontology Graph. So, This is the vision. Note that we have the same names, design patterns, and definitions for data, message, process, and objects across the enterprise.

How can we get to that vision? What is the path to it, especially for domestic smaller financial institutions that do not have the resources of the big global banks?

Starting this year, you can adopt the industry-standard, adopt the FIBO Data Model. As you roll out the data models throughout your organization, in parallel, you train data architects in Ontology Web Language, and you proceed to customize the FIBO, make your Enterprise Ontology. You reach your goal of Semantic Enterprise Information Architecture. The years are just indicative. Some FIs may traverse faster some may take more time. The benefit of the path is that you have an immediate return on investment because you’re using the FIBO content and design patterns from day one -not in two years from now when you finally have customized and implemented the FIBO. I believe you find it easier to learn a new language, RDF/OWL, because you already know the vocabulary. If you’re familiar with the Data Model, the 15 Concepts, you see the same patterns that you already know from the data model as a Graph. It is easier to learn OWL as opposed to both new language and content. If you become a reference implementation, I can teach and advise you on along that path.

Origins

The FIBO is the authoritative model of Financial Industry concepts, the definitions, and relations. About the Enterprise Data Management Council: Both the EDMC and DAMA promote data management best practices. DAMA is the world’s largest association of professionals, and not sector-specific. The EDMC is a Global Association of over 200 Financial Institutions. They describe the FIBO as “a Business Conceptual Model developed by our members.” It’s the consensus of large banks and investment managers. That’s why it is more authoritative than any vendor model.

Why did I come to develop FIB-DM, and CODT, the transformation ontology?

One and a half years ago, a New York Bank needed a schema for a new Security Master System. Of course, as a FIBO advocate, I tried to leverage the industry-standard. However, the challenge was that the data architects are not familiar with RDF/OWL. They don’t have experience in ontology editors, Protégé, or TopBraid. It was for me, the ontologist, to write SPARQL queries, extract metadata into MS-Excel so that the architects could review the content.

Another project was with a Connecticut Alternative Investment Manager. They had the Hedge Fund Ontology and some application to process regulatory forms. They just wanted to have that ontology data also on an RDBMS. I had the challenge of converting my operational ontology of some 200 FIBO and hedge fund classes into a data model so that I could create a database schema from it. The workaround was a manual transcription of graphs into ERWin, basically looking at the ontology and typing it into ERWin.

Existing tooling chokes on very large ontologies, and it does not derive a useful data model. Some modeling tools like IBM IDA and Sparx EA, they have a rudimentary import for RDF files. However, what comes out of it is not useful as a data model, and they crash um if they’re confronted with a gigantic ontology like the FIBO. That leaves ontologists and data architects to copy and paste manually. That’s when I developed a better transformation and the FIBO Data Model.

About the Premium/Freemium funding model: We all it from the android or apple store.French language: Parlez-vous français? If we want to learn French, we can get a free lesson, and we can buy more in the Premium version. Together, free content plus Premium is called a Freemium marketing/pricing strategy. In FIB-DM, the open-source has four modules, 1029 entities. The upgrade adds eight more modules, 3500 entities, and that together makes up the Full 2020/Q2 release with 4500 entities.

Ontology-derived data model

Let’s look at the left-hand side:: I have a simple ontology graph. We have a bank, which is a Depository Institution, and it provides a Bank Account, and a Bank Account is identified by precisely one Bank Account Identifier, the account number. At the right-hand side is a diagram you, as a data modeler, would design if you create a logical or conceptual data model.

You would have entities for the Depository Institution; you would have subtypes; you would have associative entities, and so on.

How does CODT work and derive? Classes transform into entities, and the subclass in the ontology becomes a data model subtype. Object properties transform to associative entities. This transformation is critical, different, and new: A common wisdom in numerous academic papers and commercially available transformations is “object properties transform into relationships” – this is wrong!

I wrote an article about it, pointing out where this failed approach loses metadata. Object properties become Associative Entities and class restrictions, domain/range determine relationships and cardinalities. When I did this transformation first, I found that the generated E/R diagram is the best representation of the business rules. It is what I, as a data modeler, would design. There are no missing entities and no unnecessary entities and relationships in the design.

FIB-DM in PowerDesigner demo

We have  4,500 entities, over 5000 relationships, 300 model packages (subject areas in ERWin). It is the world’s largest data model in PowerDesigner. I have a couple of models: This is the Core, the open-source version. There is a Normative and Informative data model—the Normative derived from FIBO Production and the Informative derived from FIBO Development. I open the Normative model.

A question was about the package structure of the FIBO Data Model and also the FIBO because data model packages derive from FIBO ontologies.

The central module is Foundation, the FIBO base module that has the framework for everything else. FIBO, in-turn, imports three Upper Ontologies: The Simple Knowledge Organization System, SKOS, and Specification Metadata are mainly used for Annotation Properties, in other words,  for documentation. Foundation imports from the Object Modeling Group, languages, countries & currencies. These are the ISO currency and country codes. These packages are within  Core, the open-source model version.

FIBO Business Entities adds on more types of legal entities and more roles that an entity can play. Finance Business & Commerce, adding contracts and business relationships constitutes FIBO Core.

The Full Version, the Normative content derived from FIBO Production, provides Securities, Derivatives, and Indicators. The Informative version, FIBO Development, is of very high quality and it has been vetted and reviewed, but not yet signed-off to make it Normative.

The Informative model then adds on Loans & Mortgages, Collective Investment Vehicles, in other words, Funds, Market Data, Business Processes, and Corporate Actions & Events. That is the structure of the FIBO.

One approach is to learn the data model is starting with FIBO Foundation, understanding the subfolders, the submodules underneath. Here, for instance, I look at Agreements – Contracts. I open the model diagram for contracts. The diagrams all come with the stamp here that shows you the version. Here are the contract entities. Because FIB-DM is a Semantic Data Model, it has deep hierarchies of subtypes. The Contract breaks down into Written, Verbal, Mutual, and Unilateral Contracts.

The blue entities are associations. A Contract has an effective date, an execution date, and Contract Parties, which can be a Creditor or Debtor.

That’s the structure of the Semantic Model: We have the Contract, which is an Agreement, and we have a Things in Role, Debtor, Creditor, the Contract Parties. That is a typical design pattern, and the associations also have deep hierarchies. The Contract Party can break down into “has Counterparty,” and “has Principal.” With the Counterparty, you may have more specialized base entities like a Policyholder in Insurance.

When I look at an entity, here at Contract has the name and the code, which derives from the FIBO Prefix, the module code in the FIBO, and the Local Name. The comment, some modeling tools say description or definition, derives from the SKOS definition.

New tabs in PowerDesigner: In other tools, you may have the Extended Attribute or User-Defined Properties in ERWin, or Sparx calls it Tagged Values. These are all documentation items in the FIBO. The FIBO documentation is more extensive than anything you would see on your data models. There are “Adapted from,” “Explanatory notes,” and so on.

The other very important tab is the Lineage, which is the traceability from the data model to its original in the um ontology. So, I have the resource name in the ontology Localname/ Prefix, what kind of ontology object it is, Class, Datatype Property, Object Property, or an Ontology. I have the URI. That is the link to the FIBO, the full traceability. Look at this: In PowerDesigner,  I can click on this link, and it takes me right into the FIBO, the FIBO Definition of the Contract on spec.edmcouncil.org. The restrictions serve two purposes: First of all, this is Ontology Metadata. These are Class Restrictions, and we preserve them in the FIBO Data Model. So that we can rationalize why does the Contract, why the Contract has an association, a connection, to “has Contract Party?” We see the expression of the ontology, and we can validate then why does the model look like this.

Furthermore, OWL is more powerful than the E/R paradigm. Some of these restrictions traverse several classes (or several entities), which is something we cannot specify in a Data Model. Some Restrictions may refer to lookup values – we cannot do that in the data model. In the Lineage tab, we preserve these FIBO definitions.

The FIBO resolves conceptual defects.

Here is a quote from Robert II d’ Uzès. “Let’s listen: Le Roi Est Mort, Vive Le Roi!.” The Involved Party is dead, long live the Autonomous Agent. Now, 600 years later, the Involved Party is still an ultimate supertype in numerous reference models and databases. The FIBO breaks up that commingled entity into two fundamental concepts: The Autonomous Agent, that would be a Person, Legal Entity, and the Thing in Role, that is what the Autonomous Agent does, the role it plays as a customer, as an employee, as a broker. You probably have an Involved Party in your Enterprise Models, which is wrong. These are two separate things. They would not have a common supertype, and they should never be in the same table – period.

FIB0-DM Concept Maps

These are 15 concepts, with mnemonic icons and abbreviations. We have Autonomous Agent, Thing in Role, we spoke about already. We have References, Arrangements,.which are codes, schemes, and classifications. We have Locations, Products, and Services. Again, the Service is not a subtype of the Product – these are two different things. We have Agreements, Documents, and to detail Agreements, we have Commitments. For instance, your limit on the credit card is a Commitment related to the credit card Agreement. Agreements break down into Contractual Elements. They may refer to Legal Construct. Of course, Account is a Fundamental Concept, and so is Time and Occurrence. Occurrence, elsewhere it’s known as “events.” These fifteen concepts are enough to visualize the design in user-friendly Concept Maps. 70% of FIB-DM entities are a subtype of the concept entities.  That’s the second access to the model.  You study the concept hierarchies. Here’s an example, a small one, the Location. All 15 Concepts have SVG diagrams where you can follow the subtype hierarchy.

For our interaction with the users, the Concept Maps … I think this is a way a user-friendly way to express and discuss the design. Here we have a Depository Institution, which is a Stock Corporation. It “has Issued Capital,” it has a Legal Entity Identifier. It has another Reference here, a Registered Address which is in some Country. There’s a direct correspondence from this user-friendly Concept Map to the Data Model. In other words, as a data modeler/ data architect, you discuss the left side and confirm it with the user, and scope from FIB-DM as is a data model.

Once you move on to ontologies, the same Concept Map directly corresponds to an ontology graph. You scope from the FIBO.

Harvest vendor and inhouse models

The FIBO resolves several defects in vendor and probably in your in-house models. However, you should keep them and harvest the content. You adhere to the 15 industry-standard and the subtype hierarchies, you adopt the FIBO/FIB-DM names and definitions, and then you just identify direct and indirect entity matches. What here’s Agreement some models call it an Arrangement. Probably all models have Security. You merge entities that are not already in FIB-DM. Okay, you just have to identify the appropriate supertype, and you merge in attributes from your vendor model. Note, the FIBO Data Model correctly defines Financial Instruments, Securities as a subtype of a Contract – it’s not a Product as in some vendor models.

Normative and Informative model

There are two models, actually, Informative and Normative. The open-source has Foundation, Business Entities, Language, Countries & Currencies, and Finance, Business & Commerce. The production version adds Derivatives, Indicators, Securities, and the Development version adds five more modules. As new models enter FIBO Development, they end up here, in the Informative model, and some like Loan are almost ready. Once they are signed-off, they move into the Normative model. You should do the same with your FIBO extension. Let’s say if you develop a module or a subject area for Credit Cards: You start it in the Informative part. When it’s all vetted, you move it over to your Normative Enterprise Model.

There is another way to look at it: Our goal is leverage; we want to leverage for implementation at a department, project, application level. Our method is to derive. We first turn to the industry-standard, we derive from the Normative FIBO Production scope Enterprise Data Model. Then we consult FIBO development alongside other standards, in-house models, and vendor models.

The strategic solution

FIB-DM m plus CODT, the Configurable Ontology to Data Transformation, is the strategic solution.

On the left-hand side, I have OWL, and there is FIBO, other industry in-house ontologies, and on the right-hand side, I have FIB-DM, our Enterprise model, project models. We generate data models from industry, and domain, and our proprietary ontologies. In the end-state in Semantic Enterprise Information Architecture, we do conceptual modeling in the ontology –  no longer as a data model. Then we derive the LDM or CDM from our Conceptual Ontology. We reverse-engineer our data models to extend the Enterprise and Project Ontologies. FIs who adapted the FIBO ontologies rapidly customize because they can reverse-engineer their data models into RDF/OWL.

U.S. Utility Patent application

Okay, CODT. The U.S. Patent and Trademark Office acknowledged the Utility Patent Application. It’s quite detailed with a lot of drawings, tables, pages, claims. Once granted, the patent protects CODT licensees, the generated models, including FIB-DM, and it enables me to share the transformation technology – to offer it for licensing.

Open Source vs. Commercial license

Here’s a comparison of the open-source GPL 3.0 license and the Customer Commercial license.: The open-source requires you to copyleft, which is to license your derived models to the public. With the Commercial License, you can keep your extensions private. Likewise, Education Materials are subject to copyright. You’re welcome to share and distribute, but you should not change them, including this PowerPoint. With the Commercial License, you’re free to modify, translate, edit, or even lift off images, but you must keep them within your organization.

Publish Open Source!

Here’s my appeal for DAMA, consultants, and vendors: Publish open source! That’s a way to showcase your expertise. The most question I get asked is about migrating FIB-DM from PowerDesigner to other tools. I have Sparx EA, I have PowerDesigner, but I don’t know how to migrate to E/R Studio. So if you have done that, publish a migration tutorial! Share your extensions and diagrams with hundreds of users. If you’re using the Sparx version and you did diagrams, then publish your Sparx model open-source. Here’s a breakdown of what modeling tools FIB-DM downloaders are using: 60% are on ERWin and PowerDesigner, the rest are on other tools. Publish your ERWin,  Sparx EA, Paradigm, or E/R Studio FIBO Data Model! Under the GP License, all the Core-derived works are open source already. You don’t have to ask for my permission to share them. Just make sure to retain or add the Jayzed, EDMC, and OMG copyright and license properties on all packages.

References

For further reading, there’s the FIB-DM website. For news, follow the LinkedIn page and watch Education Videos on YouTube. Just email me if you have questions that you didn’t get to ask in our meeting or if you want to schedule a private overview at your FI.

Thanks a lot.

---

Questions and discussion

-Howard: Jurgen, thank you very much. We appreciate the effort that you’ve put in, and it’s much intense work that you’ve done here. Thank you, I appreciate you sharing and spending time with us.

So, I would like to open it to the floor

Diagrams

-Participant: If I may, the diagrams in the PowerDesigner presents very well. So my question was, did Jurgen develop a layout algorithm, or was it manually laid out?

-Jurgen: PowerDesigner, just like ERWin, it does some default layouts and so on. In that regard, it’s much better than ontology tools. But no, I spend many days in laying out and making the diagrams neat. I follow a methodology to have the flow of foreign keys from the upper-left to the lower-right corner. That kind of makes diagrams consistent, clean to read, and understand. The color-coding: All Associative Entities are blue, and the Base Entities are orange.

-Howard: And I’m assuming that you set up in PowerDesigner?

-Jurgen: Right, this is a display preference. The associative entities have a Stereotype. Likewise, the relationships have stereotypes, whether they are a child or a parent. When we looked at the contract “has Counterparty,” then the Contract to the associative entity is a parent and the counterparty, debtor child relationship. Because the FIB-DM is a Semantic Data Model

Adopting the industry-standard

-Paul: You advise for a bank starting by your roadmap, the adoption of the data model. But that initial adaptation typically in industry-standards, you apply 60% or 70% to that, but you still need to leave room for the bank’s specific details. Can you just talk more about that process?

-Jurgen: Well, it is to make the FIBO, to make FIB-DM your Enterprise Reference Model. It comes gradually, evolving. You should follow the industry standard and then merge your current enterprise model into the FIBO.

-Paul: That in itself would be a big job, right? For a large organization, it requires many political discussions and debates. Or in your experience, that adoption is a relatively smooth process, getting through that first hurdle?

-Jurgen: Well, I think it is a lot easier because um the FIBO is an industry-standard. It’s not like a group of enterprise architects, says, I want to call it a Depository Institution, and some users want to call it a Retail Bank. You just say: Okay, that’s what the industry consensus is. Furthermore, you want to use the same names and patterns in the data models that you have on the ontology side.
-Paul: Yeah, you know, for example, IBM’s model, I just know of a local customer here, several, even if it brings a lot of new concepts, but still “debate” with that model to make it your own. Still quite a process for the customer. But of course, it is a vendor model. So as you said earlier, with something like FIBO, there is more consensus around it

-Jurgen: Right. It’s not a Waterfall like you have to review customize the whole model completely. You do this gradually. If you design a new system, a new database, then, of course, you turn to the industry-standard. Gradually your physical instantiations conform to the FIBO. If in a year or two from then, you do the Knowledge Graph, then it’s straightforward because your data sources use the same names as the Knowledge Graph Ontology. While the timeline may take two years for some institution or three years. It is the end-state, the vision that we strive to.

Other industry standards – ISO

– Henry: In terms of industry standards, in the Financial Messaging world, ISO 20022 –they also developed data models.

-Jurgen:

The ISO is the messaging standard, and the FIBO is a Business Conceptual Model. 30 person-years went into FIBO development – they considered ISO, FpML, and other industry standards. It is a lingua franca across industry-standards, including the ISO.

FIBO/FIB-DM and TOGAF

-Carl: Often, these competing initiatives, like TOGAF, Enterprise Architecture Initiative, would have as a part information architecture and then business process architecture. Can FIBO DM serve as enterprise-wide information architecture, for the sake of the TOGAF-style enterprise architecture initiative?

-Jurgen: Maybe Howard can answer that better. FIB-DM is a data model.

 -Howard: FIBO, as Jurgen says, that’s your data model, in terms of the business entities, whereas TOGAF is more of your architecture practice definition. How do I structure my practice? What are the roles and activities? How do I measure the performance of it, and through the life-cycle of development? FIBO focuses on the Financial Sector. TOGAF wouldn’t get involved at that level, very similar to the DMBOK that would talk about data architecture, and the important thing is developing an enterprise data model, but it’s industry agnostic.

-Carl: There’s much preaching about enterprise architecture, but in practice, the effort is so comprehensive that it’s overwhelming.

 Howard: I think this is one of the real benefits of an industry model like FIB-DM and FIBO. At the bottom line, architects are there to provide blueprints for applications, and using something like FIBO is phenomenal compared to starting on a blank page. Jurgen mentioned 30 person-years of development for FIBO – a phenomenal effort, and I don’t think architects in an organization can get to that level that quickly. Talking to people like Steve Hoberman, he was working on AT&T, he came in on the last two years of a 12-year project, and they canned it. Lots of failures, but I do feel it’s things like FIBO and what Jurgen’s done in terms of creating a base model, there’s a tremendous starting point., and some organizations may not be on here. Still, they are busy doing that, and it’s beneficial for them to have a reference model like this.

 -Jurgen: Number one, it’s a gradual path. You don’t have to implement it in full. You certainly, don’t have to do a 12-year project. While you are developing an enterprise model, you have the Reference Model for your project models. So if if you have to design Mortgages, a new database for Mortgages, you take the design patterns from FIB-DM. You don’t start with a blank page. That’s an immediate return on investment, irrespective of how long it takes to flash out a full custom Enterprise Reference Model. Use the model like you would use code libraries for your application development. You pick the pieces that help your specific project model.

FIB-DM for taxonomies

-Henry: In terms of unstructured data and unstructured content, can you use it as an input into a document taxonomy?

-Howard: This whole ontology translates into a Knowledge Graph very well, and that’s where you want to bring in your unstructured data. That’s what Jurgen is saying with a Semantic  Enterprise Information Architecture, and not just a data model because that Knowledge Graph that you get is more powerful than just the data model.

Henry: Many clients battle to develop a document taxonomy because they’re trying to do it from a blank piece of paper.  
-Howard: There’s this combination of what FIBO giving us there’s lovely concept maps to show the business.

-Jurgen: Yes. You mentioned taxonomies. The FIB-DM hierarchies are taxonomies. The Subtype / Supertype hierarchy is a taxonomy. You can extract it from the data model and put it in a spreadsheet, or load into your taxonomy visualization and sharing tools. Likewise, the 15 Concepts, these are the 15
FIB-DM taxonomies. If you want to look in that closer, there is an Education Video,” Semantics for Finance Users,” which dives in-depth into the 15 Concepts and makes a comparison about the taxonomy and the Concept Map hierarchy.

Conceptual vs. Logical Data Model

-Howard: You say that the ontology translates to a conceptual data model. To my understanding of the difference between a Conceptual Data Model and a Logical Data Model is purely at an attribute level. There are very few attributes other a business key, why you’re not referring to it as a Logical Data Model?

 -Jurgen: First, PowerDesigner differentiates between Logical and Conceptual data models –  other tools don’t do that. If you look at the FIB-DM in ERWin, it has the same diagram notation as a Logical Data Model. I choose the PowerDesigner Conceptual Model because its Meta Model is closer to the ontology. One example is that ontology Data Properties, the data items, are a thing on their own in the PowerDesigner Conceptual Model. E.g., “expiration date” is defined on its own; it can become an attribute on several entities. Another example is that the CDM has Associations as a model object type. The FIBO is primarily conceptual, by your definition, Howard – it is sparsely attributed and mostly on an entity level.

Data Architect vs. Ontologist

-Howard: I liked your progress map. How you refer to an ontologist as a data architect who is comfortable with the semantic way of modeling information. Is that your differentiation between architect and ontologist?

-Jurgen: The data architect is somebody who um is an expert in data modeling, the tooling, SQL, maybe Stored Procedures. The ontologist is an expert in RDF/OWL, SPARQL, and to some extent RDF databases.

-Howard: So these are undoubtedly distinct qualifications; these are usually distinct roles. But I think the two roads are merging. Data architects aspire to learn OWL, and so on.

-Jurgen: If you know the Vocabulary, FIBO Design Patterns, the hierarchies, the names, and then you see the same in an Ontology Graph, it is easier to understand and learn RDF/OWL.

-Howard: Right, that certainly makes sense.

Are models too big?

-Howard: I’m not sure if you read the paper by David McComb, who presented a data-centric architecture, and his criticism on lots of the organizations was the fact that the core model was too big. He’s saying we develop models that are too complex, and his suggestion is to have a core ontology. Then you extend the core ontology for a specific domain, call it Financial Instrument, and then you would grow the taxonomies and the ontology within that domain, but you don’t affect the core.

-Jurgen: No, I didn’t read it. You look at what constitutes FIBO Core – it is Foundation, Business Entities, and Finance Business & Commerce, and you want to regard the other modules as extensions? I don’t think the EDMC agrees with that. If you look at the Normative content: These are 2 000 classes or 2 000 entities in the data model. We are not saying, make it just 200 and call everything else extensions. Don’t shy away from large data models. They are a library. If you have the Encyclopedia Britannica, you don’t have to read through all 24 volumes. Maybe you just look up a few terms, but it’s good to have it on the shelf.

Semantic Model

 -Howard: Per my understanding, data modeling tools allow me to, for example, define a list of currencies in the domain values, and then the attribute can have that associated domain. You mentioned something that you couldn’t do that in an in the standard relational modeling?

-Jurgen: It’s not just allowed values for a code field. For example [in OWL I can define], a Treasury Bond is a Fixed Income Security with a Duration of 10 years that has been issued by the Federal Reserve Bank. That goes certainly beyond domain values, right?

-Howard: Okay, so, when you when you’re using the term reference, you’re not talking about code/decode, you’re talking about values that come from out from other providers, third-party providers.

-Jurgen: It doesn’t have to be a third-party provider. In the ontology, you can refer to Class Restrictions, and I cannot do that in the data model. The data model has relationships from one entity to another. I cannot formulate some logic that goes across several entities or refers to data instances. Here the ontology is more powerful than what we can do with E/R modeling. Therefore, in the [SEIA] end-state, you do conceptual modeling in OWL and then derive a Logical Data Model. FIB-DM preserves these class restrictions, these business rules, as Extended Attributes, as Documentation Items.

Reverse-engineer ontology from a data model

-Howard: Okay, that leads me on to my next question. If we reverse-engineer, take this approach: We’ve taken FIBO, we’ve converted it to FIB-DM, we’ve extended FIB-DM, to introduce other stuff, and now we want to take it back to the ontology. My question was, what do we lose?

-Jurgen: That’s a that’s a good question. If you reverse-engineer FIB-DM back into RDF/OWL [with CODT], you have a simplified ontology. Every entity becomes an ontology class, every Associative Entity becomes an object property, but you never get back these complex class restrictions that you have in the ontology. It is an isomorphic subset. If you have the FIB-DM model and you extend it for some purpose, for example, credit cards: You add like 20 new entities to the model, maybe you add attributes, remember the FIBO is not attributed. If you reverse that back into RDF/OWL, then you can use that to incorporate it into your Enterprise Ontology. It’s a very simple ontology, but it gives you a starting point. You don’t have to copy and paste and type in manually. You already have these entities converted into classes. Then you can add the Semantic Rules. It saves much time.

-Howard: Yeah, and I think that’s what I mean. Many of my customers have data models, and.they want to go into the new world of semantics, taxonomies, and ontologies. I got excited when you published about reverse-engineering as a way of getting our starting point a simplified or isomorphic ontology.

-Jurgen: Yeah, you have the links in on the PowerPoint. Check out on the YouTube channel, “Semantics for extra-large Bank” s, the Education Class about the Transformation Technology. Maybe we do a follow-up in a while. I just didn’t want to put too many slides in here because I think most people in the audience are not ontologists.

Party and Role

-Howard: You mentioned something about the Party and the Party Role. I’m indeed very comfortable with the differentiation between the subtypes of the Party being Individual, Organization, and with the latest one, the bot. Then the Party Roles being Customer Employee. Most of us were still dealing with it altogether. Do you think otherwise?

-Jurgen: Yes, because many models have that concept of an Involved Party, as a common supertype. Some models call it Individuals, FIBO calls it the Person, human beings, Legal Entities, Organizations, and other entities define their roles – these two are separate concepts. There is no common supertype. You are one record in the Person table, and then you may have a reference to some Employee table, to a Customer table, to a Borrower table.

-Howard: Sure, and I’m comfortable with that. Paul, maybe, on your side from a master data point of view, when you make use of Party, and then Party Role, in terms of Customer and Employee – they tend to be quite different to the actual individual, that am I. What’s your view on that, Paul?

-Paul: Yeah, the data points would be quite different. The Autonomous Agents, maybe just clarify that concept again, Jurgen.

-Jurgen: Paul, you know the Involved Party in the IBM model, the Teradata, in many others. That is an ultimate supertype, a data concept. Underneath it, you do have Persons, and the IBM model calls it Individuals, Legal Entities, Organizations, Organization Unit. Also, underneath are roles, as a Customer, Employee, Broker. The FIBO says is that this is wrong. The Autonomous Agent is the Person, Legal Entity, and the roles; these are separate concepts. They do not have a common supertype.

-Paul: Oh yeah, okay, that makes sense.  
-Jurgen: There are other examples. Product and Services are separate concepts in FIBO and FIB-DM. The Service is not a subtype of the Product.

-Paul: Don’t they, Product and Service, don’t they have a common supertype at all?

-Jurgen: No, they don’t. They relate to each other. Like, I can have a Product that’s a credit card, or the particular checking account offer,.and with that come services. Again, these are separate concepts in our data model, separate entities, and they should never be in the same table in the physical implementation.
-Paul: Agreed, a hundred percent.
 -Jurgen: There are many more examples, for instance, Security, Financial Instruments. In the FIBO, they are a form of Agreement conceptually. Some data models have Securities underneath the Product, which is wrong unless you’re an Investment Manager, and it’s one of your mutual funds or ETFs. Then, still, the securities in your ETFs aren’t Products – they are Agreements.

Product, Services, and Agreements

-Paul: I’m wondering a Product and Service, they might be bundled together in something else, like an offering or something like that, right? Would you care to model, to keep that in this kind of model, or is that purely a function of um of the implementation?

 Jurgen: I think a Product has an Associative Entity to another Product. That’s how you would structure Bundles. And Products relate to two Services. The checking account Product relates to payment services, check cashing services, and online services.

-Paul: I guess those are one of the things where the bank or the institution needs to think about how they want to deal with those concepts. Maybe, one way is just to have them associate each other with each other. That’s where like how the bank thinks about their product development or offering development. That’s where the nuances come in.

-Jurgen: Yes. Also, that’s where the Agreement comes in. The credit card offers have associated services and. You sign an agreement that would stipulate the limit on your credit with the interest rate. The Product provides a template, specifies the Services, and then Agreements are the individual instances where a customer signs up for it.

-Howard: With the associated Contractual Elements…

-Jurgen: Exactly, yes, the Agreement would typically refer to your defined Product/ Services;.it has Contractual Elements; it may refer to Legal Constructs, e.g., consumer protection. The Document is the PDF of the printed, signed Contract

-Paul: Which is unstructured stuff that starts coming in

-Jurgen: Right. The Agreement also confirms the Commitments, that’s the credit card limit.
Concept Map vs. ontology and data model

 -Gauchet (?): Your ontology is a bunch of concepts, which have relationships between concepts, and they show pictures or icons. The business can associate with those icons. So it helps them a lot. But I think this, where you go into ontology, where you then picture your conceptual model. In South Africa, we’ve got a standard bank and a first national bank, and all those big ones, so conceptually they all the same thing, but on a business level or it’s something different. So, they’re coming back to the definitions. I know there’s much skepticism, to get business to buy into something like that, is to take them through it and then make the definitions their own, putting their company words in there. That’s how you would win them over, and then you can build your Logical and Physical models based on this.

-Jurgen: First, The FIBO has excellent definitions. Even beyond the definitions or these annotation properties, they refer to the source. So it’s extensively documented. I recommend that any bank should adopt the industry-standard definitions. You can always add to it. But don’t redefine the concepts. Second, the diagram with the icons is something a user can understand – as opposed to the complexity of the data model, or even worse, the Graph, which has even more boxes, more objects in it. Also, it’s not just drawing, pretty pictures. The icons that you have here, Registration Authority or the Stock Corporation. They come from a controlled vocabulary. When you write a name in the Concept Map for the users, you already pick from something that’s a base entity in the model. Likewise, the connectors, the arrows, here “has Identity,” “has Registered Address,” they are associative entities in the model. As you develop the Concept Map with the users, You use the icons that she can understand, and you guide her with the controlled vocabulary. That and that makes it easier when you scope the ontology graph or the data model diagram.

-Gauchet: 100%. Your catalog, your business catalog, or go to your meta catalog. To make it work, to roll it out one has to make it business things, business language. They need to take the language

-Howard: This concept map is not an ontology; it’s a conceptual mapping; it’s a way of modeling. The ontology is a lot more powerful than what those concept maps are. But I think Jurgen’s done a fantastic job of taking the FIBO as an ontology and creating a Concept Map model, creating a Data Model, and creating the other ones, the UML. So there’s been lots of derivatives of the core ontology. You must be careful of saying an ontology is a concept. It’s the language and the structure of all elements within that. We would probably use those Concept Maps as groupings of data so that we can go into Powerdesigner in certain areas. But an ontology is not equivalent to a Concept Map. Am I correct, Jurgen?

-Jurgen: Correct. The Concept Map is an isomorphic subset of the Data Model and the ontology. Like going from the ontology, the FIBO to FIB-DM, you lose some semantics. The same applies here. The Concept Map is a simplification. It does not have the powerful constructs of the ontology or even the data model. My argument is: As we interact with business users, they can understand the left-hand side, but the right-hand side goes over their heads.

-Paul: Right, and I think there’s a big push now to start interacting and working more with concept maps to get the business to share with us the relationships and understand how these entities, how these concepts interact.

-Jurgen: Right. I recommend for anyone interested in the FIB Concept Maps to look at the YouTube channel. There is a class called “Semantics for Finance Users,” and that explains them in detail. Concept maps have been around as a communication tool with the business. The difference is, we don’t start with a blank page and circles. We use the icons that, over time, the users internalize, and we use that controlled vocabulary for what we call the circles and what we call the arrows.

-Howard: Right.

FIRO ontology

-Paul: I got excited with FIRO (Financial Industry Regulation Ontology) in that it could bring about regulatory adherence and compliance on top of an ingested FIBO ontology. I know from chat with George, there’s a little bit of a lack of maturity on the FIRO level. Is that your understanding? What’s happening with FIRO?

-Jurgen: I don’t think anything is happening with FIRO. Nothing had happened with it for the past three years, I suppose.

-Paul: I was quite excited about that idea or the concept of being able to regulate the data. That the elements that come into the FIBO. Is that still a vision? To apply a regulatory view?

-Jurgen: There are no references between the two. FIRO is an independent ontology. It doesn’t specify equivalent classes or pointers into the FIBO.

-Paul: Maybe I misread it. I thought FIRO was something that was on top of FIBO?

-Jurgen: You can watch my conference presentations. I worked on that a couple of years ago.  The “Bank Call Report in FIBO” or the “U.S. Investment Advisor Act in FIBO.” These were the Enterprise Data World conferences. I proposed the “Financial Regulation Ontologies” – they emerge the FIBO with the Legal ontology – LKIF, Legal Knowledge Interchange Format. I’m a fan of LKIF – I’m not a fan of FIRO.

FIB-DM vs. IBM model

 Howard: The IBM model and the FIBO – what’s your feeling about it? I’m assuming you like the FIBO because it’s an industry-driven open-source. Is IBM pulling together some form of an ontology of its data model? How is it progressing on this path?

-Jurgen: I left IBM a couple of years ago. I suggested that they should make the Industry Models available in RDF/OWL. I believe FIBO and the  FIBO Data Model are far superior to IBM or any other vendor models. It is three or four times the size, has a more modern design that addresses some conceptual deficiencies, has extensive documentation. Banks should adopt the industry-standard – not a vendor model. However, there’s much value in it [BFMDW]. Make a change to the 15 Concepts, the FIBO names and definitions, but don’t throw out your IBM model. Harvest in the valuable content. There are a lot of entities in the BDW that you don’t find in the FIBO. You merge these in,  underneath the right supertype in the FIBO hierarchy. As we said, FIBO is conceptual and sparsely attributed. The Attributes in IBM and other vendor models, in your in-house models, have tremendous value. You have to merge them into the target, the modern design of the FIBO.

The EDM Council, Retail and Auto?

-Howard: At the last EDW [Enterprise Data World conference] in San Diego, they mentioned FIBO or EDMC had taken on Retail as well. Are you aware of that?

-Jurgen: I was a speaker at the FIBO conference and heard this as well. They [the EDMC] are interested in doing “Auto,” like in vehicles, automobiles as an ontology. Well, I worked in Finance all my life. I wish they would focus the energy on the Financial Industry: Get Loans and these other modules into the Normative part, into Production, add on new subject areas like credit cards. The FIBO model, at least the Normative part, in my opinion, is a bit heavy on the investment side. It could have more for Retail and Commercial Banks.

Insurance Industry

-Howard: And also the Insurance.

-Jurgen: Excellent point. Yes, I would rather see the EDMC taking on Insurance than Retail or Automobiles.

Zelda Are there any videos or presentation more relating this model to the insurance industry? I’ve seen things that make sense to me

-Jurgen: I don’t have any presentations on the YouTube channel or the website. You have a good foundation for insurances. That’s a FIBO Foundation, Business Entities, Finance Business & Commerce. That together gives you over a thousand entities. Plus, as an Insurance Company, you have to manage your assets.  That’s where the investment side, Securities, becomes fascinating. How you manage your assets [premiums received]. Details, like policies & claims, are not there yet. Take the FIB-DM as a foundation and engage with the EDMC to add insurance content. I had an appeal together with Robert Trupitz, the leader of the FIBO development team, for data modelers to engage with the EDMC, helping to build out subject areas. They would love to see insurance people join the content groups and develop a model together with them.

-ZeldA: Because lots of this, I mean we’ve got the parties, you’ve got agreements, the Product and Offering would be interesting to see how that would work out in this model.

-Jurgen: Right. You have the foundation, the framework, the asset management side.-

Zelda: Long Term payout.

-Jurgen: But it doesn’t have detail on policies, on claims – that’s what you would have to add, to customize by yourself.

Conclusion

-Howard: All right. Thank you, Jurgen
-Paul: It was a great discussion, and thanks so much for your input and insights.

-Jurgen: Well, thank you guys, I enjoyed it, and I was blown away, like how many people were interested in, dialed in into this meeting. Again my appeal is to DAMA, folks who listened in: Publish your content open-source. In particular, if you migrated FIB-DM to ERWin, put it on the web open-source, and other users just take your ERWin model, rather than trying to migrate/import on their own.

-Howard: Yeah, fantastic. Okay, any last question?
 -Carl: What I’m interested in these days has to do with the central securities depository. I’m taking a look at the model, and it’s really easy. Thank you.

-Howard: Thanks, everybody

-Jurgen: Thanks to you, Howard, Paul, and thanks for attending

-Participants: Thank you. Thank you.

---

• 

• 

• 

• 

• 

• 

•