OWL 2 Web Ontology Language
Primer

1 Introduction

1.1 Guide to this Document

1.2 OWL Syntaxes

2 What is OWL 2?

OWL 2 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 precise descriptive statements about some part of the world (usually referred to as the domain of interest or the subject matter of the ontology). Precise descriptions satisfy several purposes: most notably, they prevent misunderstandings in human communication and they ensure that software behaves in a uniform, predictable way and works well with other software.

In order to precisely describe a domain of interest, it is helpful to come up with a set of central terms – often called vocabulary – and fix their meaning. Besides a concise natural language definition, the meaning of a term can be characterisedcharacterized by stating how this term is interrelated to the other terms. A terminology, providing a vocabulary together with such interrelation information constitutes an essential part of a typical OWL 2 document. Besides this terminological knowledge, an ontology might also contain so called assertional knowledge that deals with concrete objects of the considered domain rather than general notions.

3 ModellingModeling 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 thereal-world objects
• that are modelledExpressions: 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 ratherbe considered as a powerful general-purpose modellingmodeling language for certain parts of human knowledge. The modelling artefacts created in OWLresults of the modeling processes 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 2OWL 2 ontology is – from an abstract viewpoint –essentially just a collection of axioms. It is characteristic forsuch basic “pieces of knowledge.” Statements that are made in an ontology are called axioms in OWL 2, and the ontology asserts that they can be said toits axioms are true. In general, OWL statements might be either true or false given a certain state of affairs. This distinguishes axiomsthem from entities and expressions that areas 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 axiomsstatements A entails an axioma statement a if in any state of affairs wherein all axiomsstatements from A are true, also a is true. Moreover, a set of axiomsstatements may be consistent (that is, there is a possible state of affairs in which all the axiomsstatements 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 set of OWL ontologystatements is true.

There are OWL tools – reasoners – that can automatically compute consequences. The way ontological axioms interact can be very subtle and difficult for people to understand. This is both a strength and a weakness of OWL 2.OWL 2. It is a strength because OWL 2OWL 2 tools 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.modeling. 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,statements in OWL, 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,statements, be they objects (John, Mary), categories (female) or relations (married) are called entities. In OWL 2,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 vary 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.

Editor's Note: The following could be marked (via smaller font size or indentation) in some way as additional explanation which can be skipped. 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 to be 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 ).4 Classes, Properties, and Individuals – And Basic ModellingModeling With Them

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

4.1 Classes and Instances SupposeThereby we want towill represent information about a particular family. (WeNote that 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 culturally dependent domain of families. Instead, we intend it to be a rather simple exhibition of various features of OWL.)OWL.

4.1 Classes and Instances

We first need to providestart by introducing the information whatpersons we are talking about. This can be done as follows:

 ClassAssertion( :Person :Mary ) 

 <Person rdf:about="Mary"/>

 :Mary rdf:type :Person .

 Individual: Mary
   Types: Person

 <ClassAssertion>
    <Class IRI="Person"/>
    <NamedIndividual IRI="Mary"/>
 </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. Hence, classes essentially represent sets of individuals. In modeling, classes are often used to denote the set of objects comprised by a concept of human thinking, like the concept person or the concept woman. 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( :Woman :Mary ) 

 <Woman rdf:about="Mary"/>

 :Mary rdf:type :Woman .

 Individual: Mary
   Types: Woman

 <ClassAssertion>
    <Class IRI="Woman"/>
    <NamedIndividual IRI="Mary"/>
 </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.

4.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, itthat individual must be a person. However, this correspondencycorrespondence 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.correspondence. In OWL 2, this is done by a so-called subclass axiom:

 SubClassOf( :Woman :Person )

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

 :Woman rdfs:subClassOf :Person .

 Class: Woman
   SubClassOf: Person

 <SubClassOf>
   <Class IRI="Woman"/>
   <Class IRI="Person"/>
 </SubClassOf>

The presence of this axiom in an ontology enables reasoners to infer for every individual thatwhich is specified as an instance of the class Woman, that it 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 modellingmodeling 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( :Mother :Woman )

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

 :Mother rdfs:subClassOf :Woman .

 Class: Mother
   SubClassOf: Woman

 <SubClassOf>
   <Class IRI="Mother"/>
   <Class IRI="Woman"/>
 </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.

TwoClasses can also be saidin our vocabulary may effectively refer to the same sets, and OWL provides a mechanism by which to they are considered to be equivalent insemantically equivalent. For example, we use the senseterm Person and Human interchangeably, meaning that every instance of the class Person is also an instance of class Human, and vice versa. Two classes are considered equivalent if they contain exactly the same individuals. The following example states that the class Person is equivalent to the class Human.

 EquivalentClasses( :Person :Human )

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

 :Person owl:equivalentClass :Human .

 Class: Person
   EquivalentTo: Human

 <EquivalentClasses>
   <Class IRI="Person"/>
   <Class IRI="Human"/>
 </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.

4.3 Class Disjointness

In Section 4.3,4.1, we stated that an individual can be an instance of several classes. HoweverHowever, in some cases membership in one class specifically excludes membership in another. For example, 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( :Woman :Man )

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

 []  rdf:type     owl:AllDisjointClasses ;
     owl:members  ( :Woman  :Man ) . 

 DisjointClasses: Woman Man

 <DisjointClasses>
     <Class IRI="Woman"/>
     <Class IRI="Man"/>
 </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.

4.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. ObviouslyThese relationships are central when describing a family. We start by indicating that Mary is John's wife.

 ObjectPropertyAssertion( :hasWife :John :Mary )

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

 :John :hasWife :Mary .

 Individual: John
   Facts: hasWife Mary

 <ObjectPropertyAssertion>
   <ObjectProperty IRI="hasWife"/>
   <NamedIndividual IRI="John"/>
   <NamedIndividual IRI="Mary"/>
 </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 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 useerrors that can be avoided by using 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'sBill's wife.

 NegativeObjectPropertyAssertion( :hasWife :Bill :Mary )

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

 []  rdf:type               owl:NegativePropertyAssertion ;
     owl:sourceIndividual    :Jack ; :Bill ;
     owl:assertionProperty  :hasWife ;
     owl:targetIndividual   :Mary .

 Individual:  JackBill
   Facts: not hasWife Mary

 <NegativeObjectPropertyAssertion>
   <ObjectProperty IRI="hasWife"/>
   <NamedIndividual  IRI="Jack"/>IRI="Bill"/>
   <NamedIndividual IRI="Mary"/>
 </NegativeObjectPropertyAssertion>

Negative property assertions provide a unique opportunity to make statements where we know something that is not true. This kind of information is particularly important in OWL where the default stance is that anything is possible until you say otherwise.

4.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:

 SubObjectPropertyOf( :hasWife :hasSpouse )

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

 :hasWife rdfs:subPropertyOf :hasSpouse .

 ObjectProperty: hasWife
   SubPropertyOf: hasSpouse

 <SubObjectPropertyOf>
   <ObjectProperty IRI="hasWife"/>
   <ObjectProperty IRI="hasSpouse"/>
 </SubObjectPropertyOf>

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

4.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 these individuals. In our example, this additional information can be expressed via class memberships. OWL provides a way to state this correspondence:

 ObjectPropertyDomain( :hasWife :Man ) 
 ObjectPropertyRange( :hasWife :Woman ) 

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

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

 ObjectProperty: hasWife
   Domain: Man
   Range: Woman

 <ObjectPropertyDomain>
   <ObjectProperty IRI="hasWife"/>
   <Class  Man"/>IRI="Man"/>
 </ObjectPropertyDomain>
 <ObjectPropertyRange>
   <ObjectProperty IRI="hasWife"/>
   <Class IRI="Woman"/>
 </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.

4.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 individual 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, then 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 lack of a required “unique names assumption” would beis particularly dangerous in thewell-suited to Semantic Web,Web applications 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( :John :Bill )

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

 :John owl:differentFrom :Bill .

 Individual: John 
   DifferentFrom: Bill 

 <DifferentIndividuals>
   <NamedIndividual IRI="John"/>
   <NamedIndividual IRI="Bill"/>
 </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( :James :Jim )

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

 :James owl:sameAs :Jim.

 Individual:  JohnJames
   SameAs:  JackJim

 <SameIndividual>
   <NamedIndividual  IRI="John"/>IRI="James"/>
   <NamedIndividual  IRI="Jack"/>IRI="Jim"/>
 </SameIndividual>

This would enable a reasoner to infer that any information given about the individual Jack which is written downJames also holds for the individual John.Jim.

4.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 torelate 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.

 DataPropertyAssertion( :hasAge :John "51"^^xsd:integer )

 <Person rdf:about="John">
   <hasAge rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">51</hasAge>
 </Person>

 :John  :hasAge  51 .

 Individual: John
   Facts: hasAge "51"^^xsd:integer

 <DataPropertyAssertion>
   <DataProperty IRI="hasAge"/>
   <NamedIndividual IRI="John"/>
   <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">51</Literal>
 </DataPropertyAssertion>

Likewise, we can state that Jack's age is not 53.

 NegativeDataPropertyAssertion( :hasAge :Jack "53"^^xsd:integer )

 <owl:NegativePropertyAssertion>
   <owl:sourceIndividual rdf:about="Jack"/>
   <owl:assertionProperty rdf:about="hasAge"/>
   <owl:targetValue rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">
     53
   </owl:targetValue>
 </owl:NegativePropertyAssertion>

 []  rdf:type               owl:NegativePropertyAssertion ;
     owl:sourceIndividual   :Jack ;
     owl:assertionProperty  :hasAge ;
     owl:targetValue        53 .

 Individual: Jack
   Facts: not hasAge "53"^^xsd:integer

 <NegativeDataPropertyAssertion>
   <DataProperty IRI="hasAge"/>
   <NamedIndividual IRI="Jack"/>
   <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">53</Literal>
 </NegativeDataPropertyAssertion>

Domain and range can also be stated for datatype properties as it is done for object properties. In that case, however, the range will be a datatype instead of a class. The following states that the hasAge property is only used to relate persons with non-negative integers.

 DataPropertyDomain( :hasAge :Person ) 
 DataPropertyRange( :hasAge xsd:NonNegativeInteger ) 

 <owl:DatatypeProperty rdf:about="hasAge">
   <rdfs:domain rdf:resource="Person"/>
   <rdfs:range rdf:datatpye="http://www.w3.org/2001/XMLSchema#NonNegativeInteger"/>
 </owl:DatatypeProperty>

 :hasAge  rdfs:domain  :Person ;
          rdfs:range   xsd:NonNegativeInteger .

 DatatpyeProperty: hasAge
   Domain: Person
   Range:  xsd:NonNegativeInteger

 <DatatypePropertyDomain>
   <DatatypeProperty IRI="hasAge"/>
   <Class IRI="Person"/>
 </DatatypePropertyDomain>
 <DatatypePropertyRange>
   <DatatypeProperty IRI="hasAge"/>
   <Datatype IRI="http://www.w3.org/2001/XMLSchema#NonNegativeInteger"/>
 </DatatypePropertyRange>

We would like to point out at this stage a common mistake which easily occurs when using property domains and ranges. In the example just given, which states that the hasAge property is only used to relate persons with non-negative integers, assume that we also specify the information that Felix is in the class Cat and that Felix hasAge 9. From the combined information, it would then be possible to deduce that Felix is also in the class Person, which is probably not intended. This is a commonly modellingmodeling error: note that a domain (or range) statement is not a constraint on the knowledge, but allows a reasoner to infer further knowledge. If we state – as in our example – that an age is only given for persons, then everything we give an age for automatically becomes a person.

5 Advanced Class Relationships

In the previous sections we have dealt with classes as something “opaque” carrying a name. We used them to characterize individuals, and 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.

5.1 Complex Classes

By means of the language elements described so far allow to modelfar, simple ontologies. But their expressivity hardly surpasses that of RDFS.ontologies can be modeled. 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 tocombine atomic classes – i.e. classes with names – to complex classes.

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(
   :Mother 
   ObjectIntersectionOf( :Woman :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>

 :Mother  owl:equivalentClass  [
   rdf:type            owl:Class ;
   owl:intersectionOf  ( :Woman :Parent ) 
 ] .

 Class: Mother
   EquivalentTo: Woman and Parent

 <EquivalentClasses>
   <Class IRI="Mother"/>
   <ObjectIntersectionOf>
     <Class IRI="Woman"/>
     <Class IRI="Parent"/>
   </ObjectIntersectionOf>
 </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 at least one of these classes. Therefore we could characterize the class of all parents as the union of the classes Mother and Father:

 EquivalentClasses(
   :Parent 
   ObjectUnionOf( :Mother :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>

 :Parent  owl:equivalentClass  [
   rdf:type     owl:Class ;
   owl:unionOf  ( :Mother :Father )
 ] .

 Class: Parent
   EquivalentTo: Mother or Father

 <EquivalentClasses>
   <Class IRI="Parent"/>
   <ObjectUnionOf>
     <Class IRI="Mother"/>
     <Class IRI="Father"/>
   </ObjectUnionOf>
 </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 also demonstrates that class constructors can be nested:

 EquivalentClasses(
   :ChildlessPerson 
   ObjectIntersectionOf(
     :Person 
     ObjectComplementOf( :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>

 :ChildlessPerson  owl:equivalentClass  [
   rdf:type            owl:Class ;
   owl:intersectionOf  ( :Person  [ owl:complementOf  :Parent ] ) 
 ] .

 Class: ChildlessPerson
   EquivalentTo: Person and not Parent

 <EquivalentClasses>
   <Class IRI="ChildlessPerson"/>
   <ObjectIntersectionOf>
     <Class IRI="Person"/>
     <ObjectComplementOf>
       <Class IRI="Parent"/>
     </ObjectComplementOf>
   </ObjectIntersectionOf>
 </EquivalentClasses>

All the above examples demonstrate the usage of class constructors in order to define new classes as combination of 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 Grandfather is both a man and a parent (whereas the converse is not necessarily true):

 SubClassOf( 
   :Grandfather 
   ObjectIntersectionOf( :Man :Parent )
 )

 <owl:Class rdf:about="Grandfather">
   <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>

 :Grandfather  rdfs:subClassOf  [
   rdf:type            owl:Class ;
   owl:intersectionOf  ( :Man  :Parent )
 ] .

 Class: Grandfather
   SubClassOf: Man and Parent

 <SubClassOf>
   <Class IRI="Grandfather"/>
   <ObjectIntersectionOf>
     <Class IRI="Man"/>
     <Class IRI="Parent"/>
   </ObjectIntersectionOf>
 </SubClassOf>

In general, complex classes can be used in every place where named classes can occur, hence also in class assertions:assertions. This is demonstrated by the following example which asserts that John is a person but not a parent.

 ClassAssertion(
   ObjectIntersectionOf(
     :Person 
     ObjectComplementOf( :Parent )
   ) 
   :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>

 :John  rdf:type  [
   rdf:type            owl:Class ;
   owl:intersectionOf  ( :Person  
                         [ rdf:type          owl:Class ;
                           owl:complementOf  :Parent     ]
                       )
 ] .

 Individual: John
   Types: Person and not Parent

 <ClassAssertion>
   <ObjectIntersectionOf>
    <Class IRI="Person"/>
    <ObjectComplementOf>
      <Class IRI="Parent"/>
    </ObjectComplementOf>
   </ObjectIntersectionOf>
   <NamedIndividual IRI="John"/>
 </ClassAssertion>

5.2 Property Restrictions

ByProperty restrictions we understandprovide another type of logic-based constructors for complex classes. As the name suggests, property restrictions areuse constructors involving properties.

The firstOne 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(
   :Parent 
   ObjectSomeValuesFrom( :hasChild :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>

 :Parent  owl:equivalentClass  [
   rdf:type            owl:Restriction ;
   owl:onProperty      :hasChild ;
   owl:someValuesFrom  :Person
 ] .

 Class: Parent
   EquivalentTo: hasChild some Person

 <EquivalentClasses>
   <Class IRI="Parent"/>
   <ObjectSomeValuesFrom>
     <ObjectProperty IRI="hasChild"/>
     <Class IRI="Person"/>
   </ObjectSomeValuesFrom>
 </EquivalentClasses>

Another property restriction, called universal quantificationThis means that there is used to describe a class of individualsan expectation that for which all “property-successors” are instancesevery instance of a given class. We can use the following statement to indicateParent, there exists at least one child, and that a personchild is happya member of the class Person. This is useful to capture incomplete knowledge. For example, Sally tells us that Bob is a parent, and therefore we can infer that he has at least one child even if we don't know their name.

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

 EquivalentClasses(
   ObjectIntersectionOf( :Person :Happy ) ObjectAllValuesFrom( :hasChild :Happy :HappyPerson 
   ObjectAllValuesFrom( :hasChild :HappyPerson )
 )

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

 []  rdf:type             owl:Class ;
     owl:intersectionOf ( :Person  :Happy ) ; :HappyPerson ;
     owl:equivalentClass  [
       rdf:type           owl:Restriction ;
       owl:onProperty     :hasChild ;
       owl:allValuesFrom  :Happy
     ] .

 Class:  X EquivalentTo: Person and Happy Class: XHappyPerson
   EquivalentTo: hasChild  all Happyonly HappyPerson

 <EquivalentClasses>
    <ObjectIntersectionOf> <Class IRI="Person"/><Class  IRI="Happy"/> </ObjectIntersectionOf>IRI="HappyPerson"/>
   <ObjectAllValuesFrom>
     <ObjectProperty IRI="hasChild"/>
     <Class IRI="Happy"/>
   </ObjectAllValuesFrom>
 </EquivalentClasses>

This example also shows that OWL statements are allowed to by kind of self-referential; the class HappyPerson is used on both sides of the equivalence statement.

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 a “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:

  document doesn't tell how to handle this in fact.EquivalentClasses(
   ObjectIntersectionOf( :Person :Happy ) :HappyPerson 
   ObjectIntersectionOf(
      ObjectAllValuesFrom( :hasChild :HappyObjectAllValuesFrom( :hasChild :HappyPerson )
      ObjectSomeValuesFrom( :hasChild :HappyObjectSomeValuesFrom( :hasChild :HappyPerson )
   )
 )

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

 []  rdf:type             owl:Class ;
     owl:intersectionOf ( :Person  :Happy ) ; :HappyPerson ;
     owl:equivalentClass  [
       rdf:type            owl:Class ;
       owl:intersectionOf  ( [ rdf:type            owl:Restriction ;
                               owl:onProperty      :hasChild ;
                               owl:allValuesFrom   :Happy            ]
                             [ rdf:type            owl:Restriction ;
                               owl:onProperty      :hasChild ;
                               owl:someValuesFrom  :Happy            ]
                           )
     ] .

 Class:  X EquivalentTo: Person and Happy Class: XHappyPerson
   EquivalentTo: hasChild  all Happyonly HappyPerson and hasChild some  HappyHappyPerson

 <EquivalentClasses>
    <ObjectIntersectionOf> <Class IRI="Person"/><Class  IRI="Happy"/> </ObjectIntersectionOf>IRI="HappyPerson"/>
   <ObjectIntersectionOf>
     <ObjectAllValuesFrom>
       <ObjectProperty IRI="hasChild"/>
       <Class  IRI="Happy"/>IRI="HappyPerson"/>
     </ObjectAllValuesFrom>
     <ObjectSomeValuesFrom>
       <ObjectProperty IRI="hasChild"/>
       <Class  IRI="Happy"/>IRI="HappyPerson"/>
     </ObjectSomeValuesFrom>
   </ObjectIntersectionOf>
 </EquivalentClasses>

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

Moreover, we mightProperty restrictins can also be interested in describing a classused to describe classes of individuals that are related to one particular individual. For instance we could define the class of John's children:

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

 <owl:Class rdf:about="JohnsChildren">
   <owl:equivalentClass>
     <owl:Restriction>
       <owl:onProperty  rdf:resource="hasParent/>rdf:resource="hasParent"/>
       <owl:hasValue rdf:resource="John"/>
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>

 :JohnsChildren  owl:equivalentClass  [
   rdf:type        owl:Restriction ;
   owl:onProperty  :hasParent ;
   owl:hasValue    :John
 ] .

 Class: JohnsChildren
   EquivalentTo: hasParent value John

 <EquivalentClasses>
   <Class IRI="JohnsChildren"/>
   <ObjectHasValue>
     <ObjectProperty IRI="hasParent"/>
     <Class IRI="John"/>
   </ObjectHasValue>
 </EquivalentClasses>

As a special case of individuals being interlinked by properties, an individual might be linked to itself. Indeed, OWL providesThe possibilityfollowing example shows how to e.g. define the class NarcisticPerson asrepresent the class of individualsidea that are linked to themselves by a loves-property.all narcissists love themselves.

 EquivalentClasses(
   :NarcisticPerson 
   ObjectHasSelf( :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>

 :NarcisticPerson owl:equivalentClass  [
   rdf:type        owl:Restriction ;
   owl:onProperty  :loves ;
   owl:hasSelf     "true"^^xsd:boolean .
 ] .

 Class: NarcisticPerson
   EquivalentTo: loves Self

 <EquivalentClasses>
   <Class IRI="NarcisticPerson"/>
   <ObjectHasSelf>
     <ObjectProperty IRI="loves"/>
   </ObjectHasSelf>
 </EquivalentClasses>

5.3 Property Cardinality Restrictions

Using existential anduniversal and existential quantification, we can say something about all respectively at least one of somebody's children. In a similar way,However, we might want to specify the number of individuals involved in the restriction. Indeed, we can construct classes depending on the number of children. The following example states that John has at most four children who are themselves parents:

 ClassAssertion(
   ObjectMaxCardinality( 4 :hasChild :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>

 :John  rdf:type  [
   rdf:type                     owl:Restriction ;
   owl:maxQualifiedCardinality  "4"^^xsd:nonNegativeInteger ;
   owl:onProperty               :hasChild ;
   owl:onClass                  :Parent
 ] .

 Individual: John
   Types: hasChild max 4 Parent

 <ClassAssertion>
   <ObjectMaxCardinality cardinality="4">
     <ObjectProperty IRI="hasChild"/>
     <Class IRI="Parent"/>
   </ObjectMaxCardinality>
   <NamedIndividual IRI="John"/>
 </ClassAssertion>

Note that this statement allows John to have arbitrarily many further children whichwho 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 thatwho are parents:

 ClassAssertion(
   ObjectMinCardinality( 2 :hasChild :Parent ) 
   :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>

 :John  rdf:type  [
   rdf:type                     owl:Restriction ;
   owl:minQualifiedCardinality  "2"^^xsd:nonNegativeInteger ;
   owl:onProperty               :hasChild ;
   owl:onClass                  :Parent
 ] .

 Individual: John
   Types: hasChild min 2 Parent

 <ClassAssertion>
   <ObjectMinCardinality cardinality="2">
     <ObjectProperty IRI="hasChild"/>
     <Class IRI="Parent"/>
   </ObjectMinCardinality>
   <NamedIndividual IRI="John"/>
 </ClassAssertion>

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

 ClassAssertion( 
   ObjectExactCardinality( 3 :hasChild :Parent ) 
   :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>

 :John  rdf:type  [
   rdf:type                  owl:Restriction ;
   owl:qualifiedCardinality  "3"^^xsd:nonNegativeInteger ;
   owl:onProperty            :hasChild ;
   owl:onClass               :Parent
 ] .

 Individual: John
   Types: hasChild exactly 3 Parent

 <ClassAssertion>
   <ObjectExactCardinality cardinality="3">
     <ObjectProperty IRI="hasChild"/>
     <Class IRI="Parent"/>
   </ObjectExactCardinality>
   <NamedIndividual IRI="John"/>
 </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 write the following:

 ClassAssertion(
   ObjectExactCardinality( 5 :hasChild ) 
   :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>

 :John  rdf:type  [
   rdf:type         owl:Restriction ;
   owl:cardinality  "5"^^xsd:nonNegativeInteger ;
   owl:onProperty   :hasChild
 ] .

 Individual: John
   Types: hasChild exactly 5

 <ClassAssertion>
   <ObjectExactCardinality cardinality="5">
     <ObjectProperty IRI="hasChild"/>
   </ObjectExactCardinality>
   <NamedIndividual IRI="John"/>
 </ClassAssertion>

5.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(
   :MyBirthdayGuests
   ObjectOneOf( :Bill :John :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:Class>
   </owl:equivalentClass>
 </owl:Class>

 :MyBirthdayGuests  owl:equivalentClass  [
   rdf:type   owl:Class ;
   owl:oneOf  ( :Bill  :John  :Mary )
 ] .

 Class: MyBirthdayGuests
   EquivalentTo: { Bill John Mary }

 <EquivalentClasses>
   <Class IRI="MyBirthdayGuests"/>
   <ObjectOneOf>
     <NamedIndividual IRI="Bill"/>
     <NamedIndividual IRI="John"/>
     <NamedIndividual IRI="Mary"/>
   </ObjectOneOf>
 </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 .or enumerated sets. 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.

6 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 other modeling capabilities with properties OWL 2 offers.

6.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:

 InverseObjectProperties( :hasParent :hasChild ) 

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

 :hasParent owl:inverseOf :hasChild .

 ObjectProperty: hasParent
   InverseOf: hasChild

 <InverseObjectProperties>
   <ObjectProperty IRI="hasParent"/>
   <ObjectProperty IRI="hasChild"/>
 </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(
   :Orphan
   ObjectAllValuesFrom(
     ObjectInverseOf( :hasChild )
     :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">rdf:about="Dead"/>
     </owl:Restriction>
   </owl:equivalentClass>
 </owl:Class>

 :Orphan  owl:equivalentClass  [
   rdf:type           owl:Restriction ;
   owl:onProperty     [ owl:inverseOf  :hasChild ] ;
   owl:allValuesFrom  :Dead 
 ] .

 Class: Orphan
   EquivalentTo: inverse hasChild  allonly Dead

 <EquivalentClasses>
   <Class IRI="Orphan"/>
   <ObjectAllValuesFrom>
     <InverseObjectProperty>
       <ObjectProperty IRI="hasChild"/>
     </InverseObjectProperty>
     <Class IRI="Dead"/>
   </ObjectAllValuesFrom>
 </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, and it can be specified as follows

 SymmetricObjectProperty( :hasSpouse ) 

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

 :hasSpouse  rdf:type  owl:SymmetricProperty .

 ObjectProperty: hasSpouse
   Characteristics: Symmetric

 <SymmetricObjectProperty>
   <ObjectProperty IRI="hasSpouse"/>
 </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:

 AsymmetricObjectProperty( :hasChild ) 

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

 :hasChild  rdf:type  owl:AsymmetricProperty .

 ObjectProperty: hasChild
   Characteristics: Asymmetric

 <AsymmetricObjectProperty>
   <ObjectProperty IRI="hasChild"/>
 </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:

 DisjointObjectProperties( :hasParent :hasSpouse )  

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

 :hasParent  owl:propertyDisjointWith  :hasSpouse .

 DisjointProperties: hasParent hasSpouse

 <DisjointObjectProperties>
   <ObjectProperty IRI="hasParent"/>
   <ObjectProperty IRI="hasSpouse"/>
 </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.

 ReflexiveObjectProperty( :hasRelative )

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

 :hasRelative  rdf:type  owl:ReflexiveProperty .

 ObjectProperty: hasRelative
   Characteristics: Reflexive

 <ReflexiveObjectProperty>
   <ObjectProperty IRI="hasRelative"/>
 </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.

 IrreflexiveObjectProperty( :parentOf )   

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

 :parentOf  rdf:type  owl:IrreflexiveProperty .

 Objectproperty: parentOf
   Characteristics: Irreflexive

 <IreflexiveObjectProperty>
   <ObjectProperty IRI="parentOf"/>
 </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:

 FunctionalObjectProperty( :hasHusband ) 

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

 :hasHusband  rdf:type  owl:FunctionalProperty .

 ObjectProperty: hasHusband
   Characteristics: Functional

 <FunctionalObjectProperty>
   <ObjectProperty IRI="hasHusband"/>
 </FunctionalObjectProperty>

Note that this statement does not require every individual to have a husband, it just states that there can be no more than one. Moreover, if we additionally had a statement that Mary's husband is James and another that Mary's husband is Jim, it could be inferred that Jim and James must refer to the same individual.

It is also possible to indicate that the inverse of a given property is functional:

 InverseFunctionalObjectProperty( :hasHusband ) 

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

 :hasHusband  rdf:type  owl:InverseFunctionalProperty .

 ObjectProperty: hasHusband
   Characteristics: InverseFunctional

 <InverseFunctionalObjectProperty>
   <ObjectProperty IRI="hasHusband"/>
 </InverseFunctionalObjectProperty>

This indicates that an individual can be husband of at most one other individual. The 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.

 TransitiveObjectProperty( :hasAncestor )

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

 :hasAncestor  rdf:type  owl:TransitiveProperty .

 ObjectProperty: hasAncestor
   Characteristics: Transitive

 <TransitiveObjectProperty>
   <ObjectProperty IRI="hasAncestor"/>
 </TransitiveObjectProperty>

6.2 Property Chains

While the last example from the previous section allowed to inferimplied the presence of 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 are 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 hasGrandparent to refer to great-grandparents etc. We can express that every such chain has to be spanned by a hasGrandparent property as follows:

 SubObjectPropertyOf( 
   ObjectPropertyChain( :hasParent :hasParent ) 
   :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>

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

 ObjectProperty: hasGrandparent
   SubPropertyChain: hasParent o hasParent

 <SubObjectPropertyOf>
   <PropertyChain>
     <ObjectProperty IRI="hasParent"/>
     <ObjectProperty IRI="hasParent"/>
   </PropertyChain>
   <ObjectProperty IRI="hasGrandparent"/>
 </SubObjectPropertyOf>

6.3 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( :Person  hasSSN() ( :hasSSN ) )

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

 :Person  owl:hasKey :hasSSNowl:hasKey ( :hasSSN ) .

 HasKey: Person hasSSN

 <HasKey>
   <Class IRI="Person"/>
   <ObjectProperty IRI="hasSSN"/>
 </HasKey>

7 Advanced Use of Datatypes

In the following,Section 4.8, we describe features of OWL 2 which do not actually contributelearned that individuals can be endowed with numerical information, esentially by connecting them to the “logical” knowledge specifieda data value via a datatype property - just like object properties link to other domain individuals. In the ontology. Ratherfact, these are usedparallels extend to provide additional information aboutthe ontology itself, axioms, or even single entities. 8.1 Annotating Axiomsmore advanced features of datatype usage.

First of all, data values are grouped into datatypes and Entities In many cases,we wanthave seen in Section 4.8 how a range restriction on a datatype property can be used to furnish parts of our OWL ontology with information that actually does not describe the domain itself but talks aboutindicate the descriptionkind of the domain. OWL provides annotations forvalues this purpose. An OWL annotation simply associates property-value pairs with parts of an ontology,property can link to. Moreover, it is possible to express and define new datatypes by constraining or the entire ontology itself. Even annotations themselvescombining existing ones. Datatypes can be annotated. Annotation information is not really part ofrestricted via so-called facets. In the logical meaning of an ontology. So, forfollowing example, we could add information to one of the classes of our ontology, givingdefine a natural language description of its meaning. AnnotationAssertion( rdfs:label :Person "Representsnew datatype for a person's age by constraining the set of all people."datatype integer to values between (inclusively) 0 and 150.

 DatatypeDefinition(
   :personAge
   DatatypeRestriction( xsd:integer           
     xsd:minInclusive "0"^^xsd:integer
     xsd:maxInclusive "150"^^xsd:integer
   )
  <owl:Class rdf:about="Person"> <rdfs:label>Represents the set of all people.</rdfs:label> </owl:Class>  :Person rdfs:label "Represents the set of all people."^^xsd:string) 

 <rdf:Description rdf:about="personAge">
   <owl:equivalentClass>
     <owl:Datatype>
       <owl:onDatatype rdf:resource="http://www.w3.org/2001/XMLSchema#integer"/>
       <owl:withRestrictions rdf:parseType="Collection">
         <xsd:minInclusive rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">0</xsd:minInclusive>
         <xsd:maxInclusive rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">150</xsd:maxInclusive>          
       </owl:withRestrictions>
     </owl:Datatype>
   </owl:equivalentClass>
 </rdf:Description>

 :personAge  owl:equivalentClass
  [ rdf:type  rdfs:Datatype;
    owl:onDatatype  xsd:Integer;
    owl:withRestrictions (
       [ xsd:minInclusive  "0"^^xsd:integer ]
       [ xsd:maxInclusive  "150"^^xsd:integer ] 
    )
  ] .

 Datatype: personAge
   EquivalentTo: integer[<= 0 , >= 150]

 <EquivalentClasses>
    <Datatype IRI="personAge"/>
    <DatatypeRestriction>
       <Datatype IRI="&xsd;integer"/>
       <FacetRestriction facet="&xsd;minInclusive">
         <Literal datatypeIRI="&xsd;integer">0</Literal>
       </FacetRestriction>
       <FacetRestriction facet="&xsd;maxInclusive">
         <Literal datatypeIRI="&xsd;integer">150</Literal>
       </FacetRestriction>
    </DatatypeRestriction>
  </EquivalentClasses>

Likewise, datatypes can be combined just like classes by complement, intersection and union. Thereby, assuming we have already defined a datatype MinorAge, we can define the set ofdatatype MajorAge by excluding all people.</Literal> </AnnotationAssertion> The following is an exampledata values of an axiom with an annotation. SubClassOf( Annotation( rdfs:label "States that every man is a person."MinorAge from PersonAge:

 DatatypeDefinition(
   :majorAge
   DataIntersectionOf(
     :personAge 
     DataComplementOf( :minorAge ) 
     :Man  :Person) 
  <owl:Class rdf:about="Man"> <rdfs:subClassOf rdf:resource="Person"/> </owl:Class> <owl:Axiom> <owl:subject rdf:resource="Man"/> <owl:predicate rdf:resource="&rdfs;subClassOf"/> <owl:object rdf:resource="Person"/> <rdfs:label>States that every man is a person.</rdfs:label> </owl:Axiom>  :Man rdfs:subClassOf :Person . []) 

 <rdf:Description rdf:about="majorAge">
   <owl:equivalentClass>
     <owl:Datatype>
       <owl:intersectionOf rdf:parseType="Collection">
         <rdf:Description rdf:about="personAge"/>
         <rdfs:Datatype>
           <owl:datatypeComplementOf about="minorAge"/> 
         </rdfs:Datatype>
       </owl:intersectionOf>
     </owl:Datatype>
   </owl:equivalentClass>
 </rdf:Description> 

 :majorAge  owl:equivalentClass
   [ rdf:type   owl:Axiom ; owl:subject  :Man ; owl:predicate rdfs:subClassOf ; owl:object  :Person ; rdfs:label "States that every man is a person."^^xsd:stringrdfs:Datatype;
     owl:intersectionOf (
        :personAge
        [ rdf:type  rdfs:Datatype;
          owl:datatypeComplementOf  :minorAge ] 
     )
   ] .

 Datatype: majorAge
    EquivalentTo: personAge and not minorAge

 <EquivalentClasses>
    <Datatype IRI="majorAge"/>
    <DataIntersectionOf>
       <Datatype IRI="personAge"/>
       <DataComplementOf>
         <Datatype IRI="minorAge"/>
       </DataComplementOf>
    </DataIntersectionOf>
  </EquivalentClasses>

Moreover, a person." Person <SubClassOf> <Annotation> <AnnotationProperty IRI="&rdfs;label"/>new datatype can be generated by just enumerating the data values it contains.

 DatatypeDefinition(
   :toddlerAge
   DataOneOf( "1"^^xsd:integer "2"^^xsd:integer ) 
 ) 

 <rdf:Description rdf:about="toddlerAge">
    <owl:equivalentClass>
      <owl:Datatype>
        <owl:oneOf rdf:parseType="Collection">
           <rdf:Description rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</rdf:Description>
           <rdf:Description rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">2</rdf:Description>
        </owl:oneOf>
      </owl:Datatype>
    </owl:equivalentClass>
 </rdf:Description>

 :toddlerAge  owl:equivalentClass
   [ rdf:type rdfs:Datatype;
     owl:oneOf (  "1"^^xsd:integer  "2"^^xsd:integer )
   ] .

 Datatype: toddlerAge
    EquivalentTo: { 1 2 }

 <EquivalentClasses>
    <Datatype IRI="toddlerAge"/>
    <DataOneOf>
      <Literal  datatypeIRI="xsd:string">"States that every man is a person."</Literal> </Annotation> <Class IRI="Man"/> <Class IRI="Person"/> </SubClassOf> 8.2 Ontology ManagementdatatypeIRI="http://www.w3.org/2001/XMLSchema#integer">1</Literal> 
      <Literal datatypeIRI="http://www.w3.org/2001/XMLSchema#integer">2</Literal>
    </DataOneOf>
 </EquivalentClasses>

In OWL, general information about a topic is almost always gathered into an ontology that is then used by various applications.Section 6.1, we cansaw ways of characterizing object properties. Some of those are also provide a nameavailable for OWL ontologies , which is generally the place where the ontology document is located indatatype properties. For example, we can express that every person has only one age by characterizing the web. Particular information about a topichasAge datatype property as functional:

 FunctionalDataProperty( :hasAge ) 

 <owl:FunctionalProperty rdf:about="hasAge"/>

 :hasAge  rdf:type  owl:FunctionalProperty .

 DataProperty: hasHusband
   Characteristics: Functional

 <FunctionalDataProperty>
  <DataProperty IRI="hasHusband"/>
</FunctionalDataProperty>

New classes can alsobe placed in an ontology, if it is useddefined by different applications. Ontology(<http://example.com/owl/families> ...restrictions on datatype properties. The following example defines the class teenager as all individuals whose age is between 13 and 19 years.

 SubClassOf(
   :Teenager
   ObjectSomeValuesFrom( :hasAge
     DatatypeRestriction( xsd:integer
       xsd:minInclusive "13"^^xsd:integer
       xsd:maxInclusive "19"^^xsd:integer
     )
    <rdf:RDF ...> <owl:Ontology rdf:about="http://example.com/owl/families"/> ... </rdf:RDF> <http://example.com/owl/families>)
 )

<owl:Class rdf:about="Teenager">
  <rdfs:subClassOf>
    <owl:Restriction>
      <owl:onProperty rdf:resource="hasAge"/>
      <owl:someValuesFrom>
        <rdfs:Datatype>
          <owl:onDataType rdf:resource="&xsd;integer"/>
          <owl:withRestrictions rdf:parseType="Collection">
            <xsd:minExclusive rdf:datatype="&xsd;integer">
              12
            </xsd:minExclusive>
            <xsd:maxInclusive rdf:datatype="&xsd;integer">
              19
            </xsd:maxInclusive>
          </owl:withRestrictions>
        </rdfs:Datatype>
      </owl:someValuesFrom>
    </owl:Restriction>
  </rdfs:subClassOf>
</owl:Class>

:Teenager  rdfs:subClassOf
       [ rdf:type              owl:Ontologyowl:Restriction ;
         owl:onProperty       :hasAge ;
         owl:someValuesFrom   
          [ rdf:type             rdfs:Datatype ;
            owl:onDatatype       xsd:integer ;
            owl:withRestrictions (  [ xsd:minInclusive     "13"^^xsd:integer ]
                                    [ xsd:maxInclusive     "19"^^xsd:integer ]
            )
          ]
       ] .

Class: Teenager
  SubClassOf: hasAge some integer[<= 13 , >= 19]

<SubClassOf>
  <Class IRI="Teenager"/>
  <DataSomeValuesFrom>
    <DataProperty IRI="hasAge"/>
    <DatatypeRestriction>
      <Datatype IRI="&xsd;integer"/>
      <FacetRestriction facet="&xsd;minInclusive">
        <Literal datatypeIRI="&xsd;integer">13</Literal>
      </FacetRestriction>
      <FacetRestriction facet="&xsd;maxInclusive">
        <Literal datatypeIRI="&xsd;integer">19</Literal>
      </FacetRestriction>
    </DatatypeRestriction>
  </DataSomeValuesFrom>
</SubClassOf>

8 Document Information and Annotations

In the following, we place OWL ontologies intodescribe features of OWL documents,2 which are then placed into local filesystems or ondo not actually contribute to the World Wide Web. Aside from containing an OWL ontology, OWL documents also contain“logical” knowledge specified in the ontology. Rather these are used to provide additional information about transformingthe short names normally usedontology itself, axioms, or even single entities.

8.1 Annotating Axioms and Entities

In many cases, we want to furnish parts of our OWL ontologies (e.g., Person) into IRIs, by providing the expansion for prefixes . The IRI is then the concatention ofontology with information that actually does not describe the prefix expansion anddomain itself but talks about the reference. In our example we have so far used a numberdescription of prefixes, including xsd and the empty prefix.the former prefix has been used in compact namesdomain. OWL provides annotations for XML Schema datatypes, whose IRIs are fixed by the XML Schema recommendation. We thus must usethis purpose. An OWL annotation simply associates property-value pairs with parts of an ontology, or the standard expansion for xsd , whichentire ontology itself. Even annotations themselves can be annotated. Annotation information is http://www.w3.org/2001/XMLSchema# .not really part of the expansion we picklogical meaning of an ontology.

So, for the other prefix will affect the namesexample, we could add information to one of the classes, properties, and individuals inclasses of our ontology, as well asgiving a natural language description of its meaning.

 AnnotationAssertion( rdfs:comment :Person "Represents the  nameset of all people." )

 <owl:Class rdf:about="Person">
   <rdfs:comment>Represents the  ontology itself. If we are going to putset of all people.</rdfs:comment>
 </owl:Class>

 :Person  rdfs:comment  "Represents the  ontology onset of all people."^^xsd:string .

 Class: Person
   Annotations: rdfs:comment "Represents the  web, we should pick an expansion that is in some partset of all people."

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

The web that we control, sofollowing is an example of an axiom with an annotation.

 SubClassOf( 
   Annotation( rdfs:comment "States that  we are not using someone else's names by accident. (Here we useevery man is a  made-up place that no one controls.) The two XML-based syntaxes need namespaces for built-in names and also can use XML entities for namespaces. Namespace(=<http://example.com/owl/families/>) Namespace(otherOnt=<http://example.org/otherOntologies/families/>) Namespace(xsd=<http://www.w3.org/2001/XMLSchema#>) <!DOCTYPE rdf:RDF [ <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > <!ENTITY otherOnt "http://example.org/otherOntologies/families/" > ]> <rdf:RDF xml:base="http://example.com/owl/families/" xmlns="http://example.com/owl/families/" xmlns:otherOnt="http://example.org/otherOntologies/families/" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <owl:Ontology rdf:about="http://example.com/owl/families"/> ... @prefix : <http://example.com/owl/families/> @prefix otherOnt: <http://example.org/otherOntologies/families/> @prefix owl: <http://www.w3.org/2002/07/owl#> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> Prefix: <http://example.com/owl/families/> Prefix: otherOnt <http://example.org/otherOntologies/families/> <!DOCTYPE Ontology [ <!ENTITY xsd "http://www.w3.org/2001/XMLSchema#" > ]> <Ontology xml:base="http://example.com/owl/families/" xmlns="http://www.w3.org/2002/07/owl#" xmlns:g="http://example.org/otherOntologies/families/" ontologyIRI="http://example.com/owl/families"> ... </Ontology> Itperson." )
   :Man 
   :Person 
 )

 <owl:Class rdf:about="Man">
   <rdfs:subClassOf rdf:resource="Person"/>
 </owl:Class>
 <owl:Axiom>
   <owl:annotatedSource rdf:resource="Man"/>
   <owl:annotatedProperty rdf:resource="&rdfs;subClassOf"/>
   <owl:annotatedTarget rdf:resource="Person"/>
   <rdfs:comment>States that every man is  also commona person.</rdfs:comment>
 </owl:Axiom>

 :Man rdfs:subClassOf :Person .
 []  rdf:type       owl:Axiom ;
     owl:annotatedSource    :Man ;
     owl:annotatedProperty  rdfs:subClassOf ;
     owl:annotatedTarget    :Person ;
     rdfs:comment     "States that every man is a person."^^xsd:string .

 Class: Man
   SubClassOf: Annotations: rdfs:comment "States that every man is a person." Person

 <SubClassOf>
   <Annotation>
       <AnnotationProperty IRI="&rdfs;comment"/>
       <Literal datatypeIRI="xsd:string">"States that every man is a person."</Literal>
   </Annotation>
   <Class IRI="Man"/>
   <Class IRI="Person"/>
 </SubClassOf>

Often such annotations are used in OWLtools to reuseprovide access to natural language text to be displayed in help interfaces.

8.2 Ontology Management

In OWL, general information thatabout a topic is stored in onealmost always gathered into an ontology in other ontologies. Instead of requiring the copying of this information,that is then used by various applications. We can also provide a name for OWL allowsontologies, which is generally the import ofplace where the contents of entire ontologiesontology document is located in other ontologies, using import statements, as follows: Import( http://example.org/otherOntologies/families.owl ) <owl:Ontology rdf:about="http://example.com/owl/families"> <owl:imports rdf:resource="http://example.org/otherOntologies/families.owl" /> </owl:Ontology> <http://example.com/owl/families> owl:imports <http://example.org/otherOntologies/families.owl> . Import: <http://example.org/otherOntologies/families.owl> <Prefix name="otherOnt" IRI="http://example.org/otherOntologies/families/"/> <Import>http://example.org/otherOntologies/families.owl</Import> Asthe Semantic Web and ontology construction is distributed,web. Particular information about a topic can also be placed in an ontology, if it is common for ontologies to useused 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 ...
   ontologyIRI="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 same concept, property, or individual. AsIRI is then the concatention of the prefix expansion and the reference.

In our example we have seen, several constructs in OWL can beso far used to state that differenta number of prefixes, including xsd and the empty prefix. The former prefix has been used in compact names refer tofor XML Schema datatypes, whose IRIs are fixed by the same class , property , or individual , so,XML Schema recommendation. We thus must use the standard expansion for example,xsd, which is http://www.w3.org/2001/XMLSchema#. The expansion we could – instead of tediously renaming entities – tiepick for the other prefix will affect the names usedof the classes, properties, and individuals in our ontology, as well as the name of the ontology itself. If we are going to put the names used in an importedontology as follows: SameIndividuals( :John otherOnt:JohnBrown ) SameIndividuals( :Mary otherOnt:MaryBrown ) EquivalentClasses( :Adult otherOnt:Grownup ) EquivalentObjectProperties( :hasChild otherOnt:child ) EquivalentDataProperties( :hasAge otherOnt:age ) <rdf:Description rdf:about="John"> <owl:sameAs rdf:resource="&otherOnt;JohnBrown"/> </rdf:Description> <rdf:Description rdf:about="Mary"> <owl:sameAs rdf:resource="&otherOnt;MaryBrown"/> </rdf:Description> <owl:Class rdf:about="Adult"> <owl:equivalentClass rdf:resource="&otherOnt;Grownup"/> </owl:Class> <owl:DatatypeProperty rdf:about="hasAge"> <owl:equivalentProperty rdf:resource="&otherOnt;age"/> </owl:DatatypeProperty> <owl:Class rdf:about="Adult"> <owl:equivalentClass rdf:resource="&otherOnt;Grownup"/> </owl:Class>  :Mary owl:sameAs otherOnt:MaryBrown .  :John owl:sameAs otherOnt:JohnBrown .  :Adult owl:equivalentClass otherOnt:Grownup .  :hasChild owl:equivalentProperty otherOnt:child .  :hasAge owl:equivalentProperty otherOnt:age . SameIndividual: John otherOnt:JohnBrown SameIndividual: Mary otherOnt:MaryBrown EquivalentClasses: Adult otherOnt:Grownup EquivalentProperties: hasChild otherOnt:child EquivalentProperties: hasAge otherOnt:age <SameIndividuals> <Individual IRI="John"/> <Individual IRI="otherOnt:JohnBrown"/> </SameIndividuals> <SameIndividuals> <Individual IRI="Mary"/> <Individual IRI="otherOnt:MaryBrown"/> </SameIndividuals> <EquivalentClasses> <Class IRI="Adult"/> <Class IRI="otherOnt:Grownup"/> </EquivalentClasses> <EquivalentObjectProperties> <ObjectProperty IRI="hasChild"/> <ObjectProperty IRI="otherOnt:child"/> </EquivalentObjectProperties> <EquivalentDataProperties> <DataProperty IRI="hasAge"/> <DataProperty IRI="otherOnt:age"/> </EquivalentDataProperties> 8.3 Entity Declarations To help with managing ontologies, OWL has the notion of declarations.on the basic idea isweb, we should pick an expansion that each class, property, or individualis supposed to be declared in an ontology, and then it can be usedin some part of the web that ontology and ontologies that importwe control, so that ontology. In the Manchester syntax, declarationswe are implicit. Constructs that provide information aboutnot using someone else's names by accident. (Here we use a class, property, or individual implicitly declaremade-up place that class, property, or individual if needed.no one controls.) The othertwo XML-based syntaxes have explicit declarations. Declaration( NamedIndividual( :John ) ) Declaration( Class( :Person ) ) Declaration( ObjectProperty( :hasWife ) ) Declaration( DataProperty( :hasAge )need namespaces for built-in names and also can use XML entities for namespaces.

 Prefix(:=<http://example.com/owl/families/>)
 Prefix(otherOnt:=<http://example.org/otherOntologies/families/>)
 Prefix(xsd:=<http://www.w3.org/2001/XMLSchema#>)
 Prefix(owl:=<http://www.w3.org/2002/07/owl#>)
 
 Ontology(<http://example.com/owl/families>
    ...
 )

8.3 Entity Declarations

To help with managing ontologies, OWL 2 Full there are some extra inferences that arise fromhas the RDF viewnotion of declarations. The universe. Conceptually, webasic idea is that each class, property, or individual is supposed to be declared in an ontology, and then it can think of the difference between OWL 2 DLbe used in that ontology and OWL 2 Fullontologies that import that ontology.

In two ways: One can see OWL 2 DL as a syntactically restricted version of OWL 2 Full wherethe restrictionsManchester syntax, declarations are designed to make life easier for implementors. In fact, since OWL 2 Full is undecidable, OWL 2 DL makes writingimplicit. Constructs that provide information about a reasoner that, in principle, can return all yesclass, property, or individual implicitly declare that class, property, or individual if needed. The other syntaxes have explicit declarations.

 Declaration( NamedIndividual( :John ) )
 Declaration( Class( :Person ) )
 Declaration( ObjectProperty( :hasWife ) )
 Declaration( DataProperty( :hasAge ) )

 <owl:NamedIndividual rdf:about="John"/>
 <owl:Class rdf:about="Person"/>
 <owl:ObjectProperty rdf:about="hasWife"/>
 <owl:DatatypeProperty rdf:about="hasAge"/>

 :John    rdf:type owl:NamedIndividual .
 :Person  rdf:type owl:Class .
 :hasWife rdf:type owl:ObjectProperty .
 :hasAge  rdf:type owl:DatatypeProperty .

 Individual: John
 Class: Person
 ObjectProperty: hasWife
 Dataproperty: hasAge

 <Declaration>
     <NamedIndividual IRI="John"/>
 </Declaration>
 <Declaration>
     <Class IRI="Person"/>
 </Declaration>
 <Declaration>
     <ObjectProperty IRI="hasWife"/>
 </Declaration>
 <Declaration>
     <DataProperty IRI="hasAge"/>
 </Declaration>

9 OWL 2 DL and OWL 2 Full