Web Ontology Issue Status

This version:
1 November 2003
Previous version:
22 July 2003
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 email8 May 2003Postponed
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
21 Nov 2002Postponed
4.4 Extra-logical feature setJames Hendler31 Oct 2002 Postponed
4.5 InverseOfJames Hendler19 Apr 2002Closed
4.6 EquivalentToJames Hendler27 Jun 2003Closed
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 14 Nov 2002 Closed
5.6 daml:imports as magic syntaxJeff Heflin 10 May 2002Closed over objection
5.7 Range restrictions should not be separate URIs Ziv Hellman31 Oct 2002Postponed
5.8 DatatypesPeter F. Patel-Schneider 17 May 2002Closed
5.9 Malformed DAML+OIL Restrictions Peter F. Patel-Schneider 7 Nov 2002Closed
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 12 Dec 2002Closed
5.14 Ontology versioningJeff Heflin5 Dec 2002 Closed
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 2002Closed
5.18-Unique-Names-Assumption-Support-in-OWL Deborah L. McGuinness 08 Oct, 2002Closed
5.19-Classes-as-instances Raphael Volz, email of 7/11/02. 21 Nov 2002Closed
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
5.23-hasValue-in-owlDeb McGuinness 12 Dec 2002Closed
5.24-IF-or-IFF-property-propertiesJeremy Carroll 21 Nov 2002Closed
5.25-JustificationsDan Connolly12 Dec 2002 Postponed
5.26-OWL DL SytntaxJeremy Carroll3 Mar 2003 Closed over objection
6.1-Unnamed Individual Restrictions Jeremy Carroll12 Jun 2003 Postponed
6.2-Compound Keys Jim Hendler3 Jul 2003 Postponed

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.). This feature of DAML+OIL wasn't accounted for when developing requirements.

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

Reopened due to request from reviewers. See 1 May 2003 teleconference minutes.

Name I3.2-Qualified-Restrictions
Raised By Mike Dean e-mail.
Date8 May 2003.
OwnerJonathan Borden

The Working Group decided 25 Apr 2002 to remove qualified cardinality constraints. The issue was reopened due to new information Apr 2003 from Alan Rector. In the 8 May 2003 teleconference, the WG resolved

... to POSTPONE this issue for the following reasons:
  • OWL already contains one QCR construct: owl:someValuesFrom (QCR with minimal cardinality of 1) which covers some frequent-occurring cases of QCRs.
  • There are some workarounds for QCRs, using the rdfs:subPropertyOf construct. These can be used in simple cases, such as the example in the Guide below. The WG agrees that these workarounds are more problematic for complex part-of relations such as pointed out by Alan Rector in his use cases a) and b).
  • The evidence on whether users need this is mixed. Rector's use cases are compelling, but Protege (which has a large user community) has not reported user requests for this feature.
  • Inclusion of this feature will put additional burden on implementations. For example, it is nontrivial to add this to Protege.

The Working Group therefore POSTPONES the full treatment of QCRs, while considering possibilities for making idioms or other guidelines for QCRs available to the community.

Test Case: Case
References Telecon, 25 Apr 2002, initial vote. Reviewer comments caused re-opening.
Telecon, 8 May 2003, postponed.
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.
Date21 Nov 2002.
Resolution See Nov 21 minutes
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?

This issue was postponed. Note that the resolution to this issue does not impact 5.6 (owl:imports) nor 5.14 (ontology versioning).

Name I4.4-Extra-logical-feature-set
Raised By James Hendler
Date 31 Oct 2002
Status Closed over objection
Owner Mike Dean
Resolution In teleconference of 31 Oct 2002, "RESOLVED (to postpone?) issue 4.4 by consensus as amended.".

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 27 Jun 2003
Status Closed
Resolution Resolved by consensus: We will have owl: sameClassAs, samePropertyAs, SameIndividualAs and SameAs which is a synonym for sameIndividualAs. The ref/guide documents will include a note that owl:sameAs is typically used when it is not known whether the types are the same. See details in Proposal and Telecon of 11 Nov below.

