Ontology Class- and Data Model Entity-hierarchy, are they the same?


This article proposes that an Enterprise Conceptual Data Model derived from an authoritative Domain Ontology is an isomorphic submodel and an optimal relational design.

We present empirical support that the transformation is a structure-preserving map from Ontology Web Language to the Entity-Relationship Model with a one-to-one correspondence of the elements.

Taking the example of FIBO, the Financial Industry Business Ontology, we perform a quality assurance review of the derived Financial Industry Business Data Model, FIB-DM, starting with the generalization hierarchy rules in this part of the article, followed by entity and relationship rules.

There are two premises. First, FIBO has authoritative definitions and high-quality design. Second, data model rules are fully applicable to the higher-semantic ontology model.

The conclusion is that FIBO already reflects the data modeling rules, and therefore, FIB-DM is the optimal relational design for the Financial Industry.

Isomorphic submodel

An isomorphism exists between a subset of Ontology Web Language (OWL) and the Entity-Relationship Model (ERM). OWL has a higher expressivity and semantic richness than the ERM. In other words, we cannot express complex hypotheses in a data model. However, we can preserve the structure of classes, data properties, and object properties as entities, attributes, and associations in a Conceptual Data Model (CDM). The morphism is bidirectional. That means we can preserve the structure of a CDM through ontology classes and properties.

Configurable Ontology to Data-model Transformation (CODT)

CODT implements the morphism with configuration settings to generate a PowerDesigner conceptual data model.

Configurable Ontology to Data-model Transformation derives FIB-DM from FIBO.

My article and video explain the ontology-derived data model’s mapping, transformation rules, and structure in detail.

The empirical test examines list reports’ source and target:

  • Are all FIBO classes in the FIB-DM list of entities?
  • Data properties transformed to CDM data items?
  • Do we have all object properties transformed into CDM associations?
  • Structural, are the FIB-DM attributes on the correct entity as indicated in FIBO data property domain and class restrictions?
  • Do the relationships correctly reflect the object property domain, range, and restrictions?
  • Finally, the topic of this part is whether the generated inheritances (subtypes) represent the FIBO sub-properties.

We confirm the structural equivalence by comparing the ontology and data model profile and the object counts in both Topbraid and PowerDesigner. Then, we compare the list reports of source and target objects.

Module and data equivalence

A test for a logically correct ontology module is whether queries executed on the module produce the same results as performed on the initial ontology. Database administrators use the same test to validate data subsets.

The Bank Regulation Ontology is an operational extension of the FIBO. The ontology adds classes and properties to hold FFIEC Call report data. As presented at the 2017 FIBO conference, we load data into the extended FIBO and run SPARQL queries to reproduce parts of the regulatory report.

To prove that Bank Ontology and derived Bank Data Model are the same, we:

  1. Use CODT to transform the ontology into a CDM
  2. Generate a Physical Data Model (PDM)
  3. Create the schema on an RDBMS
  4. ETL our FFIEC sample data onto the database.
    The load is the first test to determine whether the derived schema fully supports the data requirements.
  5. Write SQL queries to extract Call Report data.
  6. Execute the SQL queries on the RDBMS and compare the results with the SPARQL queries on the RDF store.

The above is also the Proof of Concept for the Semantic Enterprise Architecture.

The diagram shows the ontology, a business conceptual enterprise model at the apex. We generate the conceptual, logical, and physical data model.

The matrix shows FIBO and FIB-DM in the context of model Use, Type, and Level.
Semantic Enterprise Reference Data Architecture

Both implementation RDBMS and RDF-store must be able to hold the same data. Both must return the same information.

Bijective transformation – ontology derived from the data model.

An isomorphism must be bijective on the underlying sets. That means FIB-DM transformed back to OWL must be equal to the FIBO.

The patented CODT transformation uses metadata sets for the source ontology, interim generic ER, target model, and PowerDesigner tool. The metadata sets are bidirectional by design. We can reverse-engineer a data model into an ontology.

CODT Reversed Transform data model into ontology
Reversed Transform data model into ontology

The roundtrip transformation “FIBO” has all classes, object-, and data properties. It will only lack the complex class restrictions on values and property chains beyond the relational model’s expressivity.

We can compare the two ontologies to prove they are the same.

Recap – FIBO and FIB-DM are isomorphic

In summary, FIB-DM is a complete structural representation of the FIBO, and the morphisms between ontology and data model are bijective.

  • We empirically show that FIB-DM represents all the FIBO model objects by comparing list reports.
  • An ontology reverse-engineered from FIB-DM is a module of the FIBO.
  • We instantiate FIBO and FIB-DM and show that both databases load the complete business data and produce the same query results.

Quality assurance review of the data model

We have shown that FIB-DM is an isomorphic representation of the FIBO. However, that doesn’t prove that FIB-DM is suitable as an enterprise data model.

In the aforementioned Call Report example, many poorly designed RDBMS instances still hold financial data and produce regulatory reports. A lousy database schema impacts performance and invites data abnormalities and inconsistencies. The same holds for poorly designed ontologies on RDF stores.

