OWL 2 Web Ontology Language
Primer

1 Introduction

1.1 Guide to this Document

This document is intended to provide an initial understanding about OWL 2. In particular it is supposed to be accessible for people yet unfamiliar with the topic. Therefore, we start with Section 2 by providing some very basic notions in knowledge representation and explain how they relate to terms used in OWL 2. Readers familiar with knowledge representation and reasoning might only skim through this section to get acquainted with the OWL 2 terminology.

Sections 3 - 7 describe most of the language features that OWL provides, starting from very basic ones and proceeding to the more sophisticated. Section 3 presents and discusses the elementary modeling features of OWL 2 before in Section 4 complex classes are introduced. Section 5 adresses advanced modeling features for properties. Section 6 focuses on advanced modeling related to dadatypes. Section 7 concludes with extra-logical features used mainly for ontology management purposes.

In Section 8 we address the differences between OWL 2 DL and OWL 2 Full, while in Section 9 we describe the 3 Profiles of OWL 2. Tool support for OWL 2 is addressed in Section 10 and in Section 11 we give pointers on where to continue reading after our informal introduction to OWL 2.

Finally, Section 12.2 explains how OWL 2 relates to other key technologies.

1.2 OWL Syntaxes

2 Modelling Knowledge: Basic Notions

OWL 2 is a knowledge representation language, designed to formulate, exchange and reason with knowledge about a domain of interest. Some fundamental notions should first be explained to understand how knowledge is represented in OWL 2. These basic notions are:

• Axioms: the basic statements that an OWL ontology expresses
• Entities: elements used to refer to the real-world objects that are modelled
• Expressions: combinations of entities to form complex descriptions from basic ones

While OWL 2 aims to capture knowledge, the kind of “knowledge” that can be represented by OWL does of course not reflect all aspects of human knowledge. OWL can rather be considered as a powerful general-purpose modelling language for certain parts of human knowledge. The modelling artefacts created in OWL are called ontologies – a terminology that also helps to avoid confusion since the term “model” is often used in a rather different sense in knowledge representation.

Now, in order to formulate knowledge explicitly, it is useful to assume that it consists of elementary pieces that are often referred to as statements or propositions. Statements like “it is raining” or “every man is mortal” are typical examples for such basic propositions. In OWL 2, these basic “pieces of knowledge” are called axioms. Indeed, every OWL 2 ontology is – from an abstract viewpoint – essentially just a collection of axioms. It is characteristic for axioms that they can be said to be true or false given a certain state of affairs. This distinguishes axioms from entities and expressions that are described further below.

When humans think, they draw consequences from their knowledge. An important feature of OWL is that it captures this aspect of human intelligence for the forms of knowledge that it can represent. But what does it mean, generally speaking, that a statement is a consequence of other statements? Essentially it means that this statement is true whenever the other statements are. In OWL terms: we say, a set of axioms A entails an axiom a if in any state of affairs wherein all axioms from A are true, also a is true. Moreover, a set of axioms may be consistent (that is, there is a possible state of affairs in which all the axioms in the set are jointly true) or inconsistent (there is no such state of affairs). The formal semantics of OWL specifies, in essence, for which possible “states of affairs” – interpretations – a particular OWL ontology is true.

There are OWL tools – reasoners – that can automatically compute consequences. The way axioms interact can be very subtle and difficult for people to understand without tool support. This is both a strength and a weakness of OWL 2. It is a strength because OWL 2 can discover information that a person would not have spotted. This allows knowledge engineers to model more directly and the system to provide useful feedback and critique of the modelling. It is a weakness because it is comparatively difficult for humans to immediately foresee the actual effect of various constructs in various combinations. Tool support ameliorates the situation but successful knowledge engineering often still requires some amount of training and experience.

Having a closer look at OWL axioms, we see that they are rarely “monolithic” but more often have some internal structure that can be explicitly represented. They normally refer to objects of the world and describe them e.g. by putting them into categories (like “Mary is female”) or saying something about their relation (“John and Mary are married”). All atomic constituents of axioms, be they objects (John, Mary), categories (female) or relations (married) are called entities. In OWL 2, we denote objects as individuals, categories as classes and relations as properties. Properties in OWL 2 are further subdivided. Object properties relate objects to objects (like a person to their spouse), while datatype properties assign data values to objects (like an age to a person). Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead of the domain of interest.

As a central feature of OWL, names of entities can be combined into expressions using so called constructors. As a basic example, the atomic classes “female” and “professor” could be combined conjunctively to describe the class of female professors. The latter would be described by an OWL class expression, that could be used in statements or in other expressions. In this sense, expressions can be seen as new entities which are defined by their structure. In OWL, the constructors for each sort of entity varies greatly. The expression language for classes is very rich and sophisticated, whereas the expression language for properties is much less so. These differences have historical as well as technical reasons.

One can use basic algebra as a somewhat naive but possibly elucidating analogy for the introduced terminology. An axiom would relate to an equation like x=y. Clearly, this axiom can be said true or false, depending on the state of affairs (i.e. the actual values of these variables). Moreover, the two axioms x=y and y=z entail the axiom x=z, as in every state of affairs where the former are true, the latter is also true. Likewise, we can have consistent sets of axioms (x=y, y=z) or inconsistent ones (x=y, y=x+1). Obviously, the axioms consist of entities (x, y, z) which are not themselves true or false and can be combined by constructors (+, -, etc.) into expressions (like x+y or y-z) which in a way represent new entities and can be used instead of simple entities in axioms (x+y=y-z).

3 Classes, Properties, and Individuals - And Basic Modelling With Them

After these general considerations, we now engage in the details of modeling with OWL 2. In the subsequent sections, we will introduce the essential modeling features that OWL 2 offers, provide examples and give some general comments on how to use them. We will proceed from basic features, which are essentially available in any modeling language, to more advanced constructs.

3.1 Classes and Instances

Suppose we want to represent information about a particular family. (We do not intend this example to be representative of the sorts of domains OWL should be used for, or as a canonical example of good modeling with OWL, or a correct representation of the rather complex, shifting, and politically explosive domain of families. Instead, we intend it to be a rather simple exhibition of various features of OWL.)

We first need to provide the information what persons we are talking about. This can be done as follows:

 ClassAssertion( f:Person f:Mary ) 

 <f:Person rdf:about="#Mary"/>

 f:Mary rdf:type f:Person .

 Individual: Mary
   Types: Person

 <owl:ClassAssertion>
    <owl:Class IRI="&f;Person"/>
    <owl:NamedIndividual IRI="&f;Mary"/>
 </owl:ClassAssertion>

This statement talks about an individual named Mary and states that this individual is a person. More technically, being a person is expressed by stating that Mary belongs to (or "is a member of" or, even more technically, "is an instance of") the class of all persons. In general classes are used to group individuals that have something in common in order to refer to them. Consequently, we can use the same type of statement to indicate that Mary is a woman by expressing that she is an instance of the class of women:

 ClassAssertion( f:Woman f:Mary ) 

 <f:Woman rdf:about="#Mary"/>

 f:Mary rdf:type f:Woman .

 Individual: Mary
   Types: Woman

 <owl:ClassAssertion>
    <owl:Class IRI="&f;Woman"/>
    <owl:NamedIndividual IRI="&f;Mary"/>
 </owl:ClassAssertion>

Hereby it also becomes clear that class membership is not exclusive: as there may be diverse criteria to group individuals (like gender, age, shoe size, etc.), one individual may well belong to several classes simultaneously.

3.2 Class Hierarchies

In the previous section, we were talking about two classes: the class of all persons and that of all women. To the human reader it is clear that these two classes are in a special relationship: Person is more general than Woman, meaning that whenever we know some individual to be a woman, it must be a person. However, this correspondence cannot be derived from the labels "Person" and "Woman" but is part of the human background knowledge about the world and our usage of those terms. Therefore, in order to enable a system to draw the desired conclusions, it has to be informed about this corresondency. In OWL 2, this is done by a so-called subclass axiom:

 SubClassOf( f:Woman f:Person )

 <owl:Class rdf:about="#Woman">
   <rdfs:subClassOf rdf:resource="#Person"/>
 </owl:Class>

 f:Woman rdfs:subClassOf f:Person .

 Class: Woman
   SubClassOf: Person

 <owl:SubClassOf>
   <owl:Class IRI="&f;Woman"/>
   <owl:Class IRI="&f;Person"/>
 </owl:SubClassOf>

The presence of this axiom in an ontology enables reasoners to infer for every individual that is specified as an instance of the class Woman, that is an instance of the class Person as well. As a rule of thumb, a subclass relationship between two classes A and B can be specified, if the phrase "every A is a B" makes sense and is correct.

It is common in ontological modelling to use subclass statements not only for sporadically declaring such interdependencies, but to model whole class hierarchies by specifying the generalization relationships of all classes in the domain of interest. Suppose we also want to state that all mothers are women:

 SubClassOf( f:Mother f:Woman )

 <owl:Class rdf:about="#Mother">
   <rdfs:subClassOf rdf:resource="#Woman"/>
 </owl:Class>

 f:Mother rdfs:subClassOf f:Woman .

 Class: Mother
   SubClassOf: Woman

 <owl:SubClassOf>
   <owl:Class IRI="&f;Mother"/>
   <owl:Class IRI="&f;Woman"/>
 </owl:SubClassOf>

Then a reasoner could not only derive for every single individual that is classified as mother, that it is also a woman (and consequently a person), but also that Mother must be a subclass of Person - coinciding with our intuition. Technically, this means that the subclass relationship between classes is transitive. Besides this, it is also reflexive, meaning that every class is its own subclass - this is intuitive as well since clearly, every person is a person etc.