Reopened/closed decision re name of sameClassAs and samePropertyAs based on feedback from reviews. Changed to equivalentClass and equivalentProperty.

Reopened/closed decision based on additional feedback from reviews. Kept the current resolution with the following amendment: "owl:sameAs" is the name in the OWL vocabulary for expressing equality of individuals; owl:sameIndividualAs is dropped from the OWL vocabulary.
  • no synonym is better
  • sameAs matches with differentFrom
  • sameAs is not biased toward either DL or Full.
Reference Opened.
Proposal to close.
Closed at Telecon, 11 Nov 2002.
Reopened and modified to change sameClass and sameProperty to equivalentClass and equivalentProperty.
Reopened in regard to sameAs/sameIndiviualAs and modified.
Closed at Telecon, 26 June 2003
See also clarification regarding sublanguage inclusion of sameAs.

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 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 Q2-Q4 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.

Name I5.1-Uniform-treatment-of-literal-data-values
Raised By Dan Connolly
Date 08 Oct 2002
Status Closed
Resolution Per Consensus on semantic layering. See Minutes of Bristol F2F.
Reference Re: SEM: semantics for current proposal (why R disjoint V?)
Re: SEM: semantics for current proposal (why R disjoint V?) (sameState TEST)
Re: rdfs:Class vs. daml:Class ?
Minutes of Bristol F2F
Test Case This inference isn't valid per the current DAML+OIL specs; 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.

This issues was briefly reopened in order to add owl:Nothing to OWL Lite. See proposal to add, agenda update and resolution to do so.

Name I5.2-Language-Compliance-Levels
Raised By Frank van Harmelen
Date 08 Oct 2002 and 1 May 2003
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).

This issue was reopened and closed in June/July 2003. The resolution passed by consensus with two abstensions.

RESOLVED: to close the layering issue (5.3) as described in Consensus on semantic layering, with the change that KB large-OWL-entails C if KB-fast-OWL-entails C (but not only if -- Large OWL is now known as Owl Full, Fast Owl is now known as OWL DL).

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 Revised proposal to close Minutes of 3 July 2003 Teleconference.
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: Concern 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 14 Nov 2002
Status Closed
Resolution OWL semantics and RDF semantics support this.
Reference Original message
Open all raised issues at Bristol F2F
Jeremy's message plus follow-up
Message re RDF CORE and Semantic Web Coordination
Teleconference, 14 Nov 2002
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 14 Nov 2002
Status Closed over objection
Owner Jeff Heflin
Resolution "... The imports set of an OWL abstract syntax document is the union of the arguments of its Imports directives and the imports sets of any documents found at the URIs given by these arguments. ..." etc. per proposal of 1 Nov 2002, adopted 14 Nov 2002 over the objections of Connolly/W3C and Hendler/MIND.
Reference Drew McDermott, 30 Apr 2002
Teleconference, 14 Nov 2002 as modified.

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 31 Oct 2002
Status Postponed
Resolution In teleconference of 31 Oct 2002
Reference http://lists.w3.org/Archives/Public/www-webont-wg/2002May/0040.html
Open all raised issues at Bristol F2F
31 Oct 2002 Telecon

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.

