OWL 2 Web Ontology Language
Primer

/* =oClassNames.length); i++){ /*>*/ arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames[i].replace(/\-/g, "\\-") + "(\\s|$)")); } } else{ arrRegExpClassNames.push(new RegExp("(^|\\s)" + oClassNames.replace(/\-/g, "\\-") + "(\\s|$)")); } var oElement; var bMatchesAll; for(var j=0; !(j>=arrElements.length); j++){ /*>*/ oElement = arrElements[j]; bMatchesAll = true; for(var k=0; !(k>=arrRegExpClassNames.length); k++){ /*>*/ if(!arrRegExpClassNames[k].test(oElement.className)){ bMatchesAll = false; break; } } if(bMatchesAll){ arrReturnElements.push(oElement); } } return (arrReturnElements) } function set_display_by_class(el, cls, newValue) { var e = getElementsByClassName(document, el, cls); if (e != null) { for (var i=0; !(i>=e.length); i++) { e[i].style.display = newValue; } } } function set_display_by_id(id, newValue) { var e = document.getElementById(id); if (e != null) { e.style.display = newValue; } } /* More stuff by sandro@hawke.org */ var idCount = 0 var groupStatus = new Array() groupStatus["manchester"] = true groupStatus["functional"] = false groupStatus["owlxml"] = false groupStatus["rdfxml"] = false groupStatus["turtle"] = false /* set the paragraphs in class "else" to be shown only if none of the groups (enumerated as keys in groupStatus) are true. */ function set_else() { optionsShown = 0 for (x in groupStatus) { if (groupStatus[x]) optionsShown++ } if (optionsShown >= 1) { set_display_by_class("p", "else", "none") } else { set_display_by_class("p", "else", "block") } } function hideshow(item) { group = item.value status = item.checked groupStatus[group] = status set_else() /* if (status) { alert('click! will now show '+group+", "+item.parentNode.parentNode.parentNode.parentNode) } else { alert('click! will now NOT show '+group) } */ var e = getElementsByClassName(document, "input", "showbox"); if (e != null) { for (var i=0; !(i>=e.length); i++) { if (e[i].value == group) { e[i].checked = status } } } set_display_by_class("p", group, (status?"block":"none")) /* window.location.href=window.location.href + "#here" or some other way to re-find this location? */ /* put this at the top of the window, because otherwise we'll get totally lost since the document changed size. */ /* search up the tree or something? */ hash = item.parentNode.parentNode.parentNode.parentNode.id if ( hash == "" ) { hash = item.parentNode.parentNode.parentNode.id if ( hash == "" ) { hash = item.parentNode.parentNode.parentNode.id /* alert("There should be an 'id' attribute on the div surrounding this form, but it's missing. Please report this to the document editor. Attempting Repair...") */ hash = "tempAnchor"+(++idCount) item.parentNode.parentNode.parentNode.id = hash } } window.location.hash=hash } /*]]>*/ -->1 Introduction

Other examples are not part of the ontology; these are so indicated.1.1 Guide to this Document

1.2 OWL Syntaxes

2 Modelling Knowledge: Basic NotionsWhat is OWL 2?

OWL 2 is a knowledge representation language, designed to formulate, exchangelanguage for expressing ontologies. The term ontology has a complex history both in and reason with knowledge aboutout of computer science, but we use it to mean a domaincertain kind of interest. Some fundamental notions should first be explainedcomputational artifact – i.e., something akin to understand how knowledge is represented in OWL 2. These basic notions are: Axioms: the basic statements thata program, an XML schema, or a web page – generally presented as a document. An OWLontology expresses Entities: elements used to refer to the real-world objects that are modelled Expressions: combinationsis a set of entities to form complex descriptions from basic ones While OWL 2 aimsprecise descriptive statements about some part of the world (usually referred to capture knowledge,as the kind of “knowledge” that can be represented by OWL does of course not reflect all aspectsdomain of human knowledge. OWL can rather be considered as a powerful general-purpose modelling language for certain partsinterest or the subject matter of human knowledge.the modelling artefacts createdontology). Precise descriptions satisfy several purposes: most notably, they prevent misunderstandings in OWL are called ontologies – a terminologyhuman communication and they ensure that also helps to avoid confusion since the term “model” is often usedsoftware behaves in a rather different sense in knowledge representation. Now,uniform, predictable way and works well with other software.

