The FIBO/FIB-DM Navigator video explains the presentation and has live demos of the tool in MS Excel and PowerDesigner.
Data architects, business users, and ontologists use the tool to analyse hierarchies and connections in the model. It accelerates the scoping of project models from the industry standard.

In data modeler lingo, the term “island” refers to an entity with no relationships to the rest of the model. While the FIBO and hence FIB-DM are integrated and consistent designs (without islands), finding paths between two entities via relationships and Associative Entities remains a major challenge, even for FIBO experts.

You can study the PowerPoint presentation and download a PDF version.

Transcript of the lecture

Hi, this is Jurgen with the brand-new class for the Financial Industry Business Data Model.

The FIB-DM Navigator – a tool for architects to analyze designs and scope consistent project models. The Navigator is an Excel analysis workbook for FIB-DM. It has 23 worksheets that accelerate model research on hierarchies and associations. Just an Excel sheet without a special GUI, and we use standard MS Excel functionality to search, filter, and sort the metadata.
The workbook is prepopulated with the latest FIB-DM release, which is Q4 2025 or later. It’s part of the FIB-DM resources for commercial licences. So, who’s it for? Data architects find critical information ad hoc rather than traversing object relations in the data modeling tool. Business users or SMEs can use the navigator, and it doesn’t need any knowledge or a license for the data modeling tool. And finally, it’s also good for ontologists, because they have the same need to find the path when populating a FIBO- derived operational ontology or writing SPARQL queries. And remember FIB-DM Base and Associative entities: The lineage provides the URI of the FIBO class or object property that they derived from, and subtypes defined from FIBO/OMG comments are the uh rdfs:subtypeOf properties.

Islands: They are a great holiday destination. However, in a data model, an island is a defect.
The lingo means an entity that has no relationships with the rest of the model. Okay, so looking at the package diagram again, it shows isolated entities. Like, here are the Loan-to-Value ratio and the payment schedule. And here’s a whole archipelago of entities: payment history, the customer account, and payment transactions. Again, they are not connected to the Loan entities.
This is not a model defect. The FIB-DM package diagram shows only entities defined in the Loan source ontology. Loan imports other FIBO modules that define the Associative Entities, and we will see the supertypes of Loan account and Payments -they have connecting Associative Entities.

Navigation in this context is the path to query the data model or to populate it. So, how do we navigate from the Loan to its LTV or principal? Application developers need to query the FIB-DM database, and ETL architects must populate it.
There are no islands in the FIBO and none in FIB-DM. All entities have connecting relationships. The modeler – that is, you – is responsible for scoping a consistent subset model. So, within your FIB-DM scope, there mustn’t be any islands, which is a big challenge in a 3000-entity data model, and even for FIBO experts.

Looking at the Loans General package diagram. How do we find the connection from the Loan to the Payment Schedule? That is what this class is about. How do we research related entities in the modeling tool, and how can we accelerate that process with the navigator?

Typically, it goes via supertype associations. And if you remember the previous class, “Scoping our first Data Model,” we added supertypes to our scoped entities all the way up to the ultimate FIB-DM Concept Entity. No. In that class, we looked at the example from the Stock Corporation to the balance, and we scoped the Associative Entities to match the business requirements in the Concept Map. We did that for the rest of the scoped model, and Associative Entities connect all required Base Entities either directly or via their supertypes. There are no islands and no archipelagos.
But how do we find the correct FIB-DM associative entity?
Okay, so here we are in PowerDesigner with the Loans diagram. Double-click on loans, look at the properties, and there are dependencies. And with the dependencies, we see Maturity Date, Account, Third parties, Principal, and so on. Now, what’s interesting is also what we see here: some of these relationships are in other modules. So, here, the classifiers of most concepts in the FIBO class have classifiers. They are uh from OMG Commons. Here, relatesTo Finance Business & Commerce, or here Third Party, the Association is defined in Agreements
Now, probably the most likely one here is one Loan relatesTo. And if we navigate, we can look at its properties. There, we can see for the Associative entity, the dependencies that it has. And here we see: OK, it relates to the Loan and to the Customer Account. That’s very important. Let’s take note of it.
However, we don’t find the loan-to-value ratio with this. So, we look at the supertypes of the Loan entity, and here, the parents tab lists that the loan is a subtype of the Debt Instrument and the Credit Agreement Repaid Periodically.
So, we investigate those supertype entities, and the Credit Agreement has relationships with many associative entities. Here, the OMG Commons Contextual Designators appear to be a candidate. Because it’s defined here in Commons and it ties to the loan.
And now, just a remark here: to the left of the column in the name, we have the FIB-DM base package and its specialized package. In this case, “cmns” stands for OMG Commons, and “cxtdsg” stands for contextual designators.
So, we explore the Associative Entities. Here, we look at the relationships of the “appliesTo” Associative Entity and see that it has a long list. We find the Loan Payment Schedule here, which is what we’re looking for. So “appliesTo” has relations to the Loan, the Credit Agreement, and the Loan Payment Schedule.