Name I5.8-Datatypes
Raised By Peter F. Patel-Schneider
Date 17 May 2002
Status Closed.
Resolution See minutes of 12 Dec 2002.
Reference Further Email
Telecon, 3 March 2003
Teleconference 12 Dec 2002.
Peter Patel-Schneider proposal.
Response from Jeremy Carrol.
Comments from Peter Patel-Schneider.
Jeremy Carrol summary of RDF datatyping.
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 07 Nov 2002
Status Closed
Resolution As per the DAML+OIL model theory. The effect of such collections of triples is to force all legal restrictions that can be formed from the triples to be co-extensional.
Reference Proposed solution.
Telecon of 7 Nov 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 12 Dec 2002
Status Closed
Resolution See proposal to close from Jonathan Borden and discusion in minutes. Advise users in the that they can use application/xml, application/rdf+xml, and application/owl+xml.
Revised at 20 Mar 2003 Teleconference. RESOLVED: to close 5.13 without making a new OWL mime type, observing that the existing mime types, e.g. app/rdf+xml and app/xml are sufficient.
Reference 20 Mar 2003 Teleconference. Telecon 12 Dec 02
Borden Proposal
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 5 Dec 2002
Status Closed
Owner Jeff Heflin
Resolution Text of resolution.
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. Deb McGuiness 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 McGuiness had 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.

Name I5.15-Feature-decision-for-CL1-local-range
Raised By Deborah McGuinness
Owner 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 Bristol 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.This addressed Wallace's dissent from a related decision 1 Jul in Stanford.

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

In the wrap-up session of the 2nd FTF in Amsterdam the group decided to produce a non-normative presentation syntax(with one member dissenting. who was it?@@). 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 Closed
Reference Clarifies status.
Peter Patel-Schneider proposal.
Comments from Masahiro Hori.
F2F Two.
Open all raised issues at Bristol F2F
Proposal to close Revised proposal to close

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 Closed
Resolution We have AllDifferent, but this is does not provide the full support requested by this issue.
RESOLVED: to close this issue using an AllDifferent class and a distinctMembers property (to be elaborated by the semantics editors). Comment on the partial nature of this solution
Proposal to postpone.
Response to proposal to postpone.
Reference Summary of status, after owl:AllDifferent added.
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". Examples include 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 11,21 Nov 2002
Status Closed
Resolution Part of OWL Full. See minutes of 14 and 21 Nov 2002.
Reference 21 Nov 2002 minutes
14 Nov 2002 minutes
Open all raised issues at Bristol F2F
Write up
Write up re OWL Lite
Discussion at Telecon, 11 Nov 2002.

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). Dean 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 24 Oct 2002
Status Closed

[...] The only thing going for owl:disjointUnionOf is that it uses fewer triples than the alternative. However almost all disjoint unions are small so the number of owl:disjointWith triples will not be that large. [...]
proposal of 18 Oct, adopted 24 Oct 2002

Removed disjointUnionOf.
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)
Documented in the guide:

A common requirement is to define a class as the union of a set of mutually disjoint subclasses.
section 5.3. Disjoint Classes in OWL Web Ontology Language Guide

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

5.23 hasValue in OWL Lite?

Certain constituencies are very interested in owl:hasValue as an element of OWL Lite.

Name I5.23-hasValue-in-owl
Raised By Deb McGuinness
Date 12 Dec 2002
Status Closed
Resolution Not in OWL Lite. See 12 Dec 02 Telecon.
References Telecon 12 Dec 02
Deborah McGuinness summary.
Telecon of 31 Oct 2002

5.24 IF or IFF propery properties

Should the definitions of the semantics for rdfs:range, owl:TransitiveProperty,owl:FunctionalProperty etc. be necessary (if) or necessary and sufficient (iff). The former semantics may be called intensional, the latter extensional. Should the choice be the same for all, or should the choice be made on a case by case basis. What about the relationship with rdf core who own the base semantics for rdf:range and rdf:domain.

Name I5.24-IF-or-IFF-property-properties
Raised By Jeremy Carroll
Date 21 Nov 2002
Status Closed
Resolution See email.
References Introduction of issue
Domain and range email, Oct 25 2002
Test example email
Email response to tests Aug 01 2002
Test Cases Test 1
Test 2
Test 3
Test 4
Test 5

5.25 Justifications

Finding proofs is a lot of work; once one is found, it can be checked straightforwardly. It would be valuable to have an exchange syntax to promote interoperability of proof-checking systems and to preserve the value of proofs, once they're found.

