REVIEW: current version of Feature Synopsis document

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.

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

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.

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.

5) Section 4: If <fact> ::= <individualFact> then why even have this
production? It has no impact on the syntax. Was this intended to avoid
the recursion Herman mentioned? If so, this is not the effect. 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

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.


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.

Jeff

"Peter F. Patel-Schneider" wrote:
> 
> Here is the current version of the Feature Synopsis document.
> 
> Changes have been made to address comments from the WG.  In particular,
> there has been some renaming of constructs, some extraneous material has
> been removed, some sections have been reordered, and some explanations have
> been added (although not all the ones called for).  Also some of the
> productions have been simplified and a bug in the productions for
> individuals has been fixed.
> 
> This document is also accessible at
>         http://www-db.research.bell-labs.com/user/pfps/owl/owl.html
> 
> peter
> 
>   ------------------------------------------------------------------------
>                Name: owl.html
>    owl.html    Type: Hypertext Markup Language (Text/Html)
>            Encoding: 7bit

Received on Thursday, 6 June 2002 16:11:31 UTC