Accelerate the Enterprise or Knowledge Graph Ontology development using your Data Models as a starting point.
The ontologist analyses model structure and documentation in familiar RDF/OWL and merges valuable content into her design.
Watch the video first because it has a live demo and explains the diagrams.
Read the article, Data Model reversed-engineered into an ontology for an in-depth treatment of the topic.
Transcript
Hello, welcome back to CODT and FIB-DM.
You probably watched a lot of the tutorials, Semantics for Data Architects, and so on already. This is something completely different:
Data Models for Ontologists. I give a short overview of the Configurable Ontology to Data model Transformation, CODT in Reverse-mode. With CODT in reverse, you can transform Entity-Relationship models into RDF/OWL, and by doing so, you accelerate your design of the enterprise ontology for Knowledge Graph and other use cases.
The FIBO and FIB-DM are the industry standard. The EDM Council now markets the FIBO as the Open Knowledge Graph. It’s a blueprint for Enterprise Ontologies and the knowledge graph.
1200 users already downloaded the ontology-derived Financial Industry Business Data Model. The patent-pending technology that created the fibo data model is available for licensing.
The intended audience for this video is the Semantic Center of Excellence that has to build enterprise and operational ontologies. You could be an ontologist with FIBO expertise, a Data Architect experienced in enterprise reference models, You know FIB-DM, you know of course your existing databases and models. As a stakeholder, you want to accelerate Semantic Enterprise Information Architecture.
There is a chasm between semantic and conventional data management. That chasm impedes FIBO customization. The ontologist has an extensive reference domain ontology. However, the Financial Institution must still customize the FIBO. The data architect has models of existing databases, maybe even an Enterprise Data Model based on FIB-DM. The ontologist cannot leverage conventional information assets in the data modeling tools. The organization has metadata for new Open Knowledge Graph modules, classes, and properties but then the ontologist must manually type in hundreds of classes, copy & paste. CODT in Reverse is the bridge across the chasm.
The vision is Semantic Enterprise Information Architecture, SEIA. When we look at architecture models, we can look at them by the use, type, and level. We have data models, logical and physical deployed on RDBMS. We have other models for the message, process, the object in the enterprise. Newly, we have the Enterprise Knowledge Graph [EKG], the FIBO in RDF/OWL residing on RDF databases. FIB-DM is the logical data model.
CODT performs is a bi-directional transformation between the ontology and the data model. Bi-directional transformation enables SEIA.
On the left-hand side, we see the FIBO, Enterprise Knowledge Graph, and operational ontologies On the right-hand side, we have FIB-DM enterprise and project models. We generate data models from industry, domain, and our proprietary ontologies. We design conceptual models in RDF/OWL,
and we reverse-engineer our data models to extend the enterprise and project ontologies.
This is the path for midsize banks, updated now – the years are indicative. Suppose, you are here at the beginning of 2021. You already adopted the industry-standard, and you want to move on to SEIA. The proposition is that for the DA, it’s easy to learn a new language, QWL, and the tooling if you already know the content and design. For the oncologist, it’s easy to build FIBO ontologies if you have FIB-DM data models.
So, what does CODT in Reverse do?
Here’s a data model-to-ontology mapping: On the left-hand side we have a data model; the right-hand side is the ontology graph that we want to generate out of the model, and for that, we have the transformation and mapping. Data model Entities become ontology Classes, Subtypes become subclass properties, associative entities, and relationships convert to object properties, and finally cardinalities to class restrictions, and not depicted here, attributes become data properties.
So, how do the bi-directional CODT Metadata Sets work?
On the left-hand side here is a symbol for PowerDesigner, as a modeling tool, on the right-hand side, the bird for the ontologies. The Transformation s the basic ETL – Extract, Transform, and Load.
The MS-Excel cod implementation uses Microsoft Power Query and the Microsoft M-language.
The first step: In the data modeling tool: we create list reports.
We can populate the tool-specific, in this case, PowerDesigner, Metadata Sets. Then we transform this into a generic (independent of the particular modeling tool) version,
and we transform it into an Ontology Metadata Set. Then we use SPARQL CONSTRUCT or bulk load to populate.
Here’s a CODT demo. I have an example logical data model in PowerDesigner – just a few entities taken from the New York Stock Exchange Open MDM. In PowerDesigner or any other tool, I can create list reports. Here, for entities, I want to report the code, name, and comment. This report, I can save as a CSV.
As I move over to CODT, there’s a PowerDesigner Metadata Set. It’s basically it’s an MS Power Query that populates our Entity MDS from the CSV, and I end up here with Code, Name, and Comment. From the tool-specific MDS, we go over to the generic representation which populates from the PowerDesigner MDS. We have a name and we have a comment. What we must configure is what we want to have as a Prefix and the Base URI. From there we head on to the Ontology Metadata Set. Here the class is basically the concatenation of the Prefix and the Entity Name, and then we have the Namespace and the SKOS definition populated from the entity comment. Now, here we have some special tabs: The prefix “T” stands for the triple. To load into the ontology we need the data in terms of Subject-Predicate-Object. This takes it from the Classes MDS and breaks it down into triples: Auction, type, OWL class We have the same for the SKOS definitions.
Finally in the Ontology Editor, in this case, it’s TopBraid, I can copy these triples, and wrap the SPARQL CONSTRUCT statement around it. When I execute the CONSTRUCT, it has six triples as a result set and I can assert these selected triples. When I do that, it creates classes in my ontology. Likewise, I can do the same here for our Annotation Properties. I execute the query and assert the triples. When I look at the class, here’s the auction, I see the class is created and it populates the SKOS definition. In the same way, we can transform/reverse-engineer object properties, and data properties. We can do it here for six entities or we could do it for an Enterprise Data Model with 600.
Well, thank you for watching, and yes just send me an email if you have more questions or like to do a POC of CODT. You can find more information on the FIB-DM website, the YouTube channel, or follow the news and discussion on LinkedIn. Thank you.