Primer

From OWL

Revision as of 16:02, 16 April 2008 by BijanParsia (Talk | contribs)
Jump to: navigation, search

[Hide Review Comments]

Document title:
OWL 2 Web Ontology Language
Primer
Authors
Bijan Parsia, University of Manchester
Peter F. Patel-Schneider, Bell Labs Research, Alcatel-Lucent
Abstract
The OWL 2 Web Ontology Language, informally OWL 2, is an ontology language for the Semantic Web with formally defined meaning. OWL 2 ontologies provide classes, properties, individuals, and data values and are stored as Semantic Web documents. OWL 2 ontologies can be used along with information written in RDF, and OWL 2 ontologies themselves are primarily exchanged as RDF documents. The OWL 2 Document Overview describes the overall state of OWL 2, and should be read before other OWL 2 documents.
This short primer provides an approachable introduction to OWL 2, including orientation for those coming from other disciplines, an example showing how OWL 2 can be used to represent first simple information and then more complex information, how OWL 2 manages ontologies, and finally the distinctions between the various sublanguages of OWL 2.
Status of this Document
This is an editors' draft. This document is a first draft with several missing parts (including sections on tools and "use"; pointers from the various constructs to a more authoritative document; and annotations in the full example in the Appendix), questions about the structure and order of sections, and further presentational experiments underway. The OWL Working Group solicits feedback on how to improve and update the document. In particular, the group solicits feedback on the content of the "technology perspectives" from the point of view of practitioners in those areas.

Copyright © 2008-2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Contents



1 Introduction

Editor's Note: At the second F2F meeting, the Working Group has decided to simplify the vocabulary of OWL ontologies. In future versions of this specification, the terminals of the functional-style grammar and the RDF vocabulary will be significantly smaller.

The W3C OWL 2 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 meaning, meanings that fit together to support exact and useful representation of many different kinds of information. OWL groups information into ontologies in the form of documents that can be stored and transmitted across the World Wide Web in the same way that data and other kinds of information are and that can be completely and effectively processed by tools that extract the information implicit in an ontology.

Review comment from Dlm 19:16, 23 March 2008 (EDT)
Added next sentence for connection to OWL 1. Also, longer higher level comments in http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0235.html <<BijanParsia 16:11, 13 April 2008 (EDT) There are now specific sections about OWL 1. Also, this is now OWL 2, so I suppose arguments appealing to it being OWL 1.1 need to be revisted?>>
Review comment from --Baojie 08:50, 3 April 2008 (EDT)
Some of my comments are on the discussion page; Talk:Primer#Review_from_Jie_Bao <<BijanParsia 16:11, 13 April 2008 (EDT) See review comments on the discussion; in general, in line comments are preferred>>

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 a running example that illustrates the different kinds of information that can be represented in OWL. The Appendix contains the entire example ontology. The primer then describes how OWL packages information into ontologies and how extra information is associated with parts of an ontology. There are links from the short descriptions of the OWL constructs here to other documents that provide more information on OWL. Finally, the primer describes the various sublanguages of OWL, and what is gained and lost by using them.

Review comment from Dlm 19:18, 23 March 2008 (EDT)
Consider rewriting if we reorganize to put some material in appendices. I am providing a longer description in a separate review note, but I suggest only brief orientation descriptions in the main part of the document and longer orientation segments (more like the current length) in an appendix. The reason I suggest this is that many readers will not want to read many of the orientations and this material, while valuable, may be distracting so early on in the document. <<BijanParsia 16:11, 13 April 2008 (EDT) I think we're mostly agreed; otoh, I don't see why people wouldn't just skip over those sections.>>

OWL is in some respects similar to various existing modeling formalisms and in other respects very different. Some features of OWL may be surprising to people grounded in specific methodologies and the significant advantages of other features may be missed due to unfamiliarity. The key goal of the primer is to help develop insight into OWL, its strengths, and its weaknesses. Users interested in the details of every OWL construct should consult the OWL 2 Structural Syntax. There are also many tutorials available freely on the web, including those bundled with specific OWL ontology development environments.

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 an appendix, we provide discussions of OWL from the lens of related or contrasting technologies, including RDF, XML, object oriented programming, databases, and the prior version of OWL, OWL 1. If you are familiar with any of these technologies, we recommend reading the relevant section of the appendix before proceeding with the rest of the primer.

