Proposed Compliance Level 1 for WebOnt's Ontology Language OWL

***Note - this document has been superseded with a document of the name Feature Synopsis for OWL Lite and OWL. This new document includes the proposed smaller OWL language as well as a feature synopsis of OWL. Please use the Feature Synopsis for OWL Lite and OWL instead of using the May 26 version (or earlier versions) of the Proposed Compliance Level 1 for WebOnt's Ontology Language OWL Document.
This version:: 26 May 2002
Previous version:: 15 May 2002; 13 May 2002
Editor:: Deborah L. McGuinness (Knowledge Systems Laboratory, Stanford University )
dlm@ksl.stanford.edu

Abstract

This document proposes a description of Level 1 compliance for the web ontology working group language. The goal 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)
easy to implement

A useful language implies that the language should be:

a step above RDF/S (thereby allowing users to implement applications that were inconvenient or impossible with RDF/S.) This can be viewed as implying 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 DAML+OIL/OWL. Extensions should not be made more difficult than necessary because of features in the core language.

The document contains a motivation, history, language synopsis, language description with simple examples, and discussion section. Once the language description is agreed upon, a more complete language description will be provided.

Motivation

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 recent modification to the proposal acknowledged that a significant number of people in the webont community thought the language design committee had gone too far in limiting the language, so this proposal attempts to choose a more expressive point and thus acknowledges that it will penalize some tool developers who cater to some communities that do not need all of the chosen constructors. Note to webont readers - This paragraph will be deleted once we reach agreement. It is in just to add clarity for your reading.

Historical Perspective

This proposal is the immediate result of a meeting held at the Knowledge Representation and Reasoning Conference in Toulouse France on Monday April 22. Attendees of the meeting included: Ian Horrocks, Hermann ter Horst, Peter Patel-Schneider, Frank van Harmelen, Chris Welty, and Deborah McGuinness. At the Webont face to face meeting, the issue of a smaller language was discussed. As input to the discussion, the first proposal for OWL and presentation was considered. The result was an action that a group revisit a compliance level below the full generality of DAML+OIL. The group consists of Mike Dean, Enrico Motta, Raphael Volz, Ian Horrocks, Frank van Harmelen, and Deborah McGuinness. The meeting at KR was to handle the action item and generate a proposal for the compliance level. Van Harmelen and McGuinness wrote up the results of the meeting and posted a proposal for the compliance level and solicited comments. This document attempts to capture feedback on previous versions of the proposal. It also attempts to resolve the open issues raised in postings on local range restrictions and cardinality by introducing editor suggestions on these two topics. The next section contains the summary of the proposal.

Language synopsis

This language takes input from many sources including a proposal by van Harmelen coined as RDF Schema on Steroids, the language proposal written up by van Harmelen and McGuinness that resulted from the Toulouse meeting, and many sources of valuable feedback from the broader webont community, some of which are captured in webont submissions following the thread initiated with the compliance level one proposal. The expanded summary listing of this proposal includes:

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
functionality of properties (properties with min cardinality 0 and max cardinality 1. The same DAML+OIL side conditions hold that a transitive property (nor its superproperties) may not be declared functional.)

Datatypes

Additions

universal local range restrictions
existential local range restrictions
minimum and maximum cardinality

The next section contains an expanded description of the language.

Language Description

This section will discuss the proposed language features in English. Following group consensus on the language, an additional section will be added containing a more formal specification. An abstract syntax is used for presentation of the language.

RDF Schema features

The language can be viewed as an extension of a restriction 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. The plan is for these terms to be used as RDF:.

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. Some would call this a primitive class definition in that it does not provide a way to specify sufficient conditions for class membership.
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. 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.
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.

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.

Additions

Universal local range restriction: A property on a particular class may have a local range restriction associated with it. 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 a universal local range restriction alone that there is at least one value for the property.

Existential local range restrictions: A property on a particular class may have an existential local range restriction associated with it. For example, the class SemanticWebPaper may have an existential range 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 an existentially qualified local range 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 universal range restrictions) that ALL values of the property are instances of the specified class.

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.

Discussion

This section diverges noticeably from the previous version discussion. That discussion section attempted to capture the state of agreement/disagreement concerning the major points of debate. This section reflects the interpretation of the editor.

The previous version of the OWL LITE or compliance level 1 language attempted to follow all of the criteria stated in the abstract. The editor perceived that there was not enough support in the language (with expressive features) to adequately cover the goal of being an expressive step above RDF/S thereby allowing users to model simple common applications that could not be expressed in RDF/S. The three features that were requested noticeably more than any others were universal and existential range restriction and cardinality. It is widely believed that local range restrictions are superior to global restrictions in many if not most modeling problems, thus adding them to the language seemed important. Additionally empirical evaluations show that most of the DAML library ontologies include both local range restrictions and cardinality (beyond just functional roles). For additional discussion on the alternatives and the arguments for the alternatives see the discussion in the May 15 version of this document along with the issues postings on local range restrictions and cardinality.

None of the other discussion topics reached critical support levels in the editor's view to warrant other additions to this language description. The only other broadly discussed topic was presentation methodology for this language description. The editor has agreed to provide this presentation of the language along with another presentation in the view as a limited version of the full OWL language.

Summary

This document captures the state of the proposal for the compliance level one for OWL. It summarizes the proposal and introduces the language through simple English examples. It makes no attempt to include a syntax. The previous version of the document attempted to reflect the state of discussion on contentious topics. This version attempts to provide a proposal that includes an answer to the contentious topics. The goal of this proposal is to gather feedback on the proposal and either reach consensus that this shall be the webont lite version of full owl or find a set of small modifications through which we can reach consensus with the modified language description.

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