Re: Semantic of FILTER NOT IN / literal comparison

good evening;

> On 2016-04-17, at 19:13, Andy Seaborne <andy@apache.org> wrote:
> 
>> which table is this?
> 
> https://www.w3.org/TR/sparql11-query/#OperatorMapping
> 
> [[
> The following table associates each of these grammatical productions with the appropriate operands and an operator function defined by either XQuery 1.0 and XPath 2.0 Functions and Operators [FUNCOP] or the SPARQL operators specified in section 17.4.
> ]]

where, again, is the definition in 17.4.1.7 intended to fit into that table?

> 
> 
> 
> On 17/04/16 17:53, james anderson wrote:
>> good evening;
>> 
>>> On 2016-04-17, at 14:49, Andy Seaborne <andy@apache.org
>>> <mailto:andy@apache.org>> wrote:
>>> 
>>> Yes - that text is a bit confusing.
>> 
>> yes, a bit.
>>> 
>>> The key point is that "RDFterm-equal" is not the "=" operator.
>> 
>> given that statement, what does the passage
>> 
>>   "xsd:boolean RDF term term1 = RDF term term2”
>> 
>> in the definitionof rdfterm-equal mean?
>> 
>>> It is the last entry in the operator dispatch table,
>> 
>> which table is this?
>> 
>>> 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.
>> 
>> this is still confusing.
>> sorry, but it is.
>> 
>>> 
>>> Andy
>>> 
>>> On 16/04/16 11:38, james anderson wrote:
>>>> 
>>>>> On 2016-04-16, at 11:55, Andy Seaborne <andy@apache.org
>>>>> <mailto: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 <mailto:james@dydra.com> |
>>>> http://dydra.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> ---
>> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com
>> 
>> 
>> 
>> 
>> 
> 
> 

---
james anderson | james@dydra.com | http://dydra.com