How OWL 2 relates to other technologies
As discussed in Section 2, OWL 2 is, in several respects, similar to many other technologies: in particular, OWL uses a class-object paradigm which aligns it (to some degree) with object oriented programming and entity-relationship diagrams. Furthermore, it is has an XML based concrete syntax as well as an RDF one, making it easy for people familiar with those technologies to project features from them onto OWL. In general, people familiar with other technologies are sometimes misled by the similarities and thus very surprised by the differences. In the following, we provide discussions of OWL from the lens of four related or contrasting technologies, RDF, XML, object oriented programming, and relational databases.
Like OWL, the Resource Description Framework (RDF) is part of the Semantic Web languages based on the W3C. RDF and OWL are closely related: Both are logic based languages coming out of the knowledge representation tradition (esp. the semantic net tradition). RDF and OWL have closely related semantics, indeed, one of the semantics for OWL is "RDF-Based". RDF (and the RDF Schema Language, RDFS) can be seen as subsets or profiles of OWL. Most prominently, the primary exchange syntax for OWL is RDF/XML.
However, there are differences of style, emphasis, and common practice that can make relying on RDF(S) intuitions misleading when working with OWL. For example, while OWL statements and expressions can be encoded as RDF triples, viewing many OWL statements and expressions as collections of facts is not a fruitful way of writing or understanding them. For example, while subclass axioms involving only class names correspond exactly to a triple, subclass axioms involving class expressions do not. For example:
|SubClassOf(:Mother, :Woman)||:Mother rdfs:subClassOf :Woman|
|SubClassOf(:Mother, ObjectSomeValuesFrom( :hasChild :Person ))|| :Mother rdfs:subClassOf _:x.|
_:x rdf:type owl:Restriction.
_:x owl:onProperty :hasChild.
_:x owl:someValuesFrom :Person
In the first row, the triple corresponds exactly to an OWL Axiom. In the second row, a single (though complex) OWL axiom corresponds to a set of RDF triples. While this is "mere syntax" (since they are notational variants of each other and one is not so much more verbose than the other) there is a conceptual difference. For example, if you want to count the number of RDF statements of a document, you just count the triples. To count the number of OWL statements requires a more complex operation.
Furthermore, OWL is, in essence, a notational variant of a very expressive logic and that expressivity is one of OWL's unique features. Thus, a major focus of many OWL developers are the implicit axioms of an ontology, that is, the entailments. In contrast, RDF is deliberately inexpressive. Indeed, it is quite common (and effective) to work with RDF as a kind of graph database where the primary focus is on the explicit statements in the graph.
Even when we consider parts of RDFS which support implicit knowledge, such as determining subclass relationships, the relation between the explicit and implicit statements is very direct. Thus, it is easy to conceptualize inference in terms of graph structure manipulation. In contrast, determining implicit knowledge in OWL, including determining subclass relationships and typing and checking consistency of an ontology, requires techniques that are much more akin to theorem proving.
OWL and the XML family of technologies share some common parts: OWL can be expressed in XML languages (such as RDF/XML or the XML serialization of OWL) and thus be manipulated by XML tools. OWL reuses datatypes and datatype derivation facets from XML Schema. Finally, OWL and XML can both be used for conceptual modeling as well as data definition, though they ways they go about it are quite different. OWL is oriented toward more abstract, higher level conceptual modeling than is XML.
OWL is designed to support the discovery of relationships between classes through automated reasoning. XML schema languages are design primarily to validate documents. OWL also builds in far fewer presumptions about the entities it is describing both generally and in terms of their physical realization in computational systems.
Both OWL and XML Schema support strong abstraction facilities. However XML Schema, is much more concerned with the data organization issues relating to its core mission of validating XML documents.
One interesting feature of XML's separation of well-formedness and validity is to weaken the general prescriptiveness of schema languages. Unlike SGML, XML does not require that an XML document is valid against at least one schema.
OWL is much less suitable for validation. For example, suppose we define the class Citizen to be those things that have a parent which is also a Citizen (assuming we have some bootstrap condition for founding citizens; we ignore that part of the definition for the moment). The definition might look something like:
Class: Citizen EquivalentTo: hasParent some Citizen
Read prescriptively, we would expect that the following assertion to be invalid (incorrect, inconsistent) in light of this definition:
Individual: Sheevah Types: Citizen
Since this says that Sheevah is a Citizen but doesn't tell us anything about her parents. That is, the definition does not force us to include information about Sheevah's parents in order to claim that she is a Citizen.
Individual: Sheevah Types: Citizen Facts: hasParent Suma
While we have not said anything about Suma's citizenship, we have not ruled out that she is a Citizen. Everything we have said about Sheevah is consistent with her being a Citizen, thus, from an OWL perspective, there is no problem. In a prescriptive system, missing information generally is a problem or a relatively rare occurrence. For example, in RDBMs system the most common way of dealing with missing information is to have special values, i.e., null values. That is, we must explictly say what we do not know. In OWL, everything not explictly said and not explicitly ruled out is considered possible.
Databases store and organize information. Relational databases, in the classic sense, are build on a very restricted version of first order logic (i.e., the relational calculus) plus some extensions. It is not uncommon to analogize database data with a set of OWL Assertions and database schemas with OWL Class and Property Axioms. However, databases are oriented to environments where all information that an application needs is available, where considerations of data integrity in situations of simultaneous access and update are important, or where very large amounts of data needs to be worked with. OWL is more oriented towards flexible and expressive description of data (or information), and only considers information to be complete if the completeness can be determined from other information.
Ontologies in OWL are much more powerful and flexible than database schemas. Database schemas generally only shape the kinds of information that is associated with objects (or tuples) that belong to a class (or table). Classes in OWL ontologies can do this, but also can provide recognition conditions so that explicit typing is not required in OWL. Of course this flexibility means that determining typing in OWL can require complex inferences.
A final major difference between databases and OWL is that the information stored in a database is derived from the database schema and integrity constraints – if the schema doesn't sanction the storage of certain kinds of information, then that information cannot be stored, and, similarly, if the information violates an integrity constraint it also cannot be stored. OWL, on the other hand, allows arbitrary information to be associated with just about any object – if there is nothing in the ontology forbidding the associated then it is allowable. OWL is thus much more flexible in its information storage.
There is one aspect, when comparing OWL to databases, that I did not find in the text and I think it may be good to note. One of the force of OWL, compared to database usage, is that an OWL ontology (both the axioms and the facts) is completely independent from the exact location of the data, whereas, at least in most people's mind, the database schema and the data itself are, sort of, bound to a specific physical database. Because OWL uses URI-s both for individuals and for axioms, that means that OWL reinforces the Web aspect of things.
Object-oriented programming (OOP) also has object-centered modeling characteristics, and thus has much in common with OWL. However, OOP generally is performed in complete-information contexts, and where the information that can possibly be known about an object is circumscribed by the information in the type of the object. As with databases, the differing stances on completeness and object information is a major difference between OWL and OOP. Similarly OOP classes are much less expressive than OWL classes.
Furthermore, OWL is a strictly declarative and logical language. OWL therefore has none of the operational aspects of OOP, like methods, and similarly reasoning in OWL is strictly logical, with nothing comparing to inheritance, particularly inheritance with exceptions or overriding.
The above may be a bit confusing as restrictions do 'inherit', just not in the typical OOP way... PeterPatel-Schneider Restrictions do not “inherit” – the behaviour of inheritance may be aped in OWL, but the underlying mechanism is totally different – thinking “inheritance” is just going to get you caught.