Re: Semantic of FILTER NOT IN / literal comparison

Yes - that text is a bit confusing.

The key point is that "RDFterm-equal" is not the "=" operator.  It is 
the last entry in the operator dispatch table, so it is chosen if all 
the required equalities datatypes don't match the test.

Then RDFTerm-equal is the minimal test left - URIs and blank nodes test 
(sameTerm), as do literals because for any datatype, if two literals are 
sameTerm that must be same value. anythign else is "unknown" and it's an 
error, and the extension point for additional datatypes and tests. 
sameTerm is closed - it would return false in that case.

 Andy

On 16/04/16 11:38, james anderson wrote:
>
>> 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 Sunday, 17 April 2016 12:50:02 UTC