W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > July 2007


From: Richard Newman <rnewman@franz.com>
Date: Mon, 9 Jul 2007 22:37:36 -0700
Message-Id: <0E8914C6-AC1F-41C9-812C-1DD50BA4D856@franz.com>
To: public-rdf-dawg-comments@w3.org


   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!


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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:08 UTC