Hi Evrin,
ARQ "knows" that the value spaces of xsd:string and xsd:integer are
disjoint. Therefore, it can implement the = and != operators as an
extension adding:
= xsd:string xsd:integer
!= xsd:string xsd:integer
as always false and true respectively.
However, your analysis is quite correct and now I look at the SPARQL
operator entries (which are from 1.0 ) the two for = and != on unknown
dataypes are wrong and ought to be removed.
Any engine can deduce:
"A"^^:type = "A"^^:type is true
"A"^^:type != "A"^^:type is false
for any datatype, whether it knows anythign about :type or not, because
two identical lexical forms of the same type must be value equals.
But for
"A"^^:type = "B"^^:type
"A"^^:type1 = "A"^^:type2
"A"^^:type != "B"^^:type
etc
there isn't much you can conclude without knowing about datatype and
value spaces.
I think this is what those two entries are getting it - but they aren't
right.
I'll raise an erratum.
Thanks,
Andy
On 22/07/13 19:55, Evren Sirin wrote:
I'm getting the following result with Jena 2.10.1 against an empty ttl file
(0 bytes):
$ bin/sparql --data empty.ttl "ASK { FILTER ('1' != 2) }"
Ask => Yes
This result seems correct intuitively but if I'm reading the SPARQL spec
right the answer should be false.
According to Section 17.4 operator mapping [1], when we have a simple
literal and a numeric literal the != will be mapped to
fn:not(RDFterm-equal(A, B)). The definition of RDFterm-equal [2] says it
"produces a type error if the arguments are both literal but are not the
same RDF term" which is the case here. Section 17.4 also says "Note that
per the XPath definitions, fn:not and op:numeric-equal produce an error if
their argument is an error." Then fn:not(RDFterm-equal('1', 2)) would
produce a type error. If there is a type error, the filter would return
false and the above query should return false too.
I was looking at the DAWG test suite to check if my understanding is
correct but the only relevant test I found (:eq-2-2 in expr-equals manifest
[3]) had a typo and was pointing to the wrong query file (eq-2-1 instead of
eq-2-2).
Is this a bug in ARQ? Or am I misinterpreting the spec?
Thanks,
Evren
[1] http://www.w3.org/TR/2012/PR-sparql11-query-20121108/#OperatorMapping
[2] http://www.w3.org/TR/2012/PR-sparql11-query-20121108/#func-RDFterm-equal
[3]
http://www.w3.org/2001/sw/DataAccess/tests/data-r2/expr-equals/manifest.ttl
