owl OWL 1.1 Web Ontology Language
Primer

Experimental Draft of 14 January 2008

Latest version:
TODAY
This version:
TODAY
Editors:
Bijan Parsia, Peter F. Patel-Schneider

Copyright © 2008 by the Editors.

Abstract

The W3C OWL 1.1 Web Ontology Language is designed to represent ontological information about individuals, classes, and properties in a Semantic Web setting. OWL provides a rich language for structuring and classifying with both complete and incomplete information. This short primer provides an approachable introduction to OWL 1.1, including orientation for those coming from other disciplines, an example showing how OWL 1.1 can be used to represent first simple information and then more complex information, how OWL 1.1 manages ontologies, and finally the distinctions between the various sublanguages of OWL 1.1.

Status of this Document

This is an editors' draft.

This document is being prepared for consideration by the W3C OWL WG. Comments are welcome. Please send feedback to public-owl-dev@w3.org, which has a public archive.

Table of Contents

1 Introduction

The W3C OWL 1.1 Web Ontology Language (OWL) is a Semantic Web language designed to represent ontologies - information about how individuals are grouped and fit together in a particular domain. OWL can represent rich and complex information about classes of individuals and their properties. OWL is a logical language, where every construct has a well-defined formal meaning that fit together to support exact and useful representation of many different kinds of information. OWL groups information into formal ontologies, which can be stored and transmitted in the World Wide Web in the same way that data and other kinds of information are.

This short primer contains, first, orientations to OWL for various communities, including XML, RDF, databases, and object-oriented programming. The bulk of the primer consists of an example that illustrates the different kinds of information that can be represented in OWL. The primer then describes how OWL packages information into ontologies and how extra non-logical information is associated with parts of an ontology. Finally, the primer describes the various sublanguages of OWL, and what is gained and lost by using them.

2 Orientation

OWL is superficially similar to many other technologies, which is not too surprising given the prevalence of XML as a concrete syntax and of the class-object paradigm. People familiar with other technologies are sometimes misled by the similarities and thus very surprised by the differences. In section 2.1, we provide a brief orientation to OWL from a number of prominent technological perspectives. At various points in the tutorial sections of this Primer, we shall highlight aspects of OWL that might be surprising to people coming from these perspectives.

In section 2.2, we briefly discuss some major ways of using OWL in applications.

2.1 Technologies

Resource Description Framework (RDF) and Schema: Of the technologies discussed in this section, RDF(S) is the closest to OWL. They both have roots in logic based knowledge representation; in many ways, RDF(S) can be seen as a subset of OWL; and, perhaps most prominently, the primary exchange syntax for OWL has been RDF/XML. However, there are differences of style, emphasis, and common practice that can make relying on RDF(S) intuitions misleading when working with OWL. For example, while OWL statements and expressions can be encoded as RDF facts (triples), the triple view is not typically a fruitful way of writing or understanding complex expressions. Similarly, it is fairly common and effective to work with RDF as a graph data structure or database where the primary focus is on the explicit statements in the graph. Even when we consider parts of RDFS which support implicit knowledge, such as subclass inheritance, the relation between the explicit and implicit statements is very direct. Thus, it is easy to conceptualize inference in terms of graph structure manipulation.

In contrast, OWL allows for -- and encourages -- operations that are not rooted so directly in the evident structure of an ontology.

XML: OWL and the XML family of technologies share some common parts: OWL can be expressed in XML languages (such as RDF/XML or the XML syntax for OWL [?]) and thus be manipulated by XML tools. OWL reuses datatypes and datatype derivation facets from XML Schema (and can use certain forms of XML Schema type definitions). Finally, both OWL and XML have an object oriented approach and, to a certain extent, similar missions. Both can be used for conceptual modeling as well as data definition, though they ways they go about it are fairly distinct.

OWL is oriented toward more abstract, higher level conceptual modeling than is XML. OWL is designed to support the discovery of relationships between descriptions through automated reasoning. It also builds in far fewer presumptions about the entities it is describing both generally and in terms of their physical realization in computational systems.

Both OWL and XML Schema support strong abstraction facilities. However XML Schema, is oriented toward a more concrete level of conceptual modeling. This is inherent in its core mission of validating XML documents.