Two classes can also be said to be equivalent in the sense that they contain exactly the same individuals. The following example states that the class Person is equivalent to the class Human.

 EquivalentClasses( f:Person f:Human )

 <owl:Class rdf:about="#Person">
   <owl:equivalentClass rdf:resource="#Human"/>
 </owl:Class>

 f:Person owl:equivalentClass f:Human .

 Class: Person
   EquivalentTo: Human

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;Person"/>
   <owl:Class IRI="&f;Human"/>
 </owl:EquivalentClasses>

Stating that Person and Human are equivalent amounts exactly to the same as stating that both Person is a subclass of Human and Human is a subclass of Person.

3.3 Class Disjointness

In Section 4.3, we stated that an individual can be an instance of several classes. However considering the classes Man and Woman, it can be excluded that there is an individual that is an instance of both classes (for the sake of the example, we disregard biological borderline cases). This "incompatibility relationship" between classes is referred to as (class) disjointness. Again, the information that two classes are disjoint is part of our background knowledge and has to be explicitly stated for a reasoning system to make use of it. This is done as follows:

 DisjointClasses( f:Woman f:Man )

 <owl:AllDisjointClasses>
   <owl:members rdf:parseType="Collection">
     <owl:Class rdf:about="#Woman"/>
     <owl:Class rdf:about="#Man"/>
   </owl:members>
 </owl:AllDisjointClasses>

 _:x rdf:type    owl:AllDisjointClasses ;
     owl:members ( f:Woman f:Man ) . 

 DisjointClasses: Woman Man

 <owl:DisjointClasses>
     <owl:Class IRI="&f;Woman"/>
     <owl:Class IRI="&f;Man"/>
 </owl:DisjointClasses>

In practice, disjointness statements are often forgotten or neglected. The arguable reason for this could be that intuitively, classes are considered disjoint unless there is other evidence. By omitting disjointness statements, many potentially useful consequences can get lost. Note that in our example, the disjointness axiom is needed to deduce that Mary is not a man. Moreover, given the above axioms, a reasoner can infer the disjointness of the classes Mother and Man.

3.4 Object Properties

In the preceding sections we were concerned with describing single individuals, their class memberships, and how classes can relate to each other based on their instances. But more often than not, an ontology is also meant to specify how the individuals relate to other individuals. Obviously those relationships are central when describing a family. We start by indicating that Mary is John's wife.

 PropertyAssertion( f:hasWife f:John f:Mary )

 <rdf:Description rdf:about="#John">
   <hasWife rdf:resource="#Mary"/>
 </rdf:Description>

 f:John f:hasWife f:Mary .

 Individual: John
   Facts: hasWife Mary

 <owl:ObjectPropertyAssertion>
   <owl:ObjectProperty IRI="&f;hasWife"/>
   <owl:NamedIndividual IRI="&f;John"/>
   <owl:NamedIndividual IRI="&f;Mary"/>
 </owl:ObjectPropertyAssertion>

Hereby, the entities describing in which way the individuals are related - like hasWife in our case, are called properties.

Note that the order in which the individuals are written down is important. While "Mary is John's wife" might be true, "John is Mary's wife" certainly isn't. Indeed, this is a common source of modeling errors. Likewise, it is important to use property names which allow only one unique intuitive reading. In case of nouns (like “wife”), such unambiguous names might be constructions with “of” or with “has” (wifeOf or hasWife). For verbs (like “to love”) an inflected form (loves) or a passive version with “by” (lovedBy) would prevent unintended readings.

We can also state that two individuals are not connected by a property. The following, for example, states that Mary is not Jack's wife.

 NegativeObjectPropertyAssertion( f:hasWife f:Jack f:Mary )

 <owl:NegativePropertyAssertion>
   <owl:sourceIndividual rdf:about="#Jack">
   <owl:assertionProperty rdf:about="#hasWife">
   <owl:targetIndividual rdf:about="#Mary">
 </owl:NegativePropertyAssertion>

 _:x rdf:type              owl:NegativePropertyAssertion ;
     owl:sourceIndividual  f:Jack ;
     owl:assertionProperty f:hasWife ;
     owl:targetIndividual  f:Mary .

 Individual: Jack
   Facts: not hasWife Mary

 <owl:NegativeObjectPropertyAssertion>
   <owl:ObjectProperty IRI="&f;hasWife"/>
   <owl:NamedIndividual IRI="&f;Jack"/>
   <owl:NamedIndividual IRI="&f;Mary"/>
 </owl:NegativeObjectPropertyAssertion>

3.5 Property Hierarchies

In Section 4.2 we argued that it is useful to specify that one class membership implies another one. Essentially the same situation can occur for properties: whenever B is known to be A's wife, it is also known to be A's spouse (note, that this is not true the other way round). OWL allows to specify this statement as follows:

 SubPropertyOf( f:hasWife f:hasSpouse )

 <owl:ObjectProperty rdf:about="#hasWife">
   <rdfs:subPropertyOf rdf:resource="#hasSpouse"/>
 </owl:ObjectProperty>

 f:hasWife rdfs:subPropertyOf f:hasSpouse .

 ObjectProperty: hasWife
   SubPropertyOf: hasSpouse

 <owl:SubObjectPropertyOf>
   <owl:ObjectProperty IRI="&f;hasWife"/>
   <owl:ObjectProperty IRI="&f;hasSpouse"/>
 </owl:SubObjectPropertyOf>

Similarly, the subproperty relationship can also be stated for datatype properties (and for annotation properties). There is also a syntactic shortcut for property equivalence, which is similar to class equivalence.

3.6 Domain and Range Restrictions

Frequently, the information that two individuals are interconnected by a certain property allows to draw further conclusions about the individuals themselves. In particular, one might infer class memberships. For instance, the statement that B is the wife of A obviously implies that B is a woman while A is a man. So in a way, the statement that two individuals are related via a certain property carries implicit additional information about those individuals. In our example, this additional information can be expressed via class memberships. OWL provides a way to state this correspondence:

 PropertyDomain( f:hasWife f:Man ) 
 PropertyRange( f:hasWife f:Woman ) 

 <owl:ObjectProperty rdf:about="#hasWife">
   <rdfs:domain rdf:resource="#Man"/>
   <rdfs:range rdf:resource="#Woman"/>
 </owl:ObjectProperty>

 f:hasWife rdfs:domain f:Man ;
           rdfs:range  f:Woman .

 ObjectProperty: hasWife
   Domain: Man
   Range: Woman

 <owl:ObjectPropertyDomain>
   <owl:ObjectProperty IRI="&f;hasWife"/>
   <owl:Class &f;Man"/>
 </owl:ObjectPropertyDomain>
 <owl:ObjectPropertyRange>
   <owl:ObjectProperty IRI="&f;hasWife"/>
   <owl:Class IRI="&f;Woman"/>
 </owl:ObjectPropertyRange>

Having these two axioms in place and given e.g. the information that Sasha is related to Hillary via the property hasWife, a reasoner would be able to infer that Sasha is a man and Hillary a woman.

3.7 Equality and Inequality of Individuals

Note that from the information given so far, it can be deduced that John and Mary are not the same as they are known to be instances of the disjoint classes Man and Woman, respectively. However, if we add information about another family member, say Bill, and indicate that he is a man, there is nothing said so far that implies that John and Bill are not the same. OWL does not make the assumption that different names are names for different individuals. (This "unique names assumption" would be particularly dangerous in the Semantic Web, where names may be coined by different organizations at different times unknowingly referring to the same individual.) Hence, if we want to exclude the option of John and Bill being the same individual, this has to be explicitly specified as follows:

 DifferentIndividuals( f:John f:Bill )

 <rdf:Description rdf:about="#John">
   <owl:differentFrom rdf:resource="#Bill"/>
 </rdf:Description>

 f:John owl:differentFrom f:Bill .

 Individual: John 
   DifferentFrom: Bill 

 <owl:DifferentIndividuals>
   <owl:NamedIndividual IRI="&f;John"/>
   <owl:NamedIndividual IRI="&f;Bill"/>
 </owl:DifferentIndividuals>

It is also possible to state that two names refer to (denote) the same individual. For example, we can say that John and Jack are the same individual.

 SameIndividual( f:John f:Jack )

 <rdf:Description rdf:about="#John">
   <owl:sameAs rdf:resource="#Jack"/>
 </rdf:Description>

 f:John owl:sameAs f:Jack.

 Individual: John 
   SameAs: Jack

 <owl:SameIndividual>
   <owl:NamedIndividual IRI="&f;John"/>
   <owl:NamedIndividual IRI="&f;Jack"/>
 </owl:SameIndividual>

This would enable a reasoner to infer any information about the individual Jack which is written down for the individual John.

3.8 Datatypes

So far, we have seen how we can describe individuals via class memberships and via their relatedness to other individuals. In many cases, however, individuals are to be described by data values. Think of a person's birth date, his age, his email address etc. For this purpose, OWL provides another kind of properties, so-called Datatype properties. These properties allow to relate individuals to data values (instead of to other individuals). The following is an example using a datatype property. It states that John's age is 51.

 PropertyAssertion( f:hasAge f:John "51"^^xsd:integer )

4 Advanced Class Relationships

In the previous sections we have dealt with classes as something "opaque" carrying a name. We used them to characterize individuals, related them to other classes via subclass or disjointness statements.

We will now demonstrate how named classes, properties, and individuals can be used as building blocks to define new classes.