Review comment from [[[User:DougLenat|Doug]] 15:37, 18 March 2008 (EDT)
Excellent plan; we need folks from those various communities to pitch in and add lots more highlights of exactly the promised sort!<<BijanParsia 13:39, 14 April 2008 (EDT) Indeed. I'm hoping to make them ongoingly editable.>>
Review comment from Dlm 19:28, 23 March 2008 (EDT)
In addition to pitching in, I would like to see someone from each of the communities in a particular orientation, read the orientation and comment (a) if it was understandable and (b) if the description might be improved to help people from their community determine when and why they might use OWL.<<BijanParsia 13:39, 14 April 2008 (EDT) This seems to be a process comment and not a comment on the text. So, no further action needed.>>

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.

Review comment from Dlm 19:43, 23 March 2008 (EDT)
I have gotten input from people asking for more introductory material here - more like the OWL Guide Level. If we do not want to introduce that much detail, perhaps we just point to it saying it provided additional introductory material for the previous version of the language and/or point to a document like ontologies 101 for background on building ontologies.

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. There are various syntaxes for OWL available, which serve various purposes: When OWL information is transferred around in the Web, it is written in an XML dialect.

Review comment from Dlm 19:38, 23 March 2008 (EDT)

We need to think about how to handle the syntax issue. The buttons turning them on and off is great. I think we want to get group consensus on which syntax to use as the default syntax. One perspective is to have the default syntax would be the one that is most compatible with the OWL 1 documents in order to help readability and acceptance. Another perspective is to use the syntax most widely adopted in W3C documents. One question that has come up is how many syntaxes to include. I propose that we gather input on (1) which syntax to use as the default (2) which syntaxes to include (3) if we should make an effort to limit the number of different syntax options.

We also may want to point out which syntax options are new over the OWL 1 documents so as to minimize confusion.

The Manchester syntax [OWL 2 Manchester Syntax] is an OWL syntax that is designed to be easier for non-logicians to read. The Functional-Style syntax [OWL 2 Specification] is designed to be easier for specification purposes and for reasoning tools to use. The OWL XML syntax is an XML syntax for OWL defined by an XML schema [OWL 2 Specification]. The RDF/XML syntax for OWL is just RDF/XML, with a particular translation for the OWL constructs [OWL 2 RDF Mapping] . There are tools that can translate between the different syntaxes for OWL.

The running example and the entire example ontology in the appendix can be viewed an any of the four different syntaxes, by default the Manchester syntax is the only one shown.

The buttons below can be used to show or hide all four syntaxes.

Suppose we want to represent information about a particular family. (We do not intend this example to be representative of the sorts of domains OWL should be used for, or as a canonical example of good modeling with OWL, or a correct representation of the rather complex, shifting, and politically explosive domain of families. Instead, we intend it to be a rather simple exhibition of various features of OWL.) We first need to 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 set up individuals and write all these facts down, along with age facts as follows.

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
The running text consistently uses properties such as 'age', 'wife' etc. where the code examples use 'hasAge' and 'hasWife'.
Review comment from RinkeHoekstra 12:27, 1 April 2008 (EDT)
Why the f namespace prefix... it doesn't exactly improve readability. EDIT: Perhaps add pointer to Ontology Management

Individual: f:John
Facts: f:hasWife f:Mary,
f:hasSon f:Bill,
f:hasDaughter f:Susan,
f:hasAge 33
Individual: f:Mary
Facts: f:hasSon f:Bill,
f:hasDaughter f:Susan,
f:hasAge 31
Individual: f:Bill
Facts: f:hasAge 13
Individual: f:Susan
Facts: f:hasAge 8

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

Individual: f:John Facts: f:hasGender f:male
Individual: f:Mary Facts: f:hasGender f:female
Individual: f:Bill Facts: f:hasGender f:male
Individual: f:Susan Facts: f:hasGender f:female Individual: f:male
Individual: f:female

However, all we have done so far is written down the basic facts about a particular family. In a sense, we have used just the "RDF" portion of OWL that is tagging individuals as instances of named classes and relating them to other individuals by properties. While this is already quite useful, OWL also lets you describe how families work in general.

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.) For starters, the individuals in families are all people, so we should have a class of people, with name Person. Below you will find 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.


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: integer

From this information we (or a reasoner) 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.

Individual: f:John Types: 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, 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.

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
Depending on audience, the meaning of terms such as functional, symmetric, inverse functional etc. may not be clear at all. We should perhaps consider a more elaborate description of these properties.

ObjectProperty: f:hasHusband Inverses: 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
DataProperty: f:hasAge Characteristics: Functional
ObjectProperty: f:hasWife Characteristics: Functional, InverseFunctional, Irreflexive, Asymmetric

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.

So far we have written down quite a bit of information about familial properties, but we have only used a single class: Person. OWL has a rich language for defining classes in terms of other classes, but also in terms of the relations its instances may or must have to other individuals. So we might have classes for men, women, and parents, each of which is a specialization of Person.

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

