Web Ontology Issue Status

This version:
30 Oct 2002
Previous version:
16 Oct 2002
Michael K. Smith (Electronic Data Systems)

Table of Issues

(How to Submit an Issue)

IssueSource DateStatus
1.1 VariablesI. Horrocks on Telecon06 Jun 2002Closed
1.2 Definitional Constraints on Conjunctive Types Telecon19 Feb 2002Closed
2.1 URI naming of instancesMike Dean email06 Jun 2002Closed
2.2 Adding Properties to Other InstancesMike Dean email19 Sep 2002Closed
2.3 Adding Properties to Other ClassesMike Dean email06 Jun 2002Closed
2.4 Enumerated ClassesMike Dean email25 Jul 2002Closed
2.5 Closed SetsMike Dean email08 Oct 2002 Closed
2.6 Ordered Property ValuesMike Dean email 08 Oct 2002Closed
3.1 Local RestrictionsMike Dean email06 Jun 2002Closed
3.2 Qualified RestrictionsMike Dean email19 Feb 2002Closed
3.3 DisjointFromMike Dean email06 Jun 2002Closed
3.4 UnambiguousPropertyMike Dean email25 Jul 2002Closed
4.1 UniqueProp BadName Tim Finan /
Amsterdam F2F
25 Jul 2002Closed
4.2 Cardinality Constructs Levels Steve Buswell /
Amsterdam F2F
11 Jul 2002Closed
4.3 Structured DatatypesJonathan Borden /
Amsterdam F2F
08 Oct 2002Open
4.4 Extra-logical feature setJames Hendler19 Apr 2002OPEN
4.5 InverseOfJames Hendler19 Apr 2002Closed
4.6 EquivalentToJames Hendler28 May 2002OPEN
4.7 Does OWL provide built in 'model checking' functionalityJames Hendler19 Apr 2002Closed
4.8 Trust and Ontology James Hendler, fwd from John Yanosy, Motorola.06 Jun 2002Postponed
5.1 Uniform treatment of literal data valuesDan Connolly08 Oct 2002 Closed
5.2 Language Compliance LevelsFrank van Harmelen 08 Oct 2002Closed
5.3 Semantic LayeringPeter Patel-Schneider 08 Oct 2002Closed
5.4 OWL:QUOTEMichael K. Smith08 Oct 2002 Postponed
5.5 List syntax or semanticsJeremy Carroll 08 Oct 2002 Open
5.6 daml:imports as magic syntaxJeff Heflin 10 May 2002OPEN
5.7 Range restrictions should not be separate URIs Ziv Hellman08 Oct 2002Open
5.8 DatatypesPeter F. Patel-Schneider 17 May 2002Pending
5.9 Malformed DAML+OIL Restrictions Peter F. Patel-Schneider 08 Oct 2002Open
5.10 DAML+OIL semantics is too weak Peter F. Patel-Schneider08 Oct 2002 Closed
5.11 hasClass ToClass namesJim Hendler13 Jun 2002 Closed
5.12 Entailing inconsistenciesJos De Roo08 Oct 2002 Postponed
5.13 Internet Media Type for OWLPeter F. Patel-Schneider 08 Oct 2002Open
5.14 Ontology versioningJeff Heflin22 MAY 2002 OPEN
5.15 Feature decision for CL1 local range Deborah McGuinness 08 Oct 2002Closed
5.16 Feature decision for CL1 cardinality Deborah McGuinness 23 May 2002Closed
5.17 XML presentation syntaxPeter F. Patel-Schneider 08 Oct 2002Open
5.18-Unique-Names-Assumption-Support-in-OWL Deborah L. McGuinness 08 Oct, 2002Open
5.19-Classes-as-instances Raphael Volz, email of 7/11/02. 08 Oct 2002Open
5.20-should-OWL-provide-synonyms-for-RDF-and-RDFS-objects Peter F. Patel-Schneider 08 Oct 2002Closed
5.21-drop-disjointUnionOfMike Dean24 Oct 2002Closed
5.22-owl:Class-still-neededMike Dean08 Oct 2002Closed

The Date column above is the date of the last change in status.


This document enumerates issues before the W3C Web Ontology working group. As such, it is an internal aide to the working group to ensure that all issues are dealt with. It is also intended that the resolution of these questions be recorded here.

Most of these issues are based on discussions concerning the requirements document, Web Ontology Requirements. In general, these issues are proposed requirements or objectives for which the working group has not yet been able to reach consensus, in some cases due to wording problems and in others to conceptual disagreements. The current version is an initial draft based on email from members of the WG, but has not yet been reviewed by the WG as a whole.

Also included are items that have been deemed implicit requirements, as well as features of DAML+OIL that are not mentioned in the requirements document. Most of these need to be explained more fully before discussion of their potential status as a requirement can proceed. Please send any expansions on these to the editor.

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. It is inappropriate to use this document as reference material.

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.

