Re: REVIEW: current version of Feature Synopsis document

Thanks for your responses, Peter. Please see my reply to some of the
issues below.

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

<snip>

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

Well, doesn't DAML+OIL allow this? In most cases, range information
should be available to determine the datatype of property. When absent,
we could say the datatype is a disjunction of all datatypes that include
that lexical-form, allowing information gained later to help constrain
the literal to a specific type. Maybe this needs to be raised as an
issue?

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

Well at first I though there wouldn't be any way to say something like
"The class triangle is equivalent to the subclass of polygons that have
three sides," but now I see how:

EquivalentClass(Triangle Polygon restriction(sides exactly(3)))

So, I withdraw this suggestion.

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

Oh, I see the last two productions at the end of the section now. Still,
this seems like an unusual use of BNF, and I imagine is likely to
confuse others as well. Maybe a brief comment can preemt such confusion.

<snip>

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

It is simpler because it is more frame/object-oriented like. Also, Class
is a simpler token than EquivalentClass and SubClass. Finally, I imagine
EquivalentClass will be used rarely, so if you make subclass a default
value, then users will only really need two of the tokens, with the
third one (subclass) only provided for symmetry.

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

On second thought, I probably shouldn't have brought up parsers since
after all this is an "abstract" syntax. What I should have said that
there should be algorithmic way to determine whether a property was Data
or Individual. I don't think XML Schema should constrain the abstract
syntax, and given the group's resolutions on OWL syntax, I don't think
it should constrain the physical syntax of OWL either. However, once we
get to physical syntax issues, I don't see why additional OWL code can't
handle the problem. There are lots of things in OWL that XML Schema (or
RDF for that matter) is not up to.

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

This is an interesting question, and might be the one reason for needing
to explicitly say DataProperty or Individual here, but I'd like to sure
that it is absolutely necessary before agreeing to complicate the
syntax. My question is, if a property does not have a range, will the
distinction matter to a decription logic reasoner? That is if a
"datatype" property does not actually have a datatype, then will the
same complications arise as with ordinary datatype properties?

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

Could you explain how XML Schema has a similar division? I don't really
have time to search through the spec right now.

> > Jeff
> 
> peter
> 
> PS:  A revised version is available at
> 
>      http://www-db.research.bell-labs.com/user/pfps/owl/owl.html

Received on Monday, 10 June 2002 11:05:30 UTC