Abstract

Model transformations depend on mapping meta-model elements of the source to elements of the target model. Academic papers, commercial tools, and education map the ontology class to the logical data model (LDM) entity, the data property to the attribute, and, erroneously, the object property to the relationship.

The Semantic Data Model emphasizes the common relations between entities. Ontology-derived Conceptual Data Models are Semantic Models by their origin. The Association or Associative entity is the appropriate design pattern for capturing semantics within the limits of Entity-Relationship Diagrams.

This article examines the points at which the ontology object property to LDM relationship transformation fails for unconstrained cardinalities in the Open World ontology, including ternary and higher relations, as well as critical RDF-S/OWL definitions for sub- and inverse object properties.

I propose that the Associative Entity, rather than a mere relationship, is the correct mapping of object properties.

The model transformation of this mapping requires user configuration and a holistic, metadata-set-based approach rather than the conventional parsing of RDF/OWL files.

The Configurable Ontology to Data model Transformation (CODT) enables the user to initialize transformation options.

Initially published in 2020, this June 2025 update of the article reflects the transformation technology patent, includes a diagram correction, and text improvements.

Background

Commercial Data Modeling tools have existed for more than two decades. Since their early versions, model transformations have been a core feature of these tools, generating a physical data model from the Logical Data Model (LDM).

Enterprise Modeling tools also support data transformation into object-oriented models and vice versa.

These transformations are straightforward and well-defined because the models describe information data sets with relationships between the sets :

• Entity Attributes, Relationships
• Table Columns, Foreign Keys
• Class Attributes, Associations

Ontologies are fundamentally different. The Resource Description Framework (RDF) stores data as triples consisting of a subject, a predicate, and an object.

My previous article argued that the Ontology Class and Data Model Hierarchy are the same. This, by implication, means that there is a one-to-one correspondence between the Ontology Class and the Logical Data Model Entity.

However, the conventional mapping of ontology object properties to data model relationships is a simplification.

Historically, the first transformations were one-directional, ontology staging, and Knowledge Graphs from relational sources. For this purpose, it is sufficient to transform data model relationships or foreign keys into object properties.

In recent years, the Ontology Web Language (OWL) has become the notation of choice for conceptual business models, also known as “domain ontologies.” The Financial Industry Business Ontology (FIBO) is a well-known example.

The assumption that we can derive the data model relationships from the object properties is false. The conventional mapping is not bi-directional.

The derived Financial Industry Business Data Model (FIB-DM) features associative entities rather than relationships derived from FIBO object properties.

Premise and approach

Just like we can translate an algorithm from one computer language into another, we can move data from one physical representation into another without losing information. We can take an RDBMS as a source and transfer the data into an RDF Store or vice versa.

The UML diagram illustrates a simplified use case featuring actors, including Business Users/Analysts (BAs), Ontologists, and Data Architects/Modelers.

Let’s presume the BA perfectly defined the requirements and the information. Examples may include financial messages, as in ISO 20020, or the thousands of pages compiled by the Enterprise Data Management Council team through interviews and joint development sessions with subject matter experts in the FIBO content groups.

• The Ontologist extends the use case and designs an optimal RDF/OWL.
• The Data Architect or Modeler extends the same definitions and requirements, designing a “perfect” data model.

The premise is that design ontology is a generalization of the “design data model” use case. In other words, the ontology already contains all the necessary information to design the optimal data model and database schema. Just like we can regard a use case, “design Physical Model,” as a specialization of “Design Data Model,”

The CODT approach considers the derived data model not as a translation of model objects but as coming as close as possible to the optimal model a data architect would design.

The next sections examine the design issues associated with the conventional transformation of object properties into relationships and demonstrate the correct design in FIB-DM.

These are Data Modeling textbook examples. What would you change as a Data Modeler to fix the “X Wrong” design defect?

Shortcomings of the object property to relationship mapping

The purpose is another fundamental difference between Relational Database Management Systems (RDBMS) and RDF stores.

• RDBMS are for operational data, core banking
• RDF (also known as Triple) Stores are used for knowledge representation.

Open vs. Closed-World Assumptions

The closed-world assumption (CWA), in a formal system of logic used for knowledge representation, is the presumption that a statement that is true is also known to be true. Therefore, conversely, what is not currently known to be true, is false. The same name also refers to a logical formalization of this assumption by Raymond Reiter. The opposite of the closed-world assumption is the open-world assumption (OWA), stating that lack of knowledge does not imply falsity.

(Wikipedia)

For a relational database, the CWA, “what is not known to be true, is false,” means that what does not conform to the schema is a violation. Using SQL, we must first create tables for Investment Advisor and Exchange Traded Fund before we can insert our BlackRock data sample. An INSERT INTO TABLE statement can only have values for columns defined in the schema.

All data must conform to the predefined DB schema.

For the RDF-Store, OWA, “lack of knowledge does not imply falsity.” We use SPARQL, the query language, to CONSTRUCT (insert) the triple without having defined Classes for Investment Advisor and Exchange Traded Fund. Likewise, we can construct data properties for the fund and advisor without defining their range and domain beforehand.

All data is permitted unless it violates an explicit schema constraint.

