Will Ontology Attack Data Modeling?

Ontology seems to be making increasing inroads into enterprises these days, so it is probably worth keeping an eye on.  However, "ontology" is one of those terms that is not used in everyday language, and is not part of conscious everyday experience.  This means it is not intuitive, and is immediately suspect of being some kind of ivory tower abstraction. 

In a sense it is an ivory tower abstraction, because it is used a lot in academic circles, but even there its definition seems to vary.  For some, it is the study of existence, for others it seems to be identical to metaphysics, and for others it seems to be the study of the types of things.  From what I can see, the serious practitioners, who are trying to bring ontology into data management, define it as the study of the types of things, their definitions, their attributes, their relationships, and rules for these relationships.  You might think that this pretty much covers data modeling, but think about the history and practice of data modeling for a moment.  Like it or not, data modeling is oriented to the design of databases that we intend to implement in applications.  At least that was how Ben Cohen explained it to me almost 20 years ago when he created ERwin.

Despite some valiant efforts, examples of which can be found among my fellow bloggers here, data modeling cannot escape its original orientation.  It is not really suited to developing taxonomies, e.g. subject area models.  These are becoming a big deal today.  We want the enterprise data landscape categorized to identify sensitive data, financial data, master data, subject areas, legal ownership, governance, and so on.  Nor does data modeling support multiple overlapping subtype-supertype relationships around the same entity.  For instance, I need to have Product Life Cycle, Product Line, Product Sales Hierarchy, and Product Class for a Product entity.  It is not possible to break these into their subtypes, and we are forced to simply have code tables connected to the Product entity.  The values in these code tables are what the subtypes should be, but they cannot be defined within the data model. 

There is a higher class of problem with data modeling too.   It is "closed world".  Not that this is a bad thing when you come to design databases.  But ontology tries to be "open world".  It seeks to make all assumptions explicit.  For instance, the notation of data modeling, with its boxes and lines representing entity types and relationships does not deal well with problems like the variation of the meaning of "Customer" within different departments of the enterprise - where will we show "department" in a data model?

To close, it seems to me that data modeling is now mature, but there is a class of problems it cannot address, or at least address well, but which enterprises are slowly beginning to realize must be addressed.  If data modeling is mature, it is unlikely to be extensible to solve these problems - which are centered around business semantics.  Ontology, perhaps the oldest science in existence, is a newcomer to this area, and offers some potential.   We can therefore expect clashes between its aficionados and at least the practitioners of conceptual data modeling.  I wonder who will win.