1. Web Ontology Language (OWL)
Prepared by:
Ameer Sameer Hamood
University of Babylon - Iraq
Information Technology - Information Networks

2. Overview Introduction to Web Ontology Language (OWL)
Requirements for ontology languages
Three species of OWL
Syntactic forms of OWL
OWL Header
Class elements & Class expressions
Property elements & Property restrictions
Special properties
Boolean combination
Datatypes

3. Introduction What You Should Already Know
Before you study OWL you should have a basic understanding of XML, XML Namespaces and RDF.
OWL is Different from RDF
OWL and RDF are much of the same thing, but OWL is a stronger language with greater machine interpretability than RDF.
OWL comes with a larger vocabulary and stronger syntax than RDF.
RDF and RDF schema is limited to binary ground predicate and RDF schema is limited to subclass hierarchy and a property hierarchy with domain and range definition of these properties

4. Introduction (cont..) Stack of Languages XML XML Schema RDF RDF Schema
Surface syntax, no semantics
XML Schema
Describes structure of XML documents
RDF
Datamodel for \relations" between \things“
RDF Schema
RDF Vocabulary Definition Language
OWL
A more expressive Vocabulary Definition Language

5. Introduction (cont..)
Figure 1

6. Technologies for the Semantic Web
Figure 2

7. What is Ontology?
Ontology is about the exact description of things and their relationships.
For the web, ontology is about the exact description of web information and relationships between web information.
W3C Recommendation, February 2004 web standard Web Ontology Language built on top of RDF
RDF: the Resource Description Framework is an XML-based language to describe resources. for processing information on the web designed to be interpreted by computers, not for being read by people OWL is written in XML
Fig1 :Ontology languages in the
Semantic Web Architecture
Figure 3

8. Markup ontology languages
These languages use a markup scheme to encode knowledge, most commonly with XML.
DARPA Agent Markup Language (DAML+OIL)
Ontology Inference Layer (OIL)
Ontology Web Language (OWL)
Resource Description Framework (RDF)
RDF Schema (RDFS)
Simple HTML Ontology Extensions (SHOE)
Ontology Exchange Language (OXL)
The Web Ontology Language OWL is a semantic markup language for publishing and sharing ontologies on the World Wide Web. OWL is developed as a vocabulary extension of RDF (the Resource Description Framework) and is derived from the DAML+OIL Web Ontology Language.

9. Introduction to Ontology Web Language (OWL)
What is OWL?
OWL stands for Web Ontology Language
OWL is built on top of RDF
OWL is for processing information on the web
OWL was designed to be interpreted by computers
OWL was not designed for being read by people
OWL is written in XML
OWL has three sublanguages
- OWL Lite , OWL DL , OWL Full
OWL is a W3C standard
OWL is Written in XML
By using XML, OWL information can easily be exchanged between different types of computers using different types of operating system and application languages.
OWL is Different from RDF
OWL and RDF are much of the same thing, but OWL is a stronger language with greater machine interpretability than RDF.
OWL comes with a larger vocabulary and stronger syntax than RDF.
OWL was Designed for Processing Information
OWL was designed to provide a common way to process the content of web information (instead of displaying it).
OWL was designed to be read by computer applications (instead of humans).
Why OWL?
OWL is a part of the "Semantic Web Vision" - a future where:
Web information has exact meaning
Web information can be processed by computers
Computers can integrate information from the web
Lite DL
Full

10. Introduction to Ontology Web Language (cont..)
Explicit
Formal
Specification
Consensus
Perception
One of the first definitions was given by Neches and colleagues (1991) who defined an ontology as follows:
An ontology defines the basic terms and relations comprising the
vocabulary of a topic area as well as the rules for combining terms and
relations to define extensions to the vocabulary.
This descriptive definition tells us what to do to build an ontology, and gives us some vague guidelines: this definition identifies basic terms and relations between terms, identifies rules to combine terms, and provides the definitions of such terms and relations. Note that, according to Neches’ definition, an ontology includes not only the terms that are explicitly defined in it, but also the knowledge that can be inferred from it. A few years later, Gruber (1993a) defined an ontology as follows: An ontology is an explicit specification of a conceptualization.
Figure 4

11. Requirements for ontology languages
Ontology languages allow users to write explicit, formal conceptualizations of domains models. The main requirements are:
1. a well-defined syntax
2. a well-defined semantics
3. efficient reasoning support
4. sufficient expressive power
5. convenience of expression.
The importance of a well-defined syntax is clear, and known from the area of programming languages; it is a necessary condition for machine-processing of information. All the languages we have presented so far have a well-defined syntax. DAML+OIL and OWL build upon RDF and RDFS and have the same kind of syntax. Of course it is questionable whether the XML-based RDF syntax is very user-friendly, there are alternatives better suitable for humans (for example, see the OIL syntax). However this drawback is not very signicant, because ultimately users will be developing their ontologies using authoring tools, or more generally ontology development tools, instead of writing them directly in DAML+OIL or OWL.
>>>>>>
DAML+OIL is a successor language to DAML and OIL that combines features of both. In turn, it was superseded by Web Ontology Language (OWL).
DAML stands for DARPA Agent Markup Language. OIL stands for Ontology Inference Layer or Ontology Interchange Language. The DAML program ended in early 2006.
DAML+OIL is a semantic markup language for Web resources. It builds on earlier W3C standards such as RDF and RDF Schema, and extends these languages with richer modelling primitives. DAML+OIL provides modelling primitives commonly found in frame-based languages. DAML+OIL (March 2001) extends DAML+OIL (December 2000) with values from XML Schema datatypes. DAML+OIL was built from the original DAML ontology language DAML-ONT (October 2000) in an effort to combine many of the language components of OIL. The language has a clean and well defined semantics.
OIL (Ontology Inference Layer or Ontology Interchange Language) can be regarded as an ontology infrastructure for the Semantic Web. OIL is based on concepts developed in Description Logic (DL) and frame-based systems and is compatible with RDFS.
>>>>>>>>
Formal semantics describes precisely the meaning of knowledge. \Precisely" here means that the semantics does not refer to subjective intuitions,nor is it open to different interpretations by different persons (or machines).The importance of formal semantics is well-established in the domain of mathematical logic, among others.
One use of formal semantics is to allow humans to reason about the knowledge. For ontological knowledge we may reason about:
Class membership: If x is an instance of a class C, and C is a subclass of D, then we can infer that x is an instance of D. Equivalence of classes: If class A is equivalent to class B, and class B equivalent to class C, then A is equivalent to C, too.
Consistency: Suppose we have declared x to be an instance of the class A.
Further suppose that
- A is a subclass of B \ C
- A is a subclass of D
- B and D are disjoint
Then we have an inconsistency because A should be empty, but has the
instance x. This is an indication of an error in the ontology.
Classication: If we have declared that certain property-value pairs are
sucient condition for membership of a class A, then if an individual x
satises such conditions, we can conclude that x must be an instance of A.
>>>>>>>
Semantics is a prerequisite for reasoning support: Derivations such as the above
can be made mechanically, instead of being made by hand. Reasoning support
is important because it allows one to
check the consistency of the ontology and the knowledge;
check for unintended relationships between classes.
automatically classify instances in classes
Automated reasoning support allows one to check many more cases than what
can be done manually. Checks like the above are valuable for
designing large ontologies, where multiple authors are involved;
integrating and sharing ontologies from various sources.
Formal semantics and reasoning support is usually provided by mapping an
ontology language to a known logical formalism, and by using automated
reasoners that already exist for those formalisms. We will see that OWL is
(partially) mapped on a description logic, and makes use of existing reasoners
such as FaCT and RACER.
>>>>>>>>>>>>>>
Limitations of the expressive power of RDF Schema
RDF and RDFS allow the representation of some ontological knowledge. The
main modelling primitives of RDF/RDFS concern the organization of vocab in typed hierarchies: subclass and subproperty relationships, domain
and range restrictions, and instances of classes. However a number of other features are missing. Here we list a few:
Local scope of properties: rdfs:range defines the range of a property, say eats, for all classes. Thus in RDF Schema we cannot declare range
restrictions that apply to some classes only. For example, we cannot say that cows eat only plants, while other animals may eat meat, too.
 Disjointness of classes: Sometimes we wish to say that classes are disjoint.
