Re: Semantic of FILTER NOT IN / literal comparison

> On 2016-04-16, at 11:55, Andy Seaborne <andy@apache.org> wrote:
> 
> On 16/04/16 07:23, Michael Schmidt wrote:
>> Dear community,
>> 
>> we’ve got a question regarding the semantics of FILTER NOT IN (inspired
>> by
>> http://www.w3.org/2001/sw/DataAccess/tests/data-r2/syntax-sparql1/manifest#sparql11-not-in-02),
>> which boils down to literal equality issues.
>> […]
>> 
>> My questions now are:
>> - What is the expected result of “a”!=1? And why — which of the rules in
>> the operator mapping table would apply here (if any?). The expected
>> result of sparql11-not-in-02 indicates that this neq comparison should
>> evaluate to true rather than error, but I actually do not see why.
> 
> There is no implicit casting in SPARQL.
> 
> If there is no mapping then it is a evaluation error.
> 
> (specific engines may do better - for example the value space of strings and the value space of integers don't overlap so the answer is "false")
>> […]

the handling of comparability in the recommendation has always troubled me.
in the paragraphs on rdfterm-equal, there are the passages

Returns TRUE if term1 and term2 are the same RDF term as defined in Resource Description Framework (RDF): Concepts and Abstract Syntax [CONCEPTS]; produces a type error if the arguments are both literal but are not the same RDF term *; returns FALSE otherwise.

* Invoking RDFterm-equal on two typed literals tests for equivalent values. An extended implementation may have support for additional datatypes. An implementation processing a query that tests for equivalence on unsupported datatypes (and non-identical lexical form and datatype IRI) returns an error, indicating that it was unable to determine whether or not the values are equivalent. For example, an unextended implementation will produce an error when testing either"iiii"^^my:romanNumeral = "iv"^^my:romanNumeral or "iiii"^^my:romanNumeral != "iv"^^my:romanNumeral.

as the first stipulates that a test of the form 1 = 2 must produce a type error, the intent must have been to combine that definition with those which follow from the earlier table, which relates the interpretation in terms of xpath tests, but the recommendation text never explains how.

the passages also leave undefined, how the operator should treat arguments which the same term - even if the datatypes are unknown.
  
> 
>  Andy
> 
> PS You may be interested in the community work to maintain the RDF 1.1 and SPARQL 1.1 tests:

it would be worthwhile to entrain in the tests a clear matrix for combinations of compared data types and values.
as they stand, the open-world tests are so unwieldy, that it is difficult to judge even whether they agree with those aspects of the recommendation which this reader believes to be clearly expressed, let alone what they might imply about those aspects which are inconclusive, inconsistent, or just poorly understood.

there could be some value to draw up a value+type combination matrix for rdfterm-equal with which to both stipulate a minimal semantics and provide a logic for extensions, based upon which to deconstruct the monolithic open-world tests into individual tests, each of which demonstrates a significant combination - or, given the combinatorics, some region of the table.

is there any interest in this?

best regards, from berlin,
---
james anderson | james@dydra.com | http://dydra.com

Received on Saturday, 16 April 2016 10:38:48 UTC