Data Modeling, RDF, and OWL

A data model (or at least a conceptual entity/relationship model) is a description of the semantics of a business. The notation chosen is a specific language for representing (to humans) the things of significance to the business, their attributes, and relationships between them. The notation is very effective at representing structure, but is limited in its ability to represent business rules and other constraints. It is good for presentation purposes, but cannot be operated on electronically.

RDF and OWL are also languages for representing the semantics of a business. They are not as accessible to the casual observer, but they are more rigorous and extensive in what they can describe. Also, the descriptions encoded in these languages can be operated on by automated retrieval and analysis programs. This presentation will take a business model and show how it could be rendered in each of these languages, highlighting the advantages and disadvantages of each.

The difference between the data modeling/ database design/ business rules approach and the ontology approach is between defining a filter that asserts that only what we say is true, and defining a means for letting the computer find things that may be true if we haven't asserted otherwise. The ontology languages are textual and XML based, so the assertions expressed in them can be used by an automated inference engine to examine a body of data, and using our constraint assertions to discover things we didn't think of. Where business rules are being developed in the context of data models, except for ORM, these representations of data structure are not adequate to represent extensive constraints. Ontology languages show promise as a way of doing exactly that.

Ontology languages are definitely intended to be read by computers, not people, however. For this reason, it will still be important to use data models as a way to represent data structures to people. The advent of ontololgy languages can give us new insights into the implications of both constraints we express and those we have always assumed.