The Closed-World Assumption and Open-World Assumption are optimal for operational data origination and manipulation versus knowledge representation. We can transform the CWA schema to OWA—we simply lift the restrictions. However, deriving CWA from OWA requires configuration.

Many-to-Many relationships.

Even a well-formed domain ontology, such as FIBO, does not have cardinality restrictions for all object properties.

Citizenship, for example, is a many-to-many relationship. A country has many citizens, and a person, like the author, can be a citizen of several countries.

The FIBO graph displays the Person and Country classes, with an Object Property indicating Citizenship.

Note that the predicate-object connection is established solely through the domain and range of the relation. We can construct any triple of Person, hasCitizenship, and country.

The naive transformation derives two entities connected with a many-to-many (n:n) relationship. Data Modeling best practices and standards at most Financial Institutions state that the modeler must resolve n:n relationships, in other words, change them into associative entities.

The SAP PowerDesigner tool uses associations for the Conceptual Data Model (CDM) and hides the n:n cardinality in the Logical Data Model (LDM).

While we can debate the strong word “wrong,” we agree that an ontology-to-data model transformation must offer different options for different Enterprise Modelling Standards.

The CODT default options for the Financial Industry Business Data Model transform all object properties into associative entities.

The transformation assigns stereotypes <<Associative Entity>> for the derived entity and <<Parent>> / <<Child>> for the connecting relationships. (Commercial version)

Finitary, n-ary relations

The relationship in a data model is binary, connecting exactly two entities.

Object Properties, however, may specify more than one domain and range class. Relations with more than two places are called ternary or finite. A textbook example of a ternary relationship is the Sale with Buyer, Seller, and Agent.

An Object Property may even stand independently without attached classes per the OWA. In other words, all classes in ontology are valid objects.

Let’s consider registrations as an example. In the FIBO, a Registrar or a Registration Authority can register things. The graph illustrates the registers object property, and on the left side, the two domain classes are shown.

On the right side, the graph depicts the Legal Entity Identifier and National Securities Identifying Number as examples.

This graph is already too complicated for most business people (unionOf, first, rest, onProperty, someValuesFrom). The Financial Industry Business Concept Maps (FIB-CM) are a simplified notation for non-technical users.

The static transformation into relationships results in a cobweb. The diagrams only show two concepts that can be registered – there are a dozen more in the range of registers. Without qualified restrictions, the blind transformation into relationships requires permutation, as all parent entities relate to all child entities.

Furthermore, the Entity-Relationship Model has no context between relationships. In other words, we lose the semantics that all four “X Wrong” relationships have a single common definition and origin.

The “✔ Correct” Semantic Data Model replaces the cobweb with a single association in the center. Some FIB-DM users say that this semantic model pattern resembles a Star Schema, specifically the factless fact table. This pattern is typical of ontology-derived data models.

Note that both models permit data anomalies—they are not in the Fourth Normal Form (4NF). For example, the Legal Entity Identifier may have a Registrar and a Registration Authority. The “Semantics for Data Architects” webinar video and handout explain how the Logical Data Modeler can resolve this pattern.

Transforming the Closure Axiom

The aforementioned “registers” FIBO graph didn’t constrain “who registers what,” and neither does the ontology-derived Semantic Data Model.

The FIBO graph below shows the classes of Legal Forms, Systems, Obligations, and Regulations. They apply in various Jurisdictions. Open World, we may insert triples of a Legal System that applies in a Housing Unit.

The appliesIn ONLY cardinality restriction owl:allValuesFrom is a closure axiom stating that a Legal System applies only in a Jurisdiction, nowhere else. Here, the EDM Council ontologists “close the world.”

The Legal System has no relationship to the applies In associative entity. Instead, a particular subtype of an associative entity establishes the connection to Jurisdiction.

Note that the Legal System only applies In associative entity has no corresponding FIBO object property. CODT creates the only association when it encounters closure axioms.

Object Property Hierarchies

The sub-property is an important RDF-Schema construct. We establish hierarchies of object properties. In the business conceptual model, the FIBO structures most object properties under the top properties “has” and “is.”

The graph illustrates an example of a Monetary Amount, including some of its sub-properties: Notional Amount and Principal Amount. (blue icon)

On the left side, we see some of the many domain classes, such as the Fund Portfolio, the Certificate of Deposit (CD), and the Loan. On the right-hand side, the domain classes are Balance, Percentage, and Loan Principal. We can state the business rules:

• The Loan has a Loan Principal Amount
• The CD has a Percentage and a Monetary Amount.
• The Fund Portfolio has a Balance.

Note that the Inference Engine (Reasoner) will infer that all have Principal and Monetary Amounts. In SPARQL, we can query all values using the Monetary Amount.

The hierarchy of associative entities is also a critical data model pattern. For example, the IBM Banking Data Warehouse Model has deep hierarchies between the nine data concepts.

The naive transformation of object properties into plain relationships is incorrect because it loses important ontology metadata.

How would you, as a Senior Data Modeler, fix the design?

The correct model replaces the relationships with associative entities. We derive the subtype hierarchy from the ontology sub-properties.