The working group has not reached consensus on all topics. Those items are documented here.

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

1. Issues from Requirements Document

1.1 Variables

"Variables: The language should support the use of variables in ontology definitions. Variables allow more complex definitions to be specified, such as the chained properties example above."

Issue raised by Ian Horrocks: wording on variables is too vague.

See proposal to close.

Name I1.1-Variables
Raised By WG Telcon of 28 Feb 2002 discussion of requirements document draft.
Date 28 Feb 2002.
Status Closed, 6 Jun 2002.
Resolution Dropped as objective, kept as issue as reminder to discuss in the future. Discussion complete.
References Proposal

1.2 Definitional Constraints on Conjunctive Types

"Definitional constraints on conjunctive types: The language should support definitions that relate the values of different properties. For example, it should be able to represent the example: style="LateGeorgian" => culture="British" AND date.created="between-1760-and-1811," where style, culture, and dateCreated are all properties"

Name I1.2-Definitional-Constraints-on-Conjunctive-Types
Raised By WG Telcon of 28 Feb 2002. Issue raised by Ian Horrocks during discussion of requirements document draft.
Date 28 Feb 2002.
Status Closed.
Resolution This objective will be dropped.

2 Possible Implicit Requirements

2.1 URI naming of instances

URI naming of instances (ability to refer to instances defined by someone else). This could be merged with "Unambiguous term referencing with URIs", which seems to focus on classes and properties.

See proposal to close.

Name I2.1-URI-naming-of-instances
Raised By Mike Dean e-mail.
Date19 Feb 2002.
Status Closed, 6 Jun 2002.
References Minutes

2.2 Adding Properties to "Someone Else's" Instances

Adding properties to "someone else's" instances.

It was proposed by Peter Patel-Schneider to close Issue 2.2 based on the same motivation as Issue 2.3. Agreed to at 19 Sep 2002 teleconference.

Name I2.2-Adding-Properties-to-Other-Instances
Raised By Mike Dean email
Date19 Feb 2002.
Status Closed, 19 Sep 2002.
References 2.3 Proposal

2.3 Adding Properties to "Someone Else's" Classes

Adding properties to "someone else's" classes (ability to extend a class without subclassing it, ability to split Restrictions across multiple pages/ontologies). This goes with 2, but may conflict with the desire for a greater frame orientation.

See proposal to close.

Our Working group has decided to use RDF/XML as our exchange framework and that the semantics of our documents will be carried by the triple store corresponding to this document (see resolutions of second face to face meeting). The basic RDF model [1] allows documents to refer to and extend the resources defined in other documents.

Name I2.3-Adding-Properties-to-Other-Classes
Raised By Mike Dean e-mail.
Date19 Feb 2002.
Status Closed, 6 Jun 2002.
References Proposal

2.4 Enumerated Classes (daml:oneOf)

See proposal to close.

Name I2.4-Enumerated-Classes
Raised By Mike Dean e-mail.
Date19 Feb 2002.
StatusClosed, 25 Jul 2002.
ResolutionInclude ONEOF in OWL. See telecon minutes
References Teleconference

2.5 Closed Sets (daml:List, daml:collection)

Closed sets (daml:List, daml:collection). This could be included as part of "Ability to state closed worlds".

Name I2.5-Closed-Sets
Raised By Mike Dean e-mail.
Date08 Oct 2002.
ResolutionCreate closed sets by using rdf:parseType="Collection".
Reference Minutes of Bristol F2F

2.6 Ordered Property Values

The ability to order property values (e.g. for a list of authors, or a sequence of events)

Name I2.6-Ordered-Property-Values
Raised By Mike Dean e-mail.
Date08 Oct 2002.
ResolutionClosed by noting the availability of rdf:List.
Reference Minutes of Bristol F2F

3 DAML+OIL Features Not Present in Requirements

3.1 Local Restrictions

Local restrictions (the ability to use the same property in somewhat different ways for different classes). Unaccounted for DAML+OIL feature.

See proposal to close.

Name I3.1-Local-Restrictions
Raised By Mike Dean e-mail.
Date19 Feb 2002.
Status Closed, 6 Jun 2002.
OwnerDeb McGuinness
Resolution Proposal
References TelConf Minutes

3.2 Qualified Restrictions

Qualified restrictions (cardinalityQ, etc.). Unaccounted for DAML+OIL feature.

Proposed resolution by Jeremy Carrol on 19 Apr 2002. See also Jeremy Carrol email of 24 Apr 2002.

At the face2face no one wished to include qualified restrictions in OWL.

The qualified restrictions of DAML+OIL:

I propose that the WG

Name I3.2-Qualified-Restrictions
Raised By Mike Dean e-mail.
Date19 Feb 2002.
OwnerJonathan Borden
Resolution See telecon minutes
Test Case: Case

3.3 daml:disjointFrom

Unaccounted for DAML+OIL feature.

