good evening; > On 2016-04-17, at 14:49, Andy Seaborne <a...@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 <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 >> >> >> >> >> >> > > --- james anderson | ja...@dydra.com | http://dydra.com
