Re: Inequality and type errors

Hi Andy.

> On 29. Oct 2018, at 11:27, Andy Seaborne <andy@apache.org> wrote:
> 
> 
> On 29/10/2018 02:07, Marcel Otto wrote:
>> Hi Peter,
>> thanks for your answer. I simply thought implementations should strive to make the test suites pass and was wondering how others did it. Although it’s quite unsatisfactory, you’re probably right in your advice, since I've meanwhile discovered more problems within the open-world test suite:
>> - date-1 and date-2 together seem to suggest that comparing a xsd:date with timezone to a xsd:date without a timezone should result in a type error, since "2006-08-23"^^xsd:date = "2006-08-23Z"^^xsd:date should not hold according to date-1, but "2006-08-23"^^xsd:date != "2006-08-23Z"^^xsd:date should not hold according to date-2. I also can’t find any hint for this behavior in the specs too.
> 
> This is from "XPath and XQuery Functions and Operators" and the definitions there of comparison.
> 
> Date/dateTime values, one with timezone and timeout that are far apart (14 hours IIRC) can be compared but if they are close, the comparison isn't defined.

Ok, didn’t notice that. Thanks for the clarification.

>> There is no specific operator mapping defined for xsd:date, which means RDFterm-equal would be applied and they should be unequal according to the differing lexical representation of the literals. Even op:date-equal from the XPath and XQuery Functions and Operators spec does not define such behaviour.
>> - I also find open-eq-06 very perplexing, which states that literals of unknown types should result in a type error. Again, I couldn’t find any explanation of this very contra-intuitive behavior in the SPARQL spec or the RDF spec on which it refers to via RDFterm-equal which should be applied in this case.
> 
> A processor without knowledge of t:type1 can't determine is "a"^^t:type1 is the same value or not as "b"^^t:type1. c.f. "001" and "1" are valid xs:integer but different lexical forms.
> 
> It can say "a"^^t:type1 = "a"^^t:type1 but the test does not identify not-equals is false from from error/unknown on "=“.

I understand. But this effectively means that the definition of A != B for generic RDF terms from the Operator Mapping table in 17.3 as fn:not(RDFterm-equal(A, B)) no longer holds. (Regarding my assumption of a type error: false seemed to make even less sense with type errors being the extension point.)

Marcel

> 
>    Andy
> 
>> Kind regards
>> Marcel
>>> On 27. Oct 2018, at 20:14, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>> 
>>> 
>>> 
>>> 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
>>>> 
>>>> 
>