W3C home > Mailing lists > Public > public-sparql-dev@w3.org > April to June 2016

Re: Semantic of FILTER NOT IN / literal comparison

From: Andy Seaborne <andy@apache.org>
Date: Sun, 17 Apr 2016 18:13:18 +0100
To: public-sparql-dev@w3.org
Message-ID: <5713C42E.2080302@apache.org>
 > 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.
]]



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
>
>
>
>
>
Received on Sunday, 17 April 2016 17:13:49 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 17 April 2016 17:13:50 UTC