Re: Inequality and type errors

Hi Marcel,

You're quite correct that in a strict interpretation of the spec these test
cases have issues. For what it's worth, the Working Group was aware of this
at the time and used several annotations in the test manifest to 'clarify'
this. This is documented here:
https://www.w3.org/2001/sw/DataAccess/tests/README , see the bottom of the
page ('Test annotations').

IIRC this was done because it was recognized that in practice, most SPARQL
processors would add a minimal extension of this form in the evaluation
semantics.

So if your goal is to write a strictly minimal SPARQL engine, you should
probably skip those tests in the suite that are annotated with these
markers. Otherwise, just add these extensions, as they are, in practice,
implemented by pretty much any SPARQL processor.

Cheers,

Jeen


On Sun, Oct 28, 2018 at 3:10 AM Marcel Otto <marcelotto.de@googlemail.com>
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
>
>
>