Databases: Both OWL and databases (either relational or object-oriented) can be used to store and organize data. However, databases are much more oriented towards this mission, and in an environment where complete information is available (at least as far as applications are concerned). OWL is more oriented towards flexible and expressive description of data (or information), i.e., ontologies, and performs in an environment where information is considered to be incomplete unless information to the contrary is known.

It is this difference in completeness that most distinguishes OWL from databases, driving the different capabilities of OWL and databases. Users who treat OWL information as complete where completeness cannot be assured are very often surprised and confused. (Similarly those who use database technology in situations where information is incomplete can be similarly surprised and confused.) Applications that incorrectly make assumption about completeness can come up with patently incorrect results.

Ontologies in OWL are much more powerful and flexible than database schemas. Database schemas generally only shape the kinds of information that is associated with objects (or tuples) that belong to a class (or table). Classes in OWL ontologies can do this, but also can provide recognition conditions so that explicit typing is not required in OWL. Of course this flexibility means that determining typing in OWL can require complex inferences.

A final major difference between databases and OWL is that the information stored in a database is derived from the database schema - if the schema doesn't sanction the storage of certain kinds of information, then that information cannot be stored. OWL, on the other hand, allows arbitrary information to be associated with just about any object - if there is nothing in the ontology forbidding the associated then it is allowable. OWL is thus much more flexible in its information storage.

Object-oriented Programming: Object-oriented programming (OOP) also has object-centered modeling characteristics, and thus has much in common with OWL. However, OOP generally is performed in complete-information contexts, and where the information that can possibly be known about an object is circumscribed by the information in the type of the object. As with databases, the differing stances on completeness and object information is a major difference between OWL and OOP. Similarly OOP classes are much less expressive than OWL classes.

Futher, OWL is a strictly declarative and logical language. OWL therefore has none of the operational aspects of OOP, like methods, and similarly reasoning in OWL is strictly logical, with nothing comparing to inheritance, particularly inheritance with exceptions or overriding.

2.2 Applications

Terminlogy development and managament. Conceptual Modeling.

3 Basic Notions

OWL allows us to express information about the world then to draw certain consequences based on this information. There are OWL tools - reasoners - that can automatically compute these consequences. In OWL, we presume that the world is primarily made up of individual entities (typically known as individuals or objects). Individuals are related to each other and to data values via properties. Using OWL, we can group individuals that share certain characteristics into classes.

OWL is part of the Semantic Web, so names in OWL are international resource identifiers (IRIs). As IRIs are long, we will use a compact way of writing them in OWL, consisting of a prefix and a reference separated by a colon. When OWL information is transferred around in the Web, it is written in an XML dialect. The Manchester syntax is an OWL syntax that is designed to be easier for non-logicians to read. The Functional-Style syntax is a formal OWL syntax that is designed to be easier for reasoning tools to use. There are tools that can translate between the different syntaxs for OWL.

This primer uses three different syntaxes, by default the Manchester syntax is the only one shown; the buttons below can be used to show or hide all three syntaxes.

3.1 Simple Information about Individuals

Suppose we want to represent information about a particular family. We first need to determine what individuals there are in a family, and how they are related to each other and what data values are associated with them. We can then proceed by writing down all this information in OWL.

So if we have a family with parents John and Mary and children Susan and Bill we could write all this down, along with ages as follows.

Manchester Syntax:
f:John f:hasWife f:Mary
f:John f:hasSon f:Bill
f:Mary f:hasSon f:Bill
f:John f:hasDaughter f:Susan
f:Mary f:hasDaughter f:Susan
f:John f:hasAge "33"^^xsd:integer
f:Mary f:hasAge "31"^^xsd:integer
f:Bill f:hasAge "13"^^xsd:integer
f:Susan f:hasAge "8"^^xsd:integer

We could also write down information about the sex of people by providing them with a gender, which is either male or female.

Manchester Syntax:
f:John f:hasGender f:male
f:Mary f:hasGender f:female
f:Bill f:hasGender f:male
f:Susan f:hasGender f:female

However, all we have done so far is written down the basic facts about a particular family. Although OWL can be used for this purpose, it is not OWL's forté. OWL's main strength here, instead, involves how families work in general.

3.2 Information about Properties

