Copyright 2002 Deborah L. McGuinness. All Rights Reserved. Distribution policies are governed by the W3C intellectual property terms.
Table of Issues |
(How to Submit an Issue) |
| Name | Source | Date | Status |
|---|---|---|---|
| 1.1-Variables | I. Horrocks on Telecon | 28 Feb 2002 | Raised |
| 1.2-Definitional-Constraints-on-Conjunctive-Types | Telecon | 19 Feb 2002 | Resolved |
| 2.1-URI-naming-of-instances | Mike Dean email | 19 Feb 2002 | Raised |
| 2.2-Adding-Properties-to-Other-Instances | Mike Dean email | 19 Feb 2002 | Raised |
| 2.3-Adding-Properties-to-Other-Classes | Mike Dean email | 19 Feb 2002 | Raised |
| 2.4-Enumerated-Classes | Mike Dean email | 19 Feb 2002 | Raised |
| 2.5-Closed-Sets | Mike Dean email | 19 Feb 2002 | Raised |
| 2.6-Ordered-Property-Values | Mike Dean email | 19 Feb 2002 | Raised |
| 3.1-Local-Restrictions | Mike Dean email | 19 Feb 2002 | Raised |
| 3.2-Qualified-Restrictions | Mike Dean email | 19 Feb 2002 | Raised |
| 3.3-DisjointFrom | Mike Dean email | 19 Feb 2002 | Raised |
| 3.4-UnambiguousProperty | Mike Dean email | 19 Feb 2002 | Raised |
| 4.1-UniqueProp-BadName | Tim Finan / Amsterdam F2F |
11 Apr 2002 | Raised |
| 4.2-Cardinality-Constructs-Levels | Steve Buswell / Amsterdam F2F |
12 Apr 2002 | Raised |
| 4.3-Structured-Datatypes | Jonathan Borden / Amsterdam F2F |
15 Apr 2002 | Raised |
| 4.4-Extra-logical-feature-set | James Hendler | Apr 19, 2002 | RAISED |
| 4.5-InverseOf | James Hendler | Apr 19, 2002 | RAISED |
| 4.6-EquivalentTo | James Hendler | Apr 19, 2002 | RAISED |
| 4.7-Does-OWL-provide-built-in-'model-checking'-functionality | James Hendler | Apr 19, 2002 | CLOSED |
| 4.8-Trust-and-Ontology | James Hendler, fwd from John Yanosy, Motorola. | Apr 19, 2002 | RAISED |
| 5.1-Uniform-treatment-of-literal/data-values | Dan Connolly | 24 Apr 2002 | RAISED |
| 5.2-Language-Compliance-Levels | Frank van Harmelen | 29 Apr 2002 | Open |
| 5.3-Semantic-Layering | Peter Patel-Schneider | 29 Apr 2002 | Open |
| 5.4-OWL:QUOTE | Michael K. Smith | 30 Apr 2002 | Raised |
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.
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 (W3C members only).
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/.
"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.
| Name | 1.1-Variables |
| Raised By | WG Telcon of 28 Feb 2002 discussion of requirements document draft. |
| Date | 28 Feb 2002. |
| Status | Raised. |
| Resolution | Dropped as objective, kept as issue as reminder to discuss in the future. |
"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 | 1.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 | Resolved. |
| Resolution | This objective will be dropped. |
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.
| Name | 2.1-URI-naming-of-instances |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
Adding properties to "someone else's" instances.
| Name | 2.2-Adding-Properties-to-Other-Instances |
| Raised By | Mike Dean email |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
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.
| Name | 2.3-Adding-Properties-to-Other-Classes |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
| Name | 2.4-Enumerated-Classes |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
Closed sets (daml:List, daml:collection). This could be included as part of "Ability to state closed worlds".
| Name | 2.5-Closed-Sets |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
The ability to order property values (e.g. for a list of authors, or a sequence of events)
| Name | 2.6-Ordered-Property-Values |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
Local restrictions (the ability to use the same property in somewhat different ways for different classes). Unaccounted for DAML+OIL feature.
| Name | 3.1-Local-Restrictions |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
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 | 3.2-Qualified-Restrictions |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution | |
| Test Case: | Case |
Unaccounted for DAML+OIL feature.
| Name | 3.3-DisjointFrom |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
Unaccounted for DAML+OIL feature.
| Name | 3.4-UnambiguousProperty |
| Raised By | Mike Dean e-mail. |
| Date | 19 Feb 2002. |
| Status | Raised. |
| Resolution |
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 | 4.1-UniqueProp-BadName |
| Raised By | Tim Finin elaboration of issues list generated at Amsterdam Face to Face, 9 Apr 2002. |
| Date | 11 April 2002. |
| Status | Raised. |
| Resolution |
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 | 4.2-Cardinality-Constructs-Levels |
| Raised By | Steven Buswell elaboration of issues list generated at Amsterdam Face to Face, 9 Apr 2002. |
| Date | 12 Apr 2002. |
| Status | Raised. |
| Resolution |
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 | 4.3-Structured-Datatypes |
| Raised By | Jonathan Borden elaboration of issues list generated at Amsterdam Face to Face, 9 Apr 2002. |
| Date | 15 Apr 2002. |
| Status | Raised. |
| Resolution |
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 | 4.4-Extra-logical-feature-set |
| Raised By | James Hendler |
| Date | 19 Apr 2002 |
| Status | RAISED |
| Resolution |
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.
| Name | 4.5-InverseOf |
| Raised By | James Hendler |
| Date | 19 Apr 2002 |
| Status | RAISED |
| Resolution |
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 | 4.6-EquivalentTo |
| Raised By | James Hendler |
| Date | 19 Apr 2002 |
| Status | RAISED |
| Resolution |
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 | 4.7-Does-OWL-provide-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). |
(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:
| Name | 4.8-Trust-and-Ontology |
| Raised By | James Hendler, fwd from John Yanosy, Motorola. |
| Date | 19 Apr 2002 |
| Status | RAISED |
| Resolution | |
| Reference | Original email |
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 | 5.1-Uniform-treatment-of-literal/data-values |
| Raised By | Dan Connolly |
| Date | 24 Apr 2002 |
| Status | RAISED |
| Resolution | |
| Reference |
|
| Test Case | This inference isn't valid per the current DAML+OIL specs; I suggest
it should be. http://www.w3.org/2002/03owlt/sameStateP.rdf http://www.w3.org/2002/03owlt/sameStateC.rdf |
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 | 5.2-Language-Compliance-Levels |
| Raised By | Frank van Harmelen |
| Date | 29 Apr 2002 |
| Status | Open |
| Resolution | |
| Reference | Original message |
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.
| Name | 5.3-Semantic-Layering |
| Raised By | Peter Patel-Schneider |
| Date | 29 Apr 2002 |
| Status | Open |
| Resolution | |
| Reference | Original message |
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.
| Name | 5.4-OWL:QUOTE |
| Raised By | Michael K. Smith |
| Date | 30 Apr 2002 |
| Status | Raised |
| Resolution | |
| Reference | Original message |
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
| Tag | Description | |
|---|---|---|
| TITLE: | title | |
| 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:
| Tag | Description | |
|---|---|---|
| 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 a sequence number and replaces spaces with dashes. | |
| TITLE: | Obvious | |
| DESCRIPTION: | One or two paragraphs. | |
| RAISED BY: | Name, link to email | |
| DATE: | Date raised. | |
| STATUS: | [ RAISED | OPEN | POSTPONED | CLOSED | SUBSUMED-BY uid ] | |
| 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.
| RAISED | Submitted, but not currently being discussed. |
| OPEN | Actively being worked on. |
| POSTPONED | Activity suspended, perhaps until some other controlling issue is resolved. Do we need this, or could we just revert to RAISED? |
| CLOSED | Resolved. |
| SUBSUMED-BY uid | Allows some freedom in clearing up sets of issues. |