In order to formulate knowledge explicitly,precisely describe a domain of interest, it is usefulhelpful to assume that it consistscome up with a set of elementary pieces that arecentral terms – 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” arecalled axioms . Indeed, every OWL 2 ontology isvocabulary – from an abstract viewpoint – essentially justand fix their meaning. Besides a collectionconcise natural language definition, the meaning of axioms. It is characteristic for axioms that theya term can be saidcharacterized by stating how this term is interrelated to be true or false giventhe other terms. 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.terminology, providing a vocabulary together with such interrelation information constitutes an important featureessential part of a typical OWL is that it captures2 document. Besides this aspect of human intelligence for the forms ofterminological knowledge, an ontology might also contain so called assertional knowledge that it can represent. But what does it mean, generally speaking, that a statement is a consequencedeals with concrete objects of other statements? Essentially it means that this statement is true wheneverthe other statements are. Inconsidered domain rather than general notions.

3 Modeling Knowledge: Basic Notions

OWL axioms, we see that they are rarely “monolithic” but more often have some internal structure that can be explicitly represented. They normally refer2 is a knowledge representation language, designed to objects of the worldformulate, exchange and describe them e.g. by putting them into categories (like “Mary is female”) or saying somethingreason with knowledge about their relation (“John and Mary are married”). All atomic constituentsa domain of axioms,interest. Some fundamental notions should first be they objects (John, Mary), categories (female) or relations (married) are called entities .explained to understand how knowledge is represented in OWL 2, we denote objects as individuals , categories as classes and relations as properties . Properties in2. These basic notions are:

• Axioms: the basic statements that an OWL 2 are further subdivided. Object properties relate objects to objects (like a personontology expresses
• Entities: elements used to their spouse), while datatype properties assign data valuesrefer to real-world objects
• (like an ageExpressions: combinations of entities to a person). Annotation properties are usedform complex descriptions from basic ones

While OWL 2 aims to encode information about (parts of) the ontology itself (like the author and creation date of an axiom) instead ofcapture knowledge, the domainkind of interest. As a central feature“knowledge” that can be represented by OWL does of OWL, namescourse not reflect all aspects of entitieshuman knowledge. OWL can be combined into expressions using so called constructors .considered as a basic example, the atomic classes “female” and “professor” could be combined conjunctively to describepowerful general-purpose modeling language for certain parts of human knowledge. The classresults of female professors.the latter would be described by an OWL class expression,modeling processes are called ontologies – a terminology that could bealso helps to avoid confusion since the term “model” is often used in statements ora rather different sense in other expressions.knowledge representation.

Now, in this sense, expressions can be seenorder to formulate knowledge explicitly, it is useful to assume that it consists of elementary pieces that are often referred to as new entities whichstatements or propositions. Statements like “it is raining” or “every man is mortal” are defined by their structure. In OWL, the constructors for each sort of entity varies greatly. The expression languagetypical examples for classessuch basic propositions. Indeed, every OWL 2 ontology is very richessentially just a collection of such basic “pieces of knowledge.” Statements that are made in an ontology are called axioms in OWL 2, 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)ontology asserts that its axioms are true. In some way as additional explanation which cangeneral, OWL statements might be skipped. One can use basic algebra aseither true or false given a somewhat naive but possibly elucidating analogy for the introduced terminology. An axiom would relate tocertain state of affairs. This distinguishes them from entities and expressions as described further below.

