

Re: Guide: Version for F2F

From: Jeff Heflin <heflin@cse.lehigh.edu>
Date: Thu, 03 Oct 2002 14:52:28 -0400
Message-ID: <3D9C91EC.CFBD216D@cse.lehigh.edu>

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

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.

between Complex Property Axioms and Usage Examples). This section should
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

- 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
inference leads to a logical contradiction. Also mention that multiple
all such classes.

- Same section, 6th paragraph: Say what "subPropertyOf" means

- 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

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

- I'm not sure if the "Wine Agent" example adds a whole lot of value to
the document.

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


"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
Received on Thursday, 3 October 2002 14:52:35 GMT