See proposal to close and revised text. Closed with revised wording.

Name I3.3-DisjointFrom
Raised By Mike Dean e-mail.
Date19 Feb 2002.
Status Closed, 6 Jun 2002.
Resolution Proposal
References Minutes

3.4 daml:UnambiguousProperty

Unaccounted for DAML+OIL feature.

daml:UnambiguousProperty is motivated by the "cardinality constraints" requirement. No one has advocated its removal and there does seem to be consensus it is a desirable feature. It is provided for in DAML+OIL and will be provided in OWL.

See proposal to close and ammended text.

Name I3.4-UnambiguousProperty
Raised By Mike Dean e-mail.
Date19 Feb 2002.
StatusClosed, 25 Jul 2002 Telecom.
OwnerFrank van Harmelen
ResolutionFunctionalProperty and InverseFunctionalProperty selected as names.
References Teleconference
Corrections Resolution

4 Amsterdam F2F Issues

4.1 UniqueProp is a Bad Name

DAML+OIL has concepts of UniqueProperty and UnambiguousProperty that are very useful but whose names seem to cause some confusion for people learning the language. Assuming we have the same concepts in OWL, we should decide on names that will be intuitive or at least minimize confusion. For a DAML+OIL triple (S,P,0), if P is a uniqueProperty then S, the subject value, uniquely identifies O, the object value. If P is an UnambiguousProperty then O determines S.

See also 3.4-UnambiguousProperty

Name I4.1-UniqueProp-BadName
Raised By Tim Finin elaboration of issues list generated at Amsterdam Face to Face, 9 Apr 2002.
Date11 April 2002.
StatusClosed, 25 July 2002 Telecom.
ResolutionFunctionalProperty and InverseFunctionalProperty selected as names.
References Teleconference

4.2 Cardinality Constructs and Levels

The language proposal paper (van Harmelen et al) contains different cardinality constructs in OWL-Lite (optional/required; single/multivalued) and in OWL-Full (min-cardinality, max-cardinality). In addition, DAML has a construct cardinality.

At the f2f, there was a proposal to drop cardinality as it can be expressed in terms of min- and max-. A number of WG members objected to this simplification on grounds of usability.

Following the level 1 / level 2 features review, and the decision to revisit the split, there was a suggestion that all cardinality constructs should be in level 2.

Note: The simplification argument above would suggest dropping optional/required and single/multivalued in favour of min- and max- if this were the case.

Name I4.2-Cardinality-Constructs-Levels
Raised By Steven Buswell elaboration of issues list generated at Amsterdam Face to Face, 9 Apr 2002.
Date12 Apr 2002.
StatusClosed, 11 July 2002 Telecon.
References See also 5.16
ResolutionAccept DAML naming convention.

4.3 Structured Datatypes

See the original discussion of this issue with proposed solution.

In brief, there is a desire to incorporate and reason about structured datatypes (e.g. XML Schema complexTypes) within OWL. Technical issues involved with integration of general XML types, XML Schema datatypes and XQuery formal types are discussed.

The fundamental issue with integration of XML types and XML Schema datatypes into OWL seems to be based on the fact that there do not exist unique URIreferences for each XML Schema type.

XML Schema does however define a type hierarchy, and it is the goal of this proposal to seemlessly integrate the XML Schema type hierarchy into the OWL class hierarchy.

Name I4.3-Structured-Datatypes
Raised By Jonathan Borden elaboration of issues list generated at Amsterdam Face to Face, 9 Apr 2002.
Date08 Oct 2002.
Reference Minutes of Bristol F2F
Rationale for postponing.
Response by Borden

4.4 Extra-logical feature set

DAML+OIL has a limited ability to add features to ontologies and assertions. Our requirements for "tagging" of various kinds goes beyond what is currently in DAML - what do we need to add to address our requirements?

Name I4.4-Extra-logical-feature-set
Raised By James Hendler
Date 19 Apr 2002
Status OPEN, 5 Sep 2002
Owner Mike Dean

4.5 InverseOf

InverseOf is a highly used (some say misused) feature of DAML+OIL. The OWL-Full proposal left it out, because of some worries on the part of some participants that it caused some logical problems for users. Other people argue it is an important expression in the mapping between ontologies.

Proposal as ammended in resolution 5.1 (when used with datatypes) still open, otherwise closed.

Name I4.5-InverseOf
Raised By James Hendler
Date 19 Apr 2002
Status Opened, 28 May 02
Closed, 30 May 02
Resolution Proposed resolution by Dan Connoly approved.

4.6 EquivalentTo

It has been argued that equivalentTo is an important property for ontology mapping as it doesn't require that a user who asserts an equivalence knows whether the things being related are properties, classes, or instances. However, DAML+OIL does not allow equivalence between things in separate categories i.e. What happens when a class is equivalentTo a instance? What happens when a class is equivalentTo a property?

