Ontology versus RDBMS

Post Reply
wktsugue
Posts: 7
Joined: 30 May 2011, 21:19

How could I justify the use of an ontology based architecture repository instead of a relational database based architecture repository? What are the advantages of using Ontology? And why not use a relational model as a architecture repository?
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Good question.

I think most of these blog postings will help to provide some background.

Using the knowledge base approach enables us to very easily add new meta classes and new relationships, either to extend the meta model or update the meta model. In Protege, this can literally be done in a matter of seconds, whereas with an RDBMS, each new meta class would probably require a new table and then for a new relationship existing tables would have to be updated etc. etc.
So, from a technical point of view, we have a highly flexible and agile platform for managing the information about your architecture along with all the rather complex relationships between them.

Of course, if you use a database backend for your Protege project, it uses a RDBMS! However, you'll see that this is a single table that reflects Protege's meta-meta model (the set of constructs from which we can define the Essential Meta Model). This is definitely not a table that is easy to build SQL queries on.

Perhaps more philosophically, the ontological approach more accurately mirrors what we're trying to do. We're not just storing data about the enterprise, rather by working with the Essential Meta Model in Protege, we're defining an ontology about a specific enterprise's architecture, using a well-defined, flexible and extensible language with strong semantics to describe that enterprise.
We're building a knowledge base (as opposed to a database) that we can then use for queries, Views, reasoning etc.

Of course, you could use a 'raw' RDBMS to provide technically the same capabilities (and many commercial EA tools do this) but the agility for defining the meta model is crucial. The semantics of each meta class must be preserved (ambiguity leads to bad information) and we need the ability to create or modify any meta class very quickly. We found that the Protege ontology editor provided exactly the capabilities that we required in managing a repository of knowledge elements.
From a technical point of view, you could look at this as just a layer on top of an RDBMS, but it's in that layer that you get the power of a highly agile repository.

So, it's all about what constructs do we have in which to build our models and even more importantly, what constructs do we have for defining these modelling constructs. That is, the real power lies in the meta-meta-model. The meta-meta-model for an ontology approach fits the requirements better than tables and columns and foreign keys.
The ontology approach enables us to focus on what are the constructs of the language in which we define the ontology and what are their semantics, rather than on the technicalities of how we represent them in tables and columns.

Since Protege can use an RDBMS to persist the repository - and we recommend this for multi-user mode and very large repositories - perhaps it doesn't make sense to compare the two. A bit like asking, which is better, Microsoft Excel or a Dell Laptop? ;)

I'll finish by pointing you at the Modelling blog entries again. Although none of them directly tackle this question, there are lot of details about the approach in general (e.g. Why Not Use Powerpoint And Excel for EA Modelling) and the approach that we've taken with respect to ontologies (e.g. What About OWL?).

Finally, this one about using a Knowledge Representation techniques for managing and using the knowledge about your organisation gives a view on the benefits of treating all the data that you capture about your People, Processes, Applications, Information, Data and Technology as knowledge.

Hope this helps

Jonathan
Essential Project Team
Post Reply