Review comment from [[[User:DougLenat|Doug]] 10:23, 19 March 2008 (EDT)
This might be a good place to insert something like: If this modeling were happening dynamically, a reasoner might at this point give the modeler the option to tighten up their previous assertions about the domain and range of hashusband, haswife, hasson, hasdaugther, etc.

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

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
Shouldn't we explain the difference/relation between functional properties and cardinality restrictions?

ObjectProperty: f:hasGender
Class: f:Person SubClassOf: f:hasAge exactly 1 and f:hasGender exactly 1 and f:hasGender only {f:female , f:male}
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:Person

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 giving them more specific domains and ranges.

ObjectProperty: f:hasWife Domain: f:Man Range: f:Woman
ObjectProperty: f:hasSon Domain: f:Parent Range: Person that f:hasGender value f:male
ObjectProperty: f:hasDaughter Domain: f:Parent Range: Person that f:hasGender value 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.

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 an integer that 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.

Class: Teenager EquivalentClass: Person and hasAge some integer[>= 13 , < 20]
Class: Adult EquivalentClass: Person and hasAge some integer[>= 21]
Class: Child EquivalentClass: Person and not ( hasAge some integer[>= 21] )

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 built-in 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 More Expressive Modeling

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
How about renaming this section to something more in line with the 'take by the hand' nature of the primer. As a naive reader, I would be scared-off by this title, and postpone reading. <<BijanParsia 19:01, 8 April 2008 (EDT) I don't know if this new title helps>>
Review comment from Dlm 19:51, 23 March 2008 (EDT)
I agree that some of this material is rather advanced (although some of it i feel is not. One question is whether we agree about what is advanced and then consider having the advanced material in an advanced appendix.<<BijanParsia 17:01, 14 April 2008 (EDT) The section's been renamed and we're hitting an overwhelming mass of appendicies>> Also, as a logistical issue, i am finding that sometimes i want to go back and forth between the syntaxes and i currently only see one set of buttons, which means i have to scroll all the way up to get to the button and then back down to get back to what i was viewing. we might consider putting the buttons on (possibly in a more compressed format since i presume that is why they are only exposed once) anywhere there is a signficant amount of owl.<<BijanParsia 17:01, 14 April 2008 (EDT) This is being dealt with...also, please keep your review comments focuse on one issue so as to make it easier to manage>>

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 understand how OWL is different.

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.

Individual: f:Jeff
Facts: f:hasWife f:Emily,
f:hasChild f:Ellen,
f:hasChild f:Jack,
f:hasAge 77

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 Jack's age is not 53.

Review comment from ivan 11:09, 28 March 2008 (EDT)
In the RDF/XML version below the rdf:Description in owl:oneOf should be indented one level deeper. Actually, it might look a bit simpler if, instead of using rdf:Description + rdf:type, the owl:DataRange and rdf:List would be used as element names.


Individual: f:Emily Types: f:hasAge some {39 , 49}
Individual: f:Ellen Types: f:hasAge some integer[ ≥ 15, ≤ 21 ]
Individual: f:Jack Facts: not f:hasAge "53"^^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.

Class: f:YoungChild EquivalentTo: f:Person and not ( f:Teenager or f:Adult )

Review comment from Doug 10:31, 19 March 2008 (EDT)
A more dramatic extension to this example might be to include a parent of Jeff, say Abe,

and a constraint about parents being older than their children, etc., etc., concluding

that Abe must be an Adult automatically.

There are many sources of incompleteness in OWL, some of which may be surprising to some readers. 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 at most one child that belongs to Man. Formally, the following is not a consequence of the above information.

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
What does 'not in complete ontology' mean?

(not in complete ontology)
Individual: f:Jeff Types: f:hasChild exactly 2
Individual: f:Jeff Types: 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.

Individual: f:Jeff Types: f:hasChild exactly 2

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" would be particularly dangerous in the Semantic Web, where names may be coined by different organizations at different times unknowingly referring to the same individual.) 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 individuals 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.

DifferentIndividuals: f:John f:Mary f:Bill f:Susan
DifferentIndividuals: f:Jeff f:Emily f:Jack f:Ellen f:Susan
Individual: f:male DifferentFrom: f: female

Review comment from ivan 11:16, 28 March 2008 (EDT)
It is clearly difficult to see what is advanced and not advanced... However, the fact that owl:sameAs is introduced so late in the process may not be the best choice. owl:sameAs may be the most widely used OWL predicate in practice (the Linking Open Data community is based on the usage of millions of owl:sameAs binding, say, DBPedia data to others). Of course, the difficulty is that the way it is introduced in the text nicely fits into the story... Sigh... <<BijanParsia 19:04, 8 April 2008 (EDT) Does the new title (without "advanced") solve this?>>

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.

Individual: f:John SameAs: f:Jack

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). However, 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.

Class: f:CivilMarriage
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.

(not in complete ontology)
Class f:Marriage DisjointUnionOf: f:ReligiousMarriage f:CivilMarriage

Review comment from pfps 08:19, 10 March 2008 (EDT)
Uli comment: Section seems very advanced and she was surprised not to see stuff on universial/existential quantifiers

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

ObjectProperty: f:hasAncestor Characteristics: Transitive, Irreflexive
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.

(not in complete ontology)
Individual: f:Bill
Facts: f:hasAncestor f:Jeff
not f:hasAncestor f:Bill

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

ObjectProperty: f:hasSpouse Characteristics: Symmetric, Irreflexive
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.)

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>

Class: f:Narcissist EquivalentTo: f:Person that f:loves Self
Individual: f:Jeff Facts: f:loves f:Jeff
Individual: f:Bill Types: 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.

