- From: Smith, Michael K <michael.smith@eds.com>
- Date: Mon, 30 Dec 2002 18:17:55 -0600
- To: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, www-webont-wg@w3.org
- Message-ID: <B8E84F4D9F65D411803500508BE3221412BC0157@USPLM207>
I have broken out Peter's suggestions with dashed lines. My responses follow each suggestion, unless I have simply made the change, in which case the dashed line begins with [DONE]. [DONE ~] means I took the suggestion and modified it. On some of the longer changes I have adopted some of suggestions and bracketed them with ----[DONE subchange]---- ... ----[subchange]---- The modified documents are attached. I need to review the edits more carefully than I have time for tonight, but this is where the document stands. - Mike Michael K. Smith, Ph.D., P.E. EDS - Austin Innovation Centre 98 San Jacinto, #500 Austin, TX 78701 * phone: +01-512-404-6683 * mailto:michael.smith@eds.com ============================================================================ ==== > From: Peter F. Patel-Schneider [pfps@research.bell-labs.com] > Sent: Monday, December 30, 2002 2:21 PM > To: www-webont-wg@w3.org > Subject: review of Reference, Guide, and Features -- snip -- > Review of Web Ontology Language (OWL) Guide Version 1.0 > > NOTE: The example in the Guide does not correspond to the wine.owl file. I assume all of the instances you found are listed below. ---------------------------------------------------------------------------- ---- > NOTE: With all the changes I am suggesting, another round of reviewing is > indicated for this document. I appreciate the extensive review. Perhaps we can get this to the point where a discussion at the face to face will be sufficient. ---------------------------------------------------------------------------- ---- > 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> I was purposely pitching the abstract at a less academic audience. When they read the first paragraph I wanted to provide some motivation to read on. Perhaps I should assume that if they are reading the Guide they are already motivated. I am flexible on this. What do others think? ---------------------------------------------------------------------------- ---- > NOTE: The document is confusing with respect to ontologies and knowledge > bases. I have tried to make the situation clearer. The process of getting to this state was somewhat tortureous, so I expect this can be improved. But I don't find most of the changes to be clearer. In places it is less so. I have tried to make this an OWL document, with reference to RDF as needed. So multiple occurences of "non-OWL RDF documents" and "RDF document" seem confusing. Perhaps they are necessary. I would appreciate some other folks input on this. ---------------------------------------------------------------------------- ---- > 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>. Is point here is that when we see <Winery rdf:ID="ChateauChevalBlanc" /> there is no particular requirement that it have a sibling term in the scope of the <RDF:rdf> tag of the form <owl:Ontology rdf:about="foo"> That is, there is nothing inherent in the instance data that is particular to OWL? And of course, even if this file is marked as an OWL ontology, it can still always be interpreted as RDF? But I remain at a loss here. OWL has a syntax that admits assertions purely about instances. In the sense we have been trying to distinguish the two, such a file would be considered a knowledge base as opposed to an ontology. As we have informally tried to distinguish two fuzzy ends of a spectrum. Ends of a fuzzy spectrum? ---------------------------------------------------------------------------- ---- > 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> I think the suggested change is overly terse. ---------------------------------------------------------------------------- ---- > REMOVE > > <p> > Datatype properties and object properties are collectively the <em>properties</em> of a > class. > </p> Dependent on the change above. ---------------------------------------------------------------------------- ---- > 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> I did not think this was the distinction that we were trying to make between a knowledge base and an ontology. Maybe I have this wrong, but I thought ontology was to knowledge base as database schema is to database. Definitions of classes and relations as opposed to instances. If this is incorrect, then we need a third term. ---[DONE subchange]---- > <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. ----[subchange]---- > 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> [DONE]---------------------------------------------------------------------- ---- > 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> Is OWL Lite just about simpler tools? I thought we were additionaly targetting a more basic audience. Maybe not. ---------------------------------------------------------------------------- ---- > 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> I'm agnostic about the above change re "the existing Description Logic business segment". However, that was inserted based on a previous WG suggestion. ---------------------------------------------------------------------------- ---- > NOTE: Somewhere is needed a good comprehensive description of the OWL Lite, > OWL DL, and OWL Full. In what sense? Or rather, how extensive? I hesitated to embark on this because a good description would include a lot of text describing all of the things you can do in OWL Full. I think of the Guide as more of a primer, with useful examples of all of the common things you might do. Someone will have an opportunity to write the textbook for each of these, including clever ways to say things that may not be very obvious. ---------------------------------------------------------------------------- ---- > 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> Glad you brought this up. Let me confirm: should I say explicitly that the normative OWL XML syntax is RDF/XML? I would be inclined to change this to In this document we present examples using the <a href="http://www.w3.org/TR/REC-rdf-syntax/#grammar">RDF/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 OWL 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. [DONE]---------------------------------------------------------------------- ------- > 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> [DONE, with changes]---------------------------------------------------------- > 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> Changed to In order to write down an ontology that can be interpreted unambiguously and used by software agents we require a syntax and formal semantics for OWL. OWL is a vocabulary extension <a href="http://www.w3.org/TR/rdf-mt/">[RDF Semantics]</a> of RDF. The OWL semantics are defined in <a href="#FormalModel"><i>OWL Abstract Syntax and Semantics</i></a>. [Some changes made]----------------------------------------------------------- > 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> This paragraph seems to take us too much into the weeds. Is this detail needed here? ---------------------------------------------------------------------------- ---- > 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> > I was explicitly told in previous WG email that this form is incorrect. [DONE]---------------------------------------------------------------------- --- > 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 Don't understand this one. I thought that the OWL classes/properties are resources. Why do we want to emphasize them as URI references? ---------------------------------------------------------------------------- ---- > REMOVE > > This is a conventional > OWL declaration, required to introduce the OWL vocabulary. Not true? Or just not necessary? [DONE]---------------------------------------------------------------------- ---- > 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> In the sense that the datatype definitions may not be correct? Or in the sense that we can't reference these defined datatypes using the style of reference I used? ---------------------------------------------------------------------------- ---- > 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 This is not strictly true. Attribute values are not URI references. I was purposely being fuzzy. ---------------------------------------------------------------------------- ---- > 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> > Again, this doesn't seem conventional. Who is right? ---------------------------------------------------------------------------- ---- > 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> Again, I thought empty was not an option. ---------------------------------------------------------------------------- ---- > NOTE: This use of a URI to refer to a document is suspect. Which use? ---------------------------------------------------------------------------- ---- > 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>). > </p> A little redundancy is not a bad thing. I will reread the document as a whole, something I have not done for a while. ---------------------------------------------------------------------------- ---- > 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> A little extra context doesn't hurt. Added '...' after imports. ---------------------------------------------------------------------------- ---- > CHANGE > > Importing another ontology brings the entire set of definitions > > TO > > Importing another ontology brings the entire set of information Seems clumsy. Is there another term, say 'set of assertions' ? ---------------------------------------------------------------------------- ---- > REMOVE > It is transitive. If X is a subclass of Y > and Y a subclass of Z then X is a subclass of Z. Why? [DONE]---------------------------------------------------------------------- ---- > NOTE: wine.owl does not import food.owl [DONE]---------------------------------------------------------------------- ---- > NOTE: wine.owl does not have a priorVersion [DONE]---------------------------------------------------------------------- ---- > NOTE: wine.owl has a different comment [DONE]---------------------------------------------------------------------- ---- > NOTE: owl:wine does not have any rdfs:label properties [DONE]---------------------------------------------------------------------- ---- > CHANGE: > > <rdfs:subClassOf rdf:resource="&food;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. To <rdfs:subClassOf rdf:resource="&food;PotableLiquid"/> [DONE]---------------------------------------------------------------------- ---- > CHANGE > > <pre><owl:Class rdf:ID="Grape"> > > TO > > <pre><owl:Class rdf:ID="Grape"> > ... > </owl:Class> Changed to Grapes are defined in the food ontology: <pre> <owl:Class rdf:ID="Grape"> ... </owl:Class> <pre> <p> And then in the wine ontology we have: </p> <pre> <owl:Class rdf:ID="WineGrape"> <rdfs:subClassOf rdf:resource="&food;Grape" /> </owl:Class> <WineGrape rdf:ID="CabernetSauvignonGrape" /> </pre> [DONE]---------------------------------------------------------------------- ---- > 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. [DONE]---------------------------------------------------------------------- ---- > CHANGE > classes and XML datatypes, </li> > TO > classes and XML Schema datatypes, </li> [DONE]---------------------------------------------------------------------- ---- > 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. [DONE]---------------------------------------------------------------------- ---- > 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. Did this finally get nailed down? Yech. Will change, but not tonight. ---------------------------------------------------------------------------- ---- > NOTE: wine.owl does not have a locatedIn restriction for wine. Does it need it? [DONE] (where did that come from)----------------------------------------------- > 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 Now marked as not in wine.owl. [DONE]---------------------------------------------------------------------- ---- > 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. Again, is it the schema or the reference to it? ---------------------------------------------------------------------------- ---- > NOTE: wines.owl uses incorrect syntax for data values [DONE]---------------------------------------------------------------------- ---- > NOTE: The following does not correspond with wines.owl > <pre><CaliforniaRegion rdf:ID="SantaCruzMountainsRegion" /> [DONE ~]--------------------------------------------------------------------- > 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> [DONE ~]-------------------------------------------------------------------------- ------ > 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> [DONE ~]-------------------------------------------------------------------------- ------ > 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> [DONE ~]-------------------------------------------------------------------------- ------ > 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> > [DONE ~]-------------------------------------------------------------------------- ------ > 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> [DONE ~]------------------------------------------------------------------------ > 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 [DONE]---------------------------------------------------------------------- ---- > 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> The issues list shows this in OWL DL and Full, not OWL Lite. ---------------------------------------------------------------------------- ---- > NOTE: There are several other headers that say [OWL DL] nowhere is this > convention described. <p> When we introduce constructs that are only permitted in OWL DL or OWL Full, they are marked by "[OWL DL]". </p> ---------------------------------------------------------------------------- ---- > 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 I thought it reasonable to emphasize the extra care that is required when you import and extend other ontologies. [DONE]---------------------------------------------------------------------- ---- > 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> [DONE]---------------------------------------------------------------------- ---- > 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 [DONE]---------------------------------------------------------------------- ---- > 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 Agree this could use a change. But are not all of the set operations similarly closed and shouldn't this be stated? How about Classes constructed using the set operations are <em>closed</em>. The members of the class are completely specified by the set operation. The example above states that <tt>WhiteWine</tt> is <em>exactly</em> the [DONE ~]------------------------------------------------------------------------ > THE FOLLOWING is not in wine.owl or food.owl > <pre><WineColor rdf:about="#White"> > <rdf:label>White</rdf:label> > </WineColor> > </pre> Marked as not in wine.owl. ---------------------------------------------------------------------------- ---- > THE HISTORY section is not useful. I am agnostic on this. ---------------------------------------------------------------------------- ---- > THE TERMINAL UML note is not useful. I am agnostic on this. -- snip --
Attachments
- text/html attachment: Guide.html
- application/octet-stream attachment: wine.owl
Received on Monday, 30 December 2002 19:18:10 UTC