Name I4.6-EquivalentTo
Raised By James Hendler
Date 19 Apr 2002
Status Open, 28 May 02

4.7 Does OWL provide built in 'model checking' functionality

Can OWL constructs explicitely constrain RDF graphs? For example, can we develop a syntax that is strict enough to disallow a user from expressing two cardinality constraints on the same entity (in a contradictory way)

Name I4.7-Built-in-model-checking-functionality
Raised By James Hendler
Date 19 Apr 2002
Status Closed
Resolution OWL will not change the DAML+OIL to this extent, it would be inconsistent with resolutions reached at the second face to face meeting. Syntactic restrictions of this kind could be realized in the development of a presentation syntax (for example, using more constrained XML expressions for defining certain predicates).

4.8 Trust and Ontology

From mail to public-webont-comments by John Yanosy, Motorola.

After briefly reviewing P3P, it appears that a similar concept could be used to share information about trust aspects of an ontology, I am not even sure what these trust aspects are at this time, but I suspect it is worthwhile to think about them at this initial requirements stage. It might be useful when creating an ontology that relies on other ontologies to be able to set some preferences about the trust levels desired with respect to shared ontologies.

Some trust properties might include:

The issue is an important one, but beyond the scope of this WG. Someone should take the ACTION to write this up for the issues document.

Discussion: Issue needs an owner. Jim responded to the outside poster citing wording in the requirements document that this is important, but outside our scope. DanC was happy with this. What trust means was discussed briefly. Most agreed it was out of scope. Evan and Laurent objected initially to closing the issue. Evan thought there are some important issues regarding trust we should allow in the language. JimH said that the languages allows for "tags it doesn't understand" and that groups of users can agree amongst themselves to use certain tags to represent trust, since RDF lets us refer to expressions themselves and say things about them. Laurent raised, I believe, the idea of confidence values as a part of the language. Jim seemed to convince him that "saying things about ontologies" was enough, or that more was outside our scope.

Name I4.8-Trust-and-Ontology
Raised By James Hendler, fwd from John Yanosy, Motorola.
Owner James Hendler
Date 19 Apr 2002 (Raised)
Status Postponed, 6 Jun 2002.
Reference Original email

5 Second Quarter 2002 Issues

5.1 Uniform treatment of literal/data values

The DAML+OIL specs separate the domain of discourse into datatype values and individuals, and require ontology designers to designate whether properties take datatype values or individuals. As a result, interesting features like UniqueProperty can't be used for properties that take string/date/integer values.

Another result of this design is the distinction between rdfs:Class and daml:Class, about which users have asked for clarification.

Per Consensus on semantic layering. See Minutes of Bristol F2F.
Name I5.1-Uniform-treatment-of-literal-data-values
Raised By Dan Connolly
Date 08 Oct 2002
Status Closed
Reference Minutes of Bristol F2F
Test Case This inference isn't valid per the current DAML+OIL specs; I suggest it should be.

5.2 Language Compliance Levels

It has been proposed that DAML+OIL is a complex language that is hard to implement and/or explain to new users. As a result, different implementors are creating incompatible subsets of the language features that they support. A possible way to improve this situation is to have a particular subset that is recommended in the form of a proper compliance level -- that is, a subset of the total functionality that is easier to explain and implement, and that forms a useable core sublanguage.

Name I5.2-Language-Compliance-Levels
Raised By Frank van Harmelen
Date 08 Oct 2002
Status Closed
Resolution Endorsed existing OWL lite language subset.
Reference Original message
Minutes of Bristol F2F

5.3 Semantic Layering

The web ontology language is expected to be maximally compatible, both syntactically and semantically, with RDF and RDFS. It was seen, however, that there might be problems with semantic compatibility and the necessary entailments needed in the ontology language's model theory. Reconciling the difference between RDF's MT and the MT for our language is important. One proposed solution, called "dark" or "unasserted" triples, might be added to RDF, another possibility is an ontology-language-only solution, if one can be produced.

Note that resolution of this issue impacts issue 5.10-DAML+OIL-semantics-is-too-weak.

Closed as described in Consensus on semantic layering, provided 2 technical pieces of work can be completed (see minutes).

Name I5.3-Semantic-Layering
Raised By Peter Patel-Schneider
Date 29 Apr 2002
Status Closed, 10 Jul 2002
Resolution See Minutes of Bristol F2F
Reference Original message
Consensus Minutes of Bristol F2F


We expect that future developers will build language extensions based on OWL. Some of them will want to extend OWL to systems that can state implications (IF a THEN b), modal properties (EVENTUALLY, ALWAYS), attributions (The book states that the earth is 6000 years old), and similar contextually restricted propositions.

There are a number of ways to build such extensions. One is to embed fragments of OWL in the new language. Alternatively, OWL could provide a minimal level of support for extensions by defining a mechanism for scoping OWL expressions that will remain semantically uninterpreted. OWL could provide the 'OWL:QUOTE' tag or attribute to mark such expressions. The key requirement is that the OWL semantics ensure that the content identified by this tag, while OWL notation, has no semantic interpretation in this context.