Related issues: 5.13 Internet Media Type for OWL and 5.3 Semantic Layering.

Name I5.25-Justifications
Raised By Dan Connolly
Date 12 Dec 2002
Status Postponed
Resolution POSTPONED. While several members of the WG agree this would be valuable, no one argues that it's critical path for this round of deliverables. Discussion of this issue should be taken to www-rdf-logic for the time being.
Reference Minutes of Bristol F2F
Oct 7 2002, IRC log

5.26-OWL DL Sytntax

Any matching of RDF triples with a DL view is going to have some ugliness somewhere. The current AS&S design has prioritised a clean abstract syntax and allowed the concrete exchanged syntax to be very difficult to describe, test, implement or understand. An alternative emphasis in the design on a clean characterization of OWL DL in RDF graphs, should be explored. This will put some of the ugliness in the mismatch into the abstract syntax. It is important to give an intelligible and correct explanation of what RDF graphs are in OWL Lite and OWL DL, that is genuinely usable by both humans and tools.

Later review determined that we could loosen the original proposal somewhat so that URI's used as the object of an annotation property do not need to be typed. See consensus in minutes of Oct 30, 2003 teleconference based on proposal B1, in Jeremy Carroll's email.

Name I5.26-OWLDLSyntax
Raised By Jeremy Carroll
Date 3 March 2003
Status Closed over objection
Resolution Proposal to resolve of 11 March was discussed in the 20 March teleconference, where it was adopted in part; in the 27 March teleconference, the WG resolved to close the issue without adopting the remaining parts (B1, B2) over the objection of Carroll/HP. cf objection from Carroll.
Modified by consensus in the minutes of Oct 30, 2003 teleconference
based on proposal B1, in email.
Reference Discussion and related work.
Parsing OWL, Sean Bechhofer, University of Manchester, June 02 2003
Minutes of Telecon 20 Feb 2003
Discussion by Carroll
Discussion by ter Horst 15 Jan 2003
Suggested text: RDF Graphs of OWL Lite Ontologies 21 Jan from Jeremy Carroll.
Ease of use design goal

6.1-Unnamed Individual Restrictions

The restrictions placed on b-nodes may limit the applicability of OWL DL to an unnecessarily restricted subset of RDF instance data, for which no such restrictions apply.

Specifically we request, that in Owl DL and Owl lite:

Name I6.1-UnnamedIndividualRestrictions
Raised By RDF Core
Date 12 June 2003
Status Postponed.
Resolution The working group felt that the changes requested would minimally require a major rework of the direct semantics of OWL DL. (Section 3 of S&AS) and should be postponed.
Reference Public Comment.
Email proposing issue.
Email opening issue.
Proposal to postpone.
Proposal to postpone.
Rationale for proposal to postpone.
Postponed in minutes of Telecon of 12 June 2003.

6.2-Compound Keys

Relational Databases often use keys that are composed of multiple fields. OWL allows keys using owl:InverseFunctionalProperty for a single field (property). It would be desirable for OWL to provide the compound keys capability as well.

We agreed to POSTPONE this issue. See resolution below.

Name I6.2-CompoundKeys
Raised By Jim Hendler
Date 3 July 2003
Status Postponed.
Resolution While compound keys would be desirable to add, there is some difficulty in adding them in the current OWL syntax, similar to the problem arising for "qualified" properties (see discussion under issue 3.2). In addition, for the OWL DL profile, it is still something of a research issue as to how these are best realized by DL reasoners. There is also a question as to whether mixing datatype and object type in a compound key would be allowed, and whether it would cause difficulties to reasoners.
Reference Closed at the 3 July 2003 Teleconference.
RAISED BY: J. Hendler 27 Jun 2003 based on a Last Call comment raised by Bob MacGregor.
Research citation 1.
Research citation 2.

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 uid Allows some freedom in clearing up sets of issues.

7 APPENDIX: Issue Process

Issues have the following life cycle: