Re: syntax task force - differences between the two approaches

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

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

Professor James Hendler
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)

Received on Monday, 3 March 2003 18:26:07 UTC