For example, male and female are disjoint. But in RDF Schema we can
only state subclass relationships, e.g. female is a subclass of person.
Boolean combinations of classes: Sometimes we wish to build new classes by combining other classes using union, intersection and complement. For
example, we may wish to dene the class person to be the disjoint union of the classes male and female. RDF Schema does not allow such denitions. Cardinality restrictions: Sometimes we wish to place restrictions on how many distinct values a property may or must take. For example, we would
like to say that a person has exactly two parents, and that a course is
taught by at least one lecturer. Again such restrictions are impossible to
express in RDF Schema.
Special characteristics of properties: Sometimes it is useful to say that a
property is transitive (like \greater than"), unique (like \is mother of"),
or the inverse of another property (like \eats" and \is eaten by").
So we need an ontology language that is richer than RDF Schema, a language
that o ers these features and more. In designing such a language one should
be aware of the tradeo between expressive power and ecient reasoning sup-
port. Generally speaking, the richer the language is, the more inecient the
reasoning support becomes, often crossing the border of non-computability.
Thus we need a compromise, a language that can be supported by reasonably
ecient reasoners, while being suciently expressive to express large classes
of ontologies and knowledge..
Compatibility of OWL with RDF/RDFS
Ideally, OWL would be an extension of RDF Schema, in the sense that
OWL would use the RDF meaning of classes and properties ( rdfs:Class,
rdfs:subClassOf, etc), and would add language primitives to support the
richer expressiveness identied above.
Unfortunately, the desire to simply extend RDF Schema clashes with
the trade-o between expressive power and ecient reasoning mentioned be-
fore. RDF Schema has some very powerful modelling primitives, such as the
rdfs:Class (the class of all classes) and rdf:Property (the class of all properties). These primitives are very expressive, and will lead to uncontrollable
computational properties if the logic is extended with the expressive primitives
identied above.

12. Three species of OWL
1- OWL Full: uses all the OWL languages primitives. It also allows to combine these primitives in arbitrary ways with RDF and RDF Schema. OWL Full allows free mixing of OWL with RDF Schema and, like RDF Schema, does not enforce a strict separation of classes, properties, individuals and data values. OWL Full is that it is fully compatible with RDF, both syntactically and semantically.
OWL Full the resource owl:Class is equivalent to rdfs:Class.
NOTE: RDF documents will generally be in OWL Full, unless they are specifically constructed to be in OWL DL or Lite.
OWL Full owl:ObjectProperty is equivalent to rdf:Property.
OWL Full: The entire language is called OWL Full, and uses all the OWL
languages primitives (which we will discuss later in this chapter). It also
allows to combine these primitives in arbitrary ways with RDF and RDF
Schema. This includes the possibility (also present in RDF) to change the
meaning of the pre-dened (RDF or OWL) primitives, by applying the
language primitives to each other. For example, in OWL Full we could im-
pose a cardinality constraint on the class of all classes, essentially limiting
the number of classes that can be described in any ontology.
The advantage of OWL Full is that it is fully upward compatible with
RDF, both syntactically and semantically: any legal RDF document is also
a legal OWL Full document, and any valid RDF/RDF Schema conclusion
is also a valid OWL Full conclusion.
The disadvantage of OWL Full is the language has become so powerful
as to be undecidable, dashing any hope of complete (let alone ecient)
reasoning support.
OWL DL: In order to regain computational eciency, OWL DL (short
for: Description Logic) is a sublanguage of OWL Full which restricts the
way in which the constructors from OWL and RDF can be used. We will
give details later, but roughly this amounts to disallowing application of
OWL's constructor's to each other, and thus ensuring that the language
corresponds to a well studied description logic.
The advantage of this is that it permits ecient reasoning support.
The disadvantage is that we loose full compatibility with RDF: an RDF
document will in general have to be extended in some ways and restricted
in others before it is a legal OWL DL document. Conversely, every legal
OWL DL document is still a legal RDF document.
OWL Lite: An ever further restriction limits OWL DL to a subset of
the language constructors. For example, OWL Lite excludes enumerated
classes, disjointness statements and arbitrary cardinality (among others).
The advantage of this is a language that is both easier to grasp (for users)
and easier to implement (for tool builders).
The disadvantage is of course a restricted expressivity.
Ontology developers adopting OWL should consider which sublanguage
best suits their needs. The choice between OWL Lite and OWL DL depends on
the extent to which users require the more-expressive constructs provided by
OWL DL and OWL Full. The choice between OWL DL and OWL Full mainly
depends on the extent to which users require the meta-modeling facilities
of RDF Schema (e.g. dening classes of classes, or attaching properties to
classes). When using OWL Full as compared to OWL DL, reasoning support is
less predictable since complete OWL Full implementations will be impossible. ::
OWL Full the universe of individuals consists of all resources (owl:Thing is equivalent to rdfs:Resource).
OWL Full owl:ObjectProperty is equivalent to rdf:Property.
in OWL Full the universe of individuals consists of all resources (owl:Thing is equivalent to rdfs:Resource). This means that object properties and datatype properties are not disjoint. In OWL Full owl:ObjectProperty is equivalent to rdf:Property.
<owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#Eurasia"/> <owl:Thing rdf:about="#Africa"/> <owl:Thing rdf:about="#NorthAmerica"/> <owl:Thing rdf:about="#SouthAmerica"/> <owl:Thing rdf:about="#Australia"/> <owl:Thing rdf:about="#Antarctica"/> </owl:oneOf> </owl:Class>

13. Three species of OWL (cont ..)
2- OWL DL = Description Logic is a sublanguage of OWL Full which restricts the way in which the constructors from OWL and RDF can be used.
OWL DL puts constraints on the mixing with RDF and requires disjointness of classes, properties, individuals and data values.
The advantage of this is that it permits efficient reasoning support.
The disadvantage is that we loose full compatibility with RDF. Most RDF(S) vocabulary cannot be used within OWL DL.
owl:Class is a proper subclass of rdfs:Class (meaning that not all RDF classes are OWL classes in OWL DL and OWL Lite).
OWL DL is a sublanguage of OWL which places a number of constraints on the use of the OWL language constructs. Briefly, these constraints are the following:
OWL DL requires a pairwise separation between classes, datatypes, datatype properties, object properties, annotation properties, ontology properties (i.e., the import and versioning stuff), individuals, data values and the built-in vocabulary. This means that, for example, a class cannot be at the same time an individual.
In OWL DL the set of object properties and datatype properties are disjoint. This implies that the following four property characteristics:
inverse of,
inverse functional,
symmetric, and
transitive
can never be specified for datatype properties
OWL DL requires that no cardinality constraints (local nor global) can be placed on transitive properties or their inverses or any of their superproperties.
Annotations are allowed only under certain conditions.

14. Three species of OWL (cont ..)
3- OWL Lite
An ever further restriction limits OWL DL to a subset of the language constructors. For example, OWL Lite excludes enumerated classes, disjointness statements and arbitrary cardinality (among others).
The advantage of this is a language that is both easier to grasp (for users) and easier to implement (for tool builders).
- The disadvantage is of course a restricted expressivity.
OWL Lite forbids the use of:
owl:oneOf
owl:unionOf
owl:complementOf
owl:hasValue
owl:disjointWith
owl:DataRange
OWL Lite also requires that:
the subject of owl:equivalentClass triples be class names and the object of owl:equivalentClass triples be class names or restrictions.
the subject of rdfs:subClassOf triples be class names and the object of rdfs:subClassOf triples be class names or restrictions;
owl:intersectionOf be used only on lists of length greater than one that contain only class names and restrictions; NOTE: This is a prototypical example of legal use of owl:intersectionOf in OWL Lite:
<owl:Class rdf:ID="Woman"> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Female"/> <owl:Class rdf:about="#Human"/> </owl:intersectionOf> </owl:Class/>
the object of owl:allValuesFrom and owl:someValuesFrom triples be class names or datatype names;
the object of rdf:type triples be class names or restrictions;
the object of rdfs:domain triples be class names; and
the object of rdfs:range triples be class names or datatype names.
OWL Lite forbids the use of:
owl:oneOf
owl:unionOf
owl:complementOf
owl:hasValue
owl:disjointWith
owl:DataRange
Figure 5

15. Three species of OWL (cont ..)
Subclass relationships between OWL and RDF/RDFS
Figure 6

16. Syntactic forms of OWL There are different syntactic forms of OWL:
1- RDF’s XML-based syntax (primary syntax for OWL)
an XML-based syntax that does not follow the RDF conventions (more easily read by human users) see
2- an abstract syntax (used in the language specification document) (much more compact and readable) see
3- a graphic syntax based on the conventions of UML
(an easy way for people to become familiar with OWL)
XML provides a surface syntax for structured documents, but imposes no semantic constraints on the meaning of these documents.
XML Schema is a language for restricting the structure of XML documents and also extends XML with datatypes.
RDF is a datamodel for objects ("resources") and relations between them, provides a simple semantics for this datamodel, and these datamodels can be represented in an XML syntax.
RDF Schema is a vocabulary for describing properties and classes of RDF resources, with a semantics for generalization-hierarchies of such properties and classes.
OWL adds more vocabulary for describing properties and classes: among others, relations between classes (e.g. disjointness), cardinality (e.g. "exactly one"), equality, richer typing of properties, characteristics of properties (e.g. symmetry), and enumerated classes.
>>>>>>
The perspective role of UML as a conceptual modelling language for the semantic web has become an important research topic. We argue that UML could be a key technology for overcoming the ontology development bottleneck thanks to its wide acceptance and sophisticated tool support. Transformational approaches are a promising way of establishing a connection between UML and web-based ontology languages.
Unified Modeling Language (UML)
which has graphical and XML-based formats, a huge user community, a high level of commercial tool support and an associated highly expressive constraint language.

17. Header
OWL documents are usually called OWL ontologies, and are RDF documents.
So the root element of a OWL ontology is an rdf:RDF element which also species a number of namespaces. For example:
<rdf:RDF
xmlns:owl ="
xmlns:rdf =" syntax-ns#"
xmlns:rdfs="
xmlns:xsd="
This is a conventional OWL declaration, used to introduce the OWL vocabulary.

18. Header (cont...)
An OWL ontology may start with a collection of assertions for housekeeping purposes. These assertions are grouped under an owl:Ontology element which contains comments, version control and inclusion of other ontologies. For example:
<owl:Ontology rdf:about="">
<rdfs:comment>An example OWL ontology</rdfs:comment>
<owl:priorVersion rdf:resource="
<owl:imports rdf:resource="
<rdfs:label>University Ontology</rdfs:label>
</owl:Ontology>
The owl:Ontology element is a place to collect much of the OWL meta-data for the document. It does not guarantee that the document describes an ontology in the traditional sense. In some communities, ontologies are not about individuals but only the classes and properties that define a domain. When using OWL to describe a collection of instance data the owl:Ontology tag may be needed in order to record version information and to import the definitions that the document depends on. Thus, in OWL the term ontology has been broadened to include instance data
>>>>>>
The rdf:about attribute provides a name or reference for the ontology. Where the value of the attribute is "", the standard case, the name of the ontology is the base URI of the owl:Ontology element. Typically, this is the URI of the document containing the ontology. An exception to this is a context that makes use of xml:base which may set the base URI for an element to something other than the URI of the current document.
>>>>>
rdfs:comment provides the obvious needed capability to annotate an ontology.
owl:priorVersion is a standard tag intended to provide hooks for version control systems working with ontologies.
Ontologies are like software, they will be maintained and thus will change over time.
it is possible to link to a previous version of the ontology being defined. The owl:priorVersion property is intended to provide this link, and can be used to track the version history of an ontology.
<owl:Ontology rdf:about=""> ... <owl:priorVersion rdf:resource=" ... </owl:Ontology> The indicated ontology is a previous version of the one being defined
>>>>>>>>>
owl:imports provides an include-style mechanism. owl:imports takes a single argument, identified by the rdf:resource attribute.
Importing another ontology brings the entire set of assertions provided by that ontology into the current ontology. In order to make best use of this imported ontology it would normally be coordinated with a namespace declaration. Notice the distinction between these two mechanisms. The namespace declarations provide a convenient means to reference names defined in other OWL ontologies. Conceptually, owl:imports is provided to indicate your intention to include the assertions of the target ontology. Importing another ontology, O2, will also import all of the ontologies that O2 imports.
Note that owl:imports may not always succeed. As you would expect when dealing with the Semantic Web, access to resources distributed across the Web may not always be possible. Tools will respond to this situation in an implementation defined manner.
Note that in order to use the OWL vocabulary you do not need to import the owl.rdf ontology. In fact, such an import is not recommended.
The rdfs:label entry provides an optional human readable name for this class. Presentation tools can make use of it. The "lang" attribute provides support for multiple languages. A label is like a comment and contributes nothing to the logical interpretation of an ontology.
<rdfs:label xml:lang="en">wine</rdfs:label>
<rdfs:label xml:lang="fr">vin</rdfs:label>

19. Header Example
Although an ontology doesn't have to include a header, it is a good place to include information that will help others to understand what your ontology contains.
As above, we've included a title and description for the ontology. But, this is also the place where we could include version information (to make sure you can appropriately track and communicate updates to your ontology) and where you can state that your ontology imports other ontologies.
If your ontology does use elements from other ontologies, this will be absolutely necessary for tools or frameworks to know that your ontology is dependent on others.
Figure 7

20. Class elements Classes are defined using a owl:Class element
For example, we can define a class associateProfessor as follows:
<owl:Class rdf:ID="associateProfessor">
<rdfs:subClassOf rdf:resource="#academicStaffMember"/>
</owl:Class>
constructor for classes is rdfs:subClassOf. It relates a more specific class to a more general class. If X is a subclass of Y, then every instance of X is also an instance of Y. The rdfs:subClassOf relation is transitive. If X is a subclass of Y and Y a subclass of Z then X is a subclass of Z.
Class descriptions form the building blocks for defining classes through class axioms. The simplest form of a class axiom is a class description of type 1, It just states the existence of a class, using owl:Class with a class identifier.
For example, the following class axiom declares the URI reference #Human to be the name of an OWL class:
<owl:Class rdf:ID="Human"/> This is correct OWL, but does not tell us very much about the class Human. Class axioms typically contain additional components that state necessary and/or sufficient characteristics of a class. OWL contains three language constructs for combining class descriptions into class axioms:
rdfs:subClassOf allows one to say that the class extension of a class description is a subset of the class extension of another class description.
owl:equivalentClass allows one to say that a class description has exactly the same class extension as another class description.
owl:disjointWith allows one to say that the class extension of a class description has no members in common with the class extension of another class description.
:::::::;
rdfs:subClassOf
AXIOM SCHEMA: class description rdfs:subClassOf class description
The rdfs:subClassOf construct is defined as part of RDF Schema [RDF Vocabulary]. Its meaning in OWL is exactly the same: if the class description C1 is defined as a subclass of class description C2, then the set of individuals in the class extension of C1 should be a subset of the set of individuals in the class extension of C2. A class is by definition a subclass of itself (as the subset may be the complete set).
An example:
<owl:Class rdf:ID="Opera"> <rdfs:subClassOf rdf:resource="#MusicalWork" /> </owl:Class> This class axiom declares a subclass relation between two OWL classes that are described through their names (Opera and MusicalWork). Subclass relations provide necessary conditions for belonging to a class. In this case, to be an opera the individual also needs to be a musical work.
NOTE: In OWL Lite the subject of an rdfs:subClassOf statement must be a class identifier. The object must be either a class identifier or a property restriction.
For any class there may be any number of subClassOf axioms. For example, we could add the following axiom about the class Opera:
<owl:Class rdf:about="#Opera"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasLibrettist" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class> This class axiom contains a property restriction. The example states that Opera is a subclass of an anonymous OWL class (remember: owl:Restriction is a subclass of owl:Class) that has as its class extension the set of all individuals for which the property hasLibrettist has at least one value. Thus, operas should have at least one librettist.
Class axioms can get more complex when class descriptions are nested. For example, property restrictions with an owl:allValuesFrom or owl:someValuesFrom statement may point to any class description. Consider the following example:
<owl:Class rdf:ID="TraditionalItalianOpera"> <rdfs:subClassOf rdf:resource="#Opera"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasOperaType"/> <owl:someValuesFrom> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#OperaSeria"/> <owl:Thing rdf:about="#OperaBuffa"/> </owl:oneOf> </owl:Class> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> This example shows the use of the owl:oneOf construct. The class axiom defines traditional Italian opera as a subclass of a class of operas that have as opera type either opera seria or opera buffa (without an additional cardinality constraint, it could actually have both values).
More examples can be found in the Guide document [OWL Guide]. Subclass axioms provide us with partial definitions: they represent necessary but not sufficient conditions for establishing class membership of an individual. In the next subsection we will see that for defining necessary and sufficient conditions OWL provides the owl:equivalentClass construct. As a stepping stone to such axioms, consider the following example:
<owl:Class rdf:ID="Operetta"> <rdfs:subClassOf rdf:resource="#MusicalWork"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hasLibrettist" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Class> <owl:complementOf rdf:resource="#Opera"/> </owl:Class> </rdfs:subClassOf> </owl:Class> This class axiom states that an operetta is a musical work, that has a at least one librettist and is not an opera. The use of the subclass relation leaves open the possibility that there are other musical works that have a librettist and are not operas. If we had wanted to say that operetta's are exactly those musical works that have a librettist but are not operas, we would need to use the owl:equivalentClass construct.