When humans think, they draw consequences from their knowledge. An equation like x=y . Clearly,important feature of OWL is that it captures this axiom can be said true or false, depending on the stateaspect of affairs (i.e.human intelligence for the actual valuesforms of these variables). Moreover, the two axioms x=y and y=z entailknowledge 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 axiom x=z , asother statements are. In everyOWL terms: we say, a set of statements A entails a statement a if in any state of affairs where the formerwherein all statements from A are true, the latter isalso a is true. Likewise, we can haveMoreover, a set of statements may be consistent sets(that is, there is a possible state of axioms ( x=y , y=z )affairs in which all the statements in the set are jointly true) or inconsistent ones ( x=y , y=x+1 ). Obviously,(there is no such state of affairs). The axioms consistformal semantics of entities ( x , y , z )OWL specifies, in essence, for which possible “states of affairs” a particular set of OWL statements is true.

There are not themselves true or false andOWL tools – reasoners – that can be combined by constructors ( + , - , etc.) into expressions (like x+y or y-z ) which in aautomatically compute consequences. The way represent new entities andontological axioms interact can be used instead of simple entities in axioms ( x+y=y-z ). 3 Classes, Properties,very subtle 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,difficult for people to more advanced constructs. 3.1 Classesunderstand. This is both a strength and Instances Suppose we want to representa weakness of OWL 2. It is a strength because OWL 2 tools can discover information aboutthat a particular family. (We doperson would not intendhave spotted. This exampleallows knowledge engineers 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 ofmodel more directly and the rather complex, shifting,system to provide useful feedback and politically explosive domaincritique of families. Instead, we intendthe modeling. It to beis a rather simple exhibitionweakness because it is comparatively difficult for humans to immediately foresee the actual effect of various features of OWL.) We first need to provideconstructs in various combinations. Tool support ameliorates the information what personssituation but successful knowledge engineering often still requires some amount of training and experience.

Having a closer look at statements in OWL, we see that they are talking about. Thisrarely “monolithic” but more often have some internal structure that 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 Maryexplicitly represented. They normally refer to objects of the world and states that this individual is a person. More technically, being a person is expresseddescribe them e.g. by stating thatputting them into categories (like “Mary is female”) or saying something about their relation (“John and Mary belongs to (or "is a member of" or, even more technically, "is an instance of") the class ofare married”). All persons.atomic constituents of statements, be they objects (John, Mary), categories (female) or relations (married) are called entities. In generalOWL 2, we denote objects as individuals, categories as classes and relations as properties. Properties in OWL 2 are usedfurther subdivided. Object properties relate objects to group individuals that have something in common in orderobjects (like a person to refertheir spouse), while datatype properties assign data values to them. Consequently, we can use the same type of statementobjects (like an age to indicate that Mary isa woman by expressing that she isperson). Annotation properties are used to encode information about (parts of) the ontology itself (like the author and creation date of an instanceaxiom) instead of the classdomain of women: ClassAssertion( f:Woman f:Mary ) <f:Woman rdf:about="#Mary"/> f:Mary rdf:type f:Womaninterest.

As a central feature of OWL, names of entities can be combined into expressions using so called constructors. 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 maya basic example, the atomic classes “female” and “professor” could be diverse criteria to group individuals (like gender, age, shoe size, etc.), one individual may well belongcombined conjunctively to several classes simultaneously. 3.2 Class Hierarchies In the previous section, we were talking about two classes:describe the class of all persons and that of all women. Tofemale professors. 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 tolatter would be a woman, it mustdescribed by an OWL class expression, that could be a person. However,used in statements or in other expressions. In this correspondence cannotsense, expressions can be derived fromseen as new entities which are defined by their structure. In OWL, the labels "Person"constructors for each sort of entity vary greatly. The expression language for classes is very rich and "Woman" butsophisticated, whereas the expression language for properties is partmuch less so. These differences have historical as well as technical reasons.

4 Classes, Properties, and Individuals – And Basic Modeling With Them

After these general considerations, we now engage in the details of modeling with OWL 2. In the human background knowledge aboutsubsequent sections, we introduce the worldessential modeling features that OWL 2 offers, provide examples and our usage of those terms. Therefore,give some general comments on how to use them. We proceed from basic features, which are essentially available in orderany modeling language, to enablemore advanced constructs.

