To understand data, it is important to recognize its syntax and semantics. This is why relational data modeling or eXtensible Markup Language (XML) modeling, the two models used in the last couple of decades for modeling data, have their limitations. Between the two, XML can capture the syntax. Additionally, semantics can be written in an XML format, if the semantics has already been captured by a modeling scheme based in formal logic. For these reasons, enterprises need a formal ontology.
The most commonly used semantic modeling language is Web Ontology Language (OWL), which is based on Description Logics. It is the de-facto standard for ontology modeling. Ontologies developed using OWL help in verifying the data model and the data it contains, inferring new facts by reasoning about the data, and proving the correctness of those inferences.
There are many reasons why ontologies based on OWL are suitable for enterprises. For instance, it is a storage-agnostic data model that can be used as the basis for generating database schemas and data exchange formats. Being storage agnostic shifts the focus from cramming data into a database to understanding data as it exists. Furthermore, by creating multiple data representations from the model it is based on, maintenance can be minimized. For instance, any change to the enterprise’s data needs to be manually changed only in the master model. The change will be reflected in the other storage and exchange schemas generated from the model.
Significantly, an ontology developed using OWL can be used to integrate competing models from different groups in an enterprise and deliver the desired outcome. Besides, by deriving ontologies from a common upper ontology, OWL-based ontologies help enterprises overcome the challenge of overlapping data models that model different objects uniquely.
In sum, ontologies developed using OWL help enterprises create effective data models. Having said that, it is up to the enterprise architect to choose a data-modeling approach that suits the objectives of their enterprise. Furthermore, regardless of the data modeling philosophy, an enterprise architect should capture both the syntax and the semantics of all the data in their enterprise.
Click here to read the article published in CIO.
Please give your feedback on this article or share a similar story for publishing by clicking here.
