As usual I bow down to your infinite knowledge and wisdom ;) Thanks for setting me straight on this one
Rob On 1/24/13 7:46 PM, "Andy Seaborne" <[email protected]> wrote: >Yes - fun isn't it? :-) > >Both are "error" because there is no "=" installed that works on >non-integer integers. "abc"^^xsd:integer is treated like any unknown >datatype. Most value operations are error. > > >Except for >"abc"^^xsd:integer = "abc"^^xsd:integer > >Think of this as > >"abc"^^dt:unknown = "abc"^^dt:unknown > >Even without knowing anything about the datatype dt:unknown, the fact >they are the same lexical form means they must be the same value. A >datatype is a functional mapping from lexical form to the value space. > >This is the observation behind what Paul says point about RDFTerm-equal >and that's captured in the operator dispatch table in the spec. > >(as well as covering <uri> = <uri> and bNode = bnode) > > Andy > >On 24/01/13 19:21, Paul Gearon wrote: >> While the datatype of "abc"^^xsd:integer and "xyz"^^xsd:integer is set >>to >> "xsd:integer", the fact that the values are not in the domain of those >> types should make the types "RDF terms" instead of "numeric". In that >>case, >> the appropriate operations are not op:numeric-equal(), but RDFterm-equal >> and fn:not(RDFterm-equal). >> >> The definition of RDFterm-equal says that it returns true only if the >> compared terms are the same term. If both terms are literals but not the >> same term, then they produce a type error. This is consistent with the >> cases you show in the first example (unbound), since the compared values >> are different terms. >> >> The second example compares values that are literal and are the same >>term. >> This means that RDFterm-equals returns "true", and fn:not(RDFterm-equal) >> returns false. >> >> Paul >> >> >> >> On Thu, Jan 24, 2013 at 1:57 PM, Rob Vesse <[email protected]> wrote: >> >>> Hey All >>> >>> A colleague was perplexed by some of the behavior mandated in the DAWG >>> tests (for SPARQL 1.0) which appear to not entirely coincide with the >>>spec. >>> The first example I think I can explain so can someone (Andy?) >>>confirm my >>> understanding. The second example I am somewhat stumped on so I'll >>>come to >>> that and my best guess of what is happening in question and hope >>>someone >>> else can explain why this happens. >>> >>> Example 1 >>> >>> Consider the malformed literals "abc"^^xsd:integer and >>>"xyz"^^xsd:integer >>> >>> If you do the following queries both will return false which would >>>seem a >>> little counter-intuitive >>> >>> ASK WHERE { FILTER("abc"^^xsd:integer = "xyz"^^xsd:integer) } >>> >>> ASK WHERE { FILTER("abc"^^xsd:integer != "xyz"^^xsd:integer) } >>> >>> While this is counter-intuitive (you usually expect = and != to be >>> reflexive) I understand why this happens. In both cases we are >>>selecting >>> which operator to use from the operator mapping and we will be >>>selecting >>> op:numeric-equals() in the first case and fn:not(op:numeric-equals()) >>>in >>> the second. In both cases we try and do numeric equality on the >>>arguments >>> but they are not valid numbers so this gives a type error. fn:not() >>>of an >>> error is still an error. Since FILTER treats error as false both >>>queries >>> yield false. >>> >>> This can perhaps be better demonstrated by the following query: >>> >>> SELECT (?a = ?b AS ?equals) (?a != ?b AS ?notEquals) >>> { >>> BIND("abc"^^xsd:integer AS ?a) >>> BIND("xyz"^^xsd:integer AS ?b) >>> } >>> >>> This gives the following: >>> ---------------------- >>> >>> | equals | notEquals | >>> ====================== >>> | | | >>> ---------------------- >>> >>> So we can see that both expressions evaluate to error and thus give >>> unbound in the result set. As far as I can tell I understand and >>>explain >>> things fine so far. >>> >>> Example 2 >>> >>> Now this is where I get stumped, now consider the case where the >>>malformed >>> literal is just "abc"^^xsd:integer. Now if I run the equivalent ASK >>> queries I get different answers. >>> >>> ASK WHERE { FILTER("abc"^^xsd:integer = "abc"^^xsd:integer) } >>> >>> ASK WHERE { FILTER("abc"^^xsd:integer != "abc"^^xsd:integer) } >>> >>> In this case the first query gives true and the second gives false, >>>while >>> this makes sense from just looking at it this seems to be at odds with >>>the >>> spec. Using the same arguments as before we are using >>>op:numeric-equals() >>> to do the equality check which should give a type error and thus both >>> filters should receive an error and thus result in false for both >>>queries. >>> >>> What seems to be happening is that the engine is trying >>> op:numeric-equals() and if it gets a type error falling back to RDF >>>term >>> equality and if that gives true returns true/false as appropriate, if >>>it >>> gives false then it passes the type error upwards. This doesn't >>>appear to >>> be mandated by the SPARQL specification but the tests certainly include >>> this. >>> >>> Again we can see this with the SELECT form: >>> >>> SELECT (?a = ?b AS ?equals) (?a != ?b AS ?notEquals) >>> { >>> BIND("abc"^^xsd:integer AS ?a) >>> BIND("abc"^^xsd:integer AS ?b) >>> } >>> >>> This time we get the following results: >>> ---------------------- >>> >>> | equals | notEquals | >>> ====================== >>> | true | false | >>> ---------------------- >>> >>> When if my understanding from Example 1 were to hold I would expect to >>>see >>> unbound for both of these again. >>> >>> Am I just missing something in my understanding of the operator mapping >>> and expression evaluation part of the SPARQL specification or is there >>> something else going on? >>> >>> Thanks, >>> >>> Rob >>> >>> >> >
