Model transformations depend on a mapping of meta-model elements of the source to elements of the target model. Academic papers, commercial tools, and education map ontology class to logical data model (LDM) entity, data property to attribute, and erroneously object property to the relationship.
The Semantic Data Model emphases the common relations between entities. Ontology-derived Conceptual Data Models are Semantic Models by their origin. The Association or Associative entity is appropriate the design pattern to capture semantics within the limits of the Entity-Relationship Diagrams.
This article examines where the ontology object property to LDM relationship transformation fails for unconstrained cardinalities in the Open World ontology, ternary and higher relations, and 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 conventional parsing of RDF/OWL files.
The Configurable Ontology to Data model Transformation (CODT) enables the user to initialize transformation options.
Commercial Data Modeling tools have be around for more than two decades. Since their first versions, model transformations, the generation of a Physical Data Model from the LDM has been a core feature.
Enterprise Modeling tools also support the transformation of data into object-oriented models and vice versa.
These transformations are straight-forward 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 of a subject, predicate, and object.
My previous article made the case that the Ontology Class and Data Model Hierarchy are the same. By implication, that means that there is a one-to-one correspondence of Ontology Class and Logical Data Model Entity.
The conventional mapping of ontology object properties to data model relationships, however, 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, Ontology Web Language (OWL) became the notation of choice for Conceptual Business Models, “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) has 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 loss of information. In our case, we can take an RDBMS as a source and transfer the data into an RDF Store, or vice versa.
The UML diagram shows a simplified use case with actors, Business User/Analyst (BA), Ontologist, and Data Architect/Modeler.
Presume the BA did a perfect job defining the requirements and defining the information. Examples may be financial messages as in ISO 20020 or the thousand of pages the Enterprise Data Management Council team gathered in interviews and joint development sessions from subject matter experts in the FIBO content groups.
- The Ontologist extends the use case and designing 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 information we need to design the optimal data model and hence the database schema. Just like we can regard a use case, “design Physical Model,” as a specialization of “Design Data Model,”
The CODT approach is to look at 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 of the conventional transformation of object properties into relationships, can show the correct design in FIB-DM.
These are Data Modeling textbook examples. What would you, as a Data Modeler change 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 (a.k.a. Triple) Stores are for knowledge representation.
Open vs. Closed-World Assumption
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 what is not conform to the schema is a violation. Using SQL, we must CREATE tables, for Investment Advisor and Exchange Traded Fund first, before we can INSERT our Black Rock 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 having defined their range and domain beforehand.
All data is permitted unless it violates an explicit schema constraint.
Closed- and Open-World Assumption are optimal for their purpose, operational data origination, and manipulation vs. knowledge representation. We can transform CWA schema to OWA – we simply lift the restrictions. However, deriving CWA from OWA requires configuration.
Even a well-formed domain ontology like the 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 shows two classes, Person and Country, and an Object Property, has Citizenship.
Note that the predicate-object connection is established via domain and range only. We can construct any triple of Person, has Citizenship, 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 over the strong word “wrong,” but 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
<<Child>> for the connecting relationships. (Commercial version 2020/Q1)
Finitary, n-ary relations
The relationship in a data model is binary, connecting exactly two entities.
Object Properties, on the other hand, may have more than one domain- and range- classes, specified. Relations with more than two places are called n-ary or finitary. A textbook example of a ternary relation is the Sale with Buyer, Seller, and Agent.
Per the OWA, an Object Property may even stand on its own without any attached classes. In order, words all classes in ontology are valid objects.
Lets consider registrations as an n-ary example. In the FIBO a Registrar or a Registration Authority can register things. The graph shows the registers object property and on the left side, the two domain classes.
On the right side, the graph depicts the Legal Entity Identifier and National Securities Identifying Number as examples.
This graph already is 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. In the absence of qualified restrictions, the blind transformation into relationships requires the permutation, all parent entities relate to all child entities.
Furthermore, and Entity-Relationship Model has no context between relationships. In other words, we lose the semantic that all four “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 looks like a Star Schema, the factless fact table. This is typical or ontology-derived data models.
Note that both models permit data anomalies – they are not in the fourth normal form (4NF). E.g., the Legal Entity Identifier may have a Registrar and a Registration Authority. The Semantics for Data Architects webinar video and handout explains how the Logical Data Modeler can resolve the pattern.
Transforming the Closure Axiom
The aforementioned “registers” FIBO graph didn’t constrain “who register what,” and neither does the ontology-derived Semantic Data Model.
The FIBO graph below shows classes 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 ONLY cardinality restriction, owl:allValuesFrom, is a closure axiom stating: A Legal System applies only in a Jurisdiction – nowhere else. Here, the EDM Council ontologists “close the world.”
The new 2020/Q1, Atlantic version supports the meaningful semantic. The Legal System has no relationship to the “applies In” associative entity. Instead, a particular subtype 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 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. As a Business-Conceptual Model, the FIBO structures most object properties under the top properties “has” and “is”.
The graph shows the example of has Monetary Amount with some of its sub-properties, has Notional Amount, and Principal Amount. (blue icon)
On the left side, we see some of the many domain classes, the Fund Portfolio, Certificate of Deposit (CD), and the Loan. The domain classes, on the right-hand side, 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 has Principal Amounts are also has Monetary Amounts. In SPARQL, we can query all values via has Monetary Amount.
Hierarchies of Associative Entities are also an important Data Model pattern. The IBM Banking Data Warehouse Model, for example, has deep hierarchies between the nine data concepts.
The naive transformation of object properties into plain relationships is wrong, because we lose important ontology metadata.
How would you as a Sr. 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 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
In the Open World Schema, an Object Property may not have a range or domain. In FIBO, anything may have a price. Consequently, the object property has a range, the Price, but no domain. The diagram depicts the graph with hasPrice sub-properties. Note that “hasPrice” itself is sub-property of the generic “has” object property.
This semantic design pattern is quite common. FIBO Production, the industry-standard has 74 more object properties that do not have both domain a range specified as property or class restriction: appoints, various dates and amounts, owns, rates, regulates, etc.
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 has 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 common for semantic data models. We want to model that all these Price relations, Offering, Call Price 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 all things in Financial Services have IDs, Loans, Contracts, Documents, Securities, Persons, Legal Entities, Banks, and other Service Providers. The FIBO connects the ID with the Thing via the identifies object property.
The example graph shows the Universal Loan Identifier (ULI) that identifies a Loan. The class restriction means that a ULI identifies exactly one loan.
We notice another object property, “isIdentifiedBy,” is the inverse of identifies. In some cases, this may just be an alias for user and ontologist convenience. However, for the oncologist, creating an inverse object property the only way to specify cardinality for the participating domain.
The conventional mapping of object property to relationships erroneously derives two relationships lines between the Loan and its identifier.
In a PDM, this wrong design creates two Foreign Keys between the tables, a Loan -ID on Universal Loan Identifier, and 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, that is “identifies,” and not the passive “is identified by.”
Inverse object properties are one reason why the Ontology to Data Model Transformation must be Configurable. With CODT options, you specify defaults for source ontologies in the English Language: Object Property names starting with “is” or “has” indicate a passive form. However for some inverse property pairs like “sells to”, “buys from”, you, the architect must tag which name to use.
PowerDesigner change 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 that have or are sub-properties. Most PD CDM users found the mix confusing. Therefore, all object properties are associative entities since the 2020/Q1 FIBO Data Model release.
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, for the same reason mentioned above, I don’t want to mix model patterns. 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 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 traditional ontology file parsing approach.
- CODT extracts ontology metadata from the development tool, like Topbraid Composer or Protégé, or from an RDF Store using SPARQL.
- CODT has 150 Metadata Sets for Ontology, generic E/R, and the particular 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.
- CODT system, method, and metadata sets are patent-pending.
Conventional object property to relationship mapping and transformation leads to loss of ontology semantics and data model defects.
An ontology to data model transformation must at least provide the option to transform object properties into associative entities.
The correct transformation process must be configurable and analyse the source ontology holistically.
The FIBO Data Model is the optimal design, a Sr. Data Architect would create.
The canonical version of this article: https://fib-dm.com/ontology-object-property-data-model-associative-entities/
Ontology class and data model hierarchy, are they the same? https://fib-dm.com/ontology-class-and-data-model-entity-hierarchy/
Upgrade to the Commercial Models with 1,968 normative and 4563 informative entities: https://fib-dm.com/full-data-model-upgrade/
Atlantic CODT, version 2020/Q4:https://fib-dm.com/atlantic-codt/
Enterprise Data Management Council, FIBO & FIB-DM: https://spec.edmcouncil.org/fibo/FIB-DM
Conventional mapping, IBM Infosphere Data Architect: https://www.ibm.com/support/knowledgecenter/en/SS9UM9_9.1.2/com.ibm.datatools.transform.owl.ldm.doc/topics/c_owl2ldm_generatedobjects.html