On 2016-04-16, at 11:55, Andy Seaborne <a...@apache.org
<mailto:a...@apache.org>
<mailto: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 <mailto:ja...@dydra.com>
<mailto:ja...@dydra.com> |
http://dydra.com
