Re: syntax task force - differences between the two approaches

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


> 
> 
> >  > >
> >>  >Jeremy - incorporates some RDF container vocabulary
> >>  >S&AS   - forbids RDF container vocabulary
> >>
> >>  certainly Full must include the containers, right?  We believe all
> >>  RDF Documents are Full (with the possible exception of those which
> >>  abuse the owl: namespace)
> >
> >>From AS&S: "this abstract syntax should be thought of a syntax for OWL DL"
> >
> >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 Monday, 3 March 2003 17:57:30 UTC