Raised By Michael K. Smith
Date 08 Oct 2002
Status Postponed
Reference Original message
Minutes of Bristol F2F

5.5 List syntax or semantics

A non-empty owl:List has precisely one owl:first element, and one owl:rest pointing to a tail. owl:nil has no owl:first or owl:rest property.

Are these restrictions syntactically or semantically expressed.

Note: I fear that this is the intersection of 5.3-semantic-layering and 2.5-closed-sets.

Name I5.5-List-syntax-or-semantics
Raised By Jeremy Carroll
Date 08 Oct 2002
Status Open
Reference Original message
Open all raised issues at Bristol F2F
Test Case A:
_:eg <rdf:type> <owl:List>.
_:eg <owl:first> _:a .
_:eg <owl:first> _:b .
_:eg <owl:rest> <owl:nil> .
_:eg <rdf:type> <owl:List>.
_:eg <owl:first> _:a .
_:eg <owl:rest> <owl:nil> .
_:a <owl:equivalentTo> _:b .
(assuming owl:equivalentTo is part of the language) In the syntactic understanding of owl:List A is a syntax error. In the semantic understanding A and B entail one another.

5.6 daml:imports as magic syntax

IN DAML+OIL, daml:imports is used to specify resources with additional relevant information. A similar feature is needed in OWL to support the "Explicit ontology extension" and "Commitment to ontologies" requirements. However, if this feature is an RDF property, as in DAML+OIL, then it is possible to write axioms that redefine this feature. For example, someone can say "Ontology A only imports resources of type foo" or "Ontology B imports at least one of the following resources." If allowed, such statements would complicate the language significantly. As such, it has been suggested in RDF-Logic that special syntax be used for this feature, so that it cannot be used in assertions in the same way as other RDF properties.

Name I5.6-daml:imports-as-magic-syntax
Raised By Jeff Heflin
Date 10 May 2002
Status OPEN, 5 Sep 2002
Owner Jeff Heflin
Reference Drew McDermott, 30 Apr 2002, http://lists.w3.org/Archives/Public/www-rdf-logic/2002Apr/0104.html

5.7 Range restrictions should not be separate URIs

If every time a user wishes to limit a property of range integer or real number to an interval he or she will need to refer to a separate URI, this will cause scalability and usability difficulties

Name I5.7-Range-restrictions-should-not-be-separate-URIs
Raised By Ziv Hellman, email of 2/5/02.
Date 08 Oct 2002
Status Open
Reference http://lists.w3.org/Archives/Public/www-webont-wg/2002May/0040.html
Open all raised issues at Bristol F2F

5.8 Datatypes

It appears that the RDF Core WG will not produce a solution to the datatypes issue, as witness the lack thereof in the current working drafts and the imminent end of the WG. Therefore the WebOnt WG will have to either use the DAML+OIL solution (which has flaws) or develop its own.

One possible resolution would be to extend the DAML+OIL solution by allowing xsi:type attributes to provide local typing information.

As of 8 Oct 2002, waiting on RDF Core.

Name I5.8-Datatypes
Raised By Peter F. Patel-Schneider
Date 17 May 2002
Status Pending: Waiting on RDF Core.
Reference RDF Core Primer WD
RDF Core WG schedule Minutes of Bristol F2F

5.9 Malformed DAML+OIL Restrictions

DAML+OIL allows for restrictions that are malformed. Restrictions with missing components (e.g., a restriction with no daml:onProperty triple) have no semantic impact, even though treating them as RDF would indicate that there should be some semantic import. Restrictions with extra components (e.g., a restriction with daml:onProperty triples to more than one property) have unusual and misleading semantic impact (in general equating the extensions of two or more well-formed restrictions). Perhaps both of these should be syntactically illegal in OWL.

Name I5.9-Malformed-DAML+OIL-Restrictions
Raised By Peter F. Patel-Schneider
Date 17 May 2002

5.10 DAML+OIL semantics is too weak

DAML+OIL semantics (both the model theory and the axiomatization) are too weak. For example, it does not allow the inference of membership in any restrictions that are not present in the knowledge base, even though many of these are desirable consequences. For example, if John is an instance of both Person and Employee, DAML+OIL does not sanction the conclusion that John is an instance of an intersection of Person and Employee.

Resolution of this issue is closely related to the descision taken with regard to issue 5.3-Semantic-Layering.

Closed per Consensus on semantic layering.

Name I5.10-DAML+OIL-semantics-is-too-weak
Raised By Peter F. Patel-Schneider
Date 08 Oct 2002
Status Open 10 Jul 2002. Closed 8 Oct 02
Resolution Closed
Reference too numerous to find a definitive reference.
Minutes of Bristol F2F