So let's switch gears and think how families work in general. (This is the process of knowledge representation. Like all processes representing information about the world, certain simplifying assumptions must be made, and since this is a primer we are going to be simplifying a lot.) Well, the individuals in families are all people, so we should have a class of people, with name Person. We have already written down information about several properties. wife is a relationship between Persons, i.e., both the domain and range of wife is Person, as are both son and daughter. age is a relationship from a Person to an integer.

Manchester Syntax:
Class: f:Person
ObjectProperty: f:hasWife domain: f:Person range: f:Person
ObjectProperty: f:hasSon domain: f:Person range: f:Person
ObjectProperty: f:hasDaughter domain: f:Person range: f:Person
DataProperty: f:hasAge domain: f:Person range: xsd:integer

From this information we can conclude that John belongs to Person, because, for example, the domain of wife is Person and John has a wife. We can also directly state that an individual belongs to a class.

Manchester Syntax:
Individual: f:John f:Person

There is more that can be said even about just this little part of familial relationships. For example, the inverse of the wife property is husband. As well, son and daughter are specializations of the child relationship. Further, no individual can be both a son and a daughter, so these properties are disjoint. Individuals have at most one age, so age is a functional data property. Individuals participate in at most one wife relationship and no individual is its own wife, so wife is functional, and inverse functional, and irreflexive. (It is also possible to specify that a property is reflexive, but this is not commonly done because the property is then reflexive for all individuals.) As well, wife is asymmetric. Note that we have added more information about several properties. It is perfectly acceptable in OWL to have information about a property (or class, or individual) occur in several places.

Manchester Syntax:
ObjectProperty: f:hasHusband inverseOf: f:hasWife
ObjectProperty: f:hasChild domain: f:Person range f:Person
ObjectProperty: f:hasSon SubPropertyOf: f:hasChild
ObjectProperty: f:hasDaughter SubPropertyOf: f:hasChild
DisjointObjectProperties: f:hasSon f:hasDaughter
FunctionalDataProperty: f:hasAge
FunctionalDataProperty: f:hasWife
InverseFunctionalDataProperty: f:hasWife
IrreflexiveFunctionalDataProperty: f:hasWife
AsymmetricFunctionalDataProperty: f:hasWife

What we have said about families and about our particular family has a number of consequences. For example, because husband is the inverse of wife, Mary's husband is John. Complete OWL reasoning tools can efficiently determine whether a particular consequence follows from the information available.

3.3 Information About Classes

So far we have written down quite a bit of information about familial properties, but all we have about the familial classes is that there are people. OWL has a rich language for defining classes. So we might have classes for men, women, and parents, each of which is a specialization of Person.

Manchester Syntax:
Class: f:Man SubClassOf: f:Person
Class: f:Woman SubClassOf: f:Person
Class: f:Parent SubClassOf: f:Person

We can do much more in OWL with classes than just provide generalizations for them. OWL can provide partial or complete information about what is required to belong to a class. (The constructs used to provide information about classes are called descriptions in OWL.) For example, saying that people have exactly one age and exactly one gender that is either male or female provides (partial) information about people. Not only saying that every individual that belongs to Man also belongs to Person, but also saying that every Person that has gender male belongs to man, and similarly for Woman, provides complete information about what it takes to belong to these two classes. We can also say that every Person that has at least one child that is a Person belongs to Parent.

Manchester Syntax:
Class: f:Person SubClassOf: f:hasAge EXACTLY 1 AND f:hasGender EXACTLY 1 AND f:hasGender ALL { f:male f:female }
Class: f:Man EquivalentTo: f:Person AND f:hasGender VALUE f:male
Class: f:Woman EquivalentTo: f:Person AND f:hasGender VALUE f:female
Class: f:Parent EquivalentTo: f:Person AND f:hasChild MIN 1 f:Parent

Complete definitions enable many consequences in OWL. For example, from the above John belongs to Man and Parent. Some of the consequences can surprise users, so some OWL tools provide (rudimentary) facilities for showing how a consequence was determined.

In OWL, descriptions can be used just about anywhere a class name can be used. So, for example, we could provide more information about the wife, son, and daughter properties by given them more specific domains and ranges.

Manchester Syntax:
ObjectProperty: f:hasWife domain: f:Man range: f:Woman
ObjectProperty: f:hasSon domain: f:Parent range: Person AND f:hasGender f:male
ObjectProperty: f:hasDaughter domain: f:Parent range: Person AND f:hasGender f:female