Yeah, from the Loan Payment Schedule to the Loan. As we pull in the associative entity, we complete the links. Now we see that it has the Credit Agreement, and it also ties to the Loan Payment Schedule. Examining our entities, their associative entities, and related entities can be very tedious and time-consuming. In practice, both entities may be associated only through their supertypes, and that means we have to traverse down from a supertype entity to its subtype, searching for our target entity.
Sometimes the connection involves two associative entities. No, for example, to find the homeowner on a mortgage.

PowerDesigner also has an impact analysis that shows the loan relationships. We can find here, via the parents, the Credit Agreement. However, it will not show us the relationships of the supertype entity. And also, as we do that at 3,000 impacted model objects, it quite reaches its limitations.

The challenge in summary: Islands, entities, or clusters of entities without connections to the rest of the model are a defect. There are no islands in FIBO, hence none in FIB-DM. All 50M entities have connecting relationships.
The way from one entity to another often um involves their supertypes. Sometimes, the route involves an Intermediate Base Entity and two Associative Entities. So, finding the route in the data modeling tool can be slow and cumbersome even for FIBO experts, and for novices, people who are new to FIB-DM or the ontology, it can be overwhelming.

FIB-DM data architects need a fast and comprehensive tool to analyze entity hierarchies and associations: The Navigator.
The FIB-DM Navigator has a worksheet tab “Entity_1Association_ Entity_2” that shows all Associative Entities that are related to both the Loan and Loan Payment Schedule or any of the supertypes.
Here, in our case, we are not interested in Loan supertypes of Debt and Financial Instrument. The Credit Agreement is what applies to our loan.
On the left-hand side, there is the first entity, the Loan, and its parent, the Credit Agreement.
The distance here is the number of levels from the entity to the parent.
If we recall, in between the Loan and the Credit Agreement, we had the Credit Agreement Repaid Periodically. That one would be distance 1, and the Credit Agreement is a distance of 2.
We also see here in the center, all the Associative Entity “appliesTo” and on the right-hand side, we have the same information for the second entity. So, here it’s a direct match. The Loan Payment Schedule and its parent are the same. So the distance is zero.

The input data for the Navigator that is there’s few list reports from the data model. So here’s the entity name code comment stereotype that’s a standard FIB-DM release report. And if we look at it, we see that it has the definitions of all entities.
OK, and then another one here, um, the relationships and that shows there the relationship code entity one and entity two, and the stereotype, whether it’s parent-child or uh, in both directions. And, uh, finally, the subtype reports now have the code of the subtype entity, the parent entity, and the parent stereotype, as well as the child entity here.

Okay, here let’s look at the first five workbooks, which are all related to entity hierarchies in FIB-DM. So we have the entity definitions here, and that spreadsheet we already know from the quarterly release reports. And here’s the next one, Supertype. So here filtered for Loan. We now see that the Loan is a Debt Instrument and a Credit Agreement. Here, with the distance, we see how we traverse up in the hierarchy. From the Loan to the Periodic Credit Agreement. The Credit Agreement, which is a Written Contract, which is a Contract, which is an Agreement.
And finally, six levels up, we end up with the OMG comments Situation Concept, the ultimate supertype.
Speaking of it, this tab simply is a list of all ultimate supertypes in the data model.
So, in other words, entities that are not a subtype of anything. Or in the ontology: derived from classes that are only a subclass of The Thing. Yeah. Then here for these ultimate supertypes, a list of all their subtypes. And again, we can filter it here by the distance level, to see everything that’s directly a subtype of the Situation level 2, and so on, until we get down to Contract and so on.
Now, Subtypes: the same thing here, we see everything that’s underneath the FIB-DM Loan. In other words, the specialized types of loans include Secured Loans, Consumer Loans, Commercial Loans, and Guaranteed Loans.