4.1 Complex Classes

The language elements described so far allow to model simple ontologies. But their expressivity hardly surpasses that of RDFS. In order to express more complex knowledge, OWL provides logical class constructors. In particular, OWL provides language elements for logical and, or, and not. The corresponding OWL terms are borrowed from set theory: (class) intersection, union and complement. These constructors allow to combine atomic classes – i.e. classes with names – to complex classes. Those class expressions can be used anywhere

The intersection of two classes consists of exactly those individuals which are instances of both classes. The following example states that the class Mother consists of exactly those objects which are instances of both Woman and Parent:

 EquivalentClasses(
   f:Mother 
   IntersectionOf( f:Woman f:Parent )
   ) 

 <owl:Class rdf:about="#Mother">
   <owl:equivalentClass>
     <owl:Class>
       <owl:intersectionOf rdf:parseType="Collection">
         <owl:Class rdf:about="#Woman"/>
         <owl:Class rdf:about="#Parent"/>
       </owl:intersectionOf>
     </owl:Class>
   </owl:equivalentClass>
 </owl:Class>

 f:Mother owl:equivalentClass _:x .
 _:x      rdf:type            owl:Class ;
          owl:intersectionOf  ( f:Woman f:Parent ) .

 Class: Mother
   EquivalentTo: Woman and Parent

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;Mother"/>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Woman"/>
     <owl:Class IRI="&f;Parent"/>
   </owl:ObjectIntersectionOf>
 </owl:EquivalentClasses>

An example for an inference which can be drawn from this is that all instances of the class Mother are also in the class Parent.

The union of two classes contains every individual which is contained in one of these classes. Therefore we could characterize the class of all parents as the union of the classes Mother and Father:

 EquivalentClasses(
   f:Parent 
   UnionOf( f:Mother f:Father )
   ) 

 <owl:Class rdf:about="#Parent">
   <owl:equivalentClass>
     <owl:Class>
       <owl:unionOf rdf:parseType="Collection">
         <owl:Class rdf:about="#Mother"/>
         <owl:Class rdf:about="#Father"/>
       </owl:unionOf>
     </owl:Class>
   </owl:equivalentClass>
 </owl:Class>

 f:Parent owl:equivalentClass _:x .
 _:x      rdf:type            owl:Class ;
          owl:unionOf         ( f:Mother f:Father ) .

 Class: Parent
   EquivalentTo: Mother or Father

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;Parent"/>
   <owl:ObjectUnionOf>
     <owl:Class IRI="&f;Mother"/>
     <owl:Class IRI="&f;Father"/>
   </owl:ObjectUnionOf>
 </owl:EquivalentClasses>

The complement of a class corresponds to logical negation: it consists of exactly those objects which are not members of the class itself. The following definition of childless persons uses the class complement and demonstrates that class constructors can be nested:

 EquivalentClasses(
   f:ChildlessPerson 
   IntersectionOf(
     f:Person 
     ComplementOf( f:Parent )
     )
   ) 

 <owl:Class rdf:about="#ChildlessPerson">
   <owl:equivalentClass>
     <owl:Class>
       <owl:intersectionOf rdf:parseType="Collection">
         <owl:Class rdf:about="#Person"/>
         <owl:Class>
           <owl:complementOf rdf:resource="#Parent"/>
         </owl:Class>
       </owl:intersectionOf>
     </owl:Class>
   </owl:equivalentClass>
 </owl:Class>

 f:ChildlessPerson owl:equivalentClass _:x .
 _:x               rdf:type            owl:Class ;
                   owl:intersectionOf  ( f:Person _:y ) .
 _:y               owl:complementOf    f:Parent .

 Class: ChildlessPerson
   EquivalentTo: Person and not Parent

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;ChildlessPerson"/>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Person"/>
     <owl:ObjectComplementOf>
       <owl:Class IRI="&f;Parent"/>
     </owl:ObjectComplementOf>
   </owl:ObjectIntersectionOf>
 </owl:EquivalentClasses>

All the above examples demonstrate the usage of class constructors in order to define new classes as combination as others. But, of course, it is also possible to use class constructors together with a subclass statement in order to indicate necessary, but not sufficient conditions for a class. The following statement indicates that every Father is both a man and a parent (whereas the converse is not necessarily true):

 SubClassOf( 
   f:Father 
   IntersectionOf( f:Man f:Parent )
   )

 <owl:Class rdf:about="#Father">
   <rdfs:subClassOf>
     <owl:Class>
       <owl:intersectionOf rdf:parseType="Collection">
         <owl:Class rdf:about="#Man"/>
         <owl:Class rdf:about="#Parent"/>
       </owl:intersectionOf>
     </owl:Class>
   </rdfs:subClassOf>
 </owl:Class>

 f:Father rdfs:subClassOf   _:x .
 _:x      rdf:type           owl:Class ;
          owl:intersectionOf ( f:Man f:Parent ) .

 Class: Father
   SubClassOf: Man and Parent

 <owl:SubClassOf>
   <owl:Class IRI="&f;Father"/>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Man"/>
     <owl:Class IRI="&f;Parent"/>
   </owl:ObjectIntersectionOf>
 </owl:SubClassOf>

In general, complex classes can be used in every place where named classes can occur, hence also in class assertions:

 ClassAssertion(
   IntersectionOf(
     f:Person 
     ComplementOf( f:Parent )
     ) 
   f:John
   )

 <rdf:Description rdf:about="#John">
   <rdf:type>
     <owl:Class>
       <owl:intersectionOf  rdf:parseType="Collection">
         <owl:Class rdf:about="#Person"/>
         <owl:Class>
           <owl:complementOf rdf:about="#Parent"/>
         </owl:Class>
       </owl:intersectionOf>
     </owl:Class>
   </rdf:type>
 </rdf:Description>

 f:John rdf:type           _:x1 .
 _:x1   rdf:type           owl:Class ;
        owl:intersectionOf ( f:Person _:x2 ) .
 _:x2   rdf:type           owl:Class ;
        owl:complementOf   f:Parent .

 Individual: John
   Types: Person and not Parent

 <owl:ClassAssertion>
   <owl:ObjectIntersectionOf>
    <owl:Class IRI="&f;Person"/>
    <owl:ObjectComplementOf>
      <owl:Class IRI="&f;Parent"/>
    </owl:ObjectComplementOf>
   </owl:ObjectIntersectionOf>
   <owl:NamedIndividual IRI="&f;John"/>
 </owl:ClassAssertion>

4.2 Property Restrictions

By property restrictions we understand another type of logic-based constructors for complex classes. As the name suggests, property restrictions are constructors involving properties.

The first property restriction called existential quantification defines a class as the set of all individuals that are connected via a particular property to another individual which is an instance of a certain class. This is best explained by an example, like the following which defines the class of parents as the class of individuals that are linked to a person by the hasChild property.

 EquivalentClasses(
   f:Parent 
   SomeValuesFrom( f:hasChild f:Person )
   )

 <owl:Class rdf:about="#Parent">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#hasChild"/>
       <owl:someValuesFrom rdf:resource="#Person"/>
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>

 f:Parent owl:equivalentClass _:x .
 _:x      rdf:type            owl:Restriction ;
          owl:onProperty      f:hasChild ;
          owl:someValuesFrom  f:Person .

 Class: Parent
   EquivalentTo: hasChild some Person

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;Parent"/>
   <owl:ObjectSomeValuesFrom>
     <owl:ObjectProperty IRI="&f;hasChild"/>
     <owl:Class IRI="&f;Person"/>
   </owl:ObjectSomeValuesFrom>
 </owl:EquivalentClasses>

Another property restriction, called universal quantification is used to describe a class of individuals for which all "property-successors" are instances of a given class. We can use the following statement to indicate that a person is happy exactly if all their children are happy.

 EquivalentClasses(
   Intersection( f:Person f:Happy ) 
   AllValuesFrom( f:hasChild f:Happy )
   )

 <owl:Class>
   <owl:intersectionOf>
     <owl:Class rdf:about="#Person"/>
     <owl:Class rdf:about="#Happy"/>
   </owl:intersectionOf>
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty rdf:about="#hasChild"/>
       <owl:allValuesFrom rdf:about="#Happy"/>
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>

 _:x1 owl:equivalentClass _:x2 .
 _:x1 rdf:type            owl:Class ;
      owl:intersectionOf  f:Person ,
                          f:Happy .
 _:x2 rdf:type            owl:Restriction ;
      owl:onProperty      f:hasChild ;
      owl:allValuesFrom   f:Happy .

 Class: X
   EquivalentTo: Person and Happy
 Class: X
   EquivalentTo: hasChild all Happy

 <owl:EquivalentClasses>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Person"/>
     <owl:Class IRI="&f;Happy"/>
   </owl:ObjectIntersectionOf>
   <owl:ObjectAllValuesFrom>
     <owl:ObjectProperty IRI="&f;hasChild"/>
     <owl:Class IRI="&f;Happy"/>
   </owl:ObjectAllValuesFrom>
 </owl:EquivalentClasses>

The usage of property restrictions may cause some conceptual confusion to “modeling beginners.” As a rule of thumb, when translating a natural language statement into a logical axiom, existential quantification occurs far more frequently. Natural language indicators for the usage of universal quantification are words like “only,” “exclusively,” or “nothing but.”