5.11 hasClass/ToClass names

Several people at WWW2002 who were using DAML+OIL suggested that using hasClass and ToClass to represent the difference between universal and existential quantification was confusing, primarily with respect to nomenclature (i.e. the names in no way connote the difference between them). It is suggested that we consider a name change for these terms to something more mnemonic and/or some examples in the walkthru documents that better show the difference.

Name I5.11-hasClass-ToClass-names
Raised By Jim Hendler
Owner Dan Connoly
Date 20 May 2002
Status Closed, 13 Jun 02
Resolution Use names allValuesFrom and someValuesFrom.
Reference DAML+OIL

5.12 Entailing inconsistencies

The Web is decentralized, allowing any one to say anything. As a result, different viewpoints may be contradictory, or even false information may be provided. In order to prevent agents from combining incompatible data or from taking consistent data and evolving it into an inconsistent state, it is important that inconsistencies can be detected automatically.

OWL could have an explicit property owl:inconsitentWith so that all kinds of inconsistencies could be entailed (at least there could be a whole bunch of testcases).

Name I5.12-Entailing-inconsistencies
Raised By Jos De Roo
Date 08 Oct 2002
Status Postponed
Reference Requirements document
Minutes of Bristol F2F

5.13 Internet Media Type for OWL

The W3C TAG has just issued a proposed finding about internet media types. WebOnt will almost certainly have to identify, and perhaps register, an internet media type for OWL documents. RDF Core will almost certainly also identify an internet media type for RDF. WebOnt will have to coordinate with RDF Core on the relationship between the media types.

Name I5.13-Internet-Media-Type-for-OWL
Raised By Peter F. Patel-Schneider
Date 08 Oct 2002
Status Open
Reference RDF mail archive
Open all raised issues at Bristol F2F
Connolly discussion

5.14 Ontology versioning

The Requirements Document states that ontology evolution is an important design goal and that versioning information is a requirement for OWL. However, DAML+OIL has very limitied support for versioning information. It only has a tag called "daml:versionInfo" which contains an unstructured string. To support machine processing, OWL needs explict structured information related to versions, such as capabilities to point to prior versions, specify backward-compatibility, and to deprecate terms (i.e., state that they are available for backwards-compatibility only).

Name I5.14-Ontology-versioning
Raised By Jeff Heflin
Date 22 MAY 2002
Status OPEN, 5 Sep 2002
Owner Jeff Heflin
Reference Goal: Evolution, Req: Versioning

5.15 Feature decision for compliance level 1: Local Range Restrictions

Compliance level 1 - a subset of the full owl language - needs a decision concerning local range restrictions. The last proposal included no local range construct. The choices as detailed in [4] below are: The choices are (for Level 1 compliance)

  1. No kind of local range restriction. the rationale for this is because choosing 2 or 3 below makes adding the other one hard and it is not clear which is most useful. Putting both in violated the goal of maintaining simplicity. I had more to say on this in [1] and the embedded message and so did Frank in [2]. This is representationally impoverished choice.
  2. Universally qualified local range restrictions. (this allows me to say that all my children are doctors). This alone is not hard to explain or implement but makes adding 3 harder to implement. Ian has more to say on this in [3] and I have more to say on this in [1] (to which Ian responded with [3]). This is a choice that some limited expressive power systems have made such as CLASSIC.
  3. Existentially qualified local range restrictions. (this allows me to say that some of my children are doctors). This alone is not hard to explain or implement but makes adding 2 harder to implement. More details in [1, 2, 3].
  4. Both universally qualified and existentially qualified local range restrictions. (this allows me to say that all my children are persons and I have some child who is a doctor and some child who is a lawyer). This is harder to implement and thus could mean some tool developers will not do it. Most expressive DLs make this choice.
One note, if cardinality is to be added, some kind of local range restriction would be important to add.

Deborah McGuinness
Name I5.15-Feature-decision-for-CL1-local-range
Raised By Deborah McGuinness
Date 22 May 2002 (raised), 8 Oct 2002 (closed)
Status Closed
Resolution As per the current working documents, including someValuesFrom, allValuesFrom by consensus.
Reference Various email - [1], [2], [3], [4]
Minutes of Bristol F2F

5.16 Feature decision for compliance level 1: Cardinality Restrictions

Compliance level 1 - a subset of the full owl language - needs a decision concerning cardinality restrictions. The last proposal [1] included the ability to state functional roles - thus there is a way to make a max cardinality 1 and min cardinality 0 restriction. It lacked further cardinality features. Requests (e.g., [2]) have been made for more expressive power with respect to cardinality.

The choices are to:

  1. include only functional roles (thus allowing max cardinality 1 and min cardinality 0).
  2. add min cardinality 1
  3. add max cardinality 0
  4. combine 2 & 3
  5. allow full min and max cardinality (i.e., min / max cardinality n)
