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
Deborah L. McGuinness (Knowledge Systems Laboratory, Stanford University )


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:

A useful language implies that the language should be: 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.


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

Equality and Inequality

The following features related to equality or inequality are included:

Property Characteristics


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.


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


    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.


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