In this case, we could just as well have used Man and Woman for the ranges of son and daughter. This would provide exactly the same information to OWL, and OWL reasoners can determine this.

It may seem that there is a circularity in defining Parent as people with at least one child and also making it be the domain of child. In OWL, however, there is no problem. The two bits of information are simply different ways of saying the same thing.

3.4 Data Ranges

OWL can also represent information about certain groupings of data values, called data ranges. For example, we might have Teenager as those people whose age is at least 13 but less than 20, Adult as those people whose age is at least 21, and Child as those people whose age is in the complement of adult ages.

Manchester Syntax:
Class: Teenager SubClassOf: Person AND hasAge SOME xsd:integer ≥ "13"^^xsd:integer < "20"^^xsd:integer
Class: Adult SubClassOf: Person AND hasAge SOME xsd:integer ≥ "21"^^xsd:integer
Class: Child SubClassOf: Person AND NOT ( hasAge SOME xsd:integer ≥ "21"^^xsd:integer )

From this, Bill belongs to Teenager, but not Adult. Both John and Mary belong to Adult, but not to Teenage. Mary belongs to neither Adult nor to Teenage.

OWL uses primitive datatypes taken from XML Schema datatypes [XML Schema Datatypes], e.g., xsd:integer, to construct data ranges. Other useful datatypes include xsd:string and xsd:decimal.

4 Advanced Notions

So far we have seen OWL used as little more than a data structuring language. OWL is considerably more expressive than data structuring languages, in several useful ways. Some of this added expressive power illustrates the differences between OWL and other formalisms and why we have to be understand how OWL is different.

4.1 Incomplete Information about Data Values

In the example so far, we knew quite a bit of information. We knew, for example, that John's (only) age was 47. OWL is designed to deal with incomplete information, so it is quite common in OWL not to know, for example, the ages of all individuals belonging to Person, as just below.

Manchester Syntax:
f:Jeff f:hasWife f:Emily
f:Jeff f:hasChild f:Jack
f:Jeff f:hasChild f:Ellen
f:Jeff f:hasAge "77"^^xsd:integer

It is a consequence of the above that Jeff belongs to Adult and not to Teenager. However, it cannot be determined whether Emily or Jack belong to Adult or Teenager, even though they both must have an age.

It is also possible to provide partial information about values, as in saying that Ellen's age is between 15 and 21, inclusive, that Emily's age is either 39 or 49, or even that Jeff's age is not 53.

Manchester Syntax:
Individual: f:Ellen f:hasAge SOME ( xsd:integer ≥ "15"^^xsd:integer ≤ "21"^^xsd:integer )
Individual: f:Emily f:hasAge VALUE { "39"^^xsd:integer "49"^^xsd:integer }
f:Jeff NOT f:hasAge "53"^^xsd:integer

From this it is possible to determine that Emily belongs to Adult, even though we don't know her exact age, but we cannot determine that Ellen belongs to either Adult or Teenager. On the other hand, we could have a class YoungChild that was neither Adult nor Teenager. Ellen would then not belong to this class.

Manchester Syntax:
Class: f:YoungChild EquivalentTo: NOT ( f:Teenager OR f:Adult )

4.2 Other Incomplete Information

There are many sources of incompleteness in OWL, some of which may be surprising to those not having a logical background. For example, although it may seem to be the case that Jeff has exactly two children, this is not the case, nor is it the case that Jeff has only one child that belongs to Man. Formally, the following is not a consequence of the above information.

Manchester Syntax:
Individual: f:Jeff f:Person AND f:hasChild EXACTLY 2
Individual: f:Jeff f:Person AND f:hasChild MAX 1 f:Man

These do not follow because there is nothing saying that Jack and Ellen are the only children of Jeff, and OWL does not make any assumptions that something that has not been said is not true. It is possible to state that Jeff has no other children, and this can be done in a number of ways. One way that is often used for this purpose is to directly say that Jeff has exactly 2 children, which should certainly be adequate to infer that Jeff has exactly 2 children

Manchester Syntax:
Individual: f:Jeff f:hasChild EXACTLY 2

4.3 Same and Different Individuals

