Re: REVIEW: current version of Feature Synopsis document

From: Jeff Heflin <heflin@cse.lehigh.edu>
Subject: REVIEW: current version of Feature Synopsis document
Date: Thu, 06 Jun 2002 16:11:28 -0400

> Here is my official review:
> 
> In general I like the document, but have a few issues.
> 
> 1) I think section 1 (2nd to last paragraph) needs a few sentences that
> describe the particular flavor of BNF you're using. In particular, it
> should explain the difference between [stuff] and {stuff}. I didn't even
> notice these the first time through, and only recently realized that []
> probably means optional and {} probably means 0,1, or many.

Agreed.  I have added something to the end of section 1.

> 2) Section 3.1: Replace "conjunction of a collection of superclasses,
> property restrictions, and descriptions" with "conjunction of
> descriptions (which are described in section 3.3)."

OK.

> 3) Did you mean for <dataLiteral> ::= <datatypeId> <lexical-form> to
> imply that all literals must be explicitly typed? If so, I am strongly
> opposed to this.

Yes, this is what is implied here.  Go ahead and oppose, but be prepared to
come up with a solution.  :-)  I have included a disclaimer.

> 4) Section 3.3: Need to add [super=<classId>] here since you removed it
> from the axiom production in 3.1. Even though this is logically
> equivalent to SubClass with a description UnionOf(<classId>) or
> IntersectionOf(<classId>), I think it's an important.

Why do you think that this is a change?  The grammar still allows

SubClass(Foo Person restriction(friend atleast(2)))

> 5) Section 4: If <fact> ::= <individualFact> then why even have this
> production? It has no impact on the syntax. 

Not true.  There are other options for <fact>.

> Was this intended to avoid
> the recursion Herman mentioned? If so, this is not the effect. 

The change was made to disallow sameIndividual inside Individual(...)

> I think
> his confusion is that <fact> (and now <individualFact>) both correspond
> to a collections of assertions about an individual (each of which seems
> like it could be called a fact). We need to find a better name for this
> collection. RDF calls it a description, but that would probably add to
> the confusion, since we're using description elsewhere. We could have
> classDescription and IndDescription

I don't like individualFact, but Description would be worse.

> Finally, I do not feel that some of my concerns originally raised in my
> first response were addressed:
> 
> 6) I'd like to see the syntax for classes really simplified. In stead of
> EquivalentClass and SubClass, why not just have Class and a qualifier
> "equivalent" or "complete" or whatever name is approriate? In the XML
> syntax, this can become an optional attribute, with the most common
> alternative (I assume SubClass) as the default. That is, have
> 
> <axiom> ::= Class ( [equivalent | subclass] <classID> {<description>} )
> 
> replace the first to axioms in 3.1.

How is this a simplification?  It replaces two tokens by three.
 
> 7) Having to write DataProperty or IndividualProperty seems really
> awkward to me. Why can't we just write Property and let a parser figure
> out which one it is? It should be easy enough. If the range is a
> dataRange then its a DataProperty, otherwise its an IndividualProperty.
> This would change the the beginning of each of the first two axioms in
> 3.2 to :
> 
> <axiom> ::= Proprerty ( ...
> 
> but otherwise leave them unchanged. I believe this preserves the desired
> separation between classes and datatypes but reduces the cognitve load
> of the user by forcing parsers to be a little smarter in determing which
> properties are of which type.

This would only work if the parser technology was up to snuff.  However, I
don't believe that XML Schema is up to this.

However, what happens if there is no way to distinguish?  For example,
what is 
     Property(foo super=bar)
or
     Property(foo Functional)

In fact, in the XML Schema, restriction is similarly divided, and this
division should probably show up here.

> Jeff

peter

PS:  A revised version is available at

     http://www-db.research.bell-labs.com/user/pfps/owl/owl.html

Received on Friday, 7 June 2002 09:23:30 UTC