There is one particular misconception concerning the universal role restriction. As an example, consider the above happiness axiom. The intuitive reading suggests that in order to be happy, a person must have at least one happy child. Yet, this is not the case: any individual that is not the "starting point" of the property hasChild is class member of any class defined by universal quantification over hasChild. Hence, by our above statement, every childless person would be qualified as happy. In order to formalize the aforementioned intended reading, the statement would have to read as follows:

 EquivalentClasses(
   Intersection( f:Person f:Happy ) 
   Intersection(
     ObjectAllValuesFrom( f:hasChild f:Happy )
     ObjectSomeValuesFrom( f:hasChild f:Happy )
     )
   )

 <owl:Class>
   <owl:intersectionOf>
     <owl:Class rdf:about="#Person"/>
     <owl:Class rdf:about="#Happy"/>
   </owl:intersectionOf>
   <owl:equivalentClass>
     <owl:Class>
       <owl:intersectionOf>
         <owl:Restriction>
           <owl:onProperty rdf:about="#hasChild"/>
           <owl:allValuesFrom rdf:about="#Happy"/>
         </owl:Restriction>
         <owl:Restriction>
           <owl:onProperty rdf:about="#hasChild"/>
           <owl:someValuesFrom rdf:about="#Happy"/>
         </owl:Restriction>
        </owl:intersectionOf>
     </owl:Class>
   </owl:equivalentClass>
 </owl:Class>

 _:x1 owl:equivalentClass _:x2 .
 _:x1 rdf:type            owl:Class ;
      owl:intersectionOf  f:Person ,
                          f:Happy .
 _:x2 rdf:type            owl:Class ;
      owl:intersectionOf  _:x3 ,
                          _:x4 .
 _:x3 rdf:type            owl:Restriction ;
      owl:onProperty      f:hasChild ;
      owl:allValuesFrom   f:Happy .
 _:x4 rdf:type            owl:Restriction ;
      owl:onProperty      f:hasChild ;
      owl:someValuesFrom  f:Happy .

 Class: X
   EquivalentTo: Person and Happy
 Class: X
   EquivalentTo: hasChild all Happy

 <owl:EquivalentClasses>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Person"/>
     <owl:Class IRI="&f;Happy"/>
   </owl:ObjectIntersectionOf>
   <owl:ObjectAllValuesFrom>
     <owl:ObjectProperty IRI="&f;hasChild"/>
     <owl:Class IRI="&f;Happy"/>
   </owl:ObjectAllValuesFrom>
 </owl:EquivalentClasses>

This example also illustrates how property restrictions can be nested with complex classes.

Moreover, we might be interested to describe a class of individuals that are related to one particular individual. For instance we could define the class of John's children:

 EquivalentClasses( 
   f:JohnsChildren 
   ObjectHasValue( f:hasParent f:John )
   )

 missing

 missing

 Class: JohnsChildren
   EquivalentTo: hasParent value John

 missing

As a special case of individuals being interlinked by properties, an individual might be linked to itself. Indeed, OWL provides the opportunity to e.g. define the class NarcisticPerson as the class of individuals that are linked to themselves by a loves-property.

 EquivalentClasses  
   f:NarcisticPerson 
   HasSelf( f:loves ) 
   )

 <owl:Class rdf:about="#NarcisticPerson">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#loves"/>
       <owl:hasSelf rdf:datatype="&xsd;boolean">
         true
       </owl:hasSelf>
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>

 f:NarcisticPerson owl:equivalentClass _:x .
 _:x               rdf:type            owl:Restriction ;
                   owl:onProperty      f:loves ;
                   owl:hasSelf         "true"^^xsd:boolean .

 Class: NarcisticPerson
   EquivalentTo: loves Self

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;NarcisticPerson"/>
   <owl:ObjectHasSelf>
     <owl:ObjectProperty IRI="&f;loves"/>
   </owl:ObjectHasSelf>
 </owl:EquivalentClasses>

4.3 Property Cardinality Restrictions

Using existential and universal quantification, we can say something about all respectively at least one of somebody's childs. In a similar way, we can construct classes depending on the number of childs. The following example states that John has at most four children who are themselves parents:

 ClassAssertion(
    MaxCardinality( 4 f:hasChild f:Parent ) 
    John
    )

 <rdf:Description rdf:about="#John">
   <rdf:type>
     <owl:Class>
       <owl:Restriction>
         <owl:maxQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">
           4
         </owl:maxQualifiedCardinality>
         <owl:onProperty rdf:about="#hasChild"/>
         <owl:onClass rdf:about="#Parent"/>
       </owl:Restriction>
     </owl:Class>
   </rdf:type>
 </rdf:Description>

 f:John rdf:type                    _:x .
 _:x    rdf:type                    owl:Restriction ;
        owl:maxQualifiedCardinality "4"^^xsd:nonNegativeInteger ;
        owl:onProperty              f:hasChild ;
        owl:onClass                 f:Parent .

 Individual: John
   Types: hasChild max 4 Parent

 <owl:ClassAssertion>
   <owl:ObjectMaxCardinality cardinality="4">
     <owl:ObjectProperty IRI="&f;hasChild"/>
     <owl:Class &f;Parent"/>
   </owl:ObjectMaxCardinality>
   <owl:NamedIndividual IRI="&f;John"/>
 </owl:ClassAssertion>

Note that this statement allows John to have arbitrarily many further children which are not parents.

Likewise, it is also possible to declare a minimum number by saying that John is an instance of the class of individuals having at least two children that are parents:

 ClassAssertion(
   MinCardinality( 2 f:hasChild f:Parent ) 
   f:John
   )

 <rdf:Description rdf:about="#John">
   <rdf:type>
     <owl:Class>
       <owl:Restriction>
         <owl:minQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">
           2
         </owl:minQualifiedCardinality>
         <owl:onProperty rdf:about="#hasChild"/>
         <owl:onClass rdf:about="#Parent"/>
       </owl:Restriction>
     </owl:Class>
   </rdf:type>
 </rdf:Description>

 f:John rdf:type                    _:x .
 _:x    rdf:type                    owl:Restriction ;
        owl:minQualifiedCardinality "2"^^xsd:nonNegativeInteger ;
        owl:onProperty              f:hasChild ;
        owl:onClass                 f:Parent .

 Individual: John
   Types: hasChild min 2 Parent

 <owl:ClassAssertion>
   <owl:ObjectMinCardinality cardinality="2">
     <owl:ObjectProperty IRI="&f;hasChild"/>
     <owl:Class IRI="&f;Parent"/>
   </owl:ObjectMinCardinality>
   <owl:NamedIndividual IRI="&f;John"/>
 </owl:ClassAssertion>

If we happen to know the exact number of John's parent children, this can be specified as follows:

 ClassAssertion( 
   ExactCardinality( 3 f:hasChild f:Parent ) 
   f:John
   ) 

 <rdf:Description rdf:about="#John">
   <rdf:type>
     <owl:Class>
       <owl:Restriction>
         <owl:qualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger">
           3
         </owl:qualifiedCardinality>
         <owl:onProperty rdf:about="#hasChild"/>
         <owl:onClass rdf:about="#Parent"/>
       </owl:Restriction>
     </owl:Class>
   </rdf:type>
 </rdf:Description>

 f:John rdf:type                 _:x .
 _:x    rdf:type                 owl:Restriction ;
        owl:qualifiedCardinality "3"^^xsd:nonNegativeInteger ;
        owl:onProperty           f:hasChild ;
        owl:onClass              f:Parent .

 Individual: John
   Types: hasChild exactly 3 Parent

 <owl:ClassAssertion>
   <owl:ObjectExactCardinality cardinality="3">
     <owl:ObjectProperty IRI="&f;hasChild"/>
     <owl:Class IRI="&f;Parent"/>
   </owl:ObjectExactCardinality>
   <owl:NamedIndividual IRI="&f;John"/>
 </owl:ClassAssertion>

In a cardinality restriction, providing the class is optional; if we just want to talk about the number of all of John's children we can also write the following:

 ClassAssertion(
   ExactCardinality( 5 f:hasChild ) 
   f:John
   )

 <rdf:Description rdf:about="#John">
   <rdf:type>
     <owl:Class>
       <owl:Restriction>
         <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">
           5
         </owl:cardinality>
         <owl:onProperty rdf:about="#hasChild"/>
       </owl:Restriction>
     </owl:Class>
   </rdf:type>
 </rdf:Description>

 f:John rdf:type        _:x .
 _:x    rdf:type        owl:Restriction ;
        owl:cardinality "5"^^xsd:nonNegativeInteger ;
        owl:onProperty  f:hasChild .

 Individual: John
   Types: hasChild exactly 5

 <owl:ClassAssertion>
   <owl:ObjectExactCardinality cardinality="5">
     <owl:ObjectProperty IRI="&f;hasChild"/>
   </owl:ObjectExactCardinality>
   <owl:NamedIndividual IRI="&f;John"/>
 </owl:ClassAssertion>

4.4 Enumeration of Individuals

A very straightforward way to describe a class is just to enumerate all its instances. OWL provides this possibility, e.g. we can create a class of birthday guests:

 EquivalentClasses(
   f:MyBirthdayGuests
   OneOf( f:Bill f:John f:Mary)
   )

 <owl:Class rdf:about="#MyBirthdayGuests">
   <owl:equivalentClass>
     <owl:Class>
       <owl:oneOf rdf:parseType="Collection">
         <rdf:Description rdf:about="#Bill"/>
         <rdf:Description rdf:about="#John"/>
         <rdf:Description rdf:about="#Mary"/>
       </owl:oneOf>
     </owl:Class
   </owl:equivalentClass>
 </owl:Class>

 f:MyBirthdayGuests owl:equivalentClass _:x .
 _:x                rdf:type            owl:Class ;
                    owl:oneOf           ( f:Bill f:John f:Mary ).

 Class: MyBirthdayGuests
   EquivalentTo: { Bill John Mary }

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;MyBirthdayGuests"/>
   <owl:ObjectOneOf>
     <owl:NamedIndividual IRI="&f;Bill"/>
     <owl:NamedIndividual IRI="&f;John"/>
     <owl:NamedIndividual IRI="&f;Mary"/>
   </owl:ObjectOneOf>
 </owl:EquivalentClasses>

