- From: Deborah McGuinness <dlm@ksl.stanford.edu>
- Date: Sat, 05 Oct 2002 08:57:45 -0700
- To: Leo Obrst <lobrst@mitre.org>
- CC: Jeff Heflin <heflin@cse.lehigh.edu>, "Smith, Michael K" <michael.smith@eds.com>, webont <www-webont-wg@w3.org>
Leo Obrst wrote: > Some comments below. > > Leo > > Jeff Heflin wrote: > > > Hi Mike, > > > > Since I will be unable to attend the F2F, here are my comments on the > > Guide. In general, I think it is very good. I haven't had a chance to > > read over other feedback you got, so if there are duplicates here, I > > apologize. > > > > General Comments: > > ------------------- > > - The sections should be numbered > > > > - You should use the common conventions for naming classes and > > properties. People will emulate the examples in this guide, so if you > > use upper case names for everything, that's what people will use > > everywhere. The RDF convention is to use mixed case to separate words in > > an identifier, and to begin class identifiers with capital letters and > > property identifiers with lower case letters. > > > > - You need a section called "Using Ontologies to Describe Data" (perhaps > > between Complex Property Axioms and Usage Examples). This section should > > point out that once an ontology is developed, you will want to describe > > data with it. It can mostly point back to the defining individuals and > > properties of individuals sections, but should have additional material > > on how ordinary documents import ontologies (this is of course still > > TBD). If you put in a placeholder, I'd be happy to contribute the text > > once imports is resolved. > > > > - Assuming we resolve the versioning issues, you'll also need a section > > on "Versioning Ontologies." Once again, I'd be happy to contribute the > > text once the WG agrees on a solution. > > > > Detailed comments: > > --------------------- > > - I think the short history is fine > > > > - The WG should think about whether it wants to advertise particular > > companies (e.g., VerticalNet) in its official documents. I feel > > uncomfortable with this. With the case in point, I think we can talk > > about e-commerce in the abstract without losing much from the document > > I would exclude the specific reference to VerticalNet and just use B2B > (business-to-business) e-commerce. Primarily because this is not now accurate. > VerticalNet sold off its 59 verticals and is now a software provider, rather > than directly a B2B company. I know, because I ran the ontology dept. there > until the dot.com burst. > Giving evidence of the impact without explicitly mentioning the company can be done with a citation to: http://www.ksl.stanford.edu/people/dlm/papers/ontologyBuilderVerticalNet-abstract.html it discusses the use of ontologies in e-commerce and the resulting requirements for ontology environments. this list of requirements was used to seed our requirements document. > > > > > > > - In "The structure of ontologies", last sentence: define "entailed" > > > > - Once the imports and versioning issues have been resolved I'll suggest > > some changes to the "Ontology Headers" section > > > > - In "Defining simple hierarchical named classes" (5th paragraph) you > > say how rdf:resource and rdf:about can be used to refer to names. You > > should explain the resource is used in properties and about is used with > > class membership > > > > - Same section, next paragraph: "...permits the extension of the > > imported definition of x without modifying the original resource" Do you > > mean ontology instead of resource? > > > > - Same section, paragraph 8, "it is always possible to reference a > > resource using its full URI..." You should say that when referencing > > with "resource" or "about" to something from another namespace, you must > > use the full URI. You can only use namespace abbreviations when the > > class or property is an element name. > > > > - In "Defining individuals", 2nd example. type should be prefixed by > > "rdf:" Can't have "VIN:" in the about or resource attribute values > > > > - Same section. You should mention what rdf:type means, thus explaining > > why the two examples are equivalent. > > > > - In "Simple Properties - Defining Properties" Explain in words what a > > domain and range are. Point out that because the Web is an open world, > > these are not used to check data, but instead to infer things. For > > example, if I have W as the subject of a "made-from-grape" predicate but > > do not state that W is a Wine, this is not an error, but instead leads > > to the inference that W must be a Wine. It is only an "error" if this > > inference leads to a logical contradiction. Also mention that multiple > > domains or ranges mean the domain or the range is the intersection of > > all such classes. > > > > - Same section, 6th paragraph: Say what "subPropertyOf" means > > generically. > > > > - Same section, 8th paragraph, "The first subClassOf defines an un-named > > class...": I think you mean "second subClassOf". The first is just a > > subclassof potable-liquid. > > > > - In "Property Characteristics and Restrictions": Shouldn't the axiom > > for TransitiveProperty be "P(x,y) and P(y,z) -> P(x,z)", not iff? Iff > > would imply that for any value pair there was some intermediate value > > that links them, implying that all such properties would have to have an > > infinite set of values or at least be symmetric. > > > > - Same section: Give generic plain English definitions for each of > > TransitiveProperty, SymmetricProperty, FunctionalProperty, and > > InverseFunctionalProperty. Add syntax examples for each (except > > inverseOf, which you already have. > > > > - In "Property Restrictions- allValuesFrom, someValuesFrom": give plain > > English descriptions of the meanings of these terms > > > > - In "Cardinality", you say "We have already seen examples of > > cardinality constraints." Is this right? I didn't see any previous > > examples of cardinality constraints. > > > > - In "Set Operators", pargraph 4, "Classes can be identified as > > closed...": I think this paragraph would be better stated by saying > > something like "The intersectionOf operator takes the intersection of a > > list of classes. Since the Semantic Web is assumed to be open, it is > > important to explicitly state that this list is closed, i.e., all of its > > members are listed. The rdf:parseType="collection" attribute is an RDF > > trick for stating that the content of an element is a closed list of RDF > > resources. In this case, a list of classes." > > > > - Same section, last example about FRUIT with two subclasses: We should > > be clear that this does not have the same meaning as intersectionOf, it > > says that Fruit is a subclassOf the intersection of SweetFruit and > > NonSweetFruit (i.e., it might be smaller than the intersection). Unlike, > > the intersectionOf operator, there might be some instances in this > > intersection which are not Fruit. I also think this example should be > > moved immediately after we discuss intersectionOf, instead of after > > Union. > > > > - In "Disjoint Classes", last example: You ask if it is permitted. I > > don't think so. First of all, having oneOf as a subelement to > > disjointWith violates RDF striping rules (a class should go here). Now > > if you wrap the oneOf in <Class> and </Class> tags, it should be okay > > as far as RDF is concerned but I don't think it will have the meaning > > you intended. First of all, oneOf takes a list of instances as its > > arguments, but you are providing classes. Whether or not this is legal > > depends on the resolution of one of our outstanding contentious issues > > (classes as instances). However, let's assume it is resolved in favor of > > classes as instances. Then I would think it means that the classes MEAT, > > FOWL, etc. cannot be members of EDIBLE-THING, but does not say anything > > about their instances. That is, if Beef was a type of Meat then it could > > also be a type of Pasta without contradicting your definition, but MEAT > > could not be a type of Pasta. > > > > - In "Complex Property Axioms": You say that if you combined the two > > restrictions it would "imply that all burgundies are dry" but the first > > restriction already does this alone (i.e, every burgundy must have a > > "Dry" value for SUGAR). It seems that the second restriction only says > > that they can't have any other values as well. > > > > - In "Usage Examples" I have the same uneasiness about referencing > > particular wine portals in a W3C spec. Is it really necessary? people had asked for concrete examples thus the references. i am not aware of anyone in the group who has any affiliations to the ones cited. in particular, they were chosen because they came up as top hits on google searches. i think we need some examples. > > > > - I'm not sure if the "Wine Agent" example adds a whole lot of value to > > the document. this was in response to requests for how this can work today on the web. if someone prefers/likes another slant, just let us know. > > > > - In "Appendix B": I think the syntax for saying hasSubArea is a > > transitive property should be: > > > > <owl:ObjectProperty rdf:ID="hasSubArea"> > > <rdf:type resource="http://www.w3.org/??/owl#TransitiveProperty"> > > </owl:ObjectProperty> > > > > Jeff > > > > "Smith, Michael K" wrote: > > > > > > I am not sure how 2 guides got in there. A slip of the mouse. > > > Here is what should have been included: > > > > > > <<Guide.html>> <<wines.owl>> > > > - Mike > > > > > > ------------------------------------------------------------------------ > > > Name: Guide.html > > > Guide.html Type: Hypertext Markup Language (text/html) > > > Encoding: quoted-printable > > > > > > Name: wines.owl > > > wines.owl Type: unspecified type (application/octet-stream) > > > Encoding: quoted-printable > > > Download Status: Not downloaded with message > > -- > _____________________________________________ > Dr. Leo Obrst The MITRE Corporation > mailto:lobrst@mitre.org Intelligent Information Management/Exploitation > Voice: 703-883-6770 7515 Colshire Drive, M/S W640 > Fax: 703-883-1379 McLean, VA 22102-7508, USA -- Deborah L. McGuinness Knowledge Systems Laboratory Gates Computer Science Building, 2A Room 241 Stanford University, Stanford, CA 94305-9020 email: dlm@ksl.stanford.edu URL: http://ksl.stanford.edu/people/dlm (voice) 650 723 9770 (stanford fax) 650 725 5850 (computer fax) 801 705 0941
Received on Saturday, 5 October 2002 11:54:50 UTC