Thereby we will represent information about a system to draw the desired conclusions, it hasparticular family. Note that we do not intend this example to be informed about this corresondency. Inrepresentative of the sorts of domains OWL 2, this is done byshould be used for, or as 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 presencecanonical example of this axiom in an ontology enables reasoners to infer for every individual that is specified as an instancegood modeling with OWL, or a correct representation of the class Woman, that is an instancerather complex, shifting, and culturally dependent domain of the class Person as well. Asfamilies. Instead, we intend it to be a rulerather simple exhibition of thumb, a subclass relationship between twovarious features of OWL.

4.1 Classes Aand BInstances

We start by introducing the persons we are talking about. This can be specified, if the phrase "every A is a B" makes sensedone 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 correct. Ita person. More technically, being a person is common in ontological modelling to use subclass statements not only for sporadically declaring such interdependencies, but to model whole class hierarchiesexpressed by specifyingstating that Mary belongs to (or “is a member of” or, even more technically, “is an instance of”) the generalization relationshipsclass 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 domainset of interest. Supposeobjects comprised by a concept of human thinking, like the concept person or the concept woman. Consequently, we also wantcan use the same type of statement to stateindicate that all mothers areMary 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 isalso reflexive , meaningbecomes clear that everyclass membership is its own subclass - this is intuitivenot exclusive: as well since clearly, every person is a person etc. Two classes can alsothere may be saiddiverse criteria to be equivalentgroup individuals (like gender, age, shoe size, etc.), one individual may well belong to several classes simultaneously.

4.2 Class Hierarchies

