Re: Inequality and type errors

Hi Andy,

I understand now that by handling some of the type errors specified by the spec can be implemented with an extension which would handle these accordingly. But your example with terms from different categories (literals, URIs and blanknodes) can IMO not be explained in line with the spec. The only condition in the specification of RDFterm-equal (which would IMO handle this comparison) for which a type error is defined and give room for an extension, seems to be two literals of differing types: 

    "[...] produces a type error if the arguments are both literal but are not the same RDF term *"

Thanks for your answers
Marcel


> On 29. Oct 2018, at 11:18, Andy Seaborne <andy@apache.org> wrote:
> 
> Hi Marcel,
> 
> It is the FILTER overall that treats treats errors as false - not the operator, not that it matters much here.
> 
> open-eq-08 is making some other assumptions:
> 
> It is using the fact that literals, URIs and blanknodes are disjoint as values in an expression.  :xyz can't not be value-equal to "xyz".
> 
> The manifest entry for this test has some additional data (there ought to be more):
> 
> :open-eq-08 a mf:QueryEvaluationTest ;
>    ...
>    mf:requires mf:StringSimpleLiteralCmp ;
>    mf:requires mf:LangTagAwareness ;
>    mf:requires mf:KnownTypesDefault2Neq ;
>    mf:notable  mf:IllFormedLiteral ;
>    ...
> 
> With langtag awareness (otherwise a processor will throw error on encountering one as a FILTER value):
> 
> | :x2 | "xyz"@en           | :x8 | :xyz               |
> 
> this is SPARQL 1.0 so the test uses RDF 1.0 - lang tag literals do not have a datatype and the notion of "value" isn't really that precise.The test assumes that simple strings (no datatype , no lang tag) and literals with lang tag are disjoint so:
> 
> | :x3 | "xyz"@EN           | :x1 | "xyz"              |
> 
> In
> https://www.w3.org/2001/sw/DataAccess/tests/README
> says that mf:KnownTypesDefault2Neq allows for the processor to know that there are disjoint values spaces: e.g. an xsd:integer but the terms using ^^xsd:integer are illegal lexical forms so don't have an integer value.
> 
>    Hope that helps, at least in part,
>    Andy
> 
> On 27/10/2018 17:08, 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 Tuesday, 30 October 2018 00:15:47 UTC