The next three tabs are all about Associations. The Associations tab shows us the Base Entity, and here I filtered for anything in the Loans packages. We have the Loan, Guaranteed Loan, Collateralized Loan, and so on. And it lists here all the Associative Entities that are related to it. Here, for example, the Loan has an Associative Entity, “hasGuarantor”; on that association, the Loan is the parent. Now we can move on to the Supertype Association. So that shows again: it shows the Loan, then its parent, its supertype, the Debt Instrument. And we see here what’s related to that. In particular, here on the Debt Instrument, we find the Borrower, then the Credit Agreement. We find the Contractual Element, we find the Currency, we find the Contract Party, and so on. And so, here it goes all the way up to generic Contracts and Agreements, all the way up to the FIB-DM concept, the Situation. And the same here, we can look at the subtypes, the children of Loans. So here with these specialized Loans, we may find additional Associative Entities. For instance, here, the Guaranteed Loan is, of course, guaranteed by a Guarantor.

OK, now it’s important that when we are researching the path between two or more entities, we must first specify the two in the Filter tab. So, in our example, Entity 1 is the Loan, and Entity 2 is its LTV.
Next, we will refresh all queries, and the result tab will show the status and the number of rows. So a question always comes up: why can’t we just have a worksheet that shows connections among all entities?
The answer is that the model is too big. The self-join has too many rows. I tried it once. We see 21 million rows loaded, and that has reached the uh limits for Excel.

OK. Let’s do that in Excel. No. So we have here Entity 1, the Loan, and Entity 2, the LTV.
Then we must go to Data Queries and Connections. This shows all the PowerQuery queries that come with the Navigator workbook. Then what we do is we refresh them all.

Okay. And here it’s finished. And it shows us here that it has four rows loaded. The Entity_1 Association_Entity 2 tab. We see here Entity 1 is the Loan, and its parent is here the Debt Instrument, the Credit Agreement, the Contract, and again the Credit Agreement. We see the distance from the Loan to its supertype and to the Associative Entities. Pretty straightforward here, the “hasCurrency”. Sure, the Credit Agreement has a Currency, and so does the LTV, but that doesn’t help us navigate from one to the other. And the same really applies to a lot of the OMG Commons Classifiers, Aspects, and so on. No. So that is not a path. And with the remaining ones, we see that the Debt Agreement applies to a Loan-to-Value ratio. Typically, we want to be as specific as can be. So I wouldn’t pick the Contract, because we’re here on Loans. So, the Credit Agreement applies to that, which is what we want to scope for our subset model.

Yeah. And then we add the associative entity that applies to this to our scope. And we see here that it not only connects us to the LTV but also to the payment schedule and the loan-specific customer account. No. And then the next thing we do is we scope the appropriate Loan supertypes. We can go back to the supertype tab. And here we see the Debt Instrument and the Credit Agreement. Okay. And as we add these Credit Agreement Repaid Periodically, the Credit Agreement. So then we can read the model: The Loan-to-Value ratio, parent, applies to child, Credit Agreement.

Now, let’s check out how the Loan connects to its Total Outstanding Principal.
We enter here, update the second entity, and then run Data Queries and Connections again. What we see here is that it runs; there are zero rows for the Entity_1 to Entity_2 relation, and the worksheet is empty. In other words, there is no direct connection from the Loan to its Outstanding Principal.
But what we can do: There’s another tab here, Entity_1_Assoc_assoc_Entity_2
This expands our navigation path to include an Intermediate Entity. Now this yields a lot of rows, 130 in total.
But what we can do is we can narrow it down to exclude:
FIBO Derivatives; we can exclude FIBO Indicators, and then, with the remainder, we can just look here. So Debt Terms looks interesting, maybe Interest as well, and Repayment Terms. We don’t need Mid-price, Security (that’s all), Finance, Business & Commerce (pertaining to investments and securities), Trade Life Cycle, and so on.
So, here we have another Loan thing. We can scope out all our loan-related items here. And then that is it. And as we do it here, we are down to a manageable set of results. So let’s look at the information in the sheet. So here the left-hand side is the same as in the uh, um, uh, in the uh one of the join. No. So we have the entity 1, its parent, distance, the Associative Entity, and the Stereotype. And now what is new is that we have an Intermediate Base Entity. No. So, a yellow entity in a diagram, sitting between to complete the path. And then entity two here is also the same. We have the Outstanding Principal here, who was our filter. It’s super type the distance, and its Associations to the Intermediate Entity. Now, let’s look at picking the right one here. Contractual Element is a good candidate. We see here that it relates to Debt Terms and, here, interestingly, to Principal Repayment Terms. But what we really need here is that we don’t need the combined LTV, because, again, it only means a Principal is input into the LTV, and it’s also attached to a Loan. But no, have a deterministic path to it. We want a direct connection, and that’s here. That would be the Principal Repayment Terms, and we see one path here, already.
So the Debt Instrument has Repayment Terms that lead to an Intermediate Entity, Principal Repayment Terms, and that connects to the Total Outstanding Principal via its subtype. And another path here: The Credit Agreement has a Contractual Element, which is a Debt Term, and that Debt Term is associated with the Total Outstanding Principal. Okay. So let’s scope that, so we take what we found, and we scope it all into our project model.
We have the Loan, we scope its two supertypes here, the Debt Instrument, all the way up to the Credit Agreement. And here, under Total Outstanding Principal, we also scope the Principal Repayment Terms and the Debt Terms.
And we see here, there are two navigation paths.: One via the Credit Agreement. It’s parent “hasContractualElement.” The Debt and the Debt Terms govern the Payment of Principal.
The second navigation is from the Debt Instrument, which has Repayment Terms and connects to the Principal Repayment Terms, which, by the way, is a subtype of Debt Terms. They govern the Payment of Principal.
The recommendation is for our initial Conceptual Model to scope both ways.
OK. Then, as you move on to the Logical Data Model, you populate it by assigning data items (attributes) to the entities. No. And uh, that will then drive whether we keep both associative intermediate entities, or whether we keep the more generic path here via dep terms, or the more specific one via the principal repayment terms. No. And again, remember that from the scoping class. If, after attribution, an entity has no attributes and has no relations to other entities, we can remove it from the model.