Therefore, we need an expert review of the Financial Industry Business Data Model to ensure quality.

Premise – FIBO is authoritative

The Enterprise Data Management Council (EDMC) is the independent authority on best practices and standards in the Financial Industry.

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. 
The EDM Council is the Global Association created to elevate the practice of Data Management as a business and operational priority.  The Council is the leading advocate for the development and implementation of Data Standards, Best Practices and comprehensive Training and Certification programs.

(Enterprise Data Management Council: https://edmcouncil.org/)

In my opinion, FIBO is superior to vendor models for these reasons:

  • The EDMC employs distinguished semantic experts like Mike Bennet, the “father of the FIBO,” and Dean Alemang, the “working ontologist.
  • Leading international financial institutions provide domain experts who participate in the FIBO content working groups.
  • The FIBO has the most extensive documentation with concise definitions and annotations.
  • Production releases undergo a rigorous review, including public comment, testing, and Object Management Group standardization.

Consequently, the quality of the FIBO design is assured, and I presume the source ontology is (almost) free of defects.

Premise – data modeling rules and best practices apply to ontologies.

The FIBO is a business conceptual model, as is an enterprise-level CDM. Conceptual models define concepts of interest to the business, their delineation, taxonomy, and relationships to other concepts.

  • The Logical Data Modeler specifies business concepts as entity types derived from tables with data records.
  • The ontologist specifies business concepts as classes. There are instances (individuals and members) that match the class restrictions.

The proposition is that the business concepts are the same regardless of the model notation, OWL vs. CDM.

To disprove the proposition, the expert review team must identify design defects in FIB-DM.

Financial Industry Business Concepts

Part one of this article reviews the major FIB-DM entity hierarchies.

In ontology, a fundamental class must be directly derived from The Thing. A Basic Concept in the data model must be an ultimate supertype. In other words, the entity must not be a child in an inheritance.

Forty FIB-DM entities, derived from FIBO fundamental classes, fulfill the condition. I arbitrarily designated the sixteen Basic Concepts as ultimate supertypes with a lot of subtypes and associations: Account, Agreement, Arrangement, Autonomous Agent, Commitment, Contractual Element, Currency, Document, Legal Construct, Location, Occurrence Kind, Product, Reference, Service, Thing In Role, and Time.

We examine the Autonomous Agent hierarchy as an example. The diagram below is a Scalable Vector Graphic (SVG). You can right-click and open the image in a separate tab. There, you can zoom in and out and scroll.

Autonomous Agent hierarchy diagram
Autonomous Agent (AA)

An agent is an autonomous individual that can adapt to and interact with its environment.

(FIBO class definition)

The subtypes of Autonomous Agents are Person, Legal Person, Automated System, and Organization.

Autonomous Agent subtypes

The Autonomous Agent hierarchy defines what an agent is – not what the agent does.

For example, the Person entity type is for a single individual human being. The various roles and employment positions of that person are in a different FIB-DM concept hierarchy, the Agent in Role.

FIB-DM has a different conceptualization than the IBM Banking and Financial Markets Data Warehouse Model (BFMDW). The IBM model places a common supertype, the Involved Party, on top of the Agent and Role. BFMDW famously has nine data concepts, while FIB-DM has sixteen.

Generalization Hierarchy Rules

The FIBO Autonomous Agent subclass hierarchy comprises more than eighty classes. With only two exceptions, these are primitive classes meant to be asserted by an application or load process.

The question is whether or not the ontology class hierarchy is optimal for a data model. In simple terms, would the expert review team raise defects:

  • Missing entities: Based on business requirements and the FIBO documentation, the reviewer suggests adding a sibling or intermediate level to the hierarchy.
  • Superfluous entities: The Reviewer flags entities as redundant; in other words, documentation does not support them.
  • Changes to the inheritances.

While no Normal Forms exist for ontologies, data modeling rules also apply to ontology design.

Subtype justification

Each subtype entity must possess one or more of the following characteristics: (1) at least one non-key attribute, or (2) a relationship with another entity that is logically only correct for it and none other.


Can we justify the two subtypes of the Adult entity in the diagram below?

FIB-DM Adult, Incapacitated, and Legally Capable Adult.
FIB-DM Adult, Incapacitated, and Legally Capable Adult.

As a conceptual domain ontology, the FIBO has only 150 data properties. Hence, FIB-DM is an entity-level model with as many attributes as possible. The reviewer considers whether attributes supporting the subtype are conceivable or even better supported in the documentation. The Incapacitated Adult should have a Date of Incapacitation, and the Legally Capable Adult a Date of Legal Capability. We can add a simple date attribute or a relationship to the date entity, and FIBO and FIB-DM support both design patterns. Once we derive a Logical Data Model from FIB-DM, we will attribute it and revisit the justification for the subtypes. We remove the entity if there is no supporting attribute or relationship.

The same considerations are under review for the ontology, and we can restate Reingruber/Gregory.

Subclass justification

Each subclass must possess one or more of the following characteristics: (1) at least one data property, or (2) an object property that is logically only correct for it and none other.

An operational ontology derived from FIBO must justify primitive subclasses with properties. Otherwise, the load process or application would not know which class to instantiate.

Supertype justification

A supertype entity or generalization hierarchy should be constructed under the following conditions: (1) a large number of entities appear to be of the same type, (2) attributes are repeated for multiple entities, or (3) the model is continually evolving.


The Autonomous Agent hierarchy is so detailed that reviewers are unlikely to report entities missing in the CDM. The example below shows attributes repeated for the Privately Held Company and Joint Stock Company. Such attributes would justify a Non-Public Company entity.

Attribution may also indicate a change in inheritance, such as making the Joint Stock Company a specialization of the Privately Held Company.

Again, the same design consideration applies to the ontology class hierarchy:

A supertype class or generalization hierarchy should be constructed under the following conditions: (1) a large number of classes appear to be of the same type, (2) data properties are repeated for multiple classes, or (3) the ontology is continually evolving.

In other words, some concepts only apply to the CDM but not to the ontology.

Subtype Discriminators

Every supertype must be associated with or contain a subtype discriminator.


In the Logical Data Model, the subtype discriminator is an attribute on the supertype that indicates which subtype(s) applies. For example, a Stock Corporation Type suggests the category of a Stock Corporation.

We do not require subtype discriminators in the Conceptual Data Model.

The less rigorous CDM opens an interesting question beyond the scope of this article: Is there an isomorphism between operational ontologies and Logical Data Models? I don’t believe discriminators are needed in an ontology unless they are business codes because of the Open World Assumption and restrictions on the subclasses.

Multiple Inheritance

A subtype entity can only be a member of the set of subtypes for one generalization relationship.


MultipInheritancence makes sense from a business perspective, and as a conceptual model, FIB-DM keeps multiple supertypes. However, the LDM permits only one supertype. Note that object models also allow various inheritances. Logical Data Modeler can use the same techniques to resolve multiple inheritances.

The FIB-DM Introduction class explains multiple inheritances in the CDM—a central bank is both a Bank and a Monetary Authority—and patterns to resolve during CDM to LDM transformation.

A valid multiple inheritance child must have characteristics of the supertypes – not merely reflect various taxonomies.

The Autonomous Agent hierarchy has two major nodes with multiple inheritances: the Polity Legal Entity and some hybrid business entities.

Legal Entity

A legal Entity is a partnership, corporation, or other organization organized under the laws of some jurisdiction that has the capacity to negotiate contracts, assume financial obligations, and pay off debts.

The diagram below shows that a legal entity is a legal person and a formal organization.

Legal Entity multiple inheritances
Legal Entity – subtypes and supertypes

The supertype Legal Person is any entity that can incur legal obligations and be sued at law. A formal Organization is recognized in some legal jurisdiction with associated rights and responsibilities. Examples include a Corporation, Charity, Government, or Church.

Both the Legal Person and Formal Organization meet the supertype justification. In other words, their subtypes share common attributes. All attributes apply to the Polity; hence, we have a valid poly-hierarchy.


A Politi is a legal person who is a supranational entity, crown, state, or subordinate civil authority, such as a province, prefecture, county, municipality, city, or district, representing the people of that entity. The Polity is also known as a Municipality or sovereign State Supranational Entity.

The Polity is a Legal Person and a Government Body, as shown in the diagram below.

An ER diagram of the Polity entity with its two supertypes, Legal Person and Government Body, and its subtypes Municipal Entity, Sovereign State and Supranational Entity.
Polity – subtypes and supertypes

A government Body is a formal organization that is an agency, instrumentality, or another body of supranational, national, federal, state, or local government, including certain multijurisdictional agencies and departments that carry out government business.

Note that Legal Entity and Polity share the same supertype Legal Entity. However, the second supertype of Polity, the Government Body, is a specialization of the Formal Organization.


Empirical evidence supports that the Configurable Ontology to Data-model Transformation preserves structural representation and bijection between ontology and conceptual data model. Hence, FIB-DM is an isomorphic subset of the FIBO.

We showed that data model generalization rules also apply to ontology class hierarchies. Accepting the premise that FIBO is authoritative implies that said generalization rules have already been reviewed and underwent extensive quality assurance. Hence, FIB-DM passes the generalization quality assurance review.

References and further reading.

The canonical version of this article:  https://fib-dm.com/ontology-class-and-data-model-entity-hierarchy/

Entities & Packages list report for the 2024/Q2 model: https://fib-dm.com/release-latest-normative-full-model/

Upgrade to the Commercial Models with 3,074 normative entities: https://fib-dm.com/full-data-model-upgrade/

Financial Industry Business Ontology (EDM Council website): https://edmcouncil.org/page/aboutfiboreview

The Data Modeling Handbook: A Best-Practice Approach to Building Quality Data Models by Michael C. Reingruber, William W. Gregory
Wiley 1996

The next installments examine Relationship and Entity data modeling rules.