Feature Synopsis for OWL Lite and OWL

This version:: 20 June 2002
Previous version:: 26 May 2002; 15 May 2002; 13 May 2002
Editors:: Deborah L. McGuinness (Knowledge Systems Laboratory, Stanford University )
dlm@ksl.stanford.edu; Frank van Harmelen (Free University, Amsterdam)
frank.van.harmelen@cs.vu.nl

Abstract

The OWL Web Ontology Language is being designed by the W3C Web Ontology Working Group in order to provide a language that can be used for applications that need to understand the logical content of information instead of just understanding the human-readable presentation of content. The OWL language can be used to allow the explicit representation of term vocabularies and the relationships between entities in these vocabularies. In this way, the language goes beyond XML, RDF and RDF-S in allowing greater machine readable content on the web. The OWL language is a revision of the DAML+OIL web ontology language. This document provides an introduction to the OWL language by providing a motivation, language synopsis, language description with simple examples, and discussion section on the full OWL language as well as a simpler language called OWL Lite. A more complete language description will be provided in accompanying documents. For a more detailed introduction to both OWL and OWL lite, please see the Abstract Syntax for the OWL Ontology Language.

Motivation

Taken from charter ***DLM****

The goal of OWL Lite is to provide a language that is viewed by tool builders to be easy enough and useful enough to support. One expectation is that tools will facilitate the widespread adoption of OWL and thus OWL language designers should attempt to create a language that tool developers will flock to. An easy language implies that the language should be:

explainable and understandable (which may imply that it is not too large)
easier to implement than the full language

A useful language implies that the language should be:

expressive enough so that it can be used to model at least some simple applications of some expected use cases.
relatively easy to extend with features in OWL. Extensions should not be made more difficult than necessary because of features in the core language.

While it is widely appreciated that all of the features in DAML+OIL are important to some users, it is also understood that a languages as expressive as DAML+OIL may be daunting to some groups who are trying to support a tool suite for the entire language. In order to provide a target that is approachable to a wider audience, a subgroup of the web ontology working group was formed to propose a smaller language.

This language attempts to capture many of the commonly used features of DAML+OIL. It also attempts to describe a useful language that provides more than RDFS with the goal of adding functionality that is important in order to support web applications. It also attempts to choose features that do not impose too many restrictions on toolbuilders who want to extend their support beyond this compliance level. Thus, one of the considerations the design group used before adding new features was feature interaction. The design group also acknowledged that there would not be consensus on one single preference ordering of constructors, thus including too many constructors in the small language would most likely end up choosing some constructors that would penalize some tool developers who were catering to communities that did not need one or more of the constructors in the small language.

The only main difference between this version of OWL Lite and the previous description is that cardinalities have been restricted. This document has been expanded to include a description of not just OWL Lite, but the full OWL language as well.

Language synopsis

This section contains the language synopsis for OWL Lite and for full OWL.

OWL Lite

The expanded summary listing of OWL Lite is:

RDF Schema features

class
property
subClassOf
subPropertyOf
domain
range
individual(named and unnamed)

Equality and Inequality

sameClassAs
samePropertyAs
sameIndividualAs
differentIndividualFrom

Property characteristics

inverseOf
transitive
symmetric
eachValueFrom (universal local range restrictions; previously toClass)
someValueFrom (existential local range restrictions; previously hasClass)

Restricted cardinality / functionality

hasAtLeast1
hasAtMost1 (previously unique property)
hasExactly1
hasExactly0
isTheOnlyOne (previously unambiguous property and inverse functional)

Datatypes

Header Information

imports
Dublin Core Meta data

OWL

The expanded summary listing of OWL adds the following:

Class axioms

oneOf (enumerated classes)
disjoint
sameClassAs applied to class expressions
subClassOf applied to class expressions

Boolean combinations of class expressions:

unionOf
intersectionOf
complementOf

Arbitrary cardinality:

hasAtLeast
hasAtMost
hasExactly

Filler information

Descriptions can include specific filler information

The next section contains an expanded description of the language.

Language Description of OWL Lite

This section will discuss the proposed language features in English. An abstract syntax is used for presentation of the language. OWL Lite has a subset of the full OWL language constructors and has a few restrictions. Unlike the full OWL language (and DAML+OIL), classes can not be defined in terms of arbitrary descriptions; instead only named superclasses and certain kinds of restrictions can be used. Equivalence for classes, and subclass between classes are all only allowed on named classes, not arbitrary descriptions. Similarly, property restrictions in OWL-Lite cannot have embedded descriptions, instead only allowing class names where descriptions would be allowed in Full OWL. It also has a limited notion of cardinality - the only cardinalities allowed to be explicitly stated are 0 or 1.