21. Class elements (cont..)
We can also say that this class is disjoint from the professor and assistantProfessor classes using owl:disjointWith elements.
<owl:Class rdf:about="associateProfessor">
<owl:disjointWith rdf:resource="#professor“ />
<owl:disjointWith rdf:resource="#assistantProfessor"/>
</owl:Class>
Example 2 :
<owl:Class rdf:about="#Man">
<owl:disjointWith rdf:resource="#Woman"/> </owl:Class>
The disjointness of a set of classes can be expressed using the owl:disjointWith constructor. It guarantees that an individual that is a member of one class cannot simultaneously be an instance of a specified other class.

22. Class elements (cont..)
Equivalence of classes can be defined using a owl:equivalentClass element:
<owl:Class rdf:ID="faculty">
<owl:equivalentClass
rdf:resource="#academicStaffMember"/>
</owl:Class>
Finally, there are two predefiened classes, owl:Thing and owl:Nothing.
The former is the most general class which contains everything (everything is
a thing), the latter is the empty class. Thus every class is a subclass of
owl:Thing and a superclass of owl:Nothing.
Note that we have only said that there exist classes that have been given these names, indicated by the 'rdf:ID=' syntax. Formally, we know almost nothing about these classes other than their existence, despite the use of familiar English terms as labels. And while the classes exist, they may have no members. For all we know at the moment, these classes might as well have been called Thing1, Thing2, and Thing3.
>>>>>>
The property owl:equivalentClass is used to indicate that two classes have precisely the same instances. Note that in OWL DL, classes simply denote sets of individuals, and are not individuals themselves. In OWL Full, however, we can use owl:sameAs between two classes to indicate that they are identical in every way.

23. Class expressions
A class expression is the name used in this document for either
1- a class name (a URI), or
2- an enumeration, enclosed in <owl:Class>...</owl:Class> tags, or
3- a property-restriction, or
4- a boolean combination of class expressions, enclosed in <rdfs:Class>...</rdfs:Class> tags
Each class expression either refers to a named class, namely the class that is identified by the URI, or implicitly defines an anonymous class, respectively the class that contains exactly the enumerated elements, or the class of all instances which satisfy the property-restriction, or the class that satisfies the boolean combination of such expressions.
Two class names are already predefined, namely the classes owl:Thing and owl:Nothing. Every object is a member of owl:Thing, and no object is a member of owl:Nothing. Consequently, every class is a subclass of owl:Thing and owl:Nothing is a subclass of every class.

24. Class expressions (cont..)
Enumerations
An enumeration is a owl:oneOf element, containing a list of the objects that are its instances.
For example:
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Eurasia"/>
<owl:Thing rdf:about="#Africa"/>
<owl:Thing rdf:about="#North_America"/>
<owl:Thing rdf:about="#South_America"/>
<owl:Thing rdf:about="#Australia"/>
<owl:Thing rdf:about="#Antarctica"/>
</oneOf>
Enumerations
An enumeration is a owl:oneOf element, containing a list of the objects that are its instances. This enables us to define a class by exhaustively enumerating its elements. The class defined by the oneOf element contains exactly the enumerated elements, no more, no less An enumeration is a owl:oneOf element, and is used to dene a class by listing all its elements.
<owl:oneOf rdf:parseType="Collection">
<owl:Thing rdf:about="#Monday"/>
<owl:Thing rdf:about="#Tuesday"/>
<owl:Thing rdf:about="#Wednesday"/>
<owl:Thing rdf:about="#Thursday"/>
<owl:Thing rdf:about="#Friday"/>
<owl:Thing rdf:about="#Saturday"/>
<owl:Thing rdf:about="#Sunday"/>
</owl:oneOf>
>>>>>
oneOf
OWL provides the means to specify a class via a direct enumeration of its members. This is done using the oneOf construct. Notably, this definition completely specifies the class extension, so that no other individuals can be declared to belong to the class.
The following defines a class WineColor whose members are the individuals White, Rose, and Red.
<owl:Class rdf:ID="WineColor"> <rdfs:subClassOf rdf:resource="#WineDescriptor"/> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="#White"/> <owl:Thing rdf:about="#Rose"/> <owl:Thing rdf:about="#Red"/> </owl:oneOf> </owl:Class>

25. Class expressions (cont..)
instances
Instances of both classes (i.e., objects) and of properties (i.e., pairs) are written in RDF/XML syntax.
<Continent rdf:ID="Africa"/>
<rdf:Description rdf:ID="Asia">
<rdf:type>
<rdfs:Class rdf:about="#Continent"/>
</rdf:type>
</rdf:Description>
<rdf:Description rdf:ID="India">
<isPartOf rdf:resource="#Asia"/>
Instances of classes are declared as in RDF. For example:
<rdf:Description rdf:ID="949352">
<rdf:type rdf:resource="#academicStaffMember"/>
</rdf:Description>
or equivalently:
<academicStaffMember rdf:ID="949352"/>
We can also provide further details, such as:
<academicStaffMember rdf:ID="949352">
<uni:age rdf:datatype="&xsd;integer">39<uni:age>
</academicStaffMember>
Unlike typical database systems, OWL does not adopt the unique names
assumption, thus: just because two instances have a dierent name (or: ID),
that does not imply that they are indeed dierent individuals. For example,
if we state that each course is taught by at most one one sta member:
<owl:ObjectProperty rdf:ID="isTaughtBy">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
</owl:ObjectProperty>
and we subsequently state that a given course is taught by two sta mem-
bers:
<course rdf:about="CIT1111">
<isTaughtBy rdf:resource="949318">
<isTaughtBy rdf:resource="949352">
</course>
this does not cause an OWL reasoner to ag an error. After all, the system
could validly infer that the resources "949318" and "949352" are apparently
equal. To ensure that dierent individuals are indeed recognised as such, we
must explicitly assert their inequality:
<lecturer rdf:about="949318">
<owl:differentFrom rdf:resource="949352">
</lecturer>
Because such inequality statements occur frequently, and the required
number of such statements would explode if we wanted to state the inequality
of a large number of individuals, OWL provides a shorthand notation to assert
the pairwise inequality of all individuals in a given list:
<owl:allDifferent>
<owl:distinctMembers rdf:parseType="Collection">
<lecturer rdf:about="949352">
<lecturer rdf:about="949111">
</owl:distinctMembers>
</owl:allDifferent>
>>>>>>>>
<Continent rdf:ID="Africa"/> <rdf:Description rdf:ID="Asia"> <rdf:type> <rdfs:Class rdf:about="#Continent"/> </rdf:type> </rdf:Description> <rdf:Description rdf:ID="India"> <isPartOf rdf:resource="#Asia"/> </rdf:Description> There is no unique name assumption for objects in OWL. To state that objects are the same, an owl:sameIndividualAs element is used. (Note that owl:sameAs can be also used here, but owl:sameIndividualAs is preferred.) To state that objects are distinct, an owl:differentFrom element is used.
>>>>>>>>>

