Web Ontology Issue Status

This version:

10 Jul 2002

Previous version:

26 Jun 2002

Editor:

Michael K. Smith (Electronic Data Systems)
michael.smith@eds.com

Copyright © 2002 W3C^® ( MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

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

Abstract

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.

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"

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.

2.2 Adding Properties to "Someone Else's" Instances

Adding properties to "someone else's" instances.

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.

2.4 Enumerated Classes (daml:oneOf)

See proposal to close.

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

2.6 Ordered Property Values

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

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.

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:

• have added to the difficulty of learning the language
• have not been used in practice
• are barely understood by the community
• potentially add to the difficulty of implementing the language
• have no compelling use cases

I propose that the WG

• decides that the qualified restrictions of DAML+OIL are not part of OWL.
• approves the test cases of http://lists.w3.org/Archives/Public/www-webont-wg/2002Apr/0126.html as reflecting this decision.
• closes the unmentioned-qualified-restrictions issue.

3.3 daml:disjointFrom

Unaccounted for DAML+OIL feature.

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

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.

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

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.

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.

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?

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.

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?

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)

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:

• reference to trusted third party for ontology integrity
• responsible party identification for ontology authentication
• commitment level to maintaining ontology integrity
• standard or consortium references for ontology
• signatures for ensuring ontology integrity (Already covered in "Integration of digital signatures") Trust Level - an overall indicator

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.

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.

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.

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.

5.4 OWL:QUOTE

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.

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.

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

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.

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

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.

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.

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.

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.

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

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.

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

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.

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)

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.

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.

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.

FORMAT FOR ISSUE SUBMISSION

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.

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.

FORMAT OF ISSUE ENTRY

Components of issue documentation will include:

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

STATUS TAGS

7 APPENDIX: Issue Process

Issues have the following life cycle:

• Issues are submitted by members of the working group. Such issues are marked raised. The process for submission is described above.
• The chair may open an issue, normally assigning an owner.
• The issue list is reviewed periodically. Normally, discussion is only in order for open issues. At times the chair may deem that a review is in order to attempt to resolve, merge, close, postpone and otherwise clean up the list.
• Issues are closed by decision of the WG. The chair determines when the WG is ready to decide, usually in response to a proposal from the issue owner. The resolution is recorded in the issues list.