Note, it is not advised to add full cardinality without some kind of local range restriction. However, max cardinality 0 and min cardinality 1 on global roles may be of some use.

At the Briston F2F (8 Oct 2002) it was resolved to stay with minCardinality etc. as currently in working documents, with an editorial note suggesting presentation syntax names hasExactlyOne, hasAtMostOne, hasAtLeastOne, hasNone, and a link to rationale by consensus.

Name I5.16-Feature-decision-for-CL1-cardinality
Raised By Deborah McGuinness
Owner Deborah McGuinness
Date May 22, 2002 (raised)
Status Closed (11 Jul 2002, Telecon)
Resolution Adopt restricted cardinality (0/1)
References Email - [1], [2] Close again (!) Minutes of Bristol F2F

5.17 XML presentation syntax

At the 2nd FTF the group decided to produce a non-normative presentation syntax. One such syntax could be XML, although the group did not mandate that it be XML. However, even so, producing a non-normative XML presentation syntax would be useful.

Name I5.17-XML-presentation-syntax
Raised By Peter F. Patel-Schneider
Date 08 Oct 2002
Status Open
Reference http://www.w3.org/2001/sw/WebOnt/f2f2.html#Decisions
Open all raised issues at Bristol F2F

5.18 Unique Names Assumption Support in OWL

OWL (and RDF) do not make the unique names assumption. That is, they do not assume that two terms with different names refer to different things. Thus, there would be no assumption that something named Deb is different from something named Deborah.

It has been recognized that it is important to be able to state that objects are different. There is currently the functionality provided by differentIndividualFrom that would allow someone to state that the individual named Deb is different from the individual named Mike. The differentIndividualFrom form provides a way of enumerating pairwise disjointness between individuals.

The abstract syntax document mentions DifferentIndividuals that takes a list as an argument that then states that all of the individuals in the list are distinct.

Both of these options however still require a complete listing of all of the individuals that are distinct either stating pairwise disjointness of combining them in a list.

This issue requests additional support for stating uniqueness. The additional functionality would allow users to state that all individuals in a document, namespace, or ontology are distinct without being forced to enumerate all of the individual names in the differentFrom statement.

Name I5.18-Unique-Names-Assumption-Support-in-OWL
Raised By Deborah L. McGuinness
Date 08 Oct 2002
Status Open
Reference Requirements document
Open all raised issues at Bristol F2F
Comments from Jos De_Roo.
Response by Peter Patel-Schneider.

5.19 Classes as instances

In certain cases it is necessary to represent "classes as instances"

Scenario 1: Representing thesauri in OWL. Thesauri are build on terms and have a set of predefined relations to establish links between terms. One can distinguish two kinds of approaches to represent thesauri for RDF(S):

  1. Syntactic representation (see for example) does not use classes to represent terms (or synsets in WordNet). OWL could be used to represent all terms as instances of a class Term. Additionally the set of relations can be tranlated to properties having this class as domain and range. Eventually additional features of these properties, such as transitivity may be specified, e.g. for the hyperonym relation.
  2. "Semantic representation". Such as work carried out at the university of Karlsruhe. Here terms are converted to OWL classes and the hyperonym relation is converted to subclassof properties. All other thesaurus properties are difficult to translate since they are used to relate classes. However, in OWL properties do only relate instances which are members of the classes specified in domain and range constraints. The semantically correct representation would be to extend the metamodel of the ontology language, leading to information that cannot be processed by OWL aware agents.

    Another possibility is to treat classes as instances allowing to related classes using properties other than subclassof.