RDF Schema features

The limited language can be viewed as an extension of a restricted view of the RDF language. The restrictions limit the set of allowable models. The implications of the restriction are that every statement valid in the language describable by this document will be valid RDF, but not all valid RDF will be valid in the language described by the document. It retains the following terms from RDF. These terms may be referred to as RDF: < TERM >.

class: Classes may be created that have a classID and a description. A trivial class creation may be to create a class with the classID foo that is a subclass of the root class THING. There is no limitation on cycle creation in subclass hierarchies. Class descriptions can either be partial, indicating that the elements of the class satisfy at least the stated description and perhaps others; or the class description can be complete, indicating that the elements of the class are precisely characterised by the stated description. A partial person description could be that it is a subclass of mammal. From this a reasoner can deduce that any instance of a person is an instance of a mammal. A complete redHairedPerson description could be a person whose hair color is red. From this a reasoner could deduce that an instance of person whose hair color property has a value of red in it is an instance of the class redHairedPerson.
property: terms that are to be used as relationships between individuals and classes may be defined as properties. Note in this document we use individual to include both instances of RDF or OWL classes as well as instances of datatypes like the integer 4. For example, hasChild, hasRelative, hasSibling, hasAge, etc. may all be stated to be properties. The first three would be expected to have values that are instances of RDF or OWL classes; the last would have a datatype value.
subClassOf: Class hierarchies may be created by stating that classes are subclasses of other classes. For example, the class person could be stated to be a subclass of the class mammal. From this a reasoner may deduce that if X is a person, then X is a mammal.
subPropertyOf: Property hierarchies may be created by stating that some properties are subproperties of other properties. For example, hasSibling may be stated to be a subproperty of hasRelative. From this a reasoner may deduce that if X is related to Y by the hasSibling property, then X is also related to Y by the hasRelative property.
domain: Properties may be stated to have domains, (i.e., the first argument of the property must be an instance of the domain class). For example, the property hasChild may be stated to have the domain of Mammal. From this a reasoner may deduce that if X is related to Y by the hasChild property, i.e., Y is the child of X, then X is a Mammal. Note that these are called global restrictions since the restriction is stated on the property and not just on the property when it is associated with a particular class. See the discussion below on local restrictions for more information.
range: Properties may be stated to have ranges, (i.e., the second argument of the property must be an instance of range class). For example, the property hasChild may be stated to have the range of Mammal. From this a reasoner may deduce that if X is related to Y by the hasChild property, i.e., Y is the child of X, then Y is a Mammal. Range is also a global restriction as is domain above. See the discussion below on local restrictions for more information.
individual: Individuals may be created with an optional individual identifier and a description. For example, an individual named Deborah may be created as an instance of the class person. Another individual may be created that is not given an identifier (thus it would not contain the id "Deborah") that is an instance of the class StanfordEmployee.

Equality and Inequality

The following features related to equality or inequality are included:

sameClassAs: Two classes may be stated to be the same, (i.e., the classes have the same extension). This can be used for creating synonymous classes. It also has the side effect of effectively creating conjunctions of classes. For example, the class CAR which is a subclass of moving vehicle may be stated to be the sameClassAs another class Automobile which is a subclass of expensiveThing. A reasoner may deduce that anything that is a Car is also an instance of Automobile and thus is also an instance of expensiveThing. The reasoner can also deduce that Car is a subclass of Automobile and Automobile is a subclass of Car.
samePropertyAs: Two properties may be stated to be the same. This may be used to create synonymous properties. For example, hasLeader may be stated to be the samePropertyAs hasHead. From this a reasoner may deduce that is X is related to Y by the property hasLeader, X is also related to Y by the property hasHead. The reasoner can also deduce that hasLeader is a subproperty of hasHead and hasHead is a subProperty of hasLeader.
sameIndividualAs: Two individuals may be stated to be the same. This may be used to create a number of different names that may be used to refer to an individual. This may be useful for identifying when one named individual is the same as an unnamed individual and it also may be useful in merging ontologies. For example, we may state that the instance Deborah is the same individual as DeborahMcGuinness and we may also state that the instance Deborah is the same as the instance that is a member of AssociateDirectorKnowledgeSystemsLab.
differentIndividualFrom: Two individuals may be stated to be different from each other. For example, the individuals Frank and Deborah may be stated to be different from each other. From this, the reasoner can deduce that Frank and Deborah refer to two unique individuals. Thus, if Frank and Deborah both fill a property that is stated to be functional (have at most 1 filler), then there is a contradiction. This can be important in systems that do not make the unique names assumption, such as RDF. For example, in a system that only knew that Frank and Deborah were both instances of the class person, without using the unique names assumption, a reasoner could not deduce that they were distinct.