Yeah. And here, briefly, there are four more useful tabs, in particular, if you look at an FIB-DM package and want to see what else is in other packages that may be useful for our scope model. No. So here we have entity one, all associations, which basically filters to entity one alone, and we find all its associations and the connected second entity. No. And then, um, there are the concepts here. These are predefined from the Situation all the way down to Service. And this is just a statistic of how many subtypes a concept has. Now here we see, like, uh, the situation is by far the biggest. I personally think it’s a bit too much, a third of a model subtype to one entity. But anyway, this shows how many associative entities are beneath the concept. And then the concept hierarchy. That is just showing all underneath the concept and concept associations. Again, like here, we have the concept, its mnemonic short code, and then its subtypes and their associations.

Then here are three more useful tabs. The concepts worksheet shows 15+5 concepts, including their names, shorthands, Ultimate Supertype entities, and two pivot tables. One shows the total number of subtypes under the concept, and the other shows the number of subtype-entity connections to associative entities.

Yeah. The first one here is the Concept Hierarchy. That’s simply a join of the Ultimate supertype hierarchy that we’ve already seen. And then filtered by the concept uh entities. And the last one is the final concept association. Same thing, a join of subtype associations and the concept table. And the tabs are useful for enterprise architects and other users to study how a concept fits into the rest of the model. Yeah, just some hint for um Excel power users who want to understand the workbook. Here we have our tab, Entity_1, Entity_2, two associations. On the right-hand side, we have the queries and connections. And if we double-click the query that populates this Excel worksheet, it opens the Power Query editor. We see the steps here, and we can go to the view to look at the query dependencies. Let me uh make this a little bigger here. Okay. So, um, here is our query, and we see here two incoming arrows that indicate a join. No. So, uh, it is a join of entity one associated entities and entity 2, the supertype, which is the filter. No. And the super type comes from the supertype table and from our filter. No. And the associative entity, um, comes from here: associations and super types. No, and super types in turn come from filter one and the super type.

Navigation for the ontologist. The data model and the ontology graph model the same business rules, concepts, and relations. It is even more challenging and time-consuming for the fiber ontologist to find the right object properties and class restrictions to navigate here from the loan to its outstanding principal. And here we see that, uh, both the data model diagram and the graph are the same. So the ontologist can leverage the navigator filter by loan and total outstanding principal class, and just rem uh remember entities in FIB-DM, and the navigators are ontology classes, associations derived from object properties.

Okay, conclusion.: We discussed that island entities without relations to the rest of the model are a defect. There are no islands in the FIBO or FIB-DM, and you must not scope entities without also scoping their associations, connecting them to the rest of your project model.
Finding the path between two scoped entities can be time-consuming in the data modeling tool. The FIB-DM navigator has Excel sheets populated with FIB-DM metadata. We sort and filter quickly to find associative, even intermediate entities to include in the scope and in the context of the FIB-DM education’s semantics for data architects, finance users, the 15 concepts, and, in particular, scoping a FIB-DM model are prerequisites for this class. So data architects and ontologists should also study the hierarchy and object property association articles, and optionally, the Configurable Ontology to Data model Transformation. CODT derived the FIBO data model.
Advanced Financial Institutions, using CODT to keep their customized ontologies, like a customized FIBO, and their data models in sync.
Okay, thank you for watching.