26. Property elements In OWL there are two kinds of properties:
Object properties which relate objects to other objects.
Object properties link individuals to individuals.
Examples are isTaughtBy, supervises etc.
- Datatype properties which relate objects to datatype values.
Datatype properties link individuals to data values.
Examples are phone, title, age etc.
OWL does not have any predefined data types, nor does it provide special definition facilities. Instead it allows one to use XML Schema data types, thus making use of the layered architecture the Semantic Web

27. Property elements (cont..)
An object property is defined as an instance of the built-in OWL class owl:ObjectProperty. Here is an example of an object property:
<owl:ObjectProperty rdf:ID="isTaughtBy">
<owl:domain rdf:resource="#course"/>
<owl:range rdf:resource="#academicStaffMember"/>
<rdfs:subPropertyOf rdf:resource="#involves"/>
</owl:ObjectProperty>
Example 2:
<owl:ObjectProperty rdf:ID="hasMother">
<rdfs:subPropertyOf rdf:resource="#hasParent"/> </owl:ObjectProperty>
An object property is defined as an instance of the built-in OWL class owl:ObjectProperty.
NOTE: In OWL Full, object properties and datatype properties are not disjoint. Because data values can be treated as individuals, datatype properties are effectively subclasses of object properties. In OWL Full owl:ObjectProperty is equivalent to rdf:Property In practice, this mainly has consequences for the use of owl:InverseFunctionalProperty.
>>>>>>>
A rdfs:subPropertyOf axiom defines that the property is a subproperty of some other property. Formally this means that if P1 is a subproperty of P2, then the property extension of P1 (a set of pairs) should be a subset of the property extension of P2 (also a set of pairs).
An example:
<owl:ObjectProperty rdf:ID="hasMother"> <rdfs:subPropertyOf rdf:resource="#hasParent"/> </owl:ObjectProperty> This states that all instances (pairs) contained in the property extension of the property "hasMother" are also members of the property extension of the property "hasParent".
Subproperty axioms can be applied to both datatype properties and object properties.
NOTE: In OWL DL the subject and object of a subproperty statement must be either both datatype properties or both object properties.
>>>>>>>>>>>
rdfs:domain
For a property one can define (multiple) rdfs:domain axioms. Syntactically, rdfs:domain is a built-in property that links a property (some instance of the class rdf:Property) to a class description. An rdfs:domain axiom asserts that the subjects of such property statements must belong to the class extension of the indicated class description.
Multiple rdfs:domain axioms are allowed and should be interpreted as a conjunction: these restrict the domain of the property to those individuals that belong to the intersection of the class descriptions. If one would want to say that multiple classes can act as domain, one should use a class description of the owl:unionOf form. For example, if we want to say that the domain of the property hasBankAccount can be either a Person or a Corporation, we would need to say something like this:
<owl:ObjectProperty rdf:ID="hasBankAccount"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Person"/> <owl:Class rdf:about="#Corporation"/> </owl:unionOf> </owl:Class> </rdfs:domain> </owl:ObjectProperty> NOTE: In OWL Lite the value of rdfs:domain must be a class identifier.
>>>>>>>>
rdfs:range
For a property one can define (multiple) rdfs:range axioms. Syntactically, rdfs:range is a built-in property that links a property (some instance of the class rdf:Property) to to either a class description or a data range. An rdfs:range axiom asserts that the values of this property must belong to the class extension of the class description or to data values in the specified data range.
Multiple range restrictions are interpreted as stating that the range of the property is the intersection of all ranges (i.e., the intersection of the class extension of the class descriptions c.q. the intersection of the data ranges). Similar to rdfs:domain, multiple alternative ranges can be specified by using a class description of the owl:unionOf form (see the previous subsection).
Note that, unlike any of the value constraints described in the section on class descriptions, rdfs:range restrictions are global. Value constraints such as owl:allValuesFrom are used in a class description and are only enforced on the property when applied to that class. In contrast, rdfs:range restrictions apply to the property irrespective of the class to which it is applied. Thus, rdfs:range should be used with care.
NOTE: In OWL Lite the only type of class descriptions allowed as objects of rdfs:range are class names.

28. Property elements (cont..)
Here is an example of a datatype property.
<owl:DatatypeProperty rdf:ID="age">
<rdfs:range rdf:resource="
#nonNegativeInteger"/>
</owl:DatatypeProperty>
OWL uses most of the built-in XML Schema datatypes. References to these datatypes are by means of the URI reference for the datatype, The following datatypes are recommended for use with OWL:

29. Property elements (cont..)
The following datatypes are recommended for use with OWL:
Figure 8

30. Property restrictions
A property restriction is a special kind of class description. It describes an anonymous class, namely a class of all individuals that satisfy the restriction. OWL distinguishes two kinds of property restrictions: value constraints and cardinality constraints.
Property restrictions have the following general form:
<owl:Restriction>
<owl:onProperty rdf:resource="(some property)" />
(precisely one value or cardinality constraint)
</owl:Restriction>
A value constraint puts constraints on the range of the property when applied to this particular class description. For example, we might want to refer to those individuals whose value of the property adjacentTo should be some Region, and then use this within a class axiom, perhaps even a class axiom for Region itself. Note that this is different from rdfs:range, which is applied to all situations in which the property is used.
A cardinality constraint puts constraints on the number of values a property can take, in the context of this particular class description. For example, we might want to say that for a soccer team the hasPlayer property has 11 values. For a basketball team the same property would have only 5 values.
OWL also supports a limited set of constructs for defining global property cardinality, namely owl:FunctionalProperty and owl:InverseFunctionalProperty Property restrictions have the following general form:
The class owl:Restriction is defined as a subclass of owl:Class. A restriction class should have exactly one triple linking the restriction to a particular property, using the owl:onProperty property. The restriction class should also have exactly one triple that represents the value constraint c.q. cardinality constraint on the property under consideration, e.g., that the cardinality of the property is exactly 1.
Property restrictions can be applied both to datatype properties (properties for which the value is a data literal) and object properties (properties for which the value is an individual). For more information about this distinction, see the section on properties.

31. Property restrictions (cont..)
A value Constraint
1- owl:allValuesFrom
2- owl:someValuesFrom
3- owl:hasValue
Cardinality Constraint
1- owl:maxCardinality
2- owl:minCardinality
3- owl:cardinality

32. Property restrictions (cont..)
A value Constraint
1- owl:allValuesFrom
A simple example:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
< owl:allValuesFrom rdf:resource="#Human" /> </owl:Restriction>
owl:allValuesFrom
The value constraint owl:allValuesFrom is a built-in OWL property that links a restriction class to either a class description or a data range. A restriction containing an owl:allValuesFrom constraint is used to describe a class of all individuals for which all values of the property under consideration are either members of the class extension of the class description or are data values within the specified data range. In other words, it defines a class of individuals x for which holds that if the pair (x,y) is an instance of P (the property concerned), then y should be an instance of the class description or a value in the data range, respectively.
A simple example:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:allValuesFrom rdf:resource="#Human" /> </owl:Restriction> This example describes an anonymous OWL class of all individuals for which the hasParent property only has values of class Human. Note that this class description does not state that the property always has values of this class; just that this is true for individuals that belong to the class extension of the anonymous restriction class.
NOTE: In OWL Lite the only type of class description allowed as object of owl:allValuesFrom is a class name.
An owl:allValuesFrom constraint is analogous to the universal (for-all) quantifier of Predicate logic - for each instance of the class that is being described, every value for P must fulfill the constraint. Also notice that the correspondence of owl:allValuesFrom with the universal quantifier means that an owl:allValuesFrom constraint for a property P is trivially satisfied for an individual that has no value for property P at all. To see why this is so, observe that the owl:allValuesFrom constraint demands that all values of P should be of type T, and if no such values exist, the constraint is trivially true.

