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 <a...@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 | ja...@dydra.com | http://dydra.com