Scenario 2: Ontology Interoperability The representation of an entity as an instance or a class may depend on the context and perspective of the user. For example, in a biological ontology, the class Orangutan may have individual animals as its instances. However, the class Orangutan may itself be an instance of the class Species. Note, that Orangutan is not a subclass of Species, because then that would say that each instance of Orangutan (an animal) is an instance of Species. (example taken from R14 in http://www.w3.org/TR/webont-req/)

Since this decision may be context dependent, the issue of making classes equivalent to instances arises in ontology interoperability and mapping scenarios. For example, a boing 777 may be represented as an instance of airplane in a general aviation ontology. However, in the ontology of a particular aerospace company boing 777 may be a class that has several instances. If both ontologies must be aligned the appropriate mapping must be able to bridge the distinct set of instances and classes.

Name I5.19-Classes-as-instances
Raised By Raphael Volz, email of 7/11/02.
Date 08 Oct 2002
Status Open
Reference Open all raised issues at Bristol F2F

5.20 Should OWL provide synonyms for RDF and RDFS objects?

The DAML+OIL official definition contains a number of sameXxxAs statements (see below) that provide daml: synonyms for resources that are part of RDF or RDFS. This is probably a bad idea that should not be repeated in OWL as it can lead to confusion as to what comes from where, particularly as not all RDF and RDFS built-in resources are so treated, and at least one ``local name'', Class, is used in both RDFS and OWL.

The DAML+OIL statements in question are

Type NameType Name
rdf:Property subPropertyOfrdfs:Class Class
rdfs:Class Literalrdfs:Class Property
rdf:Property typerdf:Property value
rdf:Property subClassOfrdf:Property domain
rdf:Property rangerdf:Property label
rdf:Property commentrdf:Property seeAlso
rdf:Property isDefinedBy   

Closed by removing all the sameXXX statements. (see also: earlier discussion of 5.20).

Name I5.20-should-OWL-provide-synonyms-for-RDF-and-RDFS-objects
Raised By Peter F. Patel-Schneider
Date 08 Oct 2002
Status Closed
Resolution Remove all the sameXXX statements
Reference Owl.owl
Minutes of Bristol F2F

5.21 drop disjointUnionOf

owl:disjointUnionOf is an awkward construct (compared to rdfs:subClassOf) for many tools to support. It can be expressed using combinations of owl:unionOf or rdfs:subClassOf and owl:disjointWith (though perhaps without conveying the notion of providing a covering set when owl:disjointUnionOf is used with with owl:sameClassAs). I and other users of DAML+OIL recommend that we drop owl:disjointUnionOf from the OWL language.

Removed disjointUnionOf
Name I5.21-drop-disjointUnionOf
Raised By Mike Dean
Date 08 Oct 2002
Status Closed
Reference Open all raised issues at Bristol F2F
Proposal by Patel-Schneider to close this issue
Response by Connoly (seconds proposal plus worked-out example)

5.22 owl:Class still needed

The introduction of daml:Class as a subclass of rdfs:Class was largely motivated by the fact that rdfs:Class prohibited cycles. The W3C RDF Core WG recently removed this restriction. Is there still a need for a separate owl:Class?

Issue 5.1 [1] also discusses this distinction, but is more appropriately focused on the disjointness of ObjectProperty and DatatypeProperty.

Still needed per Consensus on semantic layering.

Name I5.22-owl:Class-still-needed
Raised By Mike Dean
Date 08 Oct 2002
Status Closed
Resolution Still needed.
References [1] Issue 5.1 Uniform-treatment-of-literal-data-values
Minutes of Bristol F2F

6 APPENDIX: Issue Submission

Send issues via email to www-webont-wg@w3.org. In the subject line, tag them with
   ISSUE: title
title should be short enough to be turned into a UID, but descriptive enough for identification.

Components of the message should follow the format below, using the tags indicated.


An example submission is show below.

TITLE: All tags should green
DESCRIPTION: The reason for this is simple.
<quotation>Green is my favorite color</quotation>.
Enough said.
RAISED BY: M. Smith, email of 4/23/02.

The possible fields are documented below. Required fields have a • in the first column.

DESCRIPTION:One or two paragraphs. Lengthy exposition should be contained in the ATTACHMENT. Or pointed to by a REFERENCE. You can include HTML markup in both this text and ATTACHMENT text.
RAISED BY:Your name or the original source.
 STATUS:If you think it is something other than RAISED.
If you identify it as CLOSED, include a RESOLUTION.
 ATTACHMENT:Many of these issues will need extensive documentation that could consume a lot of space. If needed, and it is not present already in the webont email archive, it goes here. The entry in the issues document itself will link back to this email msg. If you think this issue has already been explained in an existing message or set of messages, provide pointers to them tagged by REFERENCE. Where by pointer I mean the URL in the webont archive.
 REFERENCE:URL(s) of other, relevant messages.
 RESOLUTION:If you claim it is CLOSED, provide a short description with a link to the minutes recording the decision.
 TEST CASE:URL(s) for applicable test case.

You can string multiple issues in one email, as long as each begins with TITLE. But it will be clearer in the archive if they are separate.


Components of issue documentation will include:

NAME:Unique id derived from TITLE. Thus, http://www.w3.org/2001/sw/WebOnt/webont-issues.html#uid will always provide a link to the issue. The default UID construction prefixes the title with 'I', followed by a sequence number and replaces spaces and other special characters with dashes.
TITLE: Obvious
DESCRIPTION: One or two paragraphs.
RAISED BY: Name, link to email
DATE: Date raised.
RESOLUTION: Short description with link to minutes recording decision
 TEST CASE:Link to test case(s).
 REFERENCE:This field is present if there was elaboration beyond DESCRIPTION in the original email (an ATTACHMENT) or if there are other relevant emails in the archive that need to be cited.

I would like to provide links to all of the relevant email discussion, but I don't think that is practical.

RAISEDSubmitted, but not currently being discussed.
OPENActively being worked on.
PENDINGActivity suspended, perhaps until some other controlling issue is resolved.
POSTPONEDActivity suspended. Will not be resolved by this working group. Left for the next revision.
SUBSUMED-BY uidAllows some freedom in clearing up sets of issues.

7 APPENDIX: Issue Process

Issues have the following life cycle: