> -----Original Message-----
> From: Richard Newman [mailto:[EMAIL PROTECTED]
> Sent: 6 July 2008 21:09
> To: Seaborne, Andy
> Cc: Nuutti Kotivuori; [email protected]; public-rdf-dawg-
> [EMAIL PROTECTED]
> Subject: Re: SPARQL and string literal matching woes - spec inconclusive -
> try 2
>
> Andy,
>
> Is this actually true? See the SPARQL Tests section of the table,
> which defines a match for two RDF terms. (Of course, they're not
> RDFterm-equal, so it produces a type error anyway.)
>
> -R
The dispatch to RDFTerm-equals is the place the type error is produced; it's a
catch-all and as such must be last in the table. It is not in the section for
dispatch based on the understood types in the "XPath Tests" nor "XPath
Arithmetic" section. It captures the fact that for two literals "A = B" if
they have the same datatype and lexical form (or lexical form and language tag)
regardless of whether the SPARQL processor understands that datatype.
In that sense, anything has a dispatch entry but this one is different because
it can produce a type error even though it matches, and it must be at the end
of the dispatch possibilities for "=" and "!=". It could equally well have
been defined as partial mapping for the true case, not dispatching if they are
not equal and dropping through to fall off the bottom of the table.
Andy
>
> On 6 Jul 2008, at 11:07 AM, Seaborne, Andy wrote:
>
> > Not trickier - uses a different part of the spec :-)
> >
> > See sec 11 operator dispatch table.
> > http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping
> >
> > Under (minimal) SPARQL,
> >
> > = (value"^^xsd:string , "value" )
> >
> > has no entry in that table. So it's a type error and the FILTER is
> > false.