This is also important for the Physical Data Model (PDM) and the database. The supertype table contains all records of its subtype. Hence, just like the data scientist in SPARQL, the database developer can query all relations at the supertype level in SQL.

Incomplete Object Properties

An Object Property may not have a range or domain in the Open World Schema. In FIBO, anything may have a price. Consequently, the object property has a range in Price but no domain. The diagram depicts the graph with hasPrice sub-properties. Note that “hasPrice” is a sub-property of the generic “has” object property.

This semantic design pattern is quite common. FIBO Production, the industry standard, has 74 object properties that do not have both domain and range specified as property or class restrictions, including appoints, various dates and amounts, owns, rates, and regulates, among others.

---

A data model relationship must have a parent and a child entity. An ontology-to-data model transformation that derives relationships from object properties cannot transform Price and the other 74 object properties. We lose these FIBO schema constructs.

The diagram shows the correct transformation into an associative entity with only one related base entity, the child stereotype.

The design pattern is typical for semantic data models. We want to model the fact that all these Price relations, Offerings, and Call Prices have a common supertype.

The pattern is also valid for Enterprise Data Models, even without a subtype hierarchy. The reference data model provides building blocks. You, the data modeler, scope has Price and Price and create the parent relationship in your project data model.

Inverse object properties must merge.

Almost everything in the Financial Services Sector has an ID, Including Loans, Contracts, Documents, Securities, Persons, Legal Entities, Banks, and other Service Providers. The FIBO connects the ID with the Thing via the identified object property.

The example graph illustrates the Universal Loan Identifier (ULI), which identifies a Loan. The class restriction means that a ULI is identified exactly as one Loan.

We notice that another object property isIdentifiedBy is the inverse of identifies. Sometimes, this may be an alias for the user’s convenience. However, for the ontologist, creating an inverse object property is the only way to specify cardinality for the participating domain.

The conventional mapping of object property to relationships erroneously derives two relationship lines between the Loan and its identifier.

This incorrect design creates two foreign keys between the tables in a PDM: a Loan ID on Universal Loan Identifier and a ULI ID on Loan.

The correct model transformation merges the two object properties into one associative entity.

But which name should we retain? Data Modeling Naming Standards stipulate active names for relationships. In our example identifies - not the passive is identified by.

Inverse object properties are one reason the ontology-to-data model transformation must be Configurable. With CODT options, you specify defaults for source ontologies in English: Object Property names starting with “is” or “has” indicate a passive form. However, for inverse property pairs like “sells to”and “buys from, “you, the architect, must tag which name to use.

PowerDesigner changes to a uniform associative entity

Depending on the selected configuration option, CODT can transform object properties into associative entities, PowerDesigner (PD) Conceptual Data Model Associations, or simple relationships.

The PD CDM has a dedicated Association model object. However, you cannot subtype associations. The previous 2018/Q4 version had a configuration mix of Associations and Associative Entities for object properties with sub-properties. Most PD CDM users found the mix confusing. Therefore, all object properties have been associative entities since the release of the 2020/Q1 FIBO Data Model.

Object properties with one-to-many cardinality and no sub-properties don’t technically need an associative entity—they could transform into plain relationships. However, I don’t want to mix model patterns for the same reason mentioned above. Furthermore, we avoid complex changes in the Semantic Data Model. For example, if an object property gets a sub-property, we don’t want to change the data model from a relationship to an associative entity.

From mapping to transformation

The correct mapping requires a Configurable Ontology to Data model Transformation. The complexities of inverse object properties and closing axioms are beyond the scope of the traditional ontology file parsing approach.

• Using SPARQL, CODT extracts ontology metadata from development tools such as TopBraid Composer, Protégé, or an RDF Store.

• CODT has 150 Metadata Sets for Ontology, generic E/R, and the specific data modeling tool. The transformation operates on whole sets rather than parsing hundreds of FIBO files. The holistic approach is mandatory for complex OWL constructs.

• The CODT system, method, and metadata sets are patented (US 12038939).

Conclusion

Conventional object property-to-relationship mapping and transformation lead to the loss of ontology semantics and data model defects.

An ontology-to-data model transformation must, at the very least, provide the option to transform object properties into associative entities.

The correct transformation process must be configurable and analyze the source ontology holistically.

The FIBO Data Model is the optimal design a Sr. Data Architect would create.

Thanks for reading. You are welcome to email your questions or comment on LinkedIn:

jziemer@jayzed.com
https://www.linkedin.com/pulse/ontology-object-properties-data-model-associative-entities-ziemer-1f

References

The canonical version of this article: https://fib-dm.com/ontology-object-property-data-model-associative-entities/

Are the ontology class and data model hierarchy the same? https://fib-dm.com/ontology-class-and-data-model-entity-hierarchy/

Entities & Packages list report for 2025/Q1 model: https://fib-dm.com/release-latest-normative-full-model/

Atlantic CODT, version 2025/Q1: https://codt.net/atlantic/

CODT Patent US12038939: https://codt.net/patent/ https://patents.google.com/patent/US12038939B2

Enterprise Data Management Council, FIBO & FIB-DM: https://spec.edmcouncil.org/fibo/page/data-model