Re: syntax task force - differences between the two approaches

On March 3, Jim Hendler writes:
> 
> At 17:46 +0000 3/3/03, Ian Horrocks wrote:
> >On February 27, Jim Hendler writes:
> >>
> >>  At 17:22 +0000 2/27/03, Ian Horrocks wrote:
> >>  >On February 26, Jim Hendler writes:
> >>  >>  At 10:11 -0500 2/26/03, Peter F. Patel-Schneider wrote:
> >>  >>  >Here is my summary of the differences between the two 
> >>approaches.  I may be
> >>  >>  >missing some differences.
> >>  >>  >
> >>  >>  >peter
> >>  >>
> >>  >>  A couple of comments on a few of these:
> >>  >>
> >>  >>  >
> >>  >>  >
> >>  >>  >Substantive Differences in Abstract Syntax
> >>  >>  >
> >>  >>  >
> >>  >>  >
> >>  >>  >Jeremy - can name data valued oneOfs
> >>  >>  >S&AS   - can't name data valued oneOfs
> >>  >>
> >>  >>  IMHO this could be a valuable construct - for example the reference
> >>  >>  manual has an example of the list of "0 15 30 40" which is the
> >>  >>  possible numeric tennis scores.  Being able to name that list would
> >>  >>  be valuable in a system reasoning about sports statistics (which is
> >>  >>  one of the actual use cases in my research group - we're doing
> >>  >>  client-side presentation of sports information based on various
> >>  >>  ontologies of sport).
> >>  >
> >>  >Naming it seems like a bad idea. It would effectively introduce an
> >>  >OWL mechanism for defining datatypes, whereas we are supposed to be
> >>  >relying on XMLS for that.
> >>
> >>  Ian - not the same - this is a specific subset in which case all
> >>  members are explicitely mentioned -- this is doable in the xsd:
> >>  world, and we have an easy place to put it.  It is not the same as
> >>  being able to say "a real number greater than 15"  which could never
> >>  be said in this form.  Also, the datatype reasoning is easy in this
> >>  case because it is a closed and enumerated list, so the cardinality
> >>  issues are solvable.
> >>    so it seems a valuable feature, adds a small amount of something we
> >>  wish we could provide, and doesn't cause serious problems to DL
> >>  reasoners.
> >
> >As far as I can understand it, what you just said is "yes it is a
> >mechanism for defining datatypes, but one that IMHO is easy to reason
> >with".
> >
> >I am not in favour of introducing such an extension at this stage, and
> >while it does appear that it would be relatively harmless, I am not
> >convinced that all the ramifications have been considered. E.g., if we
> >introduce a sameDatatypeAs property and use it to define e.g.,
> >sameDatatypeAs(D1,{0, 15, 30, 40}), then presumably adding
> >sameDatatypeAs(D2,{15, 0, 30, 40}) would entail sameDatatypeAs(D1,D2)?
> >If we add sameDatatypeAs(D3, {0,...,255}), would that entail some kind
> >of equivalence between D3 and xsd:byte?
> >
> >We would need to make sure that the semantics support these kinds of
> >entailment, and given the relative complexity/fragility of our
> >layering compromise, I don't believe that we should impose this
> >additional burden.
> >
> >Ian
> >
> 
> I must have missed it - where did this "sameDatatypeAs" come from?  I 
> agree with you that it would be a bad thing to add.   I'd still like 
> the named set in Lite.  You point out in your previous message that I 
> could create it with unionOf in DL, so it can't be a syntactically 
> bad thing.

How are you going to name it? Whatever mechanism you use (and
something like sameDatatypeAs seemed the obvious one), the name will
have to be semantically interpreted and this could result in
additional entailments.

Creating such a named object is NOT the same as naming a disjunction
of restrictions. For one thing you would need to deal with the
semantics and possible entailments as mentioned above. If you name the
datatype, you could then use it e.g. in an allValuesFrom restriction,
and this would not be decomposable in the same way as a someValuesFrom
restriction.

In the end, the feature you are asking for here MAY turn out to be
relatively harmless, but this needs to be thoroughly investigated
before we consider adding it to the language.

>   - JH
> p.s. I seem to remember not long ago someone saying that we should 
> think more about the implementation and use of our language. 

YES, and one of the things I meant by this is that we should think
VERY carefully before adding features to the language, because adding
even small and apparently harmless features can sometimes have a large
impact on the implementability of the language.

> However, every time I claim I need something because it is useful to 
> the tasks I do, I seem to be told by you that "adding it at this 
> stage" is a bad idea -- I dont' see how we can have it both ways.  My 
> group has started using OWL/OWL Lite in many projects, we have found 
> this would be a useful feature in our implementations, we argue for 
> it on the basis of use cases and implementor need, and you don't like 
> it, so you argue against it on theoreticial instead of 
> implementational grounds.  Please choose one approach or another...

I believe that I have been consistent in arguing for implementor needs
- I have fought long and hard for a language that had a well defined
semantics, known computational complexity and a well understood
implementation pathway (e.g., known reasoning algorithms).

There will always be pressure from users to add features - and what
you describe seems like a typical user need and not an implementor
need. Of course we shouldn't ignore user needs, but we should be very
careful to ensure that they are real (i.e., that they what they are
asking for makes sense and really does show up a weakness of the
language) and that we understand the impact that they would have on
the implementability of the language.

Ian

> 
> -- 
> Professor James Hendler				  hendler@cs.umd.edu
> Director, Semantic Web and Agent Technologies	  301-405-2696
> Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
> Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
> http://www.cs.umd.edu/users/hendler
>

Received on Tuesday, 4 March 2003 08:43:26 UTC