- From: Eric Prud'hommeaux <eric@w3.org>
- Date: Sat, 26 Mar 2011 07:40:59 -0400
- To: Jeen Broekstra <jeen.broekstra@gmail.com>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-dawg-comments@w3.org
* 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