Note that this axiom provides more information than simply asserting class membership of Bill, John, and Mary as described in Section 4.1. In addition to that, it also stipulates that Bill, John, and Mary are the only members of MyBirthdayGuest. Therefore, classes defined this way are sometimes referred to as closed classes. If we now assert Jeff as an instance of MyBirthdayGuest, the consequence is that Jeff must be equal to one of the above three persons.

5 Advanced Use of Properties

Until now we focussed on classes and properties that were merely used as building blocks for class expressions. In the following, we will see what role-centric modeling capabilities OWL 2 offers.

5.1 Property Characteristics

Sometimes one property can be obtained by taking another property and changing its direction, i.e. inverting it. For example, the property hasParent can be defined as the inverse property of hasChild:

 InverseProperties( f:hasParent f:hasChild ) 

 <owl:ObjectProperty rdf:about="#hasParent">
   <owl:inverseOf rdf:resource="#hasChild"/>
 </owl:ObjectProperty>

 f:hasParent owl:inverseOf f:hasChild .

 ObjectProperty: hasParent
   InverseOf: hasChild

 <owl:InverseObjectProperties>
   <owl:ObjectProperty IRI="&f;hasParent"/>
   <owl:ObjectProperty IRI="&f;hasChild"/>
 </owl:InverseObjectProperties>

This would for example allow to deduce for arbitrary individuals A and B, where A is linked to B by the hasChild property, that B and A are also interlinked by the hasParent property. However, we do not need to explicitly assign a name to the inverse of a property if we just want to use it, say, inside a class expression. Instead of using the new hasParent property for the definition of the class Orphan, we can directly refer to it as the hasChild-inverse:

 EquivalentClasses(
   f:Orphan
   AllValuesFrom(
     InverseOf( f:hasChild )
     f:Dead)
  ) 

 <owl:Class rdf:about="#Orphan">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty>
         <owl:ObjectProperty>
           <owl:inverseOf rdf:about="#hasChild"/>
         </owl:ObjectProperty>
       </owl:onProperty>
       <owl:Class rdf:about="#Dead">
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>

 f:Orphan owl:equivalentClass _:x1 .
 _:x1     rdf:type            owl:Restriction ;
          owl:onProperty      _:x2 ;
          owl:allValuesFrom   f:Dead .
 _:x2     owl:inverseOf       f:hasChild .

 Class: Orphan
   EquivalentTo: inverse hasChild all Dead

 <owl:EquivalentClasses>
   <owl:Class IRI="&f;Orphan"/>
   <owl:ObjectAllValuesFrom>
     <owl:InverseObjectProperty>
       <owl:ObjectProperty IRI="&f;hasChild"/>
     </owl:InverseObjectProperty>
     <owl:Class IRI="&f;Dead"/>
   </owl:ObjectAllValuesFrom>
 </owl:EquivalentClasses>

In some cases, a property and its inverse coincide, or in other words, the direction of a property doesn't matter. For instance the property hasSpouse relates A with B exactly if it relates B with A. For obvious reasons, a property with this characteristic is called symmetric, which can be specified as follows

 SymmetricProperty( f:hasSpouse ) 

 <owl:SymmetricProperty rdf:about="#hasSpouse"/>

 f:hasSpouse rdf:type owl:SymmetricProperty .

 ObjectProperty: hasSpouse
   Characteristics: Symmetric

 <owl:SymmetricObjectProperty>
   <owl:ObjectProperty IRI="&f;hasSpouse"/>
 </owl:SymmetricObjectProperty>

On the other hand, a property can also be asymmetric meaning that if it connects A with B it never connects B with A. Clearly (excluding paradoxical scenarios resulting from time travels), this is the case for the property hasChild and is expressed like this:

 AsymmetricProperty( f:hasChild ) 

 <owl:AsymmetricProperty rdf:about="#hasChild"/>

 f:hasChild rdf:type owl:AsymmetricProperty .

 ObjectProperty: hasChild
   Characteristics: Asymmetric

 <owl:AsymmetricObjectProperty>
   <owl:ObjectProperty IRI="&f;hasChild"/>
 </owl:AsymmetricObjectProperty>

Previously, we considered subproperties in analogy to subclasses. It turns out that it also make sense to transfer the notion of class disjointness to properties: two properties are disjoint if there are no two individuals that are interlinked by both properties. Following common law, we can thus state that parent-child marriages cannot occur:

 DisjointProperties( f:hasParent f:hasSpouse )  

 <rdf:Description rdf:about="#hasParent">
   <owl:propertyDisjointWith rdf:resource="#hasSpouse"/>
 </rdf:Description>

 f:hasParent owl:propertyDisjointWith f:hasSpouse .

 DisjointProperties: hasParent hasSpouse

 <owl:DisjointObjectProperties>
   <owl:ObjectProperty IRI="&f;hasParent"/>
   <owl:ObjectProperty IRI="&f;hasSpouse"/>
 </owl:DisjointObjectProperties>

Properties can also be reflexive: such a property relates everything to itself. For the following example, note that everybody has himself as a relative.

 ReflexiveProperty( f:hasRelative )

 <owl:ReflexiveProperty rdf:about="f:hasRelative"/>

 f:hasRelative rdf:type owl:ReflexiveProperty .

 ObjectProperty: hasRelative
   Characteristics: Reflexive

 <owl:ReflexiveObjectProperty>
   <owl:ObjectProperty IRI="&f;hasRelative"/>
 </owl:ReflexiveObjectProperty>

Note that this does not necessarily mean that every two individuals which are related by a reflexive property are identical.

Properties can furthermore be irreflexive, meaning that no individual can be related to itself by such a role. A typical example is the following which simply states that nobody can be his own parent.

 IrreflexiveProperty( f:parentOf )   

 <owl:IrreflexiveProperty rdf:about="#parentOf"/>

 f:parentOf rdf:type owl:IrreflexiveProperty .

 Objectproperty: parentOf
   Characteristics: Irreflexive

 <owl:IreflexiveObjectProperty>
   <owl:ObjectProperty IRI="&f;parentOf"/>
 </owl:IreflexiveObjectProperty>

Next, consider the hasHusband property. As every person can have only one husband (which we take for granted for the sake of the example), every individual can be linked by the hasHusband property to at most one other individual. This kind of properties are called functional and are described as follows:

 FunctionalProperty( f:hasHusband ) 

 <owl:FunctionalProperty rdf:about="#hasHusband"/>

 f:hasHusband rdf:type owl:FunctionalProperty .

 ObjectProperty: hasHusband
   Characteristics: Functional

 <owl:FunctionalObjectProperty>
   <owl:ObjectProperty IRI="&f;hasHusband"/>
 </owl:FunctionalObjectProperty>

Note that this statement does not require every individual to have a spouse, it just states that there can be no more than one. It is also possible to indicate that the inverse of a given property is functional:

 InverseFunctionalProperty( f:hasHusband ) 

 <owl:InverseFunctionalProperty rdf:about="#hasHusband"/>

 f:hasHusband rdf:type owl:InverseFunctionalProperty .

 ObjectProperty: hasHusband
   Characteristics: InverseFunctional

 <owl:InverseFunctionalObjectProperty>
   <owl:ObjectProperty IRI="&f;hasHusband"/>
 </owl:InverseFunctionalObjectProperty>

This indicates that an individual can be husband of at most one other individual. This example also indicates the difference between functionality and inverse functionality, as in a polygynous situation the former axiom is valid whereas the latter isn't.

Now have a look at a property hasAncestor which is meant to link individuals A and B whenever A is a direct descendant of B. Clearly, the property hasParent is a "special case" of hasAncestor and can be defined as a subproperty thereof. Still, it would be nice to "automatically" include parents of parents (and parents of parents of parents). This can be done by defining hasAncestor as transitive property. A transitive property interlinks two individuals A and C whenever it interlinks A with B and B with C for some individual B.

 TransitiveProperty( f:hasAncestor )

 <owl:TransitiveProperty rdf:about="#hasAncestor"/>

 f:hasAncestor rdf:type owl:TransitiveProperty .

 ObjectProperty: hasAncestor
   Characteristics: Transitive

 <owl:TransitiveObjectProperty>
   <owl:ObjectProperty IRI="&f;hasAncestor"/>
 </owl:TransitiveObjectProperty>

5.2 Property Chains