Review comment from ivan 11:16, 28 March 2008 (EDT)
Sorry to be too critical, but I found this part on property chains unclear. I think more explanation should be given on how they work (which may not avoid having something on existentials, as Uli said). For a mathematician the fact that these are concatenation of binary relations is of course clear (and the sign used in the M'ter syntax hints at that), but for non-mathematician readers this may not be obvious at all. Also: in my understanding, there are limits in what chains can express and how they can be used; maybe a word of warning should be added to the text which at least hints at that.

SubObjectProperty: f:hasSpouse o f:hasSon f:hasSon
SubObjectProperty: f:hasSpouse o f:hasDaughter f:hasDaughter

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

(not in complete ontology)
f:Emily f:hasChild f:Jack
f:Emily f:hasChild f:Ellen

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. An ontology with conflicting information allows all sorts of bad consequences - many OWL tools will detect inconsistent ontologies and provide some sort of repair mechanism.

(not in complete ontology)
Individual: f:John f:hasChild max 0 f:Woman

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
'determining consequences in OWL breaks down'... what does that mean? And what 'OWL' ? (Difference between DL and Full is only discussed later on)

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.

Review comment from [[[User:DougLenat|Doug]] 10:41, 19 March 2008 (EDT)
To amend/amplify Uli's comment, I would say that what we really should consider adding here are more examples of (1) the various sophisticated things that OWL can represent, and (2) examples of things that it can't, for users coming to OWL (as, e.g., I did) used to much more expressive formal representation languages.

5 Ontology Management

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.

Ontology: <http://example.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.

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
What are IRI's? I mean, the wiki page contains no link, and the abbreviation is not explained

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 use the standard expansion for xsd, which is http://www.w3.org/2001/XMLSchema#. The expansion we pick for 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.) The two XML-based syntaxes need namespaces for built-in names and also use XML entities for namespaces.

Review comment from ivan 11:19, 28 March 2008 (EDT)
I know this is really a small thing, but I could read the previous remark as if in the XML based syntaxes I need to use XML entities. This clearly not true; the usage of entities is a convenient, but not necessary shorthand...

Namespace: f = <http://example.com/owl/families#>
Namespace: g = <http://example.com/owl2/families#>
Namespace: dc = <http:...#>

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:

Import: http://example.com/owl2/families

Review comment from [[[User:DougLenat|Doug]] 10:57, 19 March 2008 (EDT)
It's not obvious here how the OWL user is supposed to say that one relation is

a restriction of the other; e.g., f:hasMother has the domain Animal and g:theirMother has the domain Person. The next trickier case is where and h:motherOf has the range Mammal and is the inverse function to f:hasMother. the next trickier case is where the arities are different and one is a projection of the other, such as a nextTo relation in one ontology corresponding to a projection of a ternary physicallySeparating relation in another ontology... I suppose this doesn't come up

if you limit yourself to binary relations, so we can omit treating this last case.

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 class, 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:

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

In many cases we want to associate information with parts of our OWL ontology. OWL provides annotations for this purpose. An OWL annotation simply associates property-value pairs with parts of an ontology, or the entire ontology itself. 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.

Individual f:John Facts: Annotations: dc:author Individual(f:peter) dc:creationDate "2008-01-10"^^xsd:date rdfs:comment "A simple fact about John" f:hasWife f:Mary Class: f:Person Annotations: dc:author Individual(f:peter) dc:creationDate "2008-01-10"^^xsd:date rdfs:label "Person":en rdfs:label "Persona":it rdfs:comment "The class of people"

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

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

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:

  • Some other datatype facets from XML Schema datatypes, including length, minLength, maxLength, totalDigits, and fractionDigits.
  • Data properties in, all, min, max, and value constructs.
  • Object properties in some constructs.
  • Data properties as subproperties of or disjoint from other data properties.
  • Some 2- or N-way versions of disjointness, equivalence, and difference.

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

7 Using OWL

Editor's Note: Give a worked example. I was thinking some policy both background knowledge and underlying the formalisms. Or perhaps a Galenesque example.
Review comment from Dlm 19:55, 23 March 2008 (EDT)
If the group is interested, i will explore using the vsto ontology that uses OWL to support access to and integration of scientific data in a virtual observatory.

7.1 Terminology development and management

Review comment from Dlm 19:28, 23 March 2008 (EDT)
This subsection feels a bit odd to me to be in the same section with each of the orientation perspectives.

However, if we take the suggestion of having only a few sentence summary of the different orientations, we might motivate the usage of OWL by these next subsections and have them comprise the bulk of the inline section 2 (with the different orientations in the appendix.) Another question to me is if we want to have more than just 2 of these examples.

.. <<BijanParsia 14:36, 14 April 2008 (EDT) Mooted by the reorg.>>

Terminologies, controlled vocabularies, taxonomies and the like are used for a range of information retrieval (IR) tasks such as query broadening or supporting faceted access. Predefined terminologies may also be used at data entry either to catalog the entry (for IR support) or to guide the user in a variety of ways. For example, in clinical support systems certain forms or parts of forms may only be displayed when the clinician is to perform specific sorts of procedures, and these procedures can be identified by a combination of terms from a controlled vocabulary.

Developing and maintaining large terminology is time- and skill-intensive, even if the structure of the terminology is relatively simple. OWL can support the process in a number of ways:

  • developers can encode models of the domain, instead of just encoding relations between terms -- the relations are then derived from the modeling. This provides an independent check that the terminological relation is correct. The formal semantics of OWL also gives a precise meaning to any definitions; this meaning is available to other modelers or to tools.
  • reasoners can confirm the consistency of models (and definitions). For example, a reasoner can determine whether a class definition can consistently have an instance.
  • reasoners can extract implicit information from the descriptions; i.e., inference procedures can automatically verify intended entailments and check for unintended ones.
  • reasoners can operate on the terminology as a whole, analyzing it to determine much about its structure. For example, to determine whether it is lop-sided, or to identify subsets of the terminology which are logically independent of each other (but individually interdependent; the logically independent portions of the terminology may be removed or enhanced.)
Review comment from [[[User:DougLenat|Doug]] 10:05, 19 March 2008 (EDT)
I thought I was going to just slightly touch up that last bulleted list but ended up seriously rewriting parts of it, so please review it; this applied particularly to the author(s) who wrote that list originally.

OWL has been used to support very large terminologies consisting of hundred of thousands of terms in complex hierarchies. Galen? NCI? SNOMED? Much work has been done using OWL in the Health Care and Life Sciences (HCLS) domain where there is a wealth of experience in developing large scale terminologies.

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
Just a reminder: make sure the link to Galen,NCI,SNOMED actually points somewhere

For terminology development, OWL reasoners have in the past traditionally been used at development time only; i.e., off line from the application. In such cases, the reasoner acts like a "terminology complier", that is, it assembles a complete taxonomy from definitions of terms. The taxonomy is then deployed in the application. For retrieval tasks of relatively stable collections, this has been an acceptable way to cope with the difficulty of reasoning with large ontologies. However, as computing power has increased and OWL reasoners have grown more optimized, there is increasing on line, deployment time use of OWL reasoners in terminological applications. In particular, what is sometimes known as "post coordination" -- that is, the ability of a person at the data entry point to extend the terminology to better fit their situation -- has become more common. Such dynamic terminology extension in critical systems can benefit by the methodological rigor supported by OWL reasoners. Instead of merely coining a term and plopping it somewhere in the taxonomy, end users are encouraged to refine existing terms by specializing their definitions.

To take a simple example, a doctor wishing to record that a patient has an almond allergy might be directed to enter that an almond is a kind of nut. The system then can recognize that the almond allergy is a form of nut allergy and the requisite advice or entry forms presented as usual. Of course in this situation it would be more realistic for the application to be built on, or have access to, a large, broad existing ontology such as OpenCyc which already knew things like almonds are nuts, rather than asking the physician to stop doing medicine and instruct the system in matters relating to almonds.

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
The above paragraph is quite long, and still contains an incomplete sentence ('... assembling').<<BijanParsia 13:39, 14 April 2008 (EDT) Fixed>> Also, the mentioning of OpenCyc could use a link... and we might consider mentioning other ontologies as well (or none at all)<<BijanParsia 13:39, 14 April 2008 (EDT) Yeah, I'm still unsure what or how many ontologies to mention and how.

7.2 Conceptual Modeling

As we saw with terminological management, a key benefit of OWL is the support it gives to modeling subject domains, that is, to conceptual modeling. OWL is a capable language for conceptual modeling, for example, it can easily encode most entity-relationship diagrams and many UML diagrams. Once encoded, OWL reasoners can find implicit relations, conflicts, and missing pieces. Since OWL can describe and work with incomplete information it is well suited for high level conceptual work wherein you are not merely abstracting from the physical or logical layers of an information system, but you are still unsure about various aspects of the conceptual structure. OWL allows you to defer various modeling decisions while still making effective use of what you do know.

OWL supports a variety of styles of modeling, e.g., top down or bottom up, iterative or upfront, or refinement oriented vs generalizing. When modeling, a reasoner (and other tools) can provide continual feedback to the model. Indeed, often the absence of any reaction from a reasoner gives valuable information to the modeler (i.e., their model is much less well described than they had thought).

OWL based conceptual models can be used for information integration as well. For example, supposed you are faced with the task of integration two database applications that have radically different schemata but, at least to a first glance, similar conceptual models. By first casting both models into OWL, then aligning parts of the model with each other, one can find hidden relations as well as inconsistencies between the model (or in your understanding of their relations). By exploring things at the conceptual level, you are not distracted by the in principle irrelevant low level implementation details. Since the models have a clear semantics, they can be systematically checked. Instead of tediously verifying correspondences by hand, you can spend your time tweaking the modeling or the alignment.

Review comment from [[[User:DougLenat|Doug]] 10:13, 19 March 2008 (EDT)
I suggest adding two clarifying notes here, one encouraging and one cautionary.

First, that the value of this approach to information integration dramatically increases as the number n of databases being integrated increases, as we are moving from an n-squared to a linear-in-n integration effort. Second, that in cases where the correspondence between the two database schemata is not so clearcut, the articulation axioms that one would need to write might exceed the expressive capabilities of OWL, so this should be considered

a promising candidate but by no means a guaranteed approach to such integration in all cases.


OWL based conceptual models have been used directly to federate disparate information systems. There are several techniques ranging from treating the conceptual models as high level schemas for an RDF based data store to exploiting the conceptual models to build distributed queries against the data's home systems. {{Review|[[[User:DougLenat|Doug]] 10:13, 19 March 2008 (EDT)|It would be useful to give some explicit references here.}<<BijanParsia 13:39, 14 April 2008 (EDT) See Rinke's comment>>}

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
Good suggestion, but it seems to me that the more you refer to other work, the faster this document becomes (out)dated.<<BijanParsia 13:39, 14 April 2008 (EDT) Yes, I'm concerned about longevity of the document. I don't have any good answers.>>

8 OWL Tools

Editor's Note: Different sorts of OWL tools. Maybe some discussion of using XML tooling or RDF tooling. Reasoner services. Whatev
Review comment from Dlm 19:57, 23 March 2008 (EDT)
This feels to me like it should be in another document. Perhaps we can consider getting Michael Denny to do another update to his tools document and spreadhseet. <<BijanParsia 07:13, 9 April 2008 (EDT) I think you misunderstand my intent. I don't intend to list tools, but to talk about *categories* of tools and things they can do. E.g., what's a reasoner and what services do they provide.>>

8.1 Editors

8.2 Reasoners

8.3 IDEs

9 OWL Profiles

OWL 2 has two major dialects, OWL 2 DL and OWL2 Full. Both use the entire OWL built-in vocabulary: that is, the basic concepts of the languages is very similar. Both allow you define classes using restrictions or constraint properties with property chains, and so on. Similarly, OWL DL ontologies are all syntactically legal OWL Full ontologies and the consequences under each semantics generally coincides. (Under OWL Full semantics, there may be additional entailments. Ssome ontologies may be inconsistent under OWL Full semantics while consistent under OWL DL semantics.)

Conceptually, we can think of the difference between OWL DL and OWL Full in two ways:

  • One can see OWL DL as a syntactically restricted version of OWL Full where the restrictions are designed to make life easier for implementors. In fact, since OWL Full is undecidable, OWL DL makes writing a reasoner that, in principle, can return all yes and no answers<<Yes yes, needs elaborating>> (subject to resource constraints) possible. As a consequence of its design, there are several production quality OWL DL reasoners that cover the entire language (modulo bugs in the implementation). There are no such OWL Full reasoners.
  • One can see OWL Full as the most straightforward extension of RDFS. As such, it follows the RDFS semantics and general syntactic philosophy (i.e., everything is a triple and the language is fully reflective). OWL DL, as the name suggests, is designed to be a syntactic variant of a description logic, that is, a fragment of standard first order logic. OWL Full has been used to help specify extensions to RDFS in implementations (e.g., some implementors "add a little OWL" to their RDFS systems for various applications).

Of course, OWL Full and OWL DL have been designed together and thus have influenced each other. For example, one design goal of OWL 2 was to bring OWL DL syntactically closer to OWL Full (that is, to allow more RDF Graphs/OWL Full ontologies to be legal OWL DL ontologies). This led to the incorporation of punning into OWL 2.

In addition to OWL DL and OWL Full, OWL 2 specifies three additional [Profiles] of OWL. OWL, in general, is a very expressive language (both computationally and for users) and thus can be difficult to implement well and to work with. These additional profiles are designed to be approachable subsets of OWL sufficient for a variety of applications. As with OWL DL, computational considerations are a major requirement of these profiles (and they are all much easier to implement with robust scalability given existing technology), but there are many subsets of OWL that have good computational properties. The selected OWL 2 profiles were identified as having substantial user communities already, although there were several others not included and one should expect more to emerge. The profiles document provides a clear template for specifying additional profiles.

In the following sections we discuss each profile and their design rationale, and provide some guidance for users in selecting which profile to work with. Please be aware that this discussion is not comprehensive, nor can it be. Part of any decision has to be based on available tooling and how that fits it with the rest of your system or workflow. For example, you may require that your tools are implemented in Java and that dominates any decision. So you might choose to use a profile that doesn't fit as well with your modeling problem in order to use the better Java tool. Before making a major commitment we would suggest at least consulting with [public-owl-dev@w3.org] which hosts such discussions, or consulting with an expert.

9.1 EL++

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

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

Working with EL++ is fairly similar to working with OWL DL: one can use class expressions on both sides of a subClassStatement and even infer such relations. For many class expression oriented ontologies, EL++ makes a good approximation target, that is, by only a little simplification one can get an EL++ ontology and preserve much of the meaning of the original ontology.

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

Two key missing features are allValuesFrom and cardinality restrictions....

Editor's Note: What else? I suppose some examples.

9.2 DL Lite

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

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

Editor's Note: Illustrative example here, obviously

9.3 OWL-R

The design of OWL-R stems from two related impulses:

  • It should be implementable by direct translation into standard rule systems.
  • It should capture all the OWL Fullish features of RDFS.
Editor's Note: The second is not quite right or helpful. Must ponder more...

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

OWL-R also has two dialects: The OWL DL dialect and the OWL Full dialect....

Editor's Note: Ran out of steam

9.4 OWL 1 Species

In OWL 1, profiles were called "species" and there were three of them, OWL Lite, OWL DL, and OWL Full. OWL DL 1 and OWL Full 1 are proper subsets of OWL DL 2 and OWL Full 2. There's no major reason to continue to distinguish them in OWL 2 as they are fairly close in extensibility and OWL 2 tools can handle OWL 1 ontologies without problems.

OWL Lite was intended to be similar to EL++, DL Lite, or OWL-R but there were several problems with its design, most notably that it was not significantly easier to implement nor more robustly scalable than OWL DL. Thus, there wasn't a huge performance (or tool) benefit to staying inside OWL Lite. OWL Lite also could express things that were in OWL DL but in very indirect ways that were very surprising. For example, while the "complementOf" construct was not part of the syntax of OWL Lite, that one class was a subclass of another could be encoded in OWL Lite.

OWL Lite is a subset of OWL DL 2 and OWL Full 2 but is no longer a recommended profile.


9.5 OWL Profiles (old)

Editor's Note: The may be some material (or effects accomplished) from here that we want to incorporate into the new version. Right now, there's waaaaaay to much esp. if we start giving examples of differences.

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 treatment here.

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.

Review comment from m_schnei 09:33, 12 April 2008 (EDT)
The first sentence above is misleading: It sounds to me as if undecidability of OWL Full is something inevitable, when there are no "further restrictions on what we can say in OWL". It is true that the OWL Full semantics is undecidable, but this is a research result, and it only holds for the specific semantics which currently exist for OWL Full. It is easy to weaken the semantics of OWL Full in a way that the resulting language is both RDFS compatible and decidable. Examples are RDFS and pD*, which accept all OWL Full ontologies as input. I think the relevant bit here is to talk about a language which (a) is a semantical upper language of RDFS, and (b) is a semantical upper language of OWL DL. In this case, the text would need to be a bit reorganized, because OWL DL is treated after OWL Full in the discussion above. But another question is then, whether the primer should talk about such technical terms like "undecidability" or "completeness" at all. Should these terms really be regarded as important, then they should be explained in an appendix, because most readers of this primer will not have any idea about what they mean, in particular in the context of model-theoretic semantics based reasoning.

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.

Review comment from ivan 11:24, 28 March 2008 (EDT)
I believe we will need much more examples here to show what can and cannot be done in DL; the above sentences are really a mouthful for the non-initiated:-) I also wonder whether we should not have a separate section on OWL-R Full, too, alongside the OWL DL part
Review comment from m_schnei 09:58, 12 April 2008 (EDT)
(to Ivan) But I really appreciate to have such a paragraph at least somewhere in the primer. Otherwise, the "Non-structural Restrictions" section in the DL-syntax document will keep a mouthful even for most of the initiated. ;)

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.

SameIndividual: f:Person f:Man

The above would not allow the conclusion of:

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.

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

10 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 2 Structural Specification and Functional Syntax document [OWL 2 Specification].

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

11 Appendix: OWL Features

Here is a list of the various OWL features. The features presented in this primer are linked to from this list.

Ontologies Object Properties Descriptions
ontology names domain intersection
namespaces range union
annotations functional complement
Classes inverse functional sets
subclassof reflexive object property some
equivalent (2-way, N-way) irreflexive object property only
disjoint (2-way, N-way) symmetric object property min
Dataranges asymmetric object property max
built-in datatypes transitive object property exact
datatype restrictions specialization object property value
complement equivalent (2-way, N-way) object property self
sets disjoint (2-way, N-way) data property some
Individuals object property chains data property all
same (2-way, N-way) Data Properties data property min
different (2-way, N-way) domain data property max
types range data property exact
object property facts functional data property value
negative object property facts specialization
data property facts equivalent (2-way, N-way)
negative data property facts disjoint (2-way, N-way)

12 Appendix: 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.

# Example ontology for primer Namespace: <http://example.com/owl/families#> Namespace: f <http://example.com/owl/families#> Namespace: g <http://example.com/owl2/families.owl#> Namespace: dc <http://purl.org/dc/elements/1.1/> Ontology: <http://example.com/owl/families> # Ontology name, no version name Import: <http://example.com/owl2/families.owl> Annotations: rdfs:comment "Sample ontology of familial relationships" ObjectProperty: hasWife Anotations: rdfs:comment "The relationship from a husband to his wife", rdfs:label "wife"@en Characteristics: Functional, InverseFunctional, Irreflexive, Asymmetric Domain: Person, Man Range: Person, Woman SubPropertyOf: hasSpouse, loves ObjectProperty: hasHusband InverseOf: hasWife ObjectProperty: hasSon Domain: Person, Parent Range: Person, Person that hasGender value male SubPropertyOf: hasChild SubPropertyChain: f:hasSpouse o f:hasSon DisjointProperties: hasSon hasDaughter ObjectProperty: hasDaughter Domain: Person, Parent Range: Person, Person that hasGender value female SubPropertyOf: hasChild SubPropertyChain: f:hasSpouse o f:hasDaughter ObjectProperty: hasGender ObjectProperty: hasChild Domain: Person Range: Person SubPropertyOf: inverse hasAncestor ObjectProperty: hasAncestor Characteristics: Transitive, Annotations: dc:creationDate "2008-01-10"^^xsd:date, Irreflexive ObjectProperty: hasSpouse Characteristics: Symmetric, Irreflexive ObjectProperty: loves Domain: Person DataProperty: hasAge Characteristics: Functional Domain: Person Range: integer Class: Person Annotations: dc:Creator Individual(peter), dc:creationDate "2008-01-10"^^xsd:date, rdfs:label "Person":en, Annotations: rdfs:comment "Italian label for Person" rdfs:label "Persona":it, rdfs:comment "The class of people" SubClassOf: hasAge exactly 1 and hasGender exactly 1 and hasGender only {female , male} Class: Man SubClassOf: Person EquivalentTo: Person that hasGender value male Class: Woman SubClassOf: Person EquivalentTo: Person that hasGender value female Class: Parent SubClassOf: Person EquivalentTo: Person that hasChild min 1 Class: Teenager EquivalentTo: Person that hasAge some integer[>= 13 , < 20] Class: Adult EquivalentTo: Person that hasAge some integer[>= 21] Class: Child EquivalentTo: Person and not (hasAge some integer[>= 21]) Class: YoungChild EquivalentTo: Person and not (Teenager or Adult) Class: Marriage EquivalentTo: CivilMarriage or ReligiousMarriage Class: ReligiousMarriage DisjointWith: CivilMarriage Class: CivilMarriage Class: Narcissist EquivalentTo: Person that loves Self Individual: male DifferentFrom: female Individual: female Individual: John Annotations: dc:author Individual(peter), dc:creationDate "2008-01-10"^^xsd:date, rdfs:comment "A simple fact about John" Types: Person Facts: hasWife Mary, hasSon Bill, hasDaughter Susan, hasAge 33, hasGender male SameAs: Jack Individual: Mary Facts: hasSon Bill, hasDaughter Susan, hasAge 31, hasGender female Individual: Bill Types: not (Narcissist) Facts: hasAge 13, hasGender male Individual: Susan Facts: hasAge 8, hasGender female Individual: Jeff Types: hasChild exactly 2 Facts: hasWife Emily, hasChild Ellen, hasChild Jack, hasAge 77, loves Jeff Individual: Emily Types: hasAge some {39 , 49} Individual: Ellen Types: hasAge some integer[>= 15 , <= 21] Individual: Jack Facts: not hasAge "53"^^integer DifferentIndividuals: f:John f:Mary f:Bill f:Susan DifferentIndividuals: f:Jeff f:Emily f:Jack f:Ellen f:Susan SameIndividual: f:male g:masculine SameIndividual: f:female g:feminine EquivalentClasses: f:Adult g:Grownup EquivalentProperties: f:hasChild g:child EquivalentProperties: f:hasAge g:age

13 Appendix: Technology Perspectives

Editor's Note: The Working Group is committed to making these technology-specific sections be accessible by users of those technology. We particularly solicit comments on whether this is the case and how to make them moreso.
Editor's Note: Structural issue: Some readers have commented that having these sections up front may be intimidating. The editors are considering move detailed discussion to an appendix -- feedback on this point is welcome.
Editor's Note: There is a proposal for having technology and application tips, notes, and tricks scattered throughout the document, but with optional display. Thus, as with the syntax, different users can configure the document to their tastes and needs.

13.1 Resource Description Framework (RDF) and Schema (RDFS)

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), viewing most OWL statements and expressions as collections is not typically a fruitful way of writing or understanding them. Similarly, it is fairly common and effective to work with RDF as a graph data structure or database where the primary focus is on the explicit statements in the graph.

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
It may be a bit unclear to the naive reader why an RDF-perspective makes working with OWL problematic (minor comment)

Even when we consider parts of RDFS which support implicit knowledge, such as determining subclass relationships, the relation between the explicit and implicit statements is very direct. Thus, it is easy to conceptualize inference in terms of graph structure manipulation. In contrast, determining implicit knowledge in OWL, including determining subclass relationships and typing and checking consistency of an ontology, requires techniques that are much more akin to theorem proving.

13.2 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, OWL and XML can both be used for conceptual modeling as well as data definition, though they ways they go about it are fairly distinct and OWL is oriented toward more abstract, higher level conceptual modeling than is XML.


OWL is designed to support the discovery of relationships between classes through automated reasoning. OWL 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 much more concerned with the data organization issues relating to its core mission of validating XML documents.

13.3 Databases

Review comment from Dlm 19:28, 23 March 2008 (EDT)
See my longer review comments (in http://lists.w3.org/Archives/Public/public-owl-wg/2008Mar/0235.html). This update after the f2f is much better although we may still want input from a mainstream db person for their perspective.

Databases (either relational or object-oriented) also store and organize information. However, databases are oriented to environments where all information that an application needs is available, where considerations of data integrity in situations of simultaneous access and update are important, or where very large amounts of data needs to be worked with. OWL is more oriented towards flexible and expressive description of data (or information), and only considers information to be complete if the completeness can be determined from other information.


Review comment from Doug 15:37, 18 March 2008 (EDT)
These last two paragraphs about databases being

presumed to be complete somewhat surprised/confused me. Lots of DBs are used for efficiency reasons and have no presumption of completeness, and conversely one can explicitly assert that, e.g., in OWL 2 the complete extent of a predicate is known, if one wants to. Maybe tone that down to a less extreme version of the statement, or add some other differences -- good, the next paragraph does that.

Also, should we refer to SPARQL here?

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

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

Review comment from ivan 11:06, 28 March 2008 (EDT)
There is one aspect, when comparing OWL to databases, that I did not find in the text and I think it may be good to note. One of the force of OWL, compared to database usage, is that an OWL ontology (both the axioms and the facts) is completely independent from the exact location of the data, whereas, at least in most people's mind, the database schema and the data itself are, sort of, bound to a specific physical database. Because OWL uses URI-s both for individuals and for axioms, that means that OWL reinforces the Web aspect of things.

13.4 Object-oriented Programming

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

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

Review comment from RinkeHoekstra 12:13, 1 April 2008 (EDT)
The above may be a bit confusing as restrictions do 'inherit', just not in the typical OOP way...

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

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

13.5 OWL 1

OWL 2 is a backwards compatible revision to the Web Ontology Language (OWL). OWL 2 adds several new constructs to extend the expressivity of OWL including those for qualified cardinality restrictions, role chains, and expressive data predicates. OWL 2 also includes a new XML Serialization (targeted to the XML tool chain, i.e., XSLT, schema languages, etc.) and a set of subsetting profiles with various desirable application and computational properties.

For those interested in OWL 1, it is worth consulting the OWL 1 Overview and Language Guide. As every OWL 1 ontology is also an OWL 2 ontology, the OWL 1 documentation provides a reasonable introduction to OWL 2 (though only through the RDF/XML syntax). There are other OWL 1 documents available from the WebOnt working group webpage.

Review comment from Dlm 12:54, 9 April 2008 (EDT)
These are the 2 documents that aim at the broad audience so if we are going to drop most of the others, these are the 2 i believe we should keep. ))<<BijanParsia 13:39, 14 April 2008 (EDT) Those are the documents the primer is meant to replace.>>
Editor's Note: A section on the differences between OWL 1 and OWL 2 is forthcoming.