Property Characteristics

inverseOf: Two properties may be stated to be inversely related. If properties P1 and P2 are inversely related then if P1(X,Y) is true, then P2(Y,X) is true. For example, hasChild and hasParent may be stated to be inversely related. From this the reasoner that is given hasParent(Deborah,Louise) may deduce hasChild(Louise,Deborah).
transitive: Properties may be stated to be transitive. If a property is transitive, then if the pair (x,y) is an instance of the transitive property P, and the pair (y,z) is an instance of P, then the pair (x,z) is also an instance of P. For example, if ancestor is stated to be transitive, and if Sara is an ancestor of Louise (i.e., (Sara,Louise) is an instance of ancestor) and Louise is an ancestor of Deborah (i.e., (Louise,Deborah) is an instance of ancestor), then a reasoner may deduce that Sara is an ancestor of Deborah (i.e., (Sara,Deborah) is an instance of ancestor.
The same DAML+OIL side conditions hold that restrict transitive properties (and their superproperties) from having an atmost1 or an exactly1 restriction.
symmetric: Properties may be stated to be symmetric. If a property is symmetric, then if the pair (x,y) is an instance of the symmetric property P, then the pair (y,x) is also an instance of P. For example, friend may be stated to be a symmetric property. Then a reasoner that is given that Frank is the friend of Deborah can deduce that Deborah is a friend of Frank. Note of course that properties must have appropriate domains and ranges in order to be made symmetric.
functional : Properties may be stated to be functional. If a property is functional, then it has no more than one filler. It may have 0 fillers. Another way of saying this is that its minimum cardinality is zero and its maximum cardinality is 1. For example, hasPrimaryEmployer may be stated to be functional. If something has a primary employer, there is no more than one number although not everyone has a primary employer. This proposal includes the same side condition as is stated in the DAML+OIL specification that does not allow transitive properties nor any of their superproperties to be declared functional. For more information on the details of the limitation, see the Warning under the property element section of the DAML+OIL reference description or in a research paper by Horrocks, Sattler, and Tobies showing the undecidability that would follow from violating this restriction.
eachValueFrom (universal local range restriction): A property on a particular class may have a local range restriction associated with it. This states that each value for the property must be of a certain type. For example, the class person may have a property called hasOffspring restricted to have fillers that are instances of the class person. This allows the property hasOffspring to be used with other classes, possibly the class Cat and have an appropriate value restriction associated with the use of the property on that class. In this case, hasOffspring would have the local range restriction of Cat when associated with the class cat and would have the local range restriction Person when associated with the class Person. From this statement, a reasoner may deduce that if X is the offspring of Y and Y is a Person, then X is also a person. It can also deduce that if X is the offspring of Y and Y is a cat, then X is a cat. Note that the reasoner can not deduce from an eachValueFrom restriction alone that there is at least one value for the property.
someValueFrom (existential local range restriction): A property on a particular class may have an existential local range restriction associated with it. That is saying that some value for the property is of a certain type. For example, the class SemanticWebPaper may have a someValueFrom restriction on its hasKeyword property that states that SOME keyword should be an instance of the class SemanticWebTopic. This allows for the option of having multiple keywords and as long as one or more is an instance of the class SemanticWebTopic, then the paper would be consistent with the range restriction. Unlike universal range restrictions, it does not restrict all the values of the property to be instances of the same class. From a someValueFrom restriction, a reasoner may deduce that there is at least one value for the property and it is an instance of the specified class. The reasoner can not deduce (as it could with eachValueFrom restrictions) that ALL values of the property are instances of the specified class.

Restricted Cardinality

Required properties: Classes may have properties that are required to have at least one filler. For example, the class parent may have a property named hasChild that is required - i.e., any instance of the class parent must have at least one value for its hasChild property.
Single valued properties:
Local cardinality restrictions: A property on a particular class may have minimum and maximum cardinality restrictions associated with it. Thus, on the class parent, a property named hasOffspring could have a minimum cardinality restriction of 1. From this, a reasoner could deduce that there is at least one value for the hasOffspring property on every instance of the class parent. Similarly, maximum cardinalities may be stated, for example, on the class SinglePerson, a maximum cardinality of 0 could be placed on the property hasSpouse. This proposal only allows any positive integer to be used as a cardinality restriction.

Datatypes

Datatypes will be included in the core language. Thus, for example a range could be stated to be XSD:decimal. The exact details of this is dependent upon the RDF core group's decisions on datatypes for RDF.

Header Information

Imports: Each imports statement references another OWL ontology containing definitions that apply to the current ontology. Each reference consists of a URI specifying from where the ontology is to be imported from. Imports statements are transitive, that is, if ontology A imports B, and B imports C, then A imports both B and C. Importing an ontology into itself is considered a null action. If ontology A imports B and B imports A, then they are considered to be equivalent.
Dublin Core MetaData: Ontologies also have a non-logical component (not yet specified) that can be used to record authorship, and other non-logical information associated with a ontology. A prime candidate is to associate with the ontology attributes from the Dublin Core meta-data standard.

Language Description of Full OWL

Full OWL extends the constructions of OWL Lite with the following:

oneOf (enumerated classes): classes can be defined by enumeration of the individuals that make up the class. The class is then exactly equal to the set of enumerated individuals, no more, no less. For example, the class of daysOfTheWeek can be defined by simply enumerating the instances Sunday, Monday, Tuesday etc. From this a reasoner could deduce the maximum cardinality (7) of any property that has daysOfTheWeek as its range.
hasValue (property fillers): a property can be required to have a certain individual as a value. For example, instances of the class of dutchCitizens can be characterised as those people that have theNetherlands as a value of their nationality. (Where theNetherlands itself is an instance of the class of all nationalities).
disjointClasses: The full OWL language allows the statement that classes are disjoint, for example stating that man and woman are disjoint classes. From this a reasoner could conclude an inconsistency when an instance is stated to be a member of both and similarly could deduce that if A is an instance of Man, then A is not an instance of Woman.
unionOf, complementOf, and intersectionOf (boolean combinations): OWL allows arbitrary boolean combinations of classes: IntersectionOf, UnionOf, and complementOf. For example, taking the intersection of all the class of all Dutch citizens with the class of all people of age at least 65 defines the class of all Dutch senior citizens. Using complement, we could state that children are not senior citizens (i.e. the class children is a subclass of the complement of senior citizens) Citizenship of the European Union could be defined as the union of the citizenship of all member states.
atLeast, atMost, exactly (full cardinality): While in OWL Lite, cardinalities are restricted to at least, at most or exactly 1 or 0, full OWL allows cardinality statements for arbitrary non-negative integers. For example the class of DINKs ("Dual Income, No Kids") would restrict the cardinality of the property hasIncome to at least 2 (while the property hasChild would have be restricted to exactly 0).
complex class descriptions: In many places, OIL Lite restricts the syntax to single class names (e.g. in subClassOf or equivalentClass statements). Full OWL extends this to allowing in those places arbitrarily complex class descriptions, consisting of enumerated classes, property restrictions, and boolean combinations of these.

Summary

This document provides a high level description of the OWL language by providing a feature synopsis of both OWL Lite and the full language. It provides simple English descriptions of the constructors along with a simple example. It makes no attempt to include a syntax. It also provides pointers to the other related documents for more details. Previous versions of the document provided the historical view of the evolution of OWL Lite and the issues discussed in its evolution.

TODO

dlm: owl motivation - steal from charter, requirements document
dlm: final pass
table of contents, number all of the sections
consider the following: The Web Ontology Working Group has been chartered to design a web ontology language, that builds on current web languges supporting the specification of classes and subclasses, properties and subproperties (such as RDFS), but which extends these constructs to allow more complex relationships between entities. Some of the extensions including: means to limit the properties of classes with respect to number and type, means to infer that items with various properties are members of a particular class, a well-defined model of property inheritance, and similar semantic extensions to the base languages.

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document.

This document is a working document for the use by W3C Members and other interested parties. It may be updated, replaced or made obsolete by other documents at any time.

This document has been produced as part of the W3C Semantic Web Activity, following the procedures set out for the W3C Process. The document has been compiled by the Web Ontology Working Group. The goals of the Web Ontology working group are discussed in the Web Ontology Working Group charter .

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.