33. Property restrictions (cont..)
A value Constraint 2- owl:someValuesFrom The following example defines a class of individuals which have at least one parent who is a physician: <owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:someValuesFrom rdf:resource="#Physician" /> </owl:Restriction>
owl:someValuesFrom
The value constraint owl:someValuesFrom is a built-in OWL property that links a restriction class to a class description or a data range. A restriction containing an owl:someValuesFrom constraint describes a class of all individuals for which at least one value of the property concerned is an instance of the class description or a data value in the data range. In other words, it defines a class of individuals x for which there is at least one y (either an instance of the class description or value of the data range) such that the pair (x,y) is an instance of P. This does not exclude that there are other instances (x,y') of P for which y' does not belong to the class description or data range.
The following example defines a class of individuals which have at least one parent who is a physician:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:someValuesFrom rdf:resource="#Physician" /> </owl:Restriction> The owl:someValuesFrom constraint is analogous to the existential quantifier of Predicate logic - for each instance of the class that is being defined, there exists at least one value for P that fulfills the constraint.
NOTE: In OWL Lite the only type of class description allowed as object of owl:someValuesFrom is a class name.

34. Property restrictions (cont..)
A value Constraint
3- owl:hasValue
The following example describes the class of individuals who have the individual referred to as Ameer as their parent:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" />
<owl:hasValue rdf:resource="#Ameer" /> </owl:Restriction>
owl:hasValue
The value constraint owl:hasValue is a built-in OWL property that links a restriction class to a value V, which can be either an individual or a data value. A restriction containing a owl:hasValue constraint describes a class of all individuals for which the property concerned has at least one value semantically equal to V (it may have other values as well).
NOTE: for datatypes "semantically equal" means that the lexical representation of the literals maps to the same value. For individuals it means that they either have the same URI reference or are defined as being the same individual (see owl:sameAs).
NOTE: the value constraint owl:hasValue is not included in OWL Lite.
The following example describes the class of individuals who have the individual referred to as Ameer as their parent:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:hasValue rdf:resource="#Ameer" /> </owl:Restriction>

35. Property restrictions (cont..)
Cardinality Constraint
1- owl:maxCardinality
The following example describes a class of individuals that have at most two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" /> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger"> 2
</owl:maxCardinality>
</owl:Restriction>
Cardinality constraints
In OWL, like in RDF, it is assumed that any instance of a class may have an arbitrary number (zero or more) of values for a particular property. To make a property required (at least one), to allow only a specific number of values for that property, or to insist that a property must not occur, cardinality constraints can be used. OWL provides three constructs for restricting the cardinality of properties locally within a class context.
NOTE: OWL Lite includes the use of all three types of cardinality constraints, but only when used with the values "0" or "1".
owl:maxCardinality
The cardinality constraint owl:maxCardinality is a built-in OWL property that links a restriction class to a data value belonging to the value space of the XML Schema datatype nonNegativeInteger. A restriction containing an owl:maxCardinality constraint describes a class of all individuals that have at most N semantically distinct values (individuals or data values) for the property concerned, where N is the value of the cardinality constraint. Syntactically, the cardinality constraint is represented as an RDF property element with the corresponding rdf:datatype attribute.
The following example describes a class of individuals that have at most two parents:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality>

36. Property restrictions (cont..)
Cardinality Constraint
2- owl:minCardinality
The following example describes a class of individuals that have at least two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger"> 2
</owl:minCardinality>
</owl:Restriction>
owl:minCardinality
The cardinality constraint owl:minCardinality is a built-in OWL property that links a restriction class to a data value belonging to the value space of the XML Schema datatype nonNegativeInteger. A restriction containing an owl:minCardinality constraint describes a class of all individuals that have at least N semantically distinct values (individuals or data values) for the property concerned, where N is the value of the cardinality constraint. Syntactically, the cardinality constraint is represented as an RDF property element with the corresponding rdf:datatype attribute.
The following example describes a class of individuals that have at least two parents:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:minCardinality> </owl:Restriction> Note that an owl:minCardinality of one or more means that all instances of the class must have a value for the property.

37. Property restrictions (cont..)
Cardinality Constraint
3- owl:cardinality
The following example describes a class of individuals that have exactly two parents:
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" /> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger"> 2
</owl:cardinality>
</owl:Restriction>
owl:cardinality
The cardinality constraint owl:cardinality is a built-in OWL property that links a restriction class to a data value belonging to the range of the XML Schema datatype nonNegativeInteger. A restriction containing an owl:cardinality constraint describes a class of all individuals that have exactly N semantically distinct values (individuals or data values) for the property concerned, where N is the value of the cardinality constraint. Syntactically, the cardinality constraint is represented as an RDF property element with the corresponding rdf:datatype attribute.
This construct is in fact redundant as it can always be replaced by a pair of matching owl:minCardinality and owl:maxCardinality constraints with the same value. It is included as a convenient shorthand for the user.
The following example describes a class of individuals that have exactly two parents:
<owl:Restriction> <owl:onProperty rdf:resource="#hasParent" /> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:cardinality> </owl:Restriction>

38. Special properties
Some properties of property elements can be dened directly:
1-owl:TransitiveProperty
2- owl:SymmetricProperty
3- owl:FunctionalProperty
4- owl:InverseFunctionalProperty
Some properties of property elements can be defined directly:
1- owl:TransitiveProperty defines a transitive property, such as \has better grade than", \is taller than", \is ancestor of" etc.
Typical examples of transitive properties are properties representing certain part-whole relations. For example, we might want to say that the subRegionOf property between regions is transitive:
<owl:TransitiveProperty rdf:ID="subRegionOf"> <rdfs:domain rdf:resource="#Region"/> <rdfs:range rdf:resource="#Region"/> </owl:TransitiveProperty> From this an OWL reasoner should be able to derive that if ChiantiClassico, Tuscany and Italy are regions, and ChiantiClassico is a subregion of Tuscany, and Tuscany is a subregion of Italy, then ChiantiClassico is also a subregion of Italy.
Note that because owl:TransitiveProperty is a subclass of owl:ObjectProperty, the following syntactic variant is equivalent to the example above:
<owl:ObjectProperty rdf:ID="subRegionOf"> <rdf:type rdf:resource="&owl;TransitiveProperty"/> <rdfs:domain rdf:resource="#Region"/> <rdfs:range rdf:resource="#Region"/> </owl:ObjectProperty>
>>>>>>>>

39. Special properties (cont..)
1-owl:TransitiveProperty
<owl:TransitiveProperty rdf:ID="subRegionOf">
<rdfs:domain rdf:resource="#Region"/>
<rdfs:range rdf:resource="#Region"/> </owl:TransitiveProperty>

40. Special properties (cont..)
2- owl:SymmetricProperty
A popular example of a symmetric property is the friendOf relation:
<owl:SymmetricProperty rdf:ID="friendOf">
<rdfs:domain rdf:resource="#Human"/>
<rdfs:range rdf:resource="#Human"/> </owl:SymmetricProperty>
2- owl:SymmetricProperty defines a symmetric property, such as \has same grade as", \is sibling of", etc.
A symmetric property is a property for which holds that if the pair (x,y) is an instance of P, then the pair (y,x) is also an instance of P. Syntactically, a property is defined as symmetric by making it an instance of the built-in OWL class owl:SymmetricProperty, a subclass of owl:ObjectProperty.
A popular example of a symmetric property is the friendOf relation:
<owl:SymmetricProperty rdf:ID="friendOf"> <rdfs:domain rdf:resource="#Human"/> <rdfs:range rdf:resource="#Human"/> </owl:SymmetricProperty>
>>>>>>>>>>

41. Special properties (cont..)
3- owl:FunctionalProperty
<owl:ObjectProperty rdf:ID="husband">
<rdfs:domain rdf:resource="#Woman" />
<rdfs:range rdf:resource="#Man" />
</owl:ObjectProperty>
<owl:FunctionalProperty rdf:about="#husband" />
3- owl:FunctionalProperty defines a property that has at most one unique value for each object, such as \age", \height", \directSupervisor" etc.
A functional property is a property that can have only one (unique) value y for each instance x, i.e. there cannot be two distinct values y1 and y2 such that the pairs (x,y1) and (x,y2) are both instances of this property. Both object properties and datatype properties can be declared as "functional". For this purpose, OWL defines the built-in class owl:FunctionalProperty as a special subclass of the RDF class rdf:Property.
The following axiom states that the husband property is functional, i.e., a woman can have at most one husband (a good example of culture dependence of ontologies):
<owl:ObjectProperty rdf:ID="husband"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> <rdfs:domain rdf:resource="#Woman" /> <rdfs:range rdf:resource="#Man" /> </owl:ObjectProperty> As always, there are syntactic variations. The example above is semantically equivalent to the one below:
<owl:ObjectProperty rdf:ID="husband"> <rdfs:domain rdf:resource="#Woman" /> <rdfs:range rdf:resource="#Man" /> </owl:ObjectProperty> <owl:FunctionalProperty rdf:about="#husband" />
>>>>>>>>>>>

42. Special properties (cont..)
4- owl:InverseFunctionalProperty
<owl:InverseFunctionalProperty rdf:ID="biologicalMotherOf">
<rdfs:domain rdf:resource="#Woman"/>
<rdfs:range rdf:resource="#Human"/>
</owl:InverseFunctionalProperty>
4- owl:InverseFunctionalProperty defines a property for which two different objects cannot have the same value, for example the property \is-
TheSocialSecurityNumberfor" (a social security number is assigned to one person only).
owl:InverseFunctionalProperty
If a property is declared to be inverse-functional, then the object of a property statement uniquely determines the subject (some individual). More formally, if we state that P is an owl:InverseFunctionalProperty, then this asserts that a value y can only be the value of P for a single instance x, i.e. there cannot be two distinct instances x1 and x2 such that both pairs (x1,y) and (x2,y) are instances of P.
Syntactically, an inverse-functional property axiom is specified by declaring the property to be an instance of the built-in OWL class owl:InverseFunctionalProperty, which is a subclass of the OWL class owl:ObjectProperty.
NOTE: Because in OWL Full datatype properties are a subclass of object properties, an inverse-functional property can be defined for datatype properties. In OWL DL object properties and datatype properties are disjoint, so an inverse-functional property cannot be defined for datatype properties.
A typical example of an inverse-functional property:
<owl:InverseFunctionalProperty rdf:ID="biologicalMotherOf"> <rdfs:domain rdf:resource="#Woman"/> <rdfs:range rdf:resource="#Human"/> </owl:InverseFunctionalProperty>

43. Boolean combination
A boolean combination of class expressions can be constructed from:
1- owl:intersectionOf element
2- owl:unionOf element
3- owl:complementOf element
A boolean combination of class expressions can be constructed from:
an owl:intersectionOf element, containing a list of class expressions. This defines the class that consists of exactly all the objects that are common to all class expressions from the list. It is analogous to logical conjunction;
an owl:unionOf element, containing a list of class expressions. This defines the class that consists exactly of all the objects that belong to at least one of the class expressions from the list. It is analogous to logical disjunction;
an owl:complementOf element, containing a single class expression. This defines the class that consists of exactly all objects that do not belong to the class expression. It is analogous to logical negation, but restricted to objects only.
Note that arbitrarily complex combinations of these expressions can be formed.
>>>>>>>>>>.
It is possible to talk about Boolean combinations (union, intersection, com-
plement) of classes (be it dened by owl:Class or by class expressions). For
example, we can say that courses and sta members are disjoint as follows:
<owl:Class rdf:about="#course">
<rdfs:subClassOf>
<owl:Restriction>
<owl:complementOf rdf:resource="#staffMember"/>
</owl:Restriction>
</rdfs:subClassOf>
</owl:Class>
This says that every course is an instance of the complement of sta members,
that is, no course is a sta member. Note that this statement could also have
been expressed using owl:disjointWith.
The union of classes is built using owl:unionOf.
<owl:Class rdf:ID="peopleAtUni">
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#staffMember"/>
<owl:Class rdf:about="#student"/>
</owl:unionOf>
The rdf:parseType attribute is a shorthand for an explicit syntax for
building list with <rdf:first> and <rdf:rest> tags. Such lists are required
because the built-in containers of RDF have a serious limitation: there is no
way to close them, i.e., to say \these are all the members of the container".
This is because, while one graph may describe some of the members, there is
no way to exclude the possibility that there is another graph somewhere that
describes additional members. The list syntax provides exactly this facility,
but is very verbose, which motivates the rdf:parseType shorthand notation.
Note that this does not say that the new class is a subclass of the union,
but rather that the new class is equal to the union. In other words, we have
stated an equivalence of classes. Also, we did not specify that the two classes
must be disjoint: it is possible that a sta member is also a student.
Intersection is stated with owl:intersectionOf.
<owl:Class rdf:ID="facultyInCS">
<owl:intersectionOf rdf:parseType="owl:collection">
<owl:Class rdf:about="#faculty"/>
<Restriction>
<owl:onProperty rdf:resource="#belongsTo"/>
<owl:hasValue rdf:resource="#CSDepartment"/>
</Restriction>
</owl:intersectionOf>
Note that we have built the intersection of two classes, one of which was de-
ned anonymously: the class of all objects belonging to the CS department.
This class is intersected with faculty to give us the faculty in the CS depart-
ment.
Further we note that Boolean combinations can be nested arbitrarily. The
following example denes administrative sta to be those sta members that
are neither faculty nor technical support sta.
<owl:Class rdf:ID="adminStaff">
<owl:intersectionOf rdf:parseType="Collection">
<owl:complementOf>
<owl:Class rdf:about="#techSupportStaff"/>
</owl:complementOf>
>>>>>>>>>>

44. Boolean combination (cont..)
1- owl:intersectionOf element
<owl:Class rdf:ID="WhiteBurgundy">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Burgundy" />
<owl:Class rdf:about="#WhiteWine" />
</owl:intersectionOf>
</owl:Class>

45. Boolean combination (cont..)
2- owl:unionOf element
<owl:Class rdf:ID="Fruit">
<owl:unionOf rdf:parseType="Collection">
<owl:Class rdf:about="#SweetFruit" />
<owl:Class rdf:about="#NonSweetFruit" />
</owl:unionOf>
</owl:Class>

46. Boolean combination (cont..)
3- owl:complementOf element
<owl:Class rdf:ID="NonConsumableThing">
<owl:complementOf rdf:resource="#ConsumableThing" />
</owl:Class>
The complementOf construct selects all individuals from the domain of discourse that do not belong to a certain class. Usually this refers to a very large set of individuals:
An owl:complementOf property links a class to precisely one class description. An owl:complementOf statement describes a class for which the class extension contains exactly those individuals that do not belong to the class extension of the class description that is the object of the statement. owl:complementOf is analogous to logical negation: the class extension consists of those individuals that are NOT members of the class extension of the complement class.
As an example of the use of complement, the expression "not meat" could be written as:
<owl:Class> <owl:complementOf> <owl:Class rdf:about="#Meat"/> </owl:complementOf> </owl:Class> The extension of this class description contains all individuals that do not belong to the class Meat.
NOTE: owl:complementOf is not part of OWL Lite.

47. Datatypes
Although XML Schema provides a mechanism to construct user-dened datatypes (e.g. the datatype of adultAge as all integers greater than 18, or the datatype of all strings starting with a number), such derived datatypes cannot be used in OWL. In fact, not even all of of the many the built-in XML Schema datatypes can be used in OWL. The OWL reference document lists all the XML Schema datatypes that can be used, but these include the most frequently used types such as string, integer, boolean, time and date.

48. Versioning information
We have already seen the owl:priorVersion statement as part of the header information to indicate earlier versions of the current ontology. This information has not formal model-theoretic semantics but can be exploited by humans readers and programs alike for the purposes of ontology management.
Besides owl:priorVersion, OWL has three more statements to indicate further informal versioning information. None of these carry any formal meaning.
1- owl:versionInfostatement
2- owl:backwardCompatibleWith
3- owl:incompatibleWith
An owl:versionInfostatement generally contains a string giving information about the current version, for example RCS/CVS keywords.
An owl:backwardCompatibleWith statement contains a reference to another ontology. This identifies the specified ontology as a prior version of
the containing ontology, and further indicates that it is backward compatible with it. In particular, this indicates that all identifiers from the
previous version have the same intended interpretations in the new ver-
sion. Thus, it is a hint to document authors that they can safely change
their documents to commit to the new version (by simply updating names-
pace declarations and owl:imports statements to refer to the URL of the
new version).
An owl:incompatibleWith on the other hand indicates that the containing ontology is a later version of the referenced ontology, but is not backward compatible with it. Essentially, this is for use by ontology author who want to be explicit that documents cannot upgrade to use the new
version without checking whether changes are required.

49. Diagram Toolbox OWL Elements: Toolbox Icon Description Ontology
The OWL ontology package, which holds all the OWL modeling elements.
You can export the contents of this package to produce the Ontology XML document.
Class
An extended UML Class that represents an OWL Class that describes an instantiable entity with properties and semantic meaning.
Data Range
An extended UML Enumeration that defines a collection of values for an OWL Property.
Enumerated Class
An extended UML Class that defines an OWL Class extension defined by any one of the range of the allowed OWL Individuals.
Restriction
An extended UML Class that defines an OWL Class extension as restricted by the specified property and its allowable values.
Singleton
An extended UML Class, representing an OWL Class for a specific OWL Individual.

50. Diagram Toolbox (cont..)
Toolbox Icon
Description
Annotation
An extended UML Class, representing an OWL Annotation Property definition.
Datatype Property
An extended UML Class, representing an OWL Datatype Property definition.
Object Property
An extended UML Class, representing a semantic OWL Property definition.
Ontology Property
An extended UML Part, representing a property defined on the OWL Ontology.
Individual
An extended UML Object, representing an instance of an OWL Class which defines an individual fact.
Value
An extended UML Part, holding a value defined in an OWL Property or OWL Individual.
OWL Properties (Elements):

51. Diagram Toolbox (cont..)
OWL Relationships:
Toolbox Icon
Description
Imports
An extended UML PackageImports, that enables an OWL ontology to reference another OWL Ontology.
Domain
An extended UML Association, that specifies the OWL Classes that apply the specified OWL Property (Annotation, Datatype or Object Property).
Range
An extended UML Association, that specifies the OWL Class with the value type applicable to the specified OWL Property (Annotation, Datatype or Object Property).
Inverse Of
An extended UML Association, between two opposing, but related OWL Property elements.
Sub Property Of
An extended UML Generalization between two OWL Property elements.
Subclass Of
An extended UML Generalization between two OWL Class elements.
Value
An extended UML Association, defining an OWL Property and value between OWL Classes.

52. Diagram Toolbox (cont..)
OWL Semantics (Relationships):
Toolbox Icon
Description
All Different
An extended UML Dependency between different (ie: unique) OWL Individuals typed by the same OWL Class.
Backward Compatible With
An extended UML Dependency between an OWL Ontology and another that it's backward compatible with.
Complement Of
An extended UML Dependency between an OWL Class and its complement (or opposite).
Different From
An extended UML Dependency between two semantically different OWL Individuals typed by the same OWL Class.
Disjoint With
An extended UML Dependency between two OWL Classes that have no common individuals.
Equivalent Class
An extended UML Dependency between two equivalent OWL Classes.
Equivalent Property
An extended UML Dependency between two equivalent OWL Property elements.

53. Diagram Toolbox (cont..)
OWL Semantics (Relationships):
Toolbox Icon
Description
Incompatible With
An extended UML Dependency between an OWL Ontology and another that it is incompatible with.
Intersection Of
An extended UML Dependency between an OWL Class and others it also specializes.
Ontology Property
An extended UML Dependency, representing a property defined on the OWL Ontology.
Prior Version
An extended UML Dependency between an OWL Ontology and its predecessor.
Same As
An extended UML Dependency between two semantically identical OWL Individuals typed by the same OWL Class.
Union Of
An extended UML Dependency between a general OWL Class and others that distinctly specialize it.

54. Layering of OWL Layering of OWL
Now that we have discussed all the language constructors of OWL, we can
completely specify which features of the language can be used in which sub-
language (OWL Full, DL and Lite):
OWL Full
In OWL Full, all the language constructors can be used in any combination
as long as the result is legal RDF.
OWL DL
In order to exploit the formal underpinnings and computational tractability
of Description Logics, the following constraints must be obeyed in an OWL
DL ontology:
Vocabulary Partitioning: any resource is allowed to be only either a class,
a datatype, a datatype properties, an object properties, an individuals, a
data value or part of the built-in vocabulary, and not more than one of
these. This means that, for example, a class cannot be at the same time
an individual, or that a property cannot have values some values from a
datatype and some values from a class (this would make it both a datatype
property and an object property).
Explicit typing: not only must all resources be partitioned (as prescribed
in the previous constraint), but this partitioning must be stated explicitly.
For example, if an ontology contains the following:
<owl:Class rdf:ID="C1">
<rdfs:subClassOf rdf:about="#C2" />
</owl:Class>
this already entails that C2 is a class (by virtue of the range specication
of rdfs:subClassOf). Nevertheless, an OWL DL ontology must explicitly
state this information:
<owl:Class rdf:ID="C2"/>
 Property Separation: By virtue of the rst constraint, the set of object
properties and datatype properties are disjoint. This implies that inverse
properties, and functional, inverse functional and symmetric characteris-
tics can never be specied for datatype properties.
 No transitive cardinality restrictions: no cardinality restrictions may be
placed on transitive properties (or their subproperties, which are of course
also transitive, by implication).
 Restricted anonymous classes: anonymous classes are only allowed in the
domain and range of owl:equivalentClass and owl:disjointWith, and
in the range (not the domain) of rdfs:subClassOf.
OWL Lite
An OWL ontology must be an OWL DL ontology, and must further satisfy
the following constraints:
the constructors owl:oneOf, owl:disjointWith, owl:unionOf,
owl:complementOf and owl:hasValue are not allowed
cardinality statements (both minimal, maximal and exact cardinality) can
only be made on the values 0 or 1, and no longer on arbitrary non-negative
integers.
owl:equivalentClass statements can no longer be made between anony-
mous classes, but only between class identiers.

55. Summary
OWL is the proposed standard for Web ontologies. It allows us to describe
the semantics of knowledge in a machine-accessible way.
OWL builds upon RDF and RDF Schema: (XML-based) RDF syntax is
used; instances are dened using RDF descriptions; and most RDFS modelling primitives are used.
Formal semantics and reasoning support is provided through the mapping of OWL on logics. Predicate logic and description logics have been used for this purpose. While OWL is suciently rich to be used in practice, extensions are in the making. They will provide further logical features, including rules.

56. Summary
XML—Extensible Markup Language. The language framework that, since 1998, has been used to define nearly all new languages that are used to interchange data over the Web. XML Schema — A language used to define the structure of specific XML languages. RDF—Resource Description Framework. A flexible language capable of describing all sorts of information and meta data. RDF is covered in chapter 2. Topic maps, a non-W3C alternative standard, are discussed in chapter 3. RDF Schema — A framework that provides a means to specify basic vocabularies for specific RDF application languages to use. RDF Schema is covered in chapter 7. Ontology — Languages used to define vocabularies and establish the usage of words and terms in the context of a specific vocabulary. RDF Schema is a framework for constructing ontologies and is used by many more advanced ontology frameworks. OWL is an ontology language designed for the Semantic Web. Chapter 7 discusses ontologies, including OWL. Logic and Proof — Logical reasoning is used to establish the consistency and correctness of data sets and to infer conclusions that aren’t explicitly stated but are required by or consistent with a known set of data. Proofs trace or explain the steps of logical reasoning. Chapter 6 covers some issues relating to logic in the Semantic Web. Trust — A means of providing authentication of identity and evidence of the trustworthiness of data, services, and agents.
Each layer is seen as building on the layer below. At the base, most data is expected to be created in XML formats. Each layer is progressively more specialized and also tends to be more complex than the layers below it. A lower layer doesn’t depend on any higher layers. Thus, the layers can be developed and made operational relatively independently. XML is in place now, and XML Schema has recently become standardized. RDF has been released as a W3C Recommendation,9 (and has just been re-released with changes). The other layers are under development, and their form and direction are progressively uncertain according to their altitude in the layer cake.
You should realize that this diagram represents the W3C view, and most of the technologies depicted in the diagram are W3C developed or endorsed. There are potential alternatives for some of the layers. Among others, alternative schemas exist for XML documents, and there are quite a few alternative efforts to develop ontology systems.
If you noticed that there is no layer labeled Web Services, it’s true that services don’t fit neatly into this layer cake. Such technologies make use of several layers, such as XML and XML Schemas—and perhaps, in the future, RDF and Ontology. This book also discusses other technologies and subjects that don’t appear in the layer-cake diagram.
Figure 9

57. Thank You https://www.researchgate.net/profile/Ameer_Sameer