While the last example from the previous section allowed to infer an hasAncestor property whenever there is a chain of hasParent properties, we might want to be a bit more specific and define, say, a hasGrandparent property instead. Technically, this means that we want hasGrandparent to connect all individuals that linked by a chain of exactly two hasParent properties. In contrast to the previous hasAncestor example, we do not want hasParent to be a special case of hasGrandparent nor do we want hasGrandparents to refer to great-grandparents etc. We can express that every such chain has to be spanned by a hasGrandparent property as follows:

 SubPropertyOf( 
   PropertyChain( f:hasParent f:hasParent ) 
   f:hasGrandparent 
   )

 <rdf:Description rdf:about="#hasGrandparent">
       <owl:propertyChainAxiom rdf:parseType="Collection">
               <owl:ObjectProperty rdf:about="#hasParent"/>
               <owl:ObjectProperty rdf:about="#hasParent"/>
       </owl:propertyChainAxiom>
 </rdf:Description>

 f:hasGrandparent owl:propertyChainAxiom ( f:hasParent f:hasParent ) .

 ObjectProperty: hasGrandparent
   SubPropertyChain: hasParent o hasParent

 <owl:SubObjectPropertyOf>
   <owl:PropertyChain>
     <owl:ObjectProperty IRI="&f;hasParent"/>
     <owl:ObjectProperty IRI="&f;hasParent"/>
   </owl:PropertyChain>
   <owl:ObjectProperty IRI="&f;hasGrandparent"/>
 </owl:SubObjectPropertyOf>

6 Advanced Use of Datatypes

6.1 Keys

In OWL 2 a collection of (data or object) properties can be assigned as a key to a class expression. This means that each named instance of the class expression is uniquely identified by the set of values which these properties attain in relation to the instance.

A simple example of this would be the identification of a person by her social security number.

 HasKey( f:Person hasSSN )

 <owl:Class rdf:about="#Person">
   <owl:hasKey rdf:parseType="Collection">
     <owl:ObjectProperty rdf:about="#hasSSN">
   </owl:hasKey>
 </owl:Class>

 f:Person owl:hasKey f:hasSSN .

 HasKey: Person hasSSN

 <owl:HasKey>
   <owl:Class IRI="&f;Person"/>
   <owl:ObjectProperty IRI="&f;hasSSN"/>
 </owl:HasKey>

7 Document Information and Annotations

In the following, we describe features of OWL 2 which do not actually contribute to the "logical" knowledge specified in the ontology. Rather these are used to provide additional information about the ontology itself, axioms or even single entities.

7.1 Annotating Axioms and Entities

In many cases, we want to furnish parts of our OWL ontology with information that actually does not describe the domain itself but talks about the description of the domain. OWL provides annotations for this purpose. An OWL annotation simply associates property-value pairs with parts of an ontology, or the entire ontology itself. Even annotations themselves can be annotated. Annotation information is not really part of the logical meaning of an ontology.

So, for example, we could add information to one of the classes of our ontology, giving a natural language description of its meaning.

 AnnotationAssertion( rdfs:label f:Person "Represents the set of all people." )

 <owl:Class rdf:about="#Person">
   <rdfs:label>Represents the set of all people.</rdfs:label>
 </owl:Class>

 f:Person rdfs:label "Represents the set of all people." .

 Class: Person
   Annotations: rdfs:label "Represents the set of all people."

 <owl:AnnotationAssertion>
   <owl:AnnotationProperty IRI="&rdfs;label"/>
   <owl:IRI>f:Person</owl:IRI>                       
   <owl:Literal>Represents the set of all people.</owl:Literal>
 </owl:AnnotationAssertion>

7.2 Ontology Management

In OWL, general information about a topic is almost always gathered into an ontology that is then used by various applications. We can also provide a name for OWL ontologies, which is generally the place where the ontology document is located in the web. Particular information about a topic can also be placed in an ontology, if it is used by different applications.

 Ontology(<http://example.com/owl/families>
 ...
 )

 <rdf:RDF ...>
 <owl:Ontology rdf:about="http://example.com/owl/families"/>
 ...
 </rdf:RDF>

 <http://example.com/owl/families> rdf:type owl:Ontology ;

 Ontology: <http://example.com/owl/families>

 <Ontology ...
 URI="http://example.com/owl/families">
 ...
 </Ontology>

We place OWL ontologies into OWL documents, which are then placed into local filesystems or on the World Wide Web. Aside from containing an OWL ontology, OWL documents also contain information about transforming the short names normally used in OWL ontologies (e.g., Person) into IRIs, by providing the expansion for prefixes. The IRI is then the concatention of the prefix expansion and the reference.

7.3 Entity Declarations

To help with managing ontologies, OWL has the notion of declarations. The basic idea is that each class, property, or individual is supposed to be declared in an ontology, and then it can be used in that ontology and ontologies that import that ontology.

In the Manchester syntax, declarations are implicit. Constructs that provide information about a class, property, or individual implicitly declare that class, property, or individual if needed. The other syntaxes have explicit declarations.

 MISSING.

 MISSING.

 MISSING.

 Declaration(Individual(John))
 Declaration(Class(Person))
 Declaration(ObjectProperty(hasWife))
 Declaration(DataProperty(hasAge))

 <Declaration>
     <Individual IRI="&f;John"/>
 </Declaration>
 
 <Declaration>
     <Class IRI="&f;Person"/>
 </Declaration>
 
 <Declaration>
     <ObjectProperty IRI="&f;hasWife"/>
 </Declaration>
 
 <Declaration>
     <DataProperty IRI="&f;hasAge"/>
 </Declaration>

However, an IRI may denote different entity-types (e.g. both an individual and a class) at the same time. This possibility, called "punning", has been introduced to allow for a certain amount of metamodeling. Still, OWL 2 does require some discipline in using and reusing names. To allow a more readable syntax, and for other technical reasons, OWL 2 DL requires that a name is not used for more than one property type (object, datatype or annotation property) nor can an IRI denote both a class and a datatype. Moreover, "built-in" names (such as those used by RDF and RDFS and various syntaxes of OWL) cannot be freely used in OWL.

8 OWL 2 DL and OWL 2 Full

9 OWL 2 Profiles

9.1 OWL 2 EL

OWL 2 EL is a profile of OWL 2 very closely related to the description logic EL++ and basic reasoning problems for it can be performed in time that is polynomial with respect to the size of the ontology. Working with OWL 2 EL is fairly similar to working with OWL 2 DL: one can use class expressions on both sides of a subClassStatement and even infer such relations. For many class expression oriented ontologies, OWL 2 EL makes a good approximation target, that is, by only a little simplification one can get an OWL 2 EL ontology and preserve much of the meaning of the original ontology.

OWL 2 EL is very robust computationally and reasonably easy to implement. Not only does it scale well for facts and axioms, but it scales well for complex expressions.

OWL 2 EL is designed with large biohealth ontologies in mind, such as SNOMED-CT, the NCI thesaurus, and Galen. Common characteristics of such ontologies include complex structural descriptions (e.g., defining certain body parts in terms of what parts they contain and are contained in or propagating diseases along part-subpart relations), huge numbers of classes, the heavy use of classification to manage the terminology, and the application of the resulting terminology to vast amounts of data. Thus, OWL 2 EL has a comparatively expressive class expression language and it has no restrictions on how they may be used in axioms. It also has fairly expressive property expressions, including property chains but excluding inverse.

Sensible use of OWL 2 EL is obviously not restricted to the biohealth domain: as with the other profiles of OWL, OWL 2 EL is domain independent. However, OWL 2 EL shines when your domain and your application require recognition of structurally complex objects. Such domains include system configuration, product inventories, and many scientific domains.

Besides negation and disjunction, OWL 2 EL also disallows universal quantification on properties. Therefore propositions like "all children of a rich person are rich" cannot be stated. Moreover, as all kinds of role inverses are not available, there is no way of specifying that, say, parentOf and childOf are inverses of each other.

