Web Ontology Issue Status

This version:

May 28 2002

Previous version:

23 May 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.

---

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.

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.

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.

2.4 Enumerated Classes (daml:oneOf)

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.

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.

3.4 daml:UnambiguousProperty

Unaccounted for DAML+OIL feature.

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

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.

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

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.

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.

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

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)

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