However, even this is not adequate to infer that Jeff has only one child that belongs to Man. We have not stated that Jack and Ellen are different people, and there is nothing said so far that implies that they are not the same. Again OWL does not make the assumption that different names are names for different individuals. (This "unique names assumption" is particularly dangerous in the Semantic Web, where names may be coined by different organizations at different times unknowingly referring to the same individual.) If Jack and Ellen are the same, then there could be another child of John, and this child could belong to Man.

One might think that Jack and Ellen are different because they have different genders, and people have exactly one gender. Unfortunately, we have not stated that male and female are different. We could just state that male and female are different, and have this imply that Jack and Ellen are different, but let's add in a reasonable collection of information about which names are different. Note that we don't really have to do this for John's family as their different ages imply that they are all different. Similarly the wifes and their husbands were already known to be different, because we already stated that wife is irreflexive.

Manchester Syntax:
DifferentIndividuals: f:John f:Mary f:Bill f:Bill f:Susan
DifferentIndividuals: f:Jeff f:Emily f:Jack f:Ellen f:Susan
DifferentIndividuals: f:male f:female

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

Manchester Syntax:
SameIndividual: f:John f:Jack

4.4 Disjointness of Classes

From the above we can conclude that Man and Woman are disjoint, i.e., that they can never have individuals belonging to both of them, because every Person has exactly one gender and individuals that belong to Man have a different gender (male) from those that belong to Woman (female). Hoever, we can also use OWL to state that classes are disjoint. This is most often done for classes that lack complete conditions for belonging to the class. (These classes are called primitive classes.) So, for example, for ReligiousMarriage and CivilMarriage, we have to directly state their disjointness, and here we also say that Marriage is the union of the two.

Manchester Syntax:
Class: f:ReligiousMarriage DisjointWith: f:CivilMarriage
Class: f:Marriage EquivalentTo: f:ReligiousMarriage OR f:CivilMarriage

As it is common to have this situation of a class that is the union of a number of disjoint classes, OWL provides a shorthand method for saying this all at once.

Manchester Syntax:
DisjointUnion: f:Marriage f:ReligiousMarriage f:CivilMarriage

4.5 More Information About Properties

In OWL we can have transitive properties, i.e., properties like ancestor, which also is a generalization of the inverse of the child property, and is also irreflexive.

Manchester Syntax:
TransitiveObjectProperty: f:hasAncestor
IrreflexiveObjectProperty: f:hasAncestor
ObjectProperty: f:hasChild SubPropertyOf: inverseOf f:hasAncestor

From the above information, we can now conclude that Bill has Jeff as an ancestor, and that Bill is not his own ancestor.

Manchester Syntax:
f:Bill f:hasAncestor f:Jeff
f:Bill NOT f:hasAncestor f:Bill

There are yet other kinds of information that we say provide for properties. We can have a spouse property as a symmetric and irreflexive generalization of wife.

Manchester Syntax:
SymmetricObjectProperty: f:hasSpouse
IrreflexiveObjectProperty: f:hasSpouse
ObjectProperty: f:hasWife SubPropertyOf: f:hasSpouse

Although we haven't directly so stated, we can conclude that spouse is also a generalization of husband, because spouse is a symmetric generalization of the inverse of husband.

We could enrich our example to include a loves property as a generalization of the wife property. (Thus turning our simplied view of familial relationships into an idealistic one as well.)

Manchester Syntax:
ObjectProperty: f:loves domain: f:Person
ObjectProperty: f:hasWife SubPropertyOf: f:loves

Because loves is not symmetric, we cannot conclude that loves is a generalization of husband. We have also not specified whether loves is reflexive or not, so some people may love themselves. We could have Narcissist, those people who love themselves, and add some more information about loves relationships>

Manchester Syntax:
Class: f:Narcissist EquivalentTo: f:Person AND f:loves SELF
f:Jeff f:loves f:Jeff
Individual: f:Bill NOT f:Narcissist

From this we can conclude that Jeff belongs to Narcissist and that, of course, Bill does not.

In OWL we can also say some things about how properties combine, using chains of object properties. For example, we can say that sons and daughters are the same for both spouses, i.e., the sons and daughters of an individual include those of their spouse.

Manchester Syntax:
SubObjectProperty: (f:hasSpouse f:hasSon) f:hasSon
SubObjectProperty: (f:hasSpouse f:hasSon) f:hasSon

We can now conclude that Emily has the same sons and daughters as Jeff:

Manchester Syntax:
f:Emily f:hasChild f:Jack
f:Emily f:hasChild f:Ellen

4.6 Conflicting Information

It is also possible to provide conflicting information to OWL. For example, we could say that John has no children who belong to Woman, which conflicts with John having Susan as a daughter.

Manchester Syntax:
Individual: f:John f:hasChild MAX 0 f:Woman

In the presence of conflicting information, determining consequences in OWL breaks down, so it is generally not a good idea to have conflicting information. There is no notion that OWL tools have to reject conflicting information. However, most OWL tools will at least provide some mechanisms to identify conflicting information and allow users to resolve the conflict.

5 Ontology Management

5.1 OWL Ontologies, Documents, and Namespaces

The information we have stated so far falls into two categories. We have stated general information about classes and properties related to familial relationships and particular information about two linked families. In OWL general information about a topic is almost always gathered into an ontology that is then used by various applications. We can also provide a name for OWL ontologies, which is generally the place where the ontology document is placed in the web. Particular information about a topic can also be placed in an ontology, if it is used by different applications.

Manchester Syntax:
Ontology: http://ex.com/owl/families

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

In our example ontology we have used two prefixes, f and xsd. The latter prefix has been used in compact names for XML Schema datatypes, whose IRIs are fixed by the XML Schema recommendation. We thus must the standard expansion for xsd, which is http://www.w3.org/2001/XMLSchema#. The expansion we pick for our the other prefix will affect the names of the classes, properties, and individuals in our ontology, as well as the name of the ontology itself. If we are going to put the ontology on the web, we should pick an expansion that is in some part of the web that we control, both so that we are not using someone else's names by accident. (Here we use a made-up name that no one controls.)

Manchester Syntax:
Namespace: xsd = http://www.w3.org/2001/XMLSchema#
Namespace: dc = ??
Namespace: f = http://ex.com/owl/families#
Namespace: g = http://ex2.com/owl/family#

5.2 Imports

It is also common in OWL to reuse general information in other ontologies. Instead of requiring the copying of this information, OWL allows the importation of the contents of entire ontologies in other ontologies, using imports statements, as follows:

Manchester Syntax:
Import: http://ex2.com/owl/family

As the Semantic Web and ontology construction is distributed it is common for ontologies to use different names for the same concept, property, or individual. Several constructs in OWL can be used to state that different names refer to the same concept, property, or individual, so, for example, we could tie the names used in our ontology to the names used in an imported ontology as follows:

Manchester Syntax:
SameIndividual: f:male g:masculine
SameIndividual: f:female g:feminine
EquivalentClasses: f:Adult g:Grownup
EquivalentObjectProperties: f:hasChild g:child
EquivalentDataProperties: f:age g:age

5.3 Annotations

In many cases we want to associate information with parts of our OWL ontology. OWL uses annotations for this purpose. An OWL annotation simply associates property-value pairs with parts of an ontology. This information is not really part of the logical meaning of an ontology.

So, for example, we could add author information to one of the facts in our ontology and to one of the classes. Two special annotations, labels and comments, have special synax in OWL.

Manchester Syntax:
Annotation: dc:author Individual(f:peter)
Annotation: dc:creationDate "2008-01-10"^^xsd:date
Comment: "A simple fact about John"
f:John f:hasWife f:Mary
Annotation: dc:author Individual(f:peter)
Annotation: dc:creationDate "2008-01-10"^^xsd:date
Label: "Person":en
Label: "Persona":it
Comment: "The class of people"
Class: f:Person

6 Remaining Constructs

There are a few other kinds of things that can be said in OWL, but that do not fit into this example, including the following:

Details on these constructs can be found in the OWL 1.1 Structural Specification and Functional Syntax document [OWL 1.1 Specification].

7 OWL Species

As we have seen, reasoning in OWL can be complicated. The full story of reasoning in OWL is beyond the scope of this primer, but there are some implications of reasoning that deserve treatement here.

7.1 OWL Full

If we did not place further restrictions on what we can say in OWL, e.g., classes, properties, and even bits of syntax can be used as individuals as in the Semantic Web language RDF, reasoning becomes formally undecidable. Nevertheless, there is some utility in being able to do this, so there is a mode of using OWL, called OWL Full that allows all this. The price, of course, is that reasoning tools are hard to write and are necessarily incomplete.