The following is an example which uses some of the typical modelling features available in OWL 2 EL.

 SubClassOf(
   f:Father 
   IntersectionOf( f:Man f:Parent )
   )
 
 EquivalentClass(
   f:Parent 
   SomeValuesFrom(
     f:hasChild 
     f:Person
     )
   )
 
 EquivalentClasses( 
   f:NarcisticPerson 
   HasSelf( f:loves ) 
   )
 
 DisjointClasses( 
   f:Mother 
   f:Father 
   f:YoungChild 
   )
 
 SubPropertyOf( 
   PropertyChain( f:hasFather f:hasBrother ) 
   f:hasUncle 
   )
 
 NegativePropertyAssertion( 
   f:hasDaughter 
   f:Bill 
   f:Susan 
   )

 <owl:Class rdf:about="#Father">
   <rdfs:subClassOf>
     <owl:Class>
       <owl:intersectionOf rdf:parseType="Collection">
         <owl:Class rdf:about="#Man"/>
         <owl:Class rdf:about="#Parent"/>
       </owl:intersectionOf>
     </owl:Class>
   </rdfs:subClassOf>
 </owl:Class>
 
 <owl:Class rdf:about="#Parent">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#hasChild"/>
       <owl:someValuesFrom rdf:resource="#Person"/>
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>
 
 <owl:Class rdf:about="#NarcisticPerson">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty rdf:resource="#loves"/>
       <owl:hasSelf rdf:datatype="&xsd;boolean">
         true
       </owl:hasSelf>
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>
 
 <owl:AllDisjointClasses>
   <owl:members rdf:parseType="Collection">
     <owl:Class rdf:about="#Mother"/>
     <owl:Class rdf:about="#Father"/>
     <owl:Class rdf:about="#YoungChild"/>
   </owl:members>
 </owl:AllDisjointClasses>
 
 <rdf:Description>
   <owl:propertyChain rdf:parseType="Collection">
     <owl:ObjectProperty rdf:resource="#hasFather"/>
     <owl:ObjectProperty rdf:about="#hasBrother"/>
   </owl:propertyChain>
   <rdfs:subPropertyOf rdf:resource="#hasUncle"/>
 </rdf:Description>
 
 <owl:NegativePropertyAssertion>
   <owl:sourceIndividual rdf:about="#Bill">
   <owl:assertionProperty rdf:about="#hasDaughter">
   <owl:targetIndividual rdf:about="#Susan">
 </owl:NegativePropertyAssertion>

 f:Father rdfs:subClassOf     _:x1 .
 _:x1     rdf:type            owl:Class ;
          owl:intersectionOf  ( f:Man f:Parent ) .
 
 f:Parent owl:equivalentClass _:x2 .
 _:x2     rdf:type            owl:Restriction ;
          owl:onProperty      f:hasChild ;
          owl:someValuesFrom  f:Person .
 
 f:NarcisticPerson owl:equivalentClass _:x3 .
 _:x3              rdf:type            owl:Restriction ;
                   owl:onProperty      f:loves ;
                   owl:hasSelf         "true"^^xsd:boolean .
 
 _:x4 rdf:type    owl:AllDisjointClasses ;
      owl:members ( f:Mother f:Father f:YoungChild ).
 
 _:x5 rdfs:subPropertyOf f:hasUncle ;
      owl:propertyChain  ( f:hasFather f:hasBrother ) .
 
 _:x6 rdf:type              owl:NegativePropertyAssertion ;
      owl:sourceIndividual  f:Bill ;
      owl:assertionProperty f:hasDaughter ;
      owl:targetIndividual  f:Susan .

 Class: Father
   SubClassOf: Man and Parent
 
 Class: Parent
   EquivalentTo: hasChild some Person
 
 Class: NarcisticPerson
   EquivalentTo: loves Self
 
 DisjointClasses: Mother Father YoungChild
 
 ObjectProperty: hasUncle
   SubPropertyChain: hasFather o hasBrother
 
 Individual: Bill
   Facts: not hasDaughter Susan

 <owl:SubClassOf>
   <owl:Class IRI="&f;Father"/>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Man"/>
     <owl:Class IRI="&f;Parent"/>
   </owl:ObjectIntersectionOf>
 </owl:SubClassOf>
 
 <owl:EquivalentClasses>
   <owl:Class IRI="&f;Parent"/>
   <owl:ObjectSomeValuesFrom>
     <owl:ObjectProperty IRI="&f;hasChild"/>
     <owl:Class IRI="&f;Person"/>
   </owl:ObjectSomeValuesFrom>
 </owl:EquivalentClasses>
 
 <owl:EquivalentClasses>
   <owl:Class IRI="&f;NarcisticPerson"/>
   <owl:ObjectHasSelf>
     <owl:ObjectProperty IRI="&f;loves"/>
   </owl:ObjectHasSelf>
 </owl:EquivalentClasses>
 
 <owl:DisjointClasses>
     <owl:Class IRI="&f;Father"/>
     <owl:Class IRI="&f;Mother"/>
     <owl:Class IRI="&f;YoungChild"/>
 </owl:DisjointClasses>
 
 <owl:SubObjectPropertyOf>
   <owl:PropertyChain>
     <owl:ObjectProperty IRI="&f;hasFather"/>
     <owl:ObjectProperty IRI="&f;hasBrother"/>
   </owl:PropertyChain>
   <owl:ObjectProperty IRI="&f;hasUncle"/>
 </owl:SubObjectPropertyOf>
 
 <owl:NegativeObjectPropertyAssertion>
   <owl:ObjectProperty IRI="&f;hasDaughter"/>
   <owl:NamedIndividual IRI="&f;Bill"/>
   <owl:NamedIndividual IRI="&f;Susan"/>
 </owl:NegativeObjectPropertyAssertion>

9.2 OWL 2 QL

OWL 2 QL is inspired by one of the variants of the description logic DL Lite, which emerged from research on database integration. Implementationally, it can be realized on top of standard relational database technology (e.g., SQL) simply by expanding queries in the light of class axioms. This means it can be tightly integrated with RDBMSs and benefit from their robust implementations and multi-user features. Furthermore, it can be implemented without having to "touch the data", so really as a translational/preprocessing layer. Expressively, it can represent key features of Entity-relationship and UML diagrams (at least those with functional restrictions). Thus, it is suitable both for representing database schemas and for integrating them via query rewriting. As a result, it can also be used directly as a high level database schema language, though users may prefer a diagram based syntax.

OWL 2 QL also captures many commonly used features in RDFS and small extensions thereof, such as inverse properties and subproperty hierarchies. OWL 2 QL restricts class axioms asymmetrically, that is, you can use constructs as the subclass that you cannot use as the superclass.

Among other constructs, OWL 2 QL disallows existential quantification of roles to a class expression, i.e. it can be stated that every person has a parent but not that every person has a female parent. Moreover property chain axioms are not supported.

The following is an example which uses some of the typical modelling features available in OWL 2 QL. The first axiom states that every childless person is a person for which there does not exist another person which has the first person as parent.

 SubClassOf( 
   f:ChildlessPerson 
   IntersectionOf(
     f:Person 
     ComplementOf(
       SomeValuesFrom(
         InverseOf( f:hasParent )
         f:Person
         )
       )
     )
   ) 
 
 DisjointClasses( 
  f:Mother 
  f:Father
  f:YoungChild 
  )
 
 DisjointProperties( 
   f:hasSon 
   f:hasDaughter 
   )
 
 SubObjectPropertyOf( 
   f:hasFather 
   f:hasParent
   )

 <owl:Class rdf:about="#ChildlessPerson">
   <rdfs:subClassOf>
     <owl:Class>
       <owl:intersectionOf rdf:parseType="Collection">
         <owl:Class rdf:about="#Person"/>
         <owl:Class>
           <owl:complementOf>
             <owl:Restriction>
               <owl:onProperty>
                 <owl:ObjectProperty>
                   <owl:inverseOf rdf:resource="#hasParent"/>
                 </owl:ObjectProperty>
               </owl:onProperty>
               <owl:someValuesFrom rdf:resource="#Person"/>
             </owl:Restriction>
           </owl:complementOf>
         </owl:Class>
       </owl:intersectionOf>
     </owl:Class>
   </rdfs:subClassOf>
 </owl:Class>
 
 <owl:AllDisjointClasses>
   <owl:members rdf:parseType="Collection">
     <owl:Class rdf:about="#Mother"/>
     <owl:Class rdf:about="#Father"/>
     <owl:Class rdf:about="#YoungChild"/>
   </owl:members>
 </owl:AllDisjointClasses>
 
 <owl:ObjectProperty rdf:about="#hasSon">
   <owl:propertyDisjointWith rdf:resource="#hasDaughter"/>
 </owl:ObjectProperty>
 
 <owl:ObjectProperty rdf:about="#hasFather">
   <rdfs:subPropertyOf rdf:resource="#hasParent"/>
 </owl:ObjectProperty>

 f:ChildlessPerson owl:subClassOf       _:x1 .
 _:x1              rdf:type            owl:Class ;
                   owl:intersectionOf  ( f:Person _:x2 ) .
 _:x2              owl:complementOf    _:x3 .
 _:x3              rdf:type            owl:Restriction ;
                   owl:onProperty      _:x4 ;
                   owl:someValuesFrom  f:Person .
 _:x4              owl:inverseOf       f:hasParent .
 
 _:x5 rdf:type     owl:AllDisjointClasses ;
      owl:members  ( f:Mother f:Father f:YoungChild ) .
 
 f:hasSon owl:propertyDisjointWith f:hasDaughter.
 
 f:hasFather rdfs:subPropertyOf f:hasParent.

 Class: ChildlessPerson
   SubClassOf: Person and not inverse hasParent some Person
 
 DisjointClasses: Mother Father YoungChild
 
 DisjointProperties: hasSon hasDaughter
 
 ObjectProperty: hasFather
   SubPropertyOf: hasParent

 <owl:SubClassOf>
   <owl:Class IRI="&f;ChildlessPerson"/>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Person"/>
     <owl:ObjectComplementOf>
       <owl:ObjectSomeValuesFrom>
         <owl:InverseObjectProperty>
           <owl:ObjectPropertyIRI="&f;hasParent"/>
         </owl:InverseObjectProperty>
         <owl:Class IRI="&f;Person"/>
       </owl:ObjectSomeValuesFrom>
     </owl:ObjectComplementOf>
   </owl:ObjectIntersectionOf>
 </owl:SubClassOf>
 
 <owl:DisjointClasses>
     <owl:Class IRI="&f;Father"/>
     <owl:Class IRI="&f;Mother"/>
     <owl:Class IRI="&f;YoungChild"/>
 </owl:DisjointClasses>
 
 <owl:DisjointObjectProperties>
   <owl:ObjectProperty IRI="&f;hasSon"/>
   <owl:ObjectProperty IRI="&f;hasDaughter"/>
 </owl:DisjointObjectProperties>
 
 <owl:SubObjectPropertyOf>
   <owl:ObjectProperty IRI="&f;hasFather"/>
   <owl:ObjectProperty IRI="&f;hasParent"/>
 </owl:SubObjectPropertyOf>

9.3 OWL 2 RL

The OWL 2 RL profile is aimed at applications that require scalable reasoning without sacrificing too much expressive power. It is designed to accommodate both OWL 2 applications that can trade the full expressivity of the language for efficiency, and RDF(S) applications that need some added expressivity from OWL 2. This is achieved by defining a syntactic subset of OWL 2 which is amenable to implementation using rule-based technologies, and presenting a partial axiomatization of the OWL 2 RDF-Based Semantics in the form of first-order implications that can be used as the basis for such an implementation. The design of OWL 2 RL has been inspired by Description Logic Programs [DLP] and pD* [pD*].

