Re: !=, NOT IN and type errors

* Jeen Broekstra <jeen.broekstra@gmail.com> [2011-03-26 16:52+1300]
> Thanks for the response Andy.
> 
> On 26/03/2011 02:02, Andy Seaborne wrote:
> 
> >For the expression;
> >
> >"foo"^^xsd:string != "10"^^xsd:integer
> >
> >then a minimal SPARQL 1.0 query processor is not required to know
> >that the value spaces of xsd:string and xsd:integer are disjoint.
> >For a processor that does not know this, the result of the comparison
> >is "unknown" and an error is raised. If the processor did know they
> >are disjoint, then it can return "true" -- such behavior would be
> >adding a row to the dispatch table for functions for "xsd:string !=
> >xsd:integer".
> 
> [snip]
> 
> >It's the additional fact of xsd:string and xsd:integer having
> >disjoint value spaces that is key here.
> 
> Ok, with your explanation in hand I have done another dive into the
> specs. It seems I have misread the definition of RDFterm-equal
> slightly: the fact that it expects one to do a value-based
> comparison on typed literals is rather well hidden (it's mentioned
> in a footnote, basically).
> 
> May I suggest that the section on RDFterm-equal is reworded to make
> it clearer what one should do with datatyped literals? The way it
> now reads makes it rather easy to assume you should always apply the
> definition of Literal Equality in RDF Concepts (section 6.5.1).
> Clearly (well, not quite so clearly IMHO) that's not the case for
> datatyped literals.

I suspect that the issue lies with the way the way the operator
mapping is specified. §16.3 ¶1 says
[[
When selecting the operator definition for a given set of parameters,
the definition with the most specific parameters applies. … The table
is arranged so that the upper-most viable candiate is the most
specific. Operators invoked without appropriate operands result in a
type error.
]] — http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping

Entries for the supported "=" operands, e.g.
  A = B   numeric   numeric   op:numeric-equal(A, B)       xsd:boolean
preceed the catch-all
  A = B   RDF term  RDF term  RDFterm-equal(A, B)          xsd:boolean
  A != B  RDF term  RDF term  fn:not(RDFterm-equal(A, B))  xsd:boolean

so RDFterm-equal is responsible only for non-literal terms and the
literals which are not known to be equivalent. The footnote to which
you refer is intended to help illustrate this effect, but doesn't
change the definition of RDFterm-equal (i.e. if they're both literal,
throw a type error).

§16.3.1 Operator Extensibility preceeds §16.4 Operator Definitions and
is intended to illustrate the effect of extending the set of operator
functions, the footnote illustrates the effects of extensibility on
how and when RDFterm-equal is called.

With all of these fabulous candidates laid out in front of you, can
you suggest a change to one or more which will make this clearer?


> [snip]
> 
> >We would be grateful if you would acknowledge that your comment has
> >been answered by sending a reply to this mailing list.
> 
> I am satisfied with the response.
> 
> Also, I appreciate you taking the time in explaining that basically
> I just misread the spec :)
> 
> 
> Regards,
> 
> Jeen
> 

-- 
-ericP

Received on Saturday, 26 March 2011 11:41:35 UTC