Re: REVIEW: current version of Feature Synopsis document

From: Jeff Heflin <heflin@cse.lehigh.edu>
Subject: Re: REVIEW: current version of Feature Synopsis document
Date: Mon, 10 Jun 2002 11:05:25 -0400

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

Unfortunately, this does not work as well as one might want it to, in the
presence of XML Schema union datatypes, for example.  However, I've put the
possibility back in, for now at least.

[...]

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

Commentary added.

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

OK, OK, Done.  BUT NOT THE DEFAULTING!!!!!!!!!!!

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

if the distinction eventually can be eliminated, then OK, let's eliminate
it.  However, I now believe that it cannot be eliminated.

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

In the XML schema for OWL, restrictions are syntactically distinguished.

peter

Received on Friday, 14 June 2002 03:57:20 UTC