Suitable rule-based implementations of OWL 2 RL will have desirable computational properties; for example, they can return all and only the correct answers to certain kinds of queries. Such an implementation can also be used with arbitrary RDF graphs. (In this case, however, these properties no longer hold — in particular, it is no longer possible to guarantee that all correct answers can be returned.)

As a consequence, OWL 2 RL is ideal for enriching RDF data, especially when the data must be massaged by additional rules. From a modeling perspective, however, this pushes us farther away from working with class expressions: OWL 2 RL ensures we cannot (easily) talk about unknown individuals in our superclass expressions (this restriction follows from the nature of rules). Compared with OWL 2 QL, OWL 2 RL works better when you have already massaged your data into RDF and are working with it as RDF.

One downside of OWL 2 RL is that it cannot express that the existence of an individual enforces the existence of another individual: for instance, the statement "every person has a parent" is not expressible in OWL RL.

OWL 2 RL restricts class axioms asymmetrically, that is, you can use constructs as the subclass that you cannot use as the superclass. The following is an example which uses some of the typical modelling features available in OWL 2 RL. The first - somewhat contrived - axiom states that for each of Mary, Bill, and Meg who is female, the following holds: she is a parent with at most one child, and all her children (if she has any) are female.

 SubClassOf(
   IntersectionOf(
     OneOf( f:Mary f:Bill f:Meg )
     f:Female
     )
   IntersectionOf(
     f:Parent
     MaxCardinality( 1 f:hasChild )
     AllValuesFrom( f:hasChild f:Female )
     )
   )
 
 DisjointClasses( 
   f:Mother 
   f:Father 
   f:YoungChild 
   )
 
 SubPropertyOf( 
   PropertyChain( f:hasFather f:hasBrother ) 
   f:hasUncle 
   )

 <owl:Class>
   <owl:intersectionOf rdf:parseType="Collection">
     <owl:Class>
       <owl:oneOf rdf:parseType="Collection">
         <rdf:Description rdf:about="#Mary"/>
         <rdf:Description rdf:about="#Bill"/>
         <rdf:Description rdf:about="#Meg"/>
       </owl:oneOf>
     </owl:Class>
     <owl:Class rdf:about="#Female"/>
   </owl:intersectionOf>
   <rdfs:subClassOf>
     <owl:Class>
       <owl:intersectionOf rdf:parseType="Collection">
         <owl:Class rdf:about="#Parent"/>
         <owl:Restriction>
           <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">
             2
           </owl:maxCardinality>
           <owl:onProperty rdf:resource="#hasChild"/>
         </owl:Restriction>
         <owl:Restriction>
           <owl:onProperty rdf:resource="#hasChild"/>
           <owl:allValuesFrom rdf:resource="#Female"/>
         </owl:Restriction>
       </owl:intersectionOf>
     </owl:Class>
   </rdfs:subClassOf>
 </owl:Class>
 
 <owl:AllDisjointClasses>
   <owl:members rdf:parseType="Collection">
     <owl:Class rdf:about="#Mother"/>
     <owl:Class rdf:about="#Father"/>
     <owl:Class rdf:about="#YoungChild"/>
   </owl:members>
 </owl:AllDisjointClasses>
 
 <rdf:Description>
   <owl:propertyChain rdf:parseType="Collection">
     <owl:ObjectProperty rdf:resource="#hasFather"/>
     <owl:ObjectProperty rdf:about="#hasBrother"/>
   </owl:propertyChain>
   <rdfs:subPropertyOf rdf:resource="#hasUncle"/>
 </rdf:Description>

 _:x1 rdfs:subClassOf    _:x2 .
 _:x1 rdf:type           owl:Class :
      owl:intersectionOf ( _:x3 f:Female ) .
 _:x3 rdf:type           owl:Class ;
      owl:oneOf          ( f:Mary f:Bill f:Meg ) .
 _:x2 rdf:type           owl:Class ;
      owl:intersectionOf ( f:Parent _:x4 _:x5 ) .
 _:x4 rdf:type           owl:Restriction ;
      owl:maxCardinality "1"^^xsd:nonNegativeInteger ;
      owl:onProperty     f:hasChild .
 _:x5 rdf:type           owl:Restriction ;
      owl:onProperty     f:hasChild ;
      owl:allValuesFrom  f:Female .
 
 _:x6 rdf:type    owl:AllDisjointClasses ;
      owl:members ( f:Mother f:Father f:YoungChild ) .
 
 _:x7 rdfs:subPropertyOf f:hasUncle ;
      owl:propertyChain  ( f:hasFather f:hasBrother ) .

 Class: X
   SubClassOf: Parent and hasChild max 1 and hasChild only Female
 Class: X
   EquivalentTo: {Mary Bill Meg} and Female
 
 DisjointClasses: Mother Father YoungChild
 
 ObjectProperty: hasUncle
   SubPropertyChain: hasFather o hasBrother

 <owl:SubClassOf>
   <owl:ObjectIntersectionOf>
     <owl:ObjectOneOf>
       <owl:NamedIndividual IRI="&f;Mary"/>
       <owl:NamedIndividual IRI="&f;Bill"/>
       <owl:NamedIndividual IRI="&f;Meg"/>
     </owl:ObjectOneOf>
     <owl:Class IRI="&f;Female"/>
   </owl:ObjectIntersectionOf>
   <owl:ObjectIntersectionOf>
     <owl:Class IRI="&f;Parent"/>
     <owl:ObjectMaxCardinality cardinality="1">
       <owl:ObjectProperty IRI="&f;hasChild"/>
     </owl:ObjectMaxCardinality>
     <owl:ObjectAllValuesFrom>
       <owl:ObjectProperty IRI="&f;hasChild"/>
       <owl:Class IRI="&f;Female"/>
     </owl:ObjectAllValuesFrom>
   </owl:ObjectIntersectionOf>
 </owl:SubClassOf>
 
 <owl:DisjointClasses>
     <owl:Class IRI="&f;Father"/>
     <owl:Class IRI="&f;Mother"/>
     <owl:Class IRI="&f;YoungChild"/>
 </owl:DisjointClasses>
 
 <owl:SubObjectPropertyOf>
   <owl:PropertyChain>
     <owl:ObjectProperty IRI="&f;hasFather"/>
     <owl:ObjectProperty IRI="&f;hasBrother"/>
   </owl:PropertyChain>
   <owl:ObjectProperty IRI="&f;hasUncle"/>
 </owl:SubObjectPropertyOf>

10 OWL Tools

11 What To Read Next

This short primer can only scratch the surface of OWL. There are many longer and more involved tutorials on OWL and how to use OWL tools that can be found by searching on the Web. Reading one of these primers and using a tool to build an OWL ontology is probably the best way to learn more about OWL.

12 Appendices

12.1 How OWL 2 relates to other technologies

OWL is a language for expressing ontologies. The term ontology has a complex history both in and out of computer science, but we use it to mean a certain kind of computational artifact -- i.e., something akin to a program, an XML schema, or a web page -- generally presented as a document. An ontology is a set of descriptive statements about some part of the world (usually referred to as the domain or the subject matter of the ontology).

The descriptive nature of OWL is worth emphasizing: Unlike schema languages or object-oriented programming languages, OWL is not particularly prescriptive. For example, a primary task of an XML Schema is prescribing what elements can occur as children of other elements. Typically, a schema is used to validate that a document conforms to the restrictions expressed in the schema. Similarly, an XML Schema is, to a first approximation, about XML documents. That is, the basic XML Schema perspective is that there are elements, attributes, namespaces, and other features of XML and a Schema describes the permitted ways to use such features in a document or data format. In contrast, the basic OWL perspective is that there are things (in a broad sense of the term) that are related to other things and may be grouped into sets of things according to their commonality. Whether these things are physical objects or data items depends on the intent of the modeler. Of course, it is perfectly possible to use XML Schema to describe the "Tree Mark Up" (TML) language and use TML to record information about trees. But there is a level of indirection in this use of XML Schema. The XML Schema for TML is (most directly) a model of a set of XML documents (which themselves are intended to represent trees). An OWL ontology about trees is most directly a model of a set of things (in this case trees), their relations, and their categorizations.

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.

12.1.1 RDF(S)

Of the technologies discussed in this section, the Resource Description Framework (RDF) and the RDF Schema (RDFS) Language (collectively referred to as RDF(S)) is the closest to OWL. RDF(S) has roots in logic based knowledge representation; in many ways, RDF(S) can be seen as a subset of OWL; and, perhaps most prominently, the primary exchange syntax for OWL has been 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 facts (triples), viewing most OWL statements and expressions as collections of facts is not typically a fruitful way of writing or understanding them. Similarly, it is fairly common and effective to work with RDF as a graph data structure or 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.

12.1.2 SPARQL

12.1.3 XML

12.1.4 Databases

Databases (either relational or object-oriented) also store and organize information. 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.

12.1.5 Object-oriented Programming

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.

OWL is used in a number of different ways and for a number of different domains -- far too many to enumerate here. But it's worth examining a few examples to get a feel for the sorts of problem OWL has worked well for.

Using all of the expressive power of OWL, effectively, requires a fair bit of skill.

12.2 The Complete Sample Ontology

Here we include the complete sample OWL ontology. The ontology here is ordered in a commonly-used ordering, with ontology information first, followed by information about properties, then classes, then individuals.

13 Acknowledgments

• Michel Dumontier
• Henson Graves
• Rinke Hoekstra
• Doug Lenat
• Alan Rector
• Deborah McGuinness
• Uli Sattler
• Michael Schneider

14 References