Re: !=, NOT IN and type errors

On 27/03/2011 00:40, Eric Prud'hommeaux wrote:

> I suspect that the issue lies with the way the way the operator
> mapping is specified. §16.3 ¶1 says
> [[
> When selecting the operator definition for a given set of parameters,
> the definition with the most specific parameters applies. … The table
> is arranged so that the upper-most viable candiate is the most
> specific. Operators invoked without appropriate operands result in a
> type error.
> ]] — http://www.w3.org/TR/rdf-sparql-query/#OperatorMapping
>
> Entries for the supported "=" operands, e.g.
>    A = B   numeric   numeric   op:numeric-equal(A, B)       xsd:boolean
> preceed the catch-all
>    A = B   RDF term  RDF term  RDFterm-equal(A, B)          xsd:boolean
>    A != B  RDF term  RDF term  fn:not(RDFterm-equal(A, B))  xsd:boolean
>
> so RDFterm-equal is responsible only for non-literal terms and the
> literals which are not known to be equivalent. The footnote to which
> you refer is intended to help illustrate this effect, but doesn't
> change the definition of RDFterm-equal (i.e. if they're both literal,
> throw a type error).

Ok, I am officially confused now. I have the impression that what you 
say happens is not quite the same as what Andy says happens.

> §16.3.1 Operator Extensibility preceeds §16.4 Operator Definitions and
> is intended to illustrate the effect of extending the set of operator
> functions, the footnote illustrates the effects of extensibility on
> how and when RDFterm-equal is called.
 >
> With all of these fabulous candidates laid out in front of you, can
> you suggest a change to one or more which will make this clearer?

I am probably still making a mistake somewhere, or we are all 
overlooking something. The former is more likely, so let me just go 
through a simple example case one step at a time, and you can stop me at 
the point where I make the error. That would likely be the point at 
which either I go "duh!" or you go "hmm, we could clarify that".

Example case: determine the truth value of the expression 
"foo"^^xsd:string != "4"^^xsd:integer.

Looking at the operator mapping table in 16.3 (17.3 in the editor's 
draft), let's see which mapping applies. The first mapping for != is:

  A != B numeric numeric fn:not(op:numeric-equal(A, B)) xsd:boolean

This mapping does not apply because "foo"^^xsd:string can not be 
promoted/substituted to be a numerical literal.

Second:

A != B simple literal simple literal 
fn:not(op:numeric-equal(fn:compare(A, B), 0)) xsd:boolean

Does not apply because neither is a simple literal.

Third:

A != B xsd:string xsd:string fn:not(op:numeric-equal(fn:compare(STR(A), 
STR(B)), 0)) xsd:boolean

Does not apply because "4"^^xsd:integer can not be promoted/substituted 
to xsd:string.

Fourth:

A != B xsd:boolean xsd:boolean fn:not(op:boolean-equal(A, B)) xsd:boolean

Does not apply either, neither can be promoted/substituted to boolean.

Fifth:

A != B xsd:dateTime xsd:dateTime fn:not(op:dateTime-equal(A, B)) xsd:boolean

Does not apply for the same reason.

Last:

A != B RDF term RDF term fn:not(RDFterm-equal(A, B)) xsd:boolean

So, in the case of comparing a string-typed literal with an int-typed 
one, we fall back on RDFterm-equal. Correct sofar?

Now, we apply RDFterm-equal to our comparison. Both operands are 
literals. The definition says that two literals are RDF-term-equal if 
they are "equivalent literals" according to def 6.5.1 in RDF concepts. 
Since our operands have different lexical values as well as different 
datatypes, literal equality fails. The definition of RDFterm-equal then 
says: "[it] produces a type error when both operands are literal but are 
not the same RDF term". Since in our case both are literal but are not 
the same term, it results in a type error. So RDFterm-equal results in a 
type error, and since applying fn:not on a type error results in a type 
error, "foo"^^xsd:string != "4"^^xsd:integer evaluates to a type error. 
This is what I originally thought happened, and what I thought was 
undesirable.

Andy's remark about "disjoint value spaces" made me look at the 
definition again, and realizing that the footnote says: "Invoking 
RDFterm-equal on two typed literals tests for equivalent values". I took 
this to mean that in my example case, I should not have simply returned 
a type error after the failed literal equality check, but should have 
done a lexical-to-value mapping, checking that both are semantically 
wellformed literals (which they are), and then just return FALSE for 
RDFterm-equals. This would result in "foo"^^xsd:string != 
"4"^^xsd:integer evaluating to TRUE. Which is what I would want it to be.

So, which is the correct interpretation? Or where am I going wrong?

Regards,

Jeen

Received on Saturday, 26 March 2011 22:00:08 UTC