Proposed Compliance Level 1 for WebOnt's Ontology Language OWL

This version:: 13 May 2002
Previous version:
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)
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 impose as few restrictions as possible 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.

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. The next section contains the summary of the proposal.

Language synopsis

This language is takes as its starting point the proposal from van Harmelen coined as RDF Schema on Steroids and adds two kinds of functionality:

properties that can be declared functional
datatypes (subject to the datatype resolution by the RDF Core Working Group.

The expanded summary listing of this proposal includes:

RDF Schema features

primitiveclass
property
subClassOf
subpropertyof
domain
range
individual(named and unnamed)

Equality and Inequality

sameClassAs
samePropertyAs
sameIndividualAs
differentIndividualFrom

Property characteristics

inverseOf
transitive
symmetric

Additions

functionality of properties (properties with min cardinality 0 and max cardinality 1. The same DAML+OIL side conditions hold that a transitive property may not be declared functional.)
datatypes (following the decisions of RDF Core)

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 does not differ from RDF in these core features.

primitiveClass: 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 subclas of the root class THING.
property: terms that are to be used as relationships between individuals and classes may be defined as properties. For example, hasChild, hasRelative, and hasSibling may all be stated to be properties.
subClassOf: Class hierarchies may be created by stating that classes are subclasses of other properties. 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 further discussion on this point in relation to local restrictions.
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.
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.

Additional features

functionality of properties : 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, hasUSSocialSecurityNumber may be stated to be functional. If something has a United States Social Security number, there is no more than one number although not everyone has a United States Social Security number. 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.
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.

Discussion

This section provides some perspective on the proposal to date and outstanding issues. Previous sections attempted to minimize subjective statements. This section however reflects the interpretation of the editor.

There was little resistance to the basic proposal in that there were very few suggestions to take features out of the core set. Previously some members of webont have made compelling points concerning the usefulness of local range restrictions and some dangers of global range restrictions. In response to the acknowledgement by many that local restrictions seem to be the preferred modeling mode, there was one suggestion to eliminate global domain and range restrictions from the core language. This however would mean removing something that is in RDF and has not received additional support. Thus, the remainder of the discussion concerns discussion points relating to possible additions to the language.

There were two kinds of responses concerning additions to the language. One type of comment stated that the core language should have feature X. Another type of comment revolved around the strategy for choosing what should go in the core language. We first consider some of the issues involved in choosing features.

Some members (see for example, a posting from Horrocks) have made the point that it is not possible to come up with a single ordering of features for inclusion in terms of importance. There is agreement that one total ordering that is agreed upon by the group is not an achievable goal. There is also agreement that adding some features after other features are already in the language may make the addition more difficult than adding the same feature to a language that does not include certain other features. These two issues together may lead one to conclude that a core language should stay small so as not to unfairly penalize tool implementors who need to add features to the core language.

After a briefing of the proposal to the EU/US Joint Committee, the suggestion was made that this core language might attempt to cover 50-75 percent of the needs of the typical user. (See for example, the posting by McGuinness relating a suggestion by Mike Dean). While of course typical user is not precisely defined and thus, this is a vague statement, the intent of covering most of the needs of a typical user is likely to be at odds with the goal of keeping the language small enough to be easy to explain to a broad user base and easy to implement by a wide variety of tool implementors.

The editor's summary of the strategy discussion is mostly in agreement with a posting by van Harmelen where he states that there was one approach taken to determine the core language at the face to face meeting that failed. That approach was to include features for which anyone could make a compelling case for inclusion. The approach failed since the resulting core language differed very little from DAML+OIL and many believed this was too "top heavy" a language for widespread adoption. There is another approach taken in Toulouse to define a core language that does not penalize implementors addition of new features by features already in the language while providing a small explainable core language that is a step above RDFS. It is open to debate if one or two features can be added to the Toulouse core language that will maintain the principles followed in Toulouse and meet more of the needs of the typical user.

The next set of topics could be grouped as requests for language features to be added to the core set. The next set of topics are roughly ordered by the amount of email traffic that was generated on the topic.

Existential and universal local range restrictions: There is agreement that local range restrictions are useful. In the discussion in Toulouse, there were strong cases made by Horrocks for existential local range restrictions and by McGuinness and van Harmelen for universal local range restrictions. Additional postings stating the case for existential range restrictions can be seen for example in the posting by Ian Horrocks. Additional postings stating the case for universal range restrictions can be seen for example in the posting by Mike Dean and Deborah McGuinness. A debate over the utility of universal vs. existential range restrictions was carried on through email since many believed that we might choose to put in just one of the two in the core. Both sides made strong cases for the utility of the feature. Existential local range restrictions along with functional roles can capture a lot of what is needed in many applications and universal local range restrictions along with minimum cardinality can capture a lot of what is needed in many applications. Some of the postings at the end of the discussion thread capture some of the examples on both sides (e.g., postings by Horrocks and McGuinness). The editor's summary concerning the discussion is that both features are useful and necessary in a number of applications. Universal local range restrictions may see more use in knowledge bases however that may be because more applications used languages with this representational construct.

Cardinality: There were a number of requests for more cardinality than what is available with functional roles. (Functional roles allow one to state max cardinality 1.) (See for example, postings by Mike Dean, Enrico Motta, and Jim Hendler). The editor's summary of the requests are that many would like at least min cardinality 1 and some number would like unrestricted min and max cardinality. One note, universal local range restrictions are more useful if the language has a way of stating min cardinality 1.

Functionality of roles: There were some postings asking for clarification on functionality of roles and also stating that functionality was not enough. There was also a suggestion that global functional roles may be dangerous. (See for example, postings by Mike Dean, Ziv Hellman, and Deborah McGuinness). The editor's summary of this topic is that clarification has been provided on the mailing list that functional roles means min cardinality 0 and max cardinality 1. The resolution of cardinality in the core language may make this issue disappear.

Modification of descriptions: There was a suggestion that descriptions may need to be modified from previously published and used descriptions in ontologies. (See for example, postings by Ziv Hellman, Deborah McGuinness, and van Harmelen). The editor's summary on this topic is that modifying the meaning of terms is dangerous and once this was pointed out, the requests for language support for this feature disappeared.

Compliance with rule engines: There was a request that the low compliance level be compatible and implementable with rules engines. (See for example, postings by Raphael Volz. The editor's summary is that no one disagreed with this request and no one proposed that the core language violated the request.

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 attempts to capture the ongoing discussion topics. The goal is to gain consensus on the core compliance level by resolving any remaining issues. The editor's summary of remaining issues include the strategy for choosing language features for the compliance level and what choices to make concerning cardinality and local range restrictions.

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