W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > March 2011

Re: !=, NOT IN and type errors

From: Jeen Broekstra <jeen.broekstra@gmail.com>
Date: Sat, 26 Mar 2011 16:52:28 +1300
Message-ID: <4D8D62FC.3020306@gmail.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: public-rdf-dawg-comments@w3.org
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".


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


> 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 :)


Received on Saturday, 26 March 2011 03:53:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:11 UTC