Web Ontology Issues (original) (raw)

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.

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.

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

3.3 daml:disjointFrom

Unaccounted for DAML+OIL feature.

See proposal to close andrevised 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 andammended 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 droppingoptional/required andsingle/multivalued in favour of min- andmax- 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?

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

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

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

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:Nothingto OWL Lite. See proposal to add, agenda update andresolution to do so.

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 issue5.10-DAML+OIL-semantics-is-too-weak.

Closed as described in Consensuson 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).

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: Concern that this is the intersection of 5.3-semantic-layering and 2.5-closed-sets.

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.

Closed per Consensuson 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. 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.

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 rationaleby consensus.This addressed Wallace's dissent from a related decision 1 Jul in Stanford.

5.17 XML presentation syntax

In the wrap-up session of the 2nd FTF in Amsterdamthe 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.

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.

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

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

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

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.

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 Consensuson semantic layering.

5.23 hasValue in OWL Lite?

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

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.

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.

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 teleconferencebased onproposal B1, in Jeremy Carroll's email.

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:

• that a b-node representing an individual may be the object of more than one triple
• that cycles of b-nodes representing individuals be allowed.

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.

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. Green is my favorite color. 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.

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

FORMAT OF ISSUE ENTRY

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 '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. | | | | | | • | STATUS: | [ RAISED | OPEN | PENDING | 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.

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.