7.2 OWL DL

There are a set of reasonable restrictions, however, that make reasoning in OWL decidable, and for which, moreover, there exist effective reasoning tools. This mode of using OWL is called OWL DL.

To allow effective reasoning tools, OWL DL limits the kinds of things that can be said about certain properties. Properties are said to be composite if they or their inverses are transitive or have a property chain as a subproperty. Properties that are composite or have a composite property as a specialization of themselves or their inverses are not allowed to be functional, inverse functional, irreflexive, asymmetric, or disjoint with any other property; nor are they allowed to participated in cardinality or self conditions. As well, there is a complex condition on how object property chains are constructed to prevent loops related to object property chains. OWL DL tools should recognize whether these conditions are violated in an ontology.

OWL DL allows the same name to be used for any or all of a class, a property, and an individual. However, the different aspects of this name are not tied to one another, so that if, for example, we said, perhaps by accident that Person and Man were the same individual, they would not also be equivalent classes.

Manchester Syntax:
SameIndividual: f:Person f:Man

The above would not allow the conclusion of:

Manchester Syntax:
EquivalentClasses: f:Person f:Man

OWL Full is formally stronger than OWL DL in this area (and in a few other areas) so in OWL Full this conclusion could be drawn.

7.3 OWL Fragments

Reasoning in OWL DL is still difficult, and can take a very long time in the worst case. Certain fragments of OWL DL have been identified that guarantee better worst-case performance for reasoning. The document on OWL Fragments [OWL 1.1 Fragments] identifies and chacterizes several of these fragments that have been shown to be useful in practice. Staying within one of these fragments limits what we can say, but this tradeoff can often be desirable when writing large ontologies, particularly for important applications.

8 What to Do Next

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

This short primer is also not a normative definition of OWL. The normative definition of the OWL syntax as well as informative definitions of each OWL construct can be found in the OWL 1.1 Structural Specification and Functional Syntax document [OWL 1.1 Specification].

For those interested in more formal documents, the formal meaning of OWL can be found in the OWL 1.1 Semantics document [OWL 1.1 Specification], and the mapping between OWL syntax and RDF triples can be found in the OWL 1.1 Mapping to RDF Graphs document [OWL 1.1 RDF Mapping].

9 The Complete Example

Here we include the complete example OWL ontology. The ontology here is ordered in a commonly-used ordering, with ontology information first, followed by information aabout properties, then classes, then individuals. Extra annotations have been added (NOT YET) to help explain the ontology.

