Re: Inequality and type errors

I agree with your reading of the SPARQL definitions.  I took a close look at
the SPARQL definition at
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/ and I describe my
examination here.


The SPARQL defining document
https://www.w3.org/TR/2013/REC-sparql11-query-20130321/ is rather sloppy here
but the intent seems rather clear.   The operator != is defined only on
arguments with certain pairs of types, so other arguments produce a type
error. ("Functions invoked with *an* argument of the wrong type will produce a
type error.", Section 17.2.)  Then the effective boolean value is determined,
which is again a type error (Section 17.2.2).

To find out how FILTER works with a type error it is necessary to look at the
SPARQL algebra definitions.   The FILTER becomes a Filter construct (Section
18.2.2.7) and outside of an OPTIONAL it stays as a Filter construct.  Then
Section 18.5 says that all that matters for Filter is whether the expression
has an effective boolean value of true and a type error is not true.

So
SELECT * WHERE {
    BIND ( "hi" AS ?v1 )
    BIND ( 7 AS ?v2 )
    FILTER ( ?v1 != ?v2 )
}
should produce no results.

But
SELECT * WHERE {
    BIND ( "hi" AS ?v1 )
    BIND ( 7 AS ?v2 )
    FILTER ( ?v1 = ?v2 )
}
should also produce no results!

But there is an out.  Section 17.3.1 says "SPARQL language extensions may
provide additional associations between operators and operator functions; this
amounts to adding rows to the table above."  So a SPARQL implementation is
free to add

A != B otherwise otherwise true xsd:boolean
A = B otherwise otherwise false xsd:boolean

So the test results appear to be incorrect for SPARQL as defined.

However, I expect that all SPARQL implementations include the extensions
above, so the test is not for the SPARQL definition but instead for SPARQL
implementations.


So what should you do?  My advice is to go with the flow.  I don't see that
there is any chance that the tests will be fixed.  There are worse problems in
the SPARQL definition than this one.


peter






On 10/27/18 9:08 AM, Marcel Otto wrote:
> Hi.
> 
> Some of the open-world tests fail on my SPARQL implementation in Elixir [1]. These tests seem to suggest that the != operator should treat type errors as false, although there's no hint on this behaviour in the spec. For example, the open-eq-08 test states that the result for this query:
> 
> PREFIX : <http://example/>
> PREFIX  xsd: <http://www.w3.org/2001/XMLSchema#>
> SELECT *
> {
>     ?x1 :p ?v1 .
>     ?x2 :p ?v2 .
>     FILTER ( ?v1 != ?v2 )
> }
> 
> over this data:
> 
> @prefix : <http://example/> .
> @prefix  xsd: <http://www.w3.org/2001/XMLSchema#> .
> :x1 :p "xyz" .
> :x2 :p "xyz"@en .
> :x3 :p "xyz"@EN .
> :x4 :p "xyz"^^xsd:string .
> :x5 :p "xyz"^^xsd:integer .
> :x6 :p "xyz"^^:unknown .
> :x7 :p _:xyz .
> :x8 :p :xyz .
> 
> should include almost all permutations. I'm not seeing how this behavior can be explained with the spec, which defines != as the fn:not negation of the respective equality comparison according to the types. The equality comparisons are defined to result in almost all cases with different types in a type error. With fn:not defined to produce an error if its argument is an error, all the inequality comparisons in this example should result in a rejection of the solution, which my implementation exactly does. 
> 
> Kind regards
> Marcel Otto
> 
> 
> [1]: https://github.com/marcelotto/sparql-ex
> 
>

Received on Saturday, 27 October 2018 18:15:07 UTC