- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Sat, 27 Oct 2018 11:14:42 -0700
- To: Marcel Otto <marcelotto.de@googlemail.com>, public-sparql-dev@w3.org

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