Re: Semantic of FILTER NOT IN / literal comparison

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
>>
>> [[
>> 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



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