Manchester Syntax:
Namespace: xsd = http://www.w3.org/2001/XMLSchema#
Namespace: f = http://ex.com/owl/families/#
Namespace: g = http://ex2.com/owl/family.owl#
Ontology: http://ex.com/owl/families/
Import: http://ex2.com/owl/family.owl
ObjectProperty: f:hasWife domain: f:Person range: f:Person
ObjectProperty: f:hasWife domain: f:Man range: f:Woman
FunctionalDataProperty: f:hasWife
InverseFunctionalDataProperty: f:hasWife
IrreflexiveFunctionalDataProperty: f:hasWife
AsymmetricFunctionalDataProperty: f:hasWife
ObjectProperty: f:hasHusband inverseOf: f:hasWife
ObjectProperty: f:hasChild domain: f:Person range f:Person
ObjectProperty: f:hasSon SubPropertyOf: f:hasChild
ObjectProperty: f:hasSon domain: f:Person range: f:Person
ObjectProperty: f:hasSon domain: f:Parent range: Person AND f:hasGender f:male
ObjectProperty: f:hasDaughter SubPropertyOf: f:hasChild
ObjectProperty: f:hasDaughter domain: f:Person range: f:Person
ObjectProperty: f:hasDaughter domain: f:Parent range: Person AND f:hasGender f:female
DisjointObjectProperties: f:hasSon f:hasDaughter
SubObjectProperty: (f:hasSpouse f:hasSon) f:hasSon
SubObjectProperty: (f:hasSpouse f:hasSon) f:hasSon TransitiveObjectProperty: f:hasAncestor
IrreflexiveObjectProperty: f:hasAncestor
ObjectProperty: f:hasChild SubPropertyOf: inverseOf f:hasAncestor SymmetricObjectProperty: f:hasSpouse
IrreflexiveObjectProperty: f:hasSpouse
ObjectProperty: f:hasWife SubPropertyOf: f:hasSpouse
ObjectProperty: f:loves domain: f:Person
ObjectProperty: f:hasWife SubPropertyOf: f:loves
DataProperty: f:hasAge domain: f:Person range: xsd:integer
FunctionalDataProperty: f:hasAge
Class: f:Person
Class: f:Person SubClassOf: f:hasAge EXACTLY 1 AND f:hasGender EXACTLY 1 AND f:hasGender ALL { f:male f:female }
Class: f:Man SubClassOf: f:Person
Class: f:Man EquivalentTo: f:Person AND f:hasGender VALUE f:male
Class: f:Woman SubClassOf: f:Person
Class: f:Woman EquivalentTo: f:Person AND f:hasGender VALUE f:female
Class: f:Parent SubClassOf: f:Person
Class: f:Parent EquivalentTo: f:Person AND f:hasChild MIN 1 f:Parent
Class: Teenager SubClassOf: Person AND hasAge SOME xsd:integer ≥ "13"^^xsd:integer < "20"^^xsd:integer
Class: Adult SubClassOf: Person AND hasAge SOME xsd:integer ≥ "21"^^xsd:integer
Class: Child SubClassOf: Person AND NOT ( hasAge SOME xsd:integer ≥ "21"^^xsd:integer )
Class: f:YoungChild EquivalentTo: NOT ( f:Teenager OR f:Adult )
Class: f:ReligiousMarriage DisjointWith: f:CivilMarriage
Class: f:Marriage EquivalentTo: f:ReligiousMarriage OR f:CivilMarriage
DisjointUnion: f:Marriage f:ReligiousMarriage f:CivilMarriage
Class: f:Narcissist EquivalentTo: f:Person AND f:loves SELF
f:John f:hasWife f:Mary
f:John f:hasSon f:Bill
f:Mary f:hasSon f:Bill
f:John f:hasDaughter f:Susan
f:Mary f:hasDaughter f:Susan
f:John f:hasAge "33"^^xsd:integer
f:Mary f:hasAge "31"^^xsd:integer
f:Bill f:hasAge "13"^^xsd:integer
f:Susan f:hasAge "8"^^xsd:integer f:John f:hasGender f:male
f:Mary f:hasGender f:female
f:Bill f:hasGender f:male
f:Susan f:hasGender f:female f:Jeff f:hasWife f:Emily
f:Jeff f:hasChild f:Jack
f:Jeff f:hasChild f:Ellen
f:Jeff f:hasAge "77"^^xsd:integer
Individual: f:Ellen f:hasAge SOME xsd:integer ≥ "15"^^xsd:integer ≤ "21"^^xsd:integer
Individual: f:Emily f:hasAge VALUE { "39"^^xsd:integer ≤ "49"^^xsd:integer }
f:Jeff NOT f:hasAge "53"^^xsd:integer Individual: f:Jeff f:hasChild EXACTLY 2 DifferentIndividuals: f:John f:Mary f:Bill f:Bill f:Susan
DifferentIndividuals: f:Jeff f:Emily f:Jack f:Ellen f:Susan
DifferentIndividuals: f:male f:female f:Jeff f:loves f:Jeff
Individual: f:Bill NOT f:Narcissist SameIndividual: f:John f:Jack
SameIndividual: f:male g:masculine
SameIndividual: f:female g:feminine
EquivalentClasses: f:Adult g:Grownup
EquivalentObjectProperties: f:hasChild g:child
EquivalentDataProperties: f:age g:age

References

[OWL 1.1 Fragments]
OWL 1.1 Web Ontology Language: Tractable Fragments. Bernardo Cuenca Grau, 2007.
[OWL 1.1 RDF Mapping]
OWL 1.1 Web Ontology Language: Mapping to RDF Graphs. Bernardo Cuenca Grau and Boris Motik, 2007.
[OWL 1.1 Semantics]
OWL 1.1 Web Ontology Language: Model-Theoretic Semantics. Bernardo Cuenca Grau and Boris Motik, 2007.
[OWL 1.1 Specification]
OWL 1.1 Web Ontology Language: Structural Specification and Functional-Style Syntax. Peter F. Patel-Schneider, Ian Horrocks, and Boris Motik, 2007.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, eds. W3C Recommendation 28 October 2004.