- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Mon, 30 Dec 2002 15:20:49 -0500 (EST)
- To: www-webont-wg@w3.org
- Message-Id: <20021230.152049.60038898.pfps@research.bell-labs.com>
I spent the last couple of days reading the non-technical OWL documents: Reference, Features, and Guide. One thing in particular that I tried to look out for is discrepancies between the documents and incorrect statements in them. I found lots of incorrect statements, some about RDF and some about OWL. I have tried to fix as many as possible, but there were so many, in particular in Reference, that I believe that yet another round of reviewing will be required after this round. I was unable to find complete information about the differences between OWL Lite, OWL DL, and OWL Full in these documents. There needs to be some informal but comprehensive dicussion of this important point. I think that this should be put in the Reference document. Review of Web Ontology Language (OWL) Reference Version 1.0 I had so many suggested changes to the first part of the document that I made a copy and edited it. Herein are just descriptions of some of the changes. I have not removed pointers to resolved issues, although there are a number that should be removed. I have replaced ``element'' with component in many places. Element is an XML term, and should be used with caution in OWL and RDF. I have changed URI to URI reference where appropriate. Abstracts should not have references. I removed them. The status section is too long and rather scattered. I revised and reorganized this section. The Table of Contents should be expanded to include more sub-sections in Section 2. I have changed some sub-sections to sub-sub-sections. The Introductory Remarks make a number of incorrect statements about OWL. I have revised these statements and heavily revised this section. The introduction of OWL ontologies is rather scattered. I have started the exposition of OWL ontologies in Section 1 and continued it in Section 2. The section on Collections isn't needed here: <p> Several components employ lists constructed using the <tt>rdf:List</tt>, <tt>rdf:first</tt>, <tt>rdf:rest</tt>, <tt>rdf:nil</tt>, and <tt>rdf:parseType="Collection"</tt> vocabulary <span class="future">[Ed: identify link]</span> recently added to RDF. </p> I have heavily edited the sub-section on Ontology header. I removed: This element does not contribute to the logical meaning of the ontology. which is not correct, as it does have an RDF meaning. IMPORTANT NOTE: We have fallen into the same trap that bedevils the RDF documents, namely of using a URI to mean the document referenced by that URI. This is is serious source of potential problems. The discussion of owl:imports had a number of incorrect statements that I have removed or modified. OWL no longer divides the universe into objects and values. Datatypes can be individuals. Class components contain a class name; they don't refer to one. The following is not really correct: <strong>Warning: </strong>the use of <tt><a href="#sameClassAs-def">owl:sameClassAs</a></tt> is favoured over the use of <tt><a href="#sameAs-def">owl:sameAs</a></tt>, since <tt><a href="#sameClassAs-def">owl:sameClassAs</a></tt> is declared as a subproperty of <tt><a href="#subClassOf-def">rdfs:subClassOf</a></tt>, while <tt><a href="#sameAs-def">owl:sameAs</a></tt> is not. This makes the meaning of <tt><a href="#sameClassAs-def">owl:sameClassAs</a></tt> at least partly available to an RDF Schema-only agent, while the meaning of <tt><a href="#sameAs-def">owl:sameAs</a></tt> is completely opaque to such an agent. <tt><a href="#sameAs-def">owl:sameAs</a></tt> is typically used when it is not known that the expression denotes a class.<br> The following is misleading: Although it is formally allowed to have multiple such assertions about C, as soon as two of the enumerations are not equivalent, the class C immediately becomes inconsistent (since C cannot be equivalent to both of these enumerations at once).</li> The following is incorrect: <p>A class expression ... is either</p> <ul> <li>a class name (a URI reference), or</li> <li>an <a href="#Enumerated">enumeration</a>, enclosed in <code><owl:Class>...</owl:Class></code> tags, or</li> <li>a <a href="#Restriction">property-restriction</a>, or</li> <li>a <a href="#Boolean">boolean combination</a> of class expressions, enclosed in <code><rdfs:Class>...</rdfs:Class></code> tags</li> </ul> The following is incorrect: It is also possible to create restrictions that are neither object restrictions nor datatype restrictions, these restrictions are not handled within OWL. This is the only mention of OWL Lite in this section, so out it goes: OWL Lite restricts the value of N to 0 or 1.<br> This can't be done anymore: <strong><a name="Warning" id="Warning">Warning</a>:</strong> in order to avoid "exposed content" (i.e., to hide OWL annotations from browsers), it is necessary to write cardinality constraints in an alternative RDF format. See <sup><a href="#Cardinalit">Cardinality Syntax Note</a></sup> for an example of this. <dt><a name="Cardinalit" id="Cardinalit">Cardinality Syntax Note</a>:</dt><dd>As an example of content-hiding syntax for cardinality expressions, instead of the standard notation:<br> <pre><owl:Restriction> <owl:onProperty rdf:resource="#father"/> <owl:cardinality>1</cardinality> </owl:Restriction></pre> <p>we would have to write<br> </p> <pre><owl:Restriction owl:cardinality="1"> <owl:onProperty rdf:resource="#father"/> </owl:Restriction> </pre> <p>to avoid any exposed content. The cardinality elements are the only ones for which this alternative notation is required to avoid exposed content. (See <span class="future">[Ed: identify link]</span> the section on abbreviated syntax in the RDF specification for more details on this notation).<br> </p> </dd> All the other notes are gone, so this one goes too: See <sup><a href="#Boolean1">Boolean Note</a></sup> for an example of this. The following is not really correct: <strong>Warning:</strong> the use of <tt><a href="#samePropertyAs-def">owl:samePropertyAs</a></tt> is favoured over the use of <tt><a href="#sameAs-def">owl:sameAs</a></tt>, since <tt><a href="#samePropertyAs-def">owl:samePropertyAs</a></tt> is declared as a subproperty of <tt><a href="#subPropertyOf-def">rdfs:subPropertyOf</a></tt>, while <tt><a href="#sameAs-def">owl:sameAs</a></tt> is not. This makes the meaning of <tt><a href="#samePropertyAs-def">owl:samePropertyAs</a></tt> at least partly available to an RDF Schema-only agent, while the meaning of <tt><a href="#sameAs-def">owl:sameAs</a></tt> is completely opaque to such an agent. <tt><a href="#sameAs-def">owl:sameAs</a></tt> is typically used when it is not known that the name denotes a property.<br> The following is not correct: <li><a name="inverseOf-def" id="inverseOf-def"></a>zero or more <code>owl:inverseOf</code> components, each containing a property name. for object properties only.<br> The following is not correct: , which is a subclass of <tt><a href="#ObjectProperty">owl:ObjectProperty</a></tt>. , which is a subclass of <tt><a href="#ObjectProperty">owl:ObjectProperty</a></tt>.<br> The following is the only place in this section where OWL DL is distinguished from OWL Full. If it is to be retained, the complete differentiation should be included. In OWL DL, an <tt>owl:InverseFunctionalProperty</tt> must also explicitly be an <tt><a href="#ObjectProperty">owl:ObjectProperty</a></tt>. In OWL Full, an <tt>owl:InverseFunctionalProperty</tt> may be either an <tt><a href="#ObjectProperty">owl:ObjectProperty</a></tt> or an <tt><a href="#DatatypeProperty">owl:DatatypeProperty</a></tt>. The following is not correct: A property is a binary relation that may or may not be defined in the ontology. If it is not defined, then it is assumed to be a binary relation with no globally applicable constraints, i.e. any pair with first element an object and second element an object or datatype value could be an instance of the property.<br> The following is only meaningful for OWL DL, which is not described here. <strong>Warning:</strong> If an <tt><a href="#TransitiveProperty-def">owl:TransitiveProperty</a></tt> (or any of its superproperties) is used in a cardinality constraint, then class consistency is no longer necessarily decidable. Of course, <tt><a href="#FunctionalProperty-def">owl:FunctionalProperty</a></tt> is a particular case of a cardinality constraint.</p> The following is not really correct: Instances of both classes (i.e., objects) and of properties (i.e., pairs) are written in RDF/XML syntax. <br> See the <a href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML Syntax Specification(Revised)</a> for more details on the various syntactic forms that are allowed. Here we list just some of the most common notations:<br> The following is not really correct: Datatype values are written in a manner that is valid RDF syntax, but which is given a special semantics in OWL. The preferred method is to give a lexical representation of the value as a string, along with an XML Schema datatype that is used to provide the type of the value as well as the parsing mechanism to go from the string to the value itself. The XML Schema datatype is the <tt>rdf:type</tt> of the value, and the lexical representation is the <tt>rdf:value</tt> of the value. So the decimal 10.5 could be input as <tt><xsd:decimal rdf:value="10.5"/></tt> provided that <tt>xsd</tt> was defined as the URI of the XML Schema Datatype specification. </p> <p> As a nod to backward compatability, literals that occur outside this sort of construction are interpreted as any of the XML Schema Datatype values with this lexical representation. These values are mostly unusable unless some typing information is available, such as a range for a property. </p> <p> The question of whether any XML Schema datatype can be used in such constructions, or whether only certain XML Schema dataypes can be so used (such as only the predefined datatypes), remains open. <span class="postponedissue">See issue <a href="http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I4.3-Structured-Datatypes">#4.3-Structured-Datatypes</a>.</span> <span class="issue">See issue <a href="http://www.w3.org/2001/sw/WebOnt/webont-issues.html#I5.7-Range-restrictions-should-not-be-separate-URIs">#5.7-Range-restrictions-should-not-be-separate-URIs</a>.</span> </p> Review of Web Ontology Language (OWL) Guide Version 1.0 NOTE: The example in the Guide does not correspond to the wine.owl file. NOTE: With all the changes I am suggesting, another round of reviewing is indicated for this document. SUGGESTED ABSTRACT: <p> The Web Ontology Language (OWL) is intended to provide a language that can be used to describe the classes and relations between them that are inherent in Web documents and applications. This document demonstrates the use of OWL to formalize a domain by defining classes and properties of those classes, define individuals and assert properties about them, and reason about these classes and individuals to the degree permitted by the formal semantics of the OWL language. The document is organized to present an incremental definition of OWL, beginning with the fundamentals and proceeding to more complex language components. </p> NOTE: The document is confusing with respect to ontologies and knowledge bases. I have tried to make the situation clearer. CHANGE OWL is a language for defining <em>Web ontologies</em> and their associated knowledge bases. TO OWL is a language for defining <em>Web ontologies</em>. CHANGE An OWL ontology may include the following elements. </p> <ul> <li>taxonomic relations between <em>classes</em></li> <li><em>datatype properties</em>, descriptions of attributes of elements of classes, </li> <li><em>object properties</em>, descriptions of relations between elements of classes, </li> </ul> and, to a lesser degree, <ul> <li><em>instances</em> of classes and </li> <li><em>instances</em> of properties.</li> </ul> TO An OWL ontology may include as well <em>instances</em> of classes and <em>instances</em> of properties. </p> REMOVE <p> Datatype properties and object properties are collectively the <em>properties</em> of a class. </p> CHANGE <p> A set of OWL assertions loaded into a reasoning system is called a <em>knowledge base</em> (KB). These assertions may include facts about individuals that are members of classes, as well as various <em>derived</em> facts, i.e. facts not literally present in the original textual representation of the ontology, but <em>entailed</em> (logically implied) by the semantics of OWL. These assertions may be based on a single ontology or multiple distributed ontologies that have been combined using defined <a href="#import">OWL mechanisms</a>. </p> <p> While ontologies for the most part do not include individuals (as distinct from knowledge bases), it is often the case that some individuals are needed in an ontology to define certain classes. For example, if we consider <i>Wine</i> and <i>Color</i> to be classes, and <i>red</i> to be an element of <i>Color</i>, then the class <i>Red Wine</i> would require the individual <i>red</i> as part of its definition and thus as an element of the ontology. As a result, no precise line can be drawn to distinguish when a collection of OWL assertions should be labeled an ontology and when it should be called a knowledge base. The <a href="#owl_Ontology"><tt>owl:Ontology</tt></a> tag does not necessarily identify a document as <i>an ontology</i>. There is nothing preventing a document marked as an OWL ontology document from containing exclusively individuals. The definition of ontology given above and used in this document is not enforced in any way (nor could it be) by the syntax of OWL. <!-- it is up to human users of OWL to use the tag as intended. --> </p> TO <p> An OWL reasoning system will generally work with more than just a single ontology. Where the distinction is important, we will call the entirely of the information present in an OWL reasoning system a <em>knowledge base</em> (KB). Such a knowledge base may include information derived from several OWL ontologies, perhaps combined using <a href="#import">OWL imports</a> directives, or even from non-OWL RDF documents. </p> <p> While ontologies are generally not about individuals per se, it is often the case that some individuals are needed in an ontology. For example, if we consider <i>Wine</i> and <i>Color</i> to be classes, and <i>red</i> to be an element of <i>Color</i>, then the class <i>Red Wine</i> would require the individual <i>red</i> as part of its definition and thus as an element of the ontology. As a result, no precise line can be drawn to distinguish when an RDF document, using the OWL vocabulary or not, should be considered an ontology and when it should not. The <a href="#owl_Ontology"><tt>owl:Ontology</tt></a> tag does not necessarily identify a document as an ontology in the above sense. There is nothing preventing a document marked as an OWL ontology document from containing exclusively individuals. Thus henceforward we will not bother to distinguish between ontologies and non-ontologies in the above sense. </p> REMOVE An operational consensus can always be developed over the meaning of a set of XML tags and their contents. There is furious ongoing standards activity doing exactly this. </p> <p> CHANGE <li> <em>Owl Lite</em> has been defined with the intention of satisfying users primarily needing a classification hierarchy and simple constraint features. For example, while it supports cardinality constraints, it only permits cardinality values of 0 or 1. For these reasons, it should be simpler to provide tool support for Owl Lite than its more expressive relatives. </li> TO <li> <em>OWL Lite</em> has been defined to admit simpler tools. It does not include all the OWL vocabulary, and places restrictions on some of the OWL vocabularly. For example, while it supports cardinality constraints, it only permits cardinality values of 0 or 1. As well, OWL Lite incorporates the restrictions placed on OWL DL. </li> CHANGE <li> <em>OWL DL</em> allows the complete OWL vocabulary, interpreted under a number of simple constraints. Primary among these is type separation. Class identifiers cannot simultaneously be properties or individuals. Similarly, properties cannot be individuals. OWL DL is so named due to its correspondence with <a href="#DescriptionLogics"><em>description logics</em></a>. It was designed to support the existing Description Logic business segment and has desirable computational properties for reasoning systems. </li> TO <li> <em>OWL DL</em> allows the complete OWL vocabulary, but places constraints on its use. Primary among these is type separation. Class identifiers cannot simultaneously be properties or individuals. Similarly, properties cannot be individuals. OWL DL is so named due to its correspondence with <a href="#DescriptionLogics"><em>description logics</em></a>. It was designed to have desirable computational properties for reasoning systems. </li> NOTE: Somewhere is needed a good comprehensive description of the OWL Lite, OWL DL, and OWL Full. CHANGE <p> In this document we present examples using the <a href="#OWLXMLSyntax">OWL XML syntax</a>, assuming XML will be familiar to the largest audience. The standard for interchange of OWL assertions between tools depends on <a href="#RDF1">RDF</a> triples. Note that OWL has been designed for maximal compatibility with RDF and RDF Schema. These XML and RDF formats are part of the standard. Other notations have been formulated, in particular a <a href="#OWLUMLSyntax">UML</a> version. <a href="#AppendixA">Appendix A</a> provides links to various primers on related standards. </p> TO <p> In this document we present examples in RDF/XML syntax <a href="#???">RDF/XML Syntax Specification (Revised)</a> assuming XML will be familiar to the largest audience. As OWL is a semantic extension to RDF, only the RDF information in this syntax is important - any information not carried through to the RDF Graph <a href="#???">RDF Concepts and Abstract Data Model</a> is irrelevant. </p> CHANGE <p> OWL <em>does</em> allow negative information to be explicitly stated. As a result, it is fairly simple to explicitly state contradictions. In addition, contradictions may be implicit. These properties of a knowledge base are something the designer of an ontology needs to be careful about. It is expected that tool support will help detect such cases. </p> TO <p> OWL <em>does</em> allow negative information to be explicitly stated. As a result, it is fairly simple to explicitly state contradictions. In addition, contradictions may be implicit. These properties are something the designer of an ontology needs to be careful about. It is expected that tool support will help detect such contradictions. </p> CHANGE <p> In order to write down an ontology that can be interpreted unambiguously and used by software agents we require a formal syntax and semantics. OWL provides these necessary underpinnings for ontology construction. See the <a href="#FormalModel">formal semantics</a> and <a href="#OWLXMLSyntax">XML syntax</a>. </p> TO <p> In order to write down an ontology that can be interpreted unambiguously and used by software agents we require a formal semantics for OWL. OWL is a vocabulary extension <a href="#??">[RDF Semantics]</a> of RDF, whose formal semantics are provided in the OWL Abstract Syntax and Semantics <a href="#FormalModel">[OWL Semantics]</a>. </p> CHANGE <p> Before we can use a set of terms, we need a precise indication of what specific vocabularies are being used. A standard initial component of an ontology includes a set of <em>namespace</em> declarations enclosed in an opening <tt>rdf:RDF</tt> tag. These provide a means to unambiguously interpret identifiers and make the rest of the ontology presentation much more readable. A typical OWL ontology begins with a <a href="#XMLNS">namespace declaration</a> similar to the following. </p> TO <p> XML namespaces can be used in the RDF/XML syntax. Although there is no notion of namespaces in RDF itself, XML namspaces can be used to shorten OWL ontologies written in RDF/XML and make them more readable. As well, we will often write URI references as if they were qualified names, appealing to an intuitive notion of the RDF rules that turn qualified names into URI references. Thus a typical OWL ontology begins with <a href="#XMLNS">namespace declarations</a> similar to the following. </p> CHANGE <pre><rdf:RDF xmlns ="http://www.example.org/wine#" xmlns:vin ="http://www.example.org/wine#" xmlns:food="http://www.example.org/food#" xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#" xmlns:dte ="http://www.example.org/wine-dt#" > </pre> TO <pre><rdf:RDF xmlns ="#" xmlns:vin ="#" xmlns:food="food#" xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#" xmlns:dte ="wine-dt#" > </pre> CHANGE unprefixed elements and empty URI references refer to the current TO unprefixed qualified names refer to the current CHANGE elements prefixed with <tt>owl:</tt> should be understood as referring to things drawn from the namespace called TO names prefixed with <tt>owl:</tt> should be understood as referring to URI references drawn from REMOVE This is a conventional OWL declaration, required to introduce the OWL vocabulary. CHANGE the <tt>rdf:</tt> prefix is understood to refer to things drawn from the namespace called TO the <tt>rdf:</tt> prefix refers to things drawn from THE FOLLOWING IS SUSPECT <p> This OWL document is related to a separate document containing XML Schema datatype definitions. The final declaration says that elements prefixed with <tt>dte:</tt> should be understood as referring to things drawn from the namespace called <code>http://www.example.org/wine-dt#</code>, which contains the datatype definitions for this Guide document. </p> CHANGE As an aid to writing down references to lengthy URLs it can often be TO As another way of shortening URI references it can often be CHANGE <pre><!DOCTYPE owl [ <!ENTITY vin "http://www.example.org/wine#" > <!ENTITY food "http://www.example.org/food#" > ]> </pre> TO <pre><!DOCTYPE owl [ <!ENTITY vin "#" > <!ENTITY food "food#" > ]> </pre> CHANGE <p><a id="owl_Ontology" name="owl_Ontology"></a> Once namespaces are established we begin with an assertion that what follows <em>is</em> an OWL document. </p> <pre><owl:Ontology rdf:about="http://www.example.org/wine"> </pre> <p> This assertion is formulaic. The <tt>about</tt> attribute will normally be the URL of the current file, indicating that the subject of this assertion is <em>this</em> document. If desired, the ontology may be given a name that is a URN and independent of a particular physical location. </p> TO <p><a id="owl_Ontology" name="owl_Ontology"></a> The next piece of an OWL document is generally a formulaic statement that this is an OWL ontology. </p> <pre><owl:Ontology rdf:about=""> </pre> <p> The <tt>about</tt> attribute will normally be empty, indicating that the ontology is <em>this</em> document. </p> NOTE: This use of a URI to refer to a document is suspect. REMOVE (it was stated above) <p> Note that not every document marked with the <tt>owl:Ontology</tt> tag need be <i>an ontology</i> as defined <a href="#Introduction">above</a>. Strictly speaking, the <tt>owl:Ontology</tt> tag simply identifies a document as containing OWL syntax, and nothing prevents such a document from containing, for example, exclusively individuals. However, OWL syntax is not <i>required</i> for defining individuals - plain RDF syntax can be used (as shown <a href="#DefiningIndividuals">below</a>). <!-- The following seems too strong. We get back to the question of how we indicate that a document is meant to be a set of individuals for which OWL reasoning is appropriate. Here I need to mumble about MIME types, but I don't have a clear enough picture and it is a very large digression, getting into how web servers type pages, etc. DELETED: OWL users should therefore be aware that using the owl:Ontology tag to mark a document that does not contain an ontology may cause confusion. --> </p> CHANGE <pre><owl:Ontology rdf:about="http://www.example.org/wine"> <rdfs:comment>An example OWL ontology</rdfs:comment> TO <pre><rdfs:comment>An example OWL ontology</rdfs:comment> CHANGE Importing another ontology brings the entire set of definitions TO Importing another ontology brings the entire set of information REMOVE It is transitive. If X is a subclass of Y and Y a subclass of Z then X is a subclass of Z. NOTE: wine.owl does not import food.owl NOTE: wine.owl does not have a priorVersion NOTE: wine.owl has a different comment NOTE: owl:wine does not have any rdfs:label properties CHANGE: <rdfs:subClassOf rdf:resource="#PotableLiquid"/> TO <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> NOTE: The document is too cavalier about which document the various code sections come from. This needs to be carefully investigated. CHANGE <pre><owl:Class rdf:ID="Grape"> TO <pre><owl:Class rdf:ID="Grape"> ... </owl:Class> CHANGE The wine ontology is designed to work in OWL DL, and as a result individuals like <tt>FormanChardonnay</tt> cannot simultaneously be treated as classes. TO The wine ontology is designed to work in OWL DL, and as a result individuals like <tt>FormanChardonnay</tt> are not simultaneously be treated as classes. CHANGE classes and XML datatypes, </li> TO classes and XML Schema datatypes, </li> CHANGE In OWL, a sequence of statements without an explicit operator represents an implicit conjunction. They apply to their containing element. TO In OWL, a sequence of statements without an explicit operator represents an implicit conjunction. CHANGE <owl:ObjectProperty rdf:ID="hasColor"> <rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" /> <rdfs:range rdf:resource="#WineColor" /> </owl:ObjectProperty> TO <owl:ObjectProperty rdf:ID="hasColor"> <rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" /> <rdfs:range rdf:resource="#WineColor" /> ... </owl:ObjectProperty> NOTE: The cardinality restrictions all need to be changed to look like <span class="highlight"> <owl:Restriction> <owl:onProperty rdf:resource="#madeFromGrape"/> <owl:minCardinality rdf:datatype="&xsd;NonNegativeInteger>1</owl:minCardinality> </owl:Restriction> </span> An entity for xsd should be added. NOTE: wine.owl does not have a locatedIn restriction for wine. CHANGE <pre><owl:Class rdf:ID="Vintage"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> TO <pre><owl:Class rdf:ID="Vintage"> NOTE: Vintage in wine.owl does not have a vintageOf There is no vintageOf property in wine.owl CHANGE We distinguish properties according to whether they relate resources to resources (object properties) or resources to datatypes (datatype properties). TO We distinguish properties according to whether they relate individuals to individuals (object properties) or individuals to datatype values (datatype properties). NOTE: The example of years after 1700 is suspect. NOTE: wines.owl uses incorrect syntax for data values NOTE: The following does not correspond with wines.owl <pre><CaliforniaRegion rdf:ID="SantaCruzMountainsRegion" /> CHANGE A property, P, tagged as transitive satisfies the following axiom: </p> <pre>P(x,y) and P(y,z) -> P(x,z) </pre> TO If a property, P, is tagged as transitive then P(x,y) and P(y,z) implies P(x,z), for any x, y, and z. </p> CHANGE A property, P, tagged as symmetric satisfies the following axiom: </p> <pre>P(x,y) iff P(y,x) </pre> TO If a property, P, is tagged as symmetric then P(x,y) iff P(y,x), for any x and y. </p> CHANGE A property, P, tagged as functional satisfies the following axiom: </p> <pre>P(x,y) and P(x,z) -> y = z </pre> TO If a property, P, is tagged as functional then P(x,y) and P(x,z) implies y = z forall x, y, and z. </p> CHANGE A property, P1, tagged as the <tt>inverseOf</tt> P2, satisfies the following axiom: </p> <pre>P1(x,y) iff P2(y,x) </pre> TO If a property, P1, is tagged as the <tt>inverseOf</tt> P2, then P1(x,y) iff P2(y,x) for all x and y. </p> CHANGE A property, P, tagged as InverseFunctional satisfies the following axiom: </p> <pre>P(y,x) and P(z,x) -> y = z </pre> TO If a property, P, is tagged as InverseFunctional then P(y,x) and P(z,x) implies y = z for all x, y, and z. </p> CHANGE <a id="owl_someValuesFrom" name="owl_someValuesFrom"></a> <tt>owl:someValuesFrom</tt> is similar, but less restrictive. If we TO <a id="owl_someValuesFrom" name="owl_someValuesFrom"></a> <tt>owl:someValuesFrom</tt> is similar in some sense. If we CHANGE Positive integer values other than 0 and 1 are permitted in OWL Full. TO Positive integer values other than 0 and 1 are permitted in OWL DL. CHANGE <h3><a id="hasValue" name="hasValue">hasValue</a> [OWL DL]</h3> TO <h3><a id="hasValue" name="hasValue">hasValue</a></h3> NOTE: There are several other headers that say [OWL DL] nowhere is this convention described. CHANGE ontology. This capability must be used with care. It is fairly easy to create necessarily empty sets when combining a set of distributed definitions. If the combined ontologies are contradictory (all A's TO ontology. This capability must be used with care. If the combined ontologies are contradictory (all A's CHANGE <tbody><tr><th>Relation</th><th>Implications</th></tr> <tr><td>subClassOf</td><td>TexasThings(x) → locatedIn(x,y) & TexasRegion(y)</td></tr> <tr><td>sameClassAs </td><td>TexasThings(x) → locatedIn(x,y) & TexasRegion(y)<br>locatedIn(x,y) & TexasRegion(y) → TexasThings(x)</td></tr> TO <tbody><tr><th>Relation</th><th>Implications</th></tr> <tr><td>subClassOf</td><td>TexasThings(x) implies locatedIn(x,y) and TexasRegion(y)</td></tr> <tr><td>sameClassAs </td><td>TexasThings(x) implies locatedIn(x,y) and TexasRegion(y)<br>locatedIn(x,y) and TexasRegion(y) implies TexasThings(x)</td></tr> CHANGE This brings up an important point. OWL does not have a <em>unique naming</em> assumption. Just because two names are different does not TO This brings up an important point. OWL does not have a <em>unique name</em> assumption. Just because two names are different does not CHANGE confilcts to conflicts CHANGE Classes constructed using the set operations are <em>closed</em>. The members of the class are completely specified by the set operation. This is an important capability. It permits us to state that <tt>WhiteWine</tt> is <em>exactly</em> the TO This construct permits us to state that <tt>WhiteWine</tt> is <em>exactly</em> the THE FOLLOWING is not in wine.owl or food.owl <pre><WineColor rdf:about="#White"> <rdf:label>White</rdf:label> </WineColor> </pre> THE HISTORY section is not useful. THE TERMINAL UML note is not useful. Review of Web Ontology Language (OWL Lite and OWL) Feature Synopsis Version 1.0 We now have Reference, which does not provide complete information about the differences between OWL Lite, OWL DL, and OWL Full, and Guide, which does not provide complete information about the differences between OWL Lite, OWL DL, and OWL Full. Why do we need a third document that does not provide complete information about the differences between OWL Lite, OWL DL, and OWL Full? At least Reference and Guide have other purposes, but this document appears to be only about difference between the sublanguages of OWL. I think that the information in this document should be folded into Reference, which would then be a complete informal reference document for the sublanguages of OWL. I think that this can be done by adding two sections to Reference, one for OWL DL and one for OWL Lite. If this is not deemed to be adequate, then the section in Guide about the sublanguages could also be expanded.
Attachments
- Text/Html attachment: stored
Received on Monday, 30 December 2002 15:21:04 UTC