Proposed Compliance Level 1 for WebOnt's Ontology Language OWL

This version:
15 May 2002
Previous version:
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 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: 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 does not differ from RDF in these core features.

Equality and Inequality

The following features related to equality or inequality are included:

Property Characteristics

Additional features


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.

One other type of general comment concerned presentation. There was one request to standardize our documents on the use of the term relation instead of role or property. A few other emails brought up the issue of not using the primitive vs. defined distinction, however another email stated that it was important to point out that some modeling languages that we may want to provide interfaces to such as UML, only provide primitive modeling capabilities so it may be important for our documentation to point out the differences.

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.


    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. One more recent request was to get consensus on what term to use for relations, roles, or properties with the request to use the term relation.

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