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 2024/Q2 Production, 2,332 classes detail Foundations, Business Entities, Finance, Business and Commerce, Securities, Derivatives, and Instruments. The ontology is Open Source.
The 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, FIBO implementation 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 on the sidelines. Even ontologists at early adaptors find it hard to spread FIBO usage beyond their CoE.
The EDMC recognized members’ need for more natural consumption of the standard and released the FIBO Glossary, Dictionary, Vocabulary, Wiki, and UML diagrams. These serializations are human-readable but 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 complements accessible FIBO formats and distributions.
Positioning the FIBO ontology and data model
Ontology Web Language has the richest semantics of all modeling languages. In 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 and upper ontology. Most FIBO classes don’t have Data Properties, making it 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.
FIB-DM, derived from FIBO, is mainly an entity-level data model with 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 is essential for an enterprise model and how 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, such as Retail Banking, Semantic Compliance®, Brokerage, and Financial Markets. Data Modelers use the model blueprint for project models. This process ensures common names, definitions, and design patterns 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 work quite well with Topbraid Composer (https://www.topquadrant.com/). Process modelers could derive Business Process Modeling Notation (BPMN) actors, events, and tasks from ontology classes. However, to my knowledge, no model transformation is 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, diagrammed, and fully map back to its ontology source. Above all, these principles drive the configuration for the ontology transformation process.
Practical
The Data Architect and Business User jointly scope and refine the relational design in a typical data modeling session. Diagrams are essential to communicate the design to the user. From my experience, the biggest hurdle and pushback is when a business perceives the model as too abstract and complicated. While this is already challenging with highly normalized designs, a standard ontology transformation may add many more pseudo-entities for Data Properties and Anonymous Classes. In contrast, a practical conceptual model must reduce the complexity of what is useful and needed for the Business.
Complete & Fully Documented
The derived data model should have all the 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.
First, PowerDesigner is an accurate Enterprise modeling tool, unlike other data modeling (only) devices. We can map and derive business, process, object, and message models from FIB-DM in PD.
Second, 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 conceptual Association object. This emphasis on 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 of other modeling tools, as well as 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 the ontology representation of existing database schemata. In other words, they are accessing or importing RDBMS data via OWL and SPARQL.
However, mappings from OWL to Logical models are not as trivial as they appear.
The table below shows high-level challenges for the transformation algorithm. In other words, there are different options for transforming 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) | It is straightforward as long as the parent class is single. The ER model doesn’t have multiple inheritances, and OWL uses much less complex logical expressions. |
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 are unsuitable 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 a transformation different from an upper or domain ontology. A source with high ontological commitment may not be suitable for conversion. For example, Legal Knowledge Interchange Format (LKIF), the other reference ontology for Semantic Compliance©, defines half the classes in complex expressions. FIBO, conversely, is a business conceptual domain ontology with modest use of complex owl expressions (most classes are primitive)
.
FIBO to FIB-DM transformation
US Patent and Trademark Office has issued patent #12038939 for the Configurable Ontology to Data-model Transformation (CODT). 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 the 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 import into PowerDesigner and helps 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. For example, 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. The package name is the name of the ontology, and the package code is the Prefix.
The packages contain PD links to model objects 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 Inheritance in the package of the supertype entity, but we don’t depict dangling inheritance symbols in the diagrams.
The package’s extended attributes are 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 two or more classes have the same members. The equivalent can be another class or Restriction, as in the above Transferable Contract example.
Logical Data Models cannot express these semantics. However, the Physical Modeler, DB Admin, or Developer finds 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.
Ans alias can implement this simple class equivalence.
Likewise, DBAs may implement the Transferable Contract as a database view.
Restriction
Classes that are subtypes of OWL restrictions have a constraint on the allowable instances. The Entity Restriction textbox lists restrictions on the original class. Most FIBO restrictions directly tie a Data or Object Property to the class. For example, fibo-fnd-aap-agt has the sName some xsd:stringis the reason for Attribute Name on the Entity’s 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, FIB-DM has only 149 Data Items derived from FIBO Object Properties. Most entities don’t have attributes.
OWL has an Open World Assumption, and FIBO opens the door. 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 only ten owls:FunctionalProperty declared. The data properties are multi-values for an out-of-the-box model transformation 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 by amount, date, and other types. This transformation configuration is trading off complete accuracy for the enterprise data model’s clarity and (business) user-friendliness.
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: Other modeling tools import FIB-DM inheritances 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 throws 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. First, the problem may disappear because only one supertype is scoped and attributed. Second, 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 The 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.
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 of other modeling tools, as well as 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 with sub-properties. The stereotype <<Associative Entity>> differentiates them from standard entities.
Relationships and Association Links
Relationships connect an 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, 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, only one Association between bank accounts and bank account identifiers exists.
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 identified Association and some participating entities.
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 design’s clarity for business users over the 4th Normal Form’s 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 identified 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 identity. 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 a Bank or another 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 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 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,074 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/)