!=

DAWG,

   I have a scenario I'd like to present, and an associated  
suggestion. (Alternatively, please correct whatever misunderstand  
becomes evident in the following email.)

   Consider a simple FILTER:

     FILTER ( ?x != ?y )

   Imagine ?x bound to "car"@en-us, and ?y bound to "auto"@en-us, and  
evaluate the expression.


   Sec. 11.3 defines != on two RDFterms -- these literals put us into  
RDFterm territory, as they aren't 'simple' -- as

     fn:not(RDFterm-equal(A, B))

   RDFterm-equal "produces a type error if the arguments are both  
literal but are not the same RDF term".

   We know that "Any expression other than logical-or (||) or logical- 
and (&&) that encounters an error will produce that error.". fn:not  
satisfies this requirement.


   So, let's compare these two values. The two arguments are both  
literal, but are not the same term, so RDFterm-equal produces a type  
error. fn:not propagates this type error. Finally, the FILTER fails,  
even though ?x is not intuitively equal to ?y.

   What we have here is a FILTER that only passes if RDFterm-equal  
returns precisely "false"^^xsd:boolean. When called with two  
literals, this is never the case, despite it *not* being true that ?x  
= ?y.

   My suggestion is either:

   * that != is defined in terms of sameTerm (which never returns a  
type error), not RDFterm-equal, or
   * that fn:not is replaced by a SPARQL operator that masks SPARQL  
type errors, treating them as false, but otherwise behaving as fn:not.

   The current specification defines extremely unintuitive behavior  
that baffles even experienced users, and should be changed.

   I look forward to the DAWG's response!

   Thanks,

-R

Received on Tuesday, 10 July 2007 05:37:47 UTC