Towards Ontology-driven development with derived data, process, object, and message models.
Abstract
Semantic Web technologies have matured and are implemented in enterprise applications. However, there is a chasm between semantic and conventional data management. The Enterprise Ontology can bridge the gap with derived data, object, process, and message models.
This article introduces the FIB-DM, an Enterprise Data Model transformed from the Financial Industry Business Ontology.
Industry standard reference ontology
FIBO is the authoritative model of Financial Industry concepts, their definitions,
(Enterprise Data Management Council: https://edmcouncil.org/)
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.
As of release 2020/Q4 Production, 1,448 classes detail Foundations, Business Entities, Finance, Business & Commerse, Securities, Derivatives, and Indices. The ontology is Open Source.
Chasm between semantic and conventional data management.
FIBO is specified in Ontology Web Language (OWL). The language thoroughly covers the semantics of the Entity-Relationship model and can express business rules and constraints far beyond the data model.
However, there is a barrier to FIBO implementation, because design in OWL requires specialized modeling tools and unique databases for deployment.
Some EDMC member FIs are early adopters of Semantic Technologies. They created in-house Centers of Excellence (CoE) and invested in training and new technologies. Wells Fargo, State Street Templeton, Bank of America and others contribute to FIBO content groups and present at conferences.
Ontologists with Finance Domain expertise are rare. As a result, many Financial Institutions remain at the sidelines. Even ontologists at early adaptors, find it hard to spread FIBO usage beyond their CoE.
The EDMC recognized member need for more natural consumption of the standard and released FIBO Glossary, Dictionary, Vocabulary, Wiki and UML diagrams. These serializations are human-readable, but they have a lower semantic richness and cannot instantiate model-driven development.
The Financial Industry Business Data Model is the bridge from semantic to conventional data management. It is complementing accessible FIBO formats and distributions.
Positioning the FIBO ontology and data model
Ontology Web Language has the richest semantic of all modeling languages. In a Model Driven Development. OWL can fully express relational, message, process and object models. Hence these models can be derived from an ontology.
The implication for Enterprise Architecture is to place the ontology at the apex.
The diagram shows RDF-OWL, derived models and physical implementations.
We characterize models across three dimensions, type, primary use, and organizational level.
Model Type
FIBO is a domain ontology and upper ontology. Most FIBO classes don’t have Data Properties. Hence the FIBO is a conceptual model. The ontologist
(https://en.wikipedia.org/wiki/Conceptual_model)
A conceptual model is a representation of a system, made of the composition of concepts which are used to help people know, understand, or simulate a subject the model represents.
Derived from FIBO, FIB-DM is mainly an entity-level data model. FIB-DM has few attributes and no primary keys.
For modeling tools that support conceptual data models, we release FIB-DM as CDM. Other modeling tools can import FIB-DM as a Logical Data Model (LDM).
The Data Architect scopes a subset of FIB-DM, adds attributes and keys, derives a physical model and generates an RDBMS schema.
Model uses and audience
Like the reference ontology, the Financial Industry Business Data Model is for bankers and investment managers. It is a tool for logical data modelers to facilitate joint scoping, refinement and attribution with project stakeholders and domain experts. This primary use case has essential consideration for an enterprise model and the way FIBO transforms into FIB-DM.
Data modelers then apply appropriate denormalization and generate physical data models.
Organizational level
FIBO is an enterprise ontology. Likewise, FIB-DM is an enterprise reference data model for the financial industry. Ownership would typically be within the central enterprise architecture group. Data Architecture creates scoped variants of FIB-DM departments. E.g., Retail Banking, Semantic Compliance®, Brokerage, and Financial Markets. Data Modelers use the model blueprint for project models. This process ensures common names, definition and design pattern across the enterprise.
Model transformations for ontology-driven development.
The vision of Ontology-Driven Development is to derive purpose models of lower abstraction from the enterprise ontology. The transformation from OWL to Unified Modeling Language (UML) is well known. EDMC ontologists originally modeled FIBO in Sparx Enterprise Architect and ontologists still use UML diagrams for visualization. Sparx EA can read OWL (with limitations). However, the import generates classes for data properties and restrictions – not an object model for applications.
The transformation and data exchange between OWL and XML works quite well with Topbraid Composer (https://www.topquadrant.com/). Process modelers could derive Business Process Modeling Notation (BPMN) actors, events, tasks from ontology classes. However, to my knowledge, there is no model transformation available.
Finally, for ontology derived data models the OWL-to-UML-to-ERM detour doesn’t meet the requirements for an enterprise data model. Hence, we developed a customizable OWL-to-ERM transformation.
Principles for the ontology derived EDM.
We positioned FIBO and FIB-DM as Enterprise level conceptual models for Business Users and Architects. Therefore, an ontology derived user-friendly Enterprise Data Model must be practical, complete, well documented and diagrammed and fully map back to its ontology source. Above all, these principles drive the configuration for the ontology transformation process.
Practical
In a typical data
Complete & Fully Documented
The derived data model should have all concepts and properties of the source ontology.
There is a tradeoff between the principles of completeness and practicality.
Full Documentation includes OWL annotation properties. OWL has a higher semantic than a logical data model (LDM). While we cannot express complex class restrictions in an LDM, we should preserve them as documentation. Finally, all data model objects must include a reference to the URI of the ontology resource.
SAP PowerDesigner is the FIB-DM development tool
After evaluating 2 data modeling tools, I selected PowerDesigner (PD) for import and the golden copy of the Financial Industry Business Data Model.
Firstly, PowerDesigner is an accurate Enterprise modeling tool, as opposed to other data modeling (only) devices. In PD we can map and derive business, process, object and message models from FIB-DM.
Secondly, only PD has an exact conceptual data model (CDM) with a dedicated conceptual notation (Merise). In an LDM the attributes are local to the Entity. For example, attributes with the same name may have different definitions and other properties on separate entities. The PD CDM has Data Items with global properties. This concept matches Data Properties in OWL. In addition to relationships, the PD CDM Merise has a conceptional Association object. This emphasis of relations better reflects OWL Object Properties than mere relationship lines.
Finally, PowerDesigner has a slow, but very robust import facility. The proprietary OWL-to-LDM transformation generates lists of ontology metadata. PD imports the metadata as MS-Excel sheets, with a transparent mapping of an Excel column to the PD object property.
However, you can use FIB-DM with any other Data Modeling tool. All widely used modeling tools import native PD model files. The PD CDM-to-LDM generation converts Data Items into attributes and Associations into Associative Entities. The evaluation will determine the best import file format, PD-CDM, PD-LDM or XMI ( XML Metadata Exchange).
Update for PowerDesigner CDM users: As of 2021/Q1, the Full Commercial Model has all Object Properties transformed into Associative Entities. Customers on other modeling tools and even PowerDesigner users prefer the LDM. Even those on PowerDesigner CDM with Merise notation found two symbols distracting. Hence we no longer use Associations.
Ontology to data model transformation
Most research focuses on ontology representation of existing databases schemata. In other words, accessing or importing an RDBMS data via OWL and SPARQL.
However, mappings from OWL to Logical models are not as trivial as it appears.
The below table shows high-level challenges for the transformation algorithm. In other words, there different options to transform these OWL types into ER objects.
| OWL | LDM | Challenges |
| owl:Class | Entity | The mapping is straightforward for primitive classes, but what about defined classes, anonymous classes? |
| owl:DatatypeProperty | Attribute | Technically, this holds only for functional properties. Non-functional properties without a maximum cardinality restriction are multi-valued. |
| owl:ObjectProperty | Relationship | 1) Properties have many cardinalities for domain and range by default. Results in many-to-many relationships. 2) The ER model has no generalization of relationships. We lose the object property hierarchy. 3) What about inverse Object Properties? |
| rdfs:subClassOf | Inheritance (subtype) | Straightforward as long as the parent is a single class. The ER-model doesn’t have multiple inheritances, much less complex logical expressions used in OWL |
Therefore, the optimal transformation depends on the purpose of the data model and an in-depth analysis of the source ontology:
- Patterns desired in a CDM would not be permitted in an LDM ready for a physical generation. What is wanted for a UML-style visualization would not make sense in a data model? FIB-DM conceptual enterprise model for business users.
- An operational ontology requires different transformation than an Upper or Domain Ontology. A source with high ontological commitment may not be suitable for conversion at all. For example, Legal Knowledge Interchange Format (LKIF), the other reference ontology for Semantic Compliance©, defines half the classes in complex expressions. FIBO, on the other hand, is a business conceptual domain ontology with modest use of complex owl expressions (most classes are primitive)
.
FIBO to FIB-DM transformation
The Configurable Ontology to Data-model Transformation (CODT) is patent pending with the US Patent and Trademark Office. This section explains FIB-DM model objects and their transformation from FIBO OWL.
Overview
The diagram shows the FIBO graph and FIB-DM diagram site by the side.
- Classes transform into entities and owl:subClassOf becomes an Inheritance (subtype).
- We transform owl:ObjectProperty into PD Associative Entities.
- Class Restrictions (e.g., owl:someValuesOf), domain and range determine Association Links and cardinality.
- Data Properties transform into Attributes.
Naming convention
FIB-DM follows standard naming convention for Logical Data Models.
Object Names are capitalized and separated by spaces. Data Item Names don’t carry the leading verb in the FIBO Data Property (“has” “is”). We leave verbs in Association, and Associative Entity names in lowercase.
| Object type | Name | Code |
| Entity | Privately Held Company | fibo-be-corp-corp:PrivatelyHeldCompany |
| Data Item (Attribute) | Numeric Country Code | lcc-cr:hasNumericCountryCode |
| Associative Entity | identifies | fibo-fnd-aap-agt:identifies |
Example FIB-DM Names and Codes.
Object Codes are the unique FIBO Resource Name (Prefix + Local Name). This convention facilitates the import into PowerDesigner and helps to browse and search for model objects in the tool. We preserve the FIBO resource name as an extended attribute so that you can replace FIB-DM codes with codes generated by your company’s naming standard and dictionary.
Extended attributes (user-defined properties)
The Financial Industry Business Ontology has extensive documentation, expressed in OWL Annotation Properties. FIB-DM preserves all annotations as PowerDesigner Extended Attributes. Also, we added extended Attributes to document model object lineage and ontology semantics.
List of extended attributes of the entity Account Identifier
| Name | Data Type | Value | Target Name |
| ent-fibo-fnd-utl-av:adaptedFrom | (String) | ISO 13616-1:2007 Financial services – International bank account number (IBAN) | Local Extensions |
| ent-fibo-fnd-utl-av:synonym | (String) | account number | Local Extensions |
| ent-rdfs:label | (String) | account identifier | Local Extensions |
| ent-skos:definition | (String) | an identifier that identifies an account | Local Extensions |
| entResourceName | (String) | fibo-fbc-pas-caa:AccountIdentifier | Local Extensions |
| enttLocalName | (String) | AccountIdentifier | Local Extensions |
| enttPrefix | (String) | fibo-fbc-pas-caa | Local Extensions |
| enttResourceType | (String) | owl:Class | Local Extensions |
| entURI | (URL) | https://spec.edmcouncil.org/fibo/ontology/FBC/ProductsAndServices/ClientsAndAccounts/AccountIdentifier | Local Extensions |
| owl:Restriction | (Text) | fibo-fnd-aap-agt:identifies exactly 1 fibo-fbc-pas-caa:Account | Local Extensions |
All data modeling tools support user extended object properties. E.g., importing the PowerDesigner FIB-DM into ERWin converts the Extended Attributes into User Defined Properties (UDPs).
Packages (subject areas) from FIBO modules
The Financial Industry Business Data Model has 259 packages.
The FIBO is a highly modular ontology. The 2018Q4 Production Specification download has 194 ontology files in a multi-level directory structure. Similarly, ontology Prefix and Namespace reflect the module structure.
The FIB-DM transformation converts FIBO modules into PD packages. Whereby the package name is the name of the ontology and the package code is the prefix.
The Packages contains PD links to model objects that transformed from the sibling ontology module. In other words, the package includes all and only those objects that have the Prefix of the Package code.
Besides, every package has the main diagram showing all package objects. Note: We list Inheritances in the package of the supertype entity, but we don’t depict dangling inheritance symbols in the diagrams.
Extended attributes of the package an abstract, license, label, change notes, copyright, dependencies, ontology file, resource name, and URI.
Note: Other modeling tools import PD packages (e.g., ERWin converts them into Subject Areas).
Entities from FIBO classes
We transformed 1616 FIBO Prod 2018Q4 classes into FIB-DM entities.
As a PowerDesigner extension, the entity property dialog has tabs for ontology Lineage and Annotations. The Lineage tab shows three unique extended attributes, Resource Type, Equivalent and Restriction.
Resource Type
The Resource Type dropdown indicates whether an OWL Class or Object Property transformed into the entity. Classes with the stereotype Associative Class originate from Object Properties.
Equivalent
OWL Equivalent Class means that the two or more classes have the same members. The equivalent can either be another class or as Restriction as in the above Transferable Contract example.
Logical Data Models cannot express these semantics. However,
the Physical Modeler, DB Admin or Developer find important hints for Implementation: For example, there are two Collection entities in the model: fibo-fnd-arr-arr:Collection has the Equivalent entity lcc-lr:Collection.
This simple class equivalence can be implemented as an Alias.
Likewise, DBAs may implement the Transferable Contract as a database view.
Restriction
Classes that are Subtype of OWL Restrictions have a constraint of the allowable instances. The Entity Restriction textbox lists restrictions on the original class. Most FIBO restrictions are directly tying a Data or Object Property to the class. For instance, fibo-fnd-aap-agt:hasName some xsd:stringis the reason for Attribute Name on Entity Legal Form.
Complex class restrictions are beyond the Logical Data Model. However, again developers can implement these constraints on the DBS or in the application.
Attributes
FIBO is a business conceptual model, and Conceptual Enterprise Data Models are entity-level.
Therefore, there are only 149 Data Items derived from FIBO Object Properties in FIB-DM. Consequently, most entities don’t have attributes.
OWL has an Open World Assumption, and FIBO leaves the door wide open. Again, this is perfectly fine for a business domain ontology.
Single value assumption
Most Data Properties in FIBO are not limited to one cardinality, and there only 10 owl:FunctionalProperty declared. For an out-of-the-box model transformation that means the data properties are multi-values and get a wrapper UML-Class (entity).
The Financial Industry Business Data Model transforms all FIBO data properties into Data Items and entity attributes. FIBO ontologists did not intend Multi-valued data properties, because they already define wrapper classes for amounts, dates, and other types. This transformation configuration is trading off complete accuracy for clarity and (business) user-friendliness of the enterprise data model.
Parent Data Items
The extended property Parent Data Item refers to a higher level data item. For example, Common Name has the parent data item Name.
OWL enables the ontologist to define hierarchies of data and object properties. The Logical Data Model cannot express these semantics. Therefore, FIB-DM preserves the rdfs:subPropertyOf as an extended attribute.
Datatypes
FIB-DM uses standard generic datatypes for all data items. Hence, the model doesn’t define domains. The Financial Industry Business Data model is a blueprint to generate project models. The project application and target RDBMS determine domains and datatypes. Consequently, there is no benefit in having the source ontology XML Data Types in an EDM.
Inheritance (subtypes)
FIBO defines rich taxonomies of Functional Business Entities and other concepts. FIB-DM transforms 514 owl:subClassOf ranges into PD Inheritances. Note: In other modeling tools FIB-DM inheritances would be imported as Subtypes or Generalizations.
OWL and UML use multiple inheritances. For example, in the diagram below a Central Bank is both a Bank and Monetary Authority.
The Entity-Relationship Model allows only one supertype. As a result, the model consistency check throw an error.
However, I decided to keep multiple parent inheritances in the model for the following reasons:
- Business users prefer the clarity of the inheritance symbol for all classes.
- Multiple
inheritance is a valid pattern for conceptual models - FIB-DM is a blueprint EDM to create project models. Therefore, it is not a (relational) Enterprise Data Warehouse model to instantiate as is.
- The logical data modeler applies standard UML-to-ERM transformation techniques to resolve the issue. Firstly, the problem may go away, because only one supertype is scoped and attributed. Secondly, the data modeler may decide to make one inheritance dominant and change the less important inheritance into a relationship. Alternatively, the data modeler may convert both inheritances into identifying relationships (This also happens, when we generate a Physical model from the above pattern.) I don’t want to prescribe how the modeler should modify the design pattern.
Associative Entities, and Relationships
FIB-DM has 613 Associative Entities generated from OWL Object Properties.
I believe that the commonplace OWL-to-LDM mapping from to owl:ObjectProperty Relationship is a simplification leading to ambiguity and information loss.
Object properties are the most complex OWL to transform. The configuration of the transformation process depends on EDM target principles and analysis of the source ontology.
Many-to-many relationships
OWL has an Open World Assumption, and the FIBO doesn’t restrict maximum cardinality to one on most classes. Consequently, transforming object properties into relationships would lead to many-to-many relationships.
Relationship hierarchies
Relationship hierarchies are an essential data modeling pattern. For instance, the IBM Banking & Financial Markets Data Warehouse (BFMDW) model has deep relationship hierarchies between the nine concepts.
The Financial Industry Business Ontology defines property hierarchies with specializations.rdfs:subPropertyOf We want to preserve these FIBO semantics in the EDM.
Associations
As aforementioned, the PowerDesigner CDM Association gives true prominence to OWL Object Properties. The association resolves many-to-many relationships and allows more than two entities to participate in the relationship.
Unfortunately, the PD CDM does not support inheritance between associations. Therefore object properties that are domain or range in
rdfs:subPropertyOf must become Associative Entities.
Update for PowerDesigner CDM users: As of 2021/Q1, the Full Commercial Model has all Object Properties transformed into Associative Entities. Customers on other modeling tools and even PowerDesigner users prefer the LDM. Even those on PowerDesigner CDM with Merise notation found two symbols distracting. Hence we no longer use Associations.
Associative Entities
The transformation process creates Associative Entities for all object properties that are or have sub-properties. The stereotype <<Associative Entity>> differentiates them from standard entities.
Relationships and Association Links
Relationships connect and Associative Entity to its participating Entities. Likewise, the Association Link joins the Association with the participating entities.
The transformation process harvests participating entities from ontology class restrictions and object property domain and range. Also, the transformation process harvests the cardinalities of class restrictions (e.g., owl:someValuesFrom, owl:minCardinality, owl:maxQualifiedCardinality) to set relationship and association link cardinalities.
Relationship and Association Link names and codes are purely technical: Entity <space> Associative Entity. For example, the Currency Identifier identifies.
Inverse Object Properties
The propertyowl:inverseOf asserts that two object properties are equivalent, except for having opposite directions. In other words, they have domain and range swapped. For example: : :
fibo-fnd-aap-agt:identifies owl:inverseOf fibo-fnd-aap-agt:isIdentifiedBy
The LDM doesn’t need “inverse relationships.” Consequently, there can only be one association between Bank Account and Bank Account Identifier.
As a naming convention, we use the active form to name Associative Entities and preserve the passive form in the relationship name. Finally, the transformation process harvests the inverse property for participating entities and their cardinalities.
Associative Entities – a Star Schema?
The context diagram below shows the identifies Association and some participating entities.
Yes, the diagram looks like a Star Schema (with a “factless” fact table in the center). While this is perfectly fine for a dimensional data model, and the model check doesn’t complain, the denormalized design would not be appropriate in a relational model.
However, as previously done for multiple inheritances we prioritize the clarity for business users of the design over 4th Normal Form correctness.
After scoping and attribution, the data modeler can resolve to 4NF:
- Once the modeler removes entities without attributes,
theissue may disappear. - The standard 4NF resolution replaces the identifies association with role-named associations (a subtype of identifies). E.g., Bank Identifier identifies Bank. The entity Lineage tab Restriction on Bank Identifier shows the class restriction.
- A relationship Role can be added to stipulate the identifier. For example, a Security Identifier Type can tell the application whether to look for a Security Identifier or National Securities Identifying Number.
- We can manage Associations at the supertype level. For instance, an Account Type Role can be added to tell the application whether the association is for Bank or some other Account type. With this pattern, we can remove the relationships from the subtypes.
As said before, I don’t want to prescribe how the data modeler resolves the design.
Conclusion
The article made a case to place the ontology at the apex of enterprise architecture. We showed how to transform a domain ontology into an enterprise data model. The clarity of the ER diagrams speaks for itself. The Financial Industry Business Ontology is of high value as a standard reference for both semantic and relational architecture.
References
The canonical version of this article: https://fib-dm.com/finance-ontology-transform-data-model/
Upgrade to the Commercial Models with 3,085 normative entities: https://fib-dm.com/full-data-model-upgrade/
Entities & Packages list report for the latest data model version: https://fib-dm.com/release-latest-normative-full-model/
Financial Industry Business Ontology (EDM Council website): https://spec.edmcouncil.org/fibo/page/data-model
SAP PowerDesigner: https://www.sap.com/sea/products/technology-platform/powerdesigner-data-modeling-tools.html
Sparx Enterprise Architect: https://sparxsystems.com/products/ea/
Thanks for reading. Please email the author at jziemer@jayzed.com or join the discussion on LinkedIn (https://www.linkedin.com/showcase/fib-dm/)