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 the erroneous 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 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 the conventional parsing of RDF/OWL files.
The Configurable Ontology to Data model Transformation (CODT) enables the user to initialize transformation options.
Background
Commercial Data Modeling tools have existed for more than two decades. Since their first versions, model transformations have been a core feature of these tools, generating a physical data model from the LDM.
Enterprise Modeling tools also support data transformation 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 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, Ontology Web Language (OWL) has become the notation of choice for conceptual business models, or “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 losing information. 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 Users/Analysts (BA), Ontologists, and Data Architects/Modelers.
I presume the BA did a perfect job defining the requirements and the information. Examples may be financial messages, as in ISO 20020, or the thousands of pages the Enterprise Data Management Council team gathered in 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 information we need to design the optimal data model and the 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 of the conventional transformation of object properties into relationships and show 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 (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 does 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 defining their range and domain beforehand.
All data is permitted unless it violates an explicit schema constraint.
Closed-world assumption and Open-World Assumption are optimal for operational data origination and manipulation vs. 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 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 Person and Country classes 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, 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 2020/Q1)
Finitary, n-ary relations
The relationship in a data model is binary, connecting exactly two entities.
Object Properties, however, may have more than one domain and range classes specified. 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 order 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 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. Without qualified restrictions, the blind transformation into relationships requires permutation, as 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 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 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 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 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 an example of a Monetary Amount with 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:
- TLoanoan 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 an important 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 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
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 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 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, 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 Financial Services has IDs, 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 shows the Universal Loan Identifier (ULI) that identifies a Loan. The class restriction means that a ULI identifies exactly as one Loan.
We notice another object property, “isIdentifiedBy,” is the inverse of identifies. Sometimes, this may be an alias for user and ontologist convenience. However, for the oncologist, 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 tLoanoan and its identifier.
In a PDM, this wrong design creates two foreign keys between the tables: 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 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 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 traditional ontology file parsing approach.
- Using SPARQL, CODT extracts ontology metadata from a development tool like Topbraid Composer Protégé or an RDF Store.
- 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 patented.
Conclusion
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,e and the source ontology must be analyzed 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/
Ontology class and data model hierarchy 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/
Entities & Packages list report for 2023/Q4 model: https://fib-dm.com/release-latest-normative-full-model/
Atlantic CODT, version 2020/Q4:https://fib-dm.com/atlantic-codt/
Financial Industry Business Concept Maps, FIB-CM
Semantic for Business Users YouTube video: https://youtu.be/O101XJpEZ7I
PowerPoint: https://fib-dm.com/semantics-for-finance-users/
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