Re: Semantic of FILTER NOT IN / literal comparison

good morning;

> On 2016-04-18, at 11:08, Andy Seaborne <andy@apache.org <mailto:andy@apache.org>> wrote:
> 
> On 17/04/16 19:59, james anderson wrote:
>> good evening;
>> 
>>> On 2016-04-17, at 19:13, Andy Seaborne <andy@apache.org <mailto:andy@apache.org>> wrote:
>>> 
>>>> which table is this?
>>> 
>>> https://www.w3.org/TR/sparql11-query/#OperatorMapping <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?
> 
> The SPARQL Tests section:
> 
> SPARQL Tests
> A = B <https://www.w3.org/TR/sparql11-query/#rRelationalExpression> RDF term RDF term RDFterm-equal <https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal>(A, B) xsd:boolean
> A != B <https://www.w3.org/TR/sparql11-query/#rRelationalExpression> RDF term RDF term fn:not <http://www.w3.org/TR/xpath-functions/#func-not>(RDFterm-equal <https://www.w3.org/TR/sparql11-query/#func-RDFterm-equal>(A, B)) xsd:boolean

do please forgive me for my lack of insight, but this then together with 17.4.1.7 seems to define rdfterm-equal in terms of “=“ and “=“ in terms of rdfterm-equal.
is that the intent?


> 
>> 
>>> 
>>> 
>>> 
>>> 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>
>>>>> <mailto: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>
>>>>>>> <mailto: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 <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> <mailto:james@dydra.com <mailto:james@dydra.com>> |
>>>>>> http://dydra.com <http://dydra.com/>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> ---
>>>> james anderson | james@dydra.com <mailto:james@dydra.com> <mailto:james@dydra.com <mailto:james@dydra.com>> |  <http://dydra.com/>http://dydra.com <http://dydra.com/>
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> ---
>> james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com <http://dydra.com/>
>> 
>> 
>> 
>> 
>> 
> 



---
james anderson | james@dydra.com <mailto:james@dydra.com> | http://dydra.com <http://dydra.com/>