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>&lt;owl:Class&gt;...&lt;/owl:Class&gt;</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>&lt;rdfs:Class&gt;...&lt;/rdfs:Class&gt;</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>&lt;owl:Restriction&gt;
&lt;owl:onProperty rdf:resource="#father"/&gt;
&lt;owl:cardinality&gt;1&lt;/cardinality&gt;
&lt;/owl:Restriction&gt;</pre>
<p>we would have to write<br>
</p>
<pre>&lt;owl:Restriction owl:cardinality="1"&gt;
&lt;owl:onProperty rdf:resource="#father"/&gt;
&lt;/owl:Restriction&gt; </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>&lt;xsd:decimal rdf:value="10.5"/&gt;</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>&lt;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#" &gt;
</pre>
TO
<pre>&lt;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#" &gt;
</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>&lt;!DOCTYPE owl [
&lt;!ENTITY vin "http://www.example.org/wine#" &gt;
&lt;!ENTITY food "http://www.example.org/food#" &gt; ]&gt;
</pre>
TO
<pre>&lt;!DOCTYPE owl [
&lt;!ENTITY vin "#" &gt;
&lt;!ENTITY food "food#" &gt; ]&gt;
</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>&lt;owl:Ontology rdf:about="http://www.example.org/wine"&gt;
</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>&lt;owl:Ontology rdf:about=""&gt;
</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>&lt;owl:Ontology rdf:about="http://www.example.org/wine"&gt;
&lt;rdfs:comment&gt;An example OWL ontology&lt;/rdfs:comment&gt;
TO
<pre>&lt;rdfs:comment&gt;An example OWL ontology&lt;/rdfs:comment&gt;
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:
&lt;rdfs:subClassOf rdf:resource="#PotableLiquid"/&gt;
TO
&lt;rdfs:subClassOf rdf:resource="&food;PotableLiquid"/&gt;
NOTE: The document is too cavalier about which document the various code
sections come from. This needs to be carefully investigated.
CHANGE
<pre>&lt;owl:Class rdf:ID="Grape"&gt;
TO
<pre>&lt;owl:Class rdf:ID="Grape"&gt;
...
&lt;/owl:Class&gt;
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
&lt;owl:ObjectProperty rdf:ID="hasColor"&gt;
&lt;rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" /&gt;
&lt;rdfs:range rdf:resource="#WineColor" /&gt;
&lt;/owl:ObjectProperty&gt;
TO
&lt;owl:ObjectProperty rdf:ID="hasColor"&gt;
&lt;rdfs:subPropertyOf rdf:resource="#hasWineDescriptor" /&gt;
&lt;rdfs:range rdf:resource="#WineColor" /&gt;
...
&lt;/owl:ObjectProperty&gt;
NOTE: The cardinality restrictions all need to be changed to look like
<span class="highlight"> &lt;owl:Restriction&gt;
&lt;owl:onProperty rdf:resource="#madeFromGrape"/&gt;
&lt;owl:minCardinality rdf:datatype="&xsd;NonNegativeInteger&gt;1&lt;/owl:minCardinality&gt;
&lt;/owl:Restriction&gt; </span>
An entity for xsd should be added.
NOTE: wine.owl does not have a locatedIn restriction for wine.
CHANGE
<pre>&lt;owl:Class rdf:ID="Vintage"&gt;
&lt;rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/&gt;
TO
<pre>&lt;owl:Class rdf:ID="Vintage"&gt;
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>&lt;CaliforniaRegion rdf:ID="SantaCruzMountainsRegion" /&gt;
CHANGE
A property, P, tagged as transitive
satisfies the following axiom:
</p>
<pre>P(x,y) and P(y,z) -&gt; 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) -&gt; 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) -&gt; 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) &#8594; locatedIn(x,y) &amp; TexasRegion(y)</td></tr>
<tr><td>sameClassAsÂ Â </td><td>TexasThings(x) &#8594;
locatedIn(x,y) &amp; TexasRegion(y)<br>locatedIn(x,y) &amp;
TexasRegion(y) &#8594; 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>&lt;WineColor rdf:about="#White"&gt;
&lt;rdf:label&gt;White&lt;/rdf:label&gt;
&lt;/WineColor&gt;
</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.