- From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
- Date: Fri, 07 Jun 2002 09:23:18 -0400
- To: heflin@cse.lehigh.edu
- Cc: www-webont-wg@w3.org
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