14 Acknowledgments

Editor's Note: There'll be a list of everyone whose comments resulted in a change to a draft of the text.

15 References

[OWL 2 Profiles]
OWL 2 Web Ontology Language: Profiles. Bernardo Cuenca Grau, 2008.
[OWL 2 Manchester Syntax]
OWL 2 Web Ontology Language: Manchester Syntax. Matthew Horridge and Peter F. Patel-Schneider and others, 2008.
[OWL 2 RDF Mapping]
OWL 2 Web Ontology Language: Mapping to RDF Graphs. Bernardo Cuenca Grau and Boris Motik. 2008.
[OWL 2 Semantics]
OWL 2 Web Ontology Language: Model-Theoretic Semantics. Bernardo Cuenca Grau and Boris Motik. 2008.
[OWL 2 Specification]
OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax. Boris Motik, Peter F. Patel-Schneider, and Ian Horrocks. 2008.
[OWL 2 XML Syntax]
OWL 2 Web Ontology Language: XML Serialization. Bernardo Cuenca Grau, Boris Motik, and Peter F. Patel-Schneider, 2008.
[XML Schema Datatypes]
XML Schema Part 2: Datatypes Second Edition. Paul V. Biron and Ashok Malhotra, eds. W3C Recommendation 28 October 2004.
Retrieved from "http://www.w3.org/2007/OWL/wiki/Primer"
Personal tools