In the sense that they contain exactly the same individuals. The following example states thatprevious section, we were talking about two classes: the class Person is equivalentof all persons and that of all women. 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> Statingreader it is clear that Person and Humanthese two classes are equivalent amounts exactly to the same as stating that both Person isin a subclass of Human and Humanspecial relationship: Person is a subclass of Person. 3.3 Class Disjointness In Section 4.3,more general than Woman, meaning that whenever we statedknow some individual to be a woman, that anindividual canmust be an instance of several classes. However consideringa person. However, this correspondence cannot be derived from the classes Manlabels “Person” 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“Woman” but is part of ourthe human background knowledge about the world and hasour usage of those terms. Therefore, in order to be explicitly stated forenable a reasoningsystem to make use of it.draw the desired conclusions, it has to be informed about this correspondence. In OWL 2, this is done as follows: DisjointClasses( f:Woman f:Manby a so-called subclass axiom:

 SubClassOf( :Woman :Person )

 <owl:Class  rdf:about="#Man"/> </owl:members> </owl:AllDisjointClasses> _:x rdf:type owl:AllDisjointClasses ; owl:members ( f:Woman f:Man )rdf:about="Woman">
   <rdfs:subClassOf rdf:resource="Person"/>
 </owl:Class>

 :Woman rdfs:subClassOf :Person .

 Class: 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.SubClassOf: Person

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

The arguable reason forpresence of 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 disjointnessaxiom is neededin an ontology enables reasoners to deduceinfer for every individual which is specified as an instance of the class Woman, that Maryit is not a man. Moreover, givenan instance of the above axioms,class Person as well. As a reasoner can infer the disjointnessrule of thethumb, a subclass relationship between two classes MotherA and Man. 3.4 Object Properties InB can be specified, if the preceding sections we were concerned with describing single individuals, their class memberships,phrase “every A is a B” makes sense and how classes can relateis correct.

It is common in ontological modeling to each other based on their instances.use subclass statements not only for sporadically declaring such interdependencies, but more often than not, an ontology is also meantto specify howmodel whole class hierarchies by specifying the individuals relate to other individuals. Obviously thosegeneralization relationships are central when describing a family.of all classes in the domain of interest. Suppose we start by indicatingalso want to state that Mary is John's wife. PropertyAssertion( f:hasWife f:John f:Maryall 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 case, are called properties. Noteintuition. Technically, this means that the order in which the individuals are written downsubclass relationship between classes is important. While "Marytransitive. Besides this, it is John's wife" might be true, "Johnalso reflexive, meaning that every class is Mary's wife" certainly isn't. Indeed,its own subclass – this is a common source of modeling errors. Likewise, itintuitive as well since clearly, every person is importanta person etc.

Classes in our vocabulary may effectively refer to use property namesthe same sets, and OWL provides a mechanism by which allow only one unique intuitive reading. In case of nouns (like “wife”), such unambiguous names mightto they are considered to be constructions with “of” or with “has” (wifeOf or hasWife).semantically equivalent. For verbs (like “to love”) an inflected form (loves) or a passive version with “by” (lovedBy) would prevent unintended readings.example, we can also stateuse the term Person and Human interchangeably, meaning that every instance of the class Person is also an instance of class Human, and vice versa. Two individualsclasses are not connected by a property.considered equivalent if they contain exactly the following, for example,same individuals. The following example states that Marythe class Person is not Jack's wife. NegativeObjectPropertyAssertion( f:hasWife f:Jack f:Maryequivalent 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.24.1, we argued that it is useful to specifystated that an individual can be an instance of several classes. However, in some cases membership in one class specifically excludes membership implies another one. Essentiallyin another. For example, considering the same situationclasses Man and Woman, it can occur for properties: whenever B is known tobe A's wife, itexcluded that there is also known to be A's spouse (note,an individual that thisis not truean instance of both classes (for the other way round). OWL allows to specifysake of the example, we disregard biological borderline cases). This statement“incompatibility relationship” between classes is referred to 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(class) disjointness. 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,Again, the information that two individualsclasses 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 Bdisjoint is the wifepart 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. Inour example, this additional information canbackground knowledge and has to be expressed via class memberships. OWL providesexplicitly stated for a wayreasoning system to statemake use of it. This correspondence: PropertyDomain( f:hasWife f:Man ) PropertyRange( f:hasWife f:Womanis done as follows:

 DisjointClasses( :Woman :Man )

 <owl:AllDisjointClasses>
   <owl:members rdf:parseType="Collection">
     <owl:Class  &f;Man"/> </owl:ObjectPropertyDomain> <owl:ObjectPropertyRange> <owl:ObjectProperty IRI="&f;hasWife"/>rdf:about="Woman"/>
     <owl:Class  IRI="&f;Woman"/> </owl:ObjectPropertyRange> Having these two axiomsrdf: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 place and given e.g.practice, disjointness statements are often forgotten or neglected. The informationarguable reason for this could be that Sashaintuitively, classes are considered disjoint unless there is related to Hillary viaother evidence. By omitting disjointness statements, many potentially useful consequences can get lost. Note that in our example, the property hasWife, a reasoner would be abledisjointness axiom is needed to inferdeduce that SashaMary is not a man and Hillaryman. Moreover, given the above axioms, a woman. 3.7 Equality and Inequality of Individuals Note that from the information given so far, itreasoner can be deduced that John and Mary are notinfer the same as they are known to be instancesdisjointness of the disjointclasses 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 JohnMother 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 dangerousMan.

4.4 Object Properties

In the Semantic Web, where names may be coined by different organizations at different times unknowingly referring to the same individual.) Hence, ifpreceding sections we want to exclude the option of Johnwere concerned with describing single individuals, their class memberships, and Bill being the same individual, this hashow classes can relate 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> Iteach other based on their instances. But more often than not, an ontology is also possible to state that two names refermeant to (denote)specify how the same individual. For example,individuals relate to other individuals. These relationships are central when describing a family. We can saystart by indicating that John and Jack are the same individual. SameIndividual( f:John f:JackMary is John's wife.

 ObjectPropertyAssertion( :hasWife :John :Mary )

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

 :John :hasWife :Mary .

 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 aboutFacts: hasWife Mary

 <ObjectPropertyAssertion>
   <ObjectProperty IRI="hasWife"/>
   <NamedIndividual IRI="John"/>
   <NamedIndividual IRI="Mary"/>
 </ObjectPropertyAssertion>

Hereby, the individual Jack which is written down forentities describing in which way the individual John. 3.8 Datatypes So far, we have seen how we can describeindividuals via class memberships and via their relatedness to other individuals.are related – like hasWife in many cases, however,our case, are called properties.

Note that the order in which the individuals are towritten is important. While “Mary is John's wife” might be described by data values. Think of a person's birth date, his age, his email address etc. Fortrue, “John is Mary's wife” certainly isn't. Indeed, this purpose, OWL provides another kindis a common source of properties, so-called Datatype properties . These propertiesmodeling errors that can be avoided by using property names which allow to relate individuals to data values (insteadonly one unique intuitive reading. In case of to other individuals). The following isnouns (like “wife”), such unambiguous names might be constructions with “of” or with “has” (wifeOf or hasWife). For verbs (like “to love”) an example usinginflected form (loves) or a datatype property. It states that John's age is 51. PropertyAssertion( f:hasAge f:John "51"^^xsd:integer ) <f:Person rdf:about="#John"> <f:hasAge rdf:datatype=" http://www.w3.org/2001/XMLSchema#integer ">51</hasAge> </f:Person> f:John f:hasAge "51"^^xsd:integer . Individual: John Facts: hasAge "51"^^xsd:integer <owl:DataPropertyAssertion> <owl:DataProperty IRI="&f;hasAge"/> <owl:NamedIndividual IRI="&f;John"/> <owl:Literal datatypeIRI=" http://www.w3.org/2001/XMLSchema#integer ">51</owl:Literal> </owl:ataPropertyAssertion> Likewise,passive version with “by” (lovedBy) would prevent unintended readings.

We can also state that Jack's agetwo individuals are not connected by a property. The following, for example, states that Mary is not 53. NegativeDataPropertyAssertion( f:hasAge f:Jack "53"^^xsd:integerBill's wife.

 NegativeObjectPropertyAssertion( :hasWife :Bill :Mary )

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

 []  rdf:type               owl:NegativePropertyAssertion ;
     owl:sourceIndividual   f:Jack ; :Bill ;
     owl:assertionProperty  f:hasAge ; owl:targetValue "53"^^xsd:integer :hasWife ;
     owl:targetIndividual   :Mary .

 Individual:  JackBill
   Facts: not  hasAge "53"^^xsd:integer <owl:NegativeDataPropertyAssertion> <owl:DataProperty IRI="&f;hasAge"/> <owl:NamedIndividual IRI="&f;Jack"/> <owl:Literal datatypeIRI=" http://www.w3.org/2001/XMLSchema#integer ">53</owl:Literal> </owl: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 behasWife Mary

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

Negative property assertions provide a datatype instead of a class. The following states that the hasAge property is only usedunique opportunity to relate persons with non-negative integers. PropertyDomain( f:hasAge f:Person ) PropertyRange( f:hasAge xsd:NonNegativeInteger ) <owl:DatatypeProperty rdf:about="#hasAge"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:datatpye="&xsd;NonNegativeInteger"/> </owl:DatatypeProperty> f:hasAge rdfs:domain f:Person ; rdfs:range xsd:NonNegativeInteger . DatatpyeProperty: hasAge Domain: Person Range: xsd:NonNegativeInteger <owl:DatatypePropertyDomain> <owl:DatatypeProperty IRI="&f;hasAge"/> <owl:Class IRI="&f;Person"/> </owl:DatatypePropertyDomain> <owl:DatatypePropertyRange> <owl:DatatypeProperty IRI="&f;hasAge"/> <owl:Datatype IRI="&xsd;NonNegativeInteger"/> </owl:DatatypePropertyRange>make statements where we would like to point out atknow something that is not true. This stage a common mistake which easily occurs when using property domains and ranges.kind of information is particularly important in OWL where the example just given, which statesdefault stance is that the hasAgeanything is possible until you say otherwise.

4.5 Property Hierarchies

In Section 4.2 we argued that it is only useduseful to relate persons with non-negative integers, assume that we alsospecify the informationthat Felix is in theone class Cat and that Felix hasAge 9. Frommembership implies another one. Essentially the combined information, it would then be possiblesame situation can occur for properties: whenever B is known to deduce that Felixbe A's wife, it is also in the class Person, whichknown to be A's spouse (note, that this is probablynot intended.true the other way round). OWL allows to specify this is a commonly modelling error: note that a domain (or range)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>

There is notalso a constraint onsyntactic shortcut for property equivalence, which is similar to class equivalence.

4.6 Domain and Range Restrictions

Frequently, the knowledge, butinformation that two individuals are interconnected by a certain property allows to inferdraw further knowledge. If we state - asconclusions about the individuals themselves. In our example -particular, one might infer class memberships. For instance, the statement that an ageB is only given for persons, then everything we give an age for automatically becomesthe wife of A person. 4 Advanced Class Relationshipsobviously implies that B is a woman while A is a man. So in a way, the previous sections we have dealt with classes as something "opaque" carryingstatement that two individuals are related via a name. We used themcertain 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 characterize individuals,state this correspondence:

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

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

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

 ObjectProperty: hasWife
   Domain: Man
   Range: Woman

 <ObjectPropertyDomain>
   <ObjectProperty IRI="hasWife"/>
   <Class 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 themto other classesHillary via subclass or disjointness statements. We will now demonstrate how named classes, properties,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 useddeduced that John and Mary are not the same individual as building blocksthey are known to define new classes. 4.1 Complex Classesbe instances of the language elements describeddisjoint 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 allow to model simple ontologies. But their expressivity hardly surpassesthat of RDFS. In order to express more complex knowledge, OWL provides logical class constructors. In particular, OWL provides language elements for logical and, or,implies that John and not.Bill are not the correspondingsame. OWL termsdoes not make the assumption that different names are borrowed from set theory: (class) intersection , union and complement . These constructors allow to combine atomic classes – i.e. classes withnames –for different individuals. (This lack of a required “unique names assumption” is particularly well-suited to complex classes. Those class expressions canSemantic Web applications where names may be used anywhere The intersection of two classes consists of exactly those individuals which are instances of both classes.coined by different organizations at different times unknowingly referring to the following example states thatsame individual.) Hence, if we want to exclude the class Mother consists of exactly those objects which are instancesoption of both WomanJohn 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:ParentBill 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 all instances oftwo names refer to (denote) the class Mothersame individual. For example, we can say that John and Jack 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:Fathersame individual.

 SameIndividual( :James :Jim )

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

 :James owl:sameAs :Jim.

 Individual: James
   SameAs: Jim

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

This would enable a class correspondsreasoner 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 demonstratesinfer 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> Allany information given about the above examples demonstrateindividual James also holds for the usage ofindividual Jim.

4.8 Datatypes

So far, we have seen how we can describe individuals via class constructorsmemberships and via their relatedness to other individuals. In ordermany cases, however, individuals are to define new classes as combination as others. But,be described by data values. Think of course, it is also possible to use class constructors together witha subclass statement in order to indicate necessary, but not sufficient conditionsperson's birth date, his age, his email address etc. For a class.this purpose, OWL provides another kind of properties, so-called Datatype properties. These properties relate individuals to data values (instead of to other individuals). The following statement indicates that every Fatheris both a man andan example using a parent (whereas the conversedatatype property. It states that John's age 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:Parent51.

 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 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 _:x2state 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:Class ; owl:complementOf f:Parentowl:NegativePropertyAssertion ;
     owl:sourceIndividual   :Jack ;
     owl:assertionProperty  :hasAge ;
     owl:targetValue        53 .

 Individual:  John Types: Person andJack
   Facts: 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 constructorshasAge "53"^^xsd:integer