- From: Richard Newman <rnewman@franz.com>
- Date: Thu, 23 Jul 2009 21:29:29 -0700
- To: Samuel Pedro <samuelcpspam@gmail.com>
- Cc: public-sparql-dev@w3.org, Paul Gearon <gearon@ieee.org>
> Finally, several stores provide an extension to the = operator, > allowing it to return "true" for the same string that is either an > untyped literal or an xsd:string. Not every store does this however, > and then some stores can even differ depending on the type of graph > (for instance, IIRC Jena has this extension if the graph is in memory, > but not if it is on disk). Some additional notes: more formally, using '=' makes the query subject to the implementation's choices of operator extensibility, as in sec. 11.3.1; putting the resource or literal in the triple pattern itself makes the query subject to the entailment regime used by the implementation (sec 12.6). As Paul points out, implementations will usually run the query without the FILTER more efficiently. Some implementations provide a way of passing in external bindings, allowing you to use ?label in your query but substitute in "Tomato" at runtime. This allows you to generalize, and also get the variable binding back out in the results. Operators seem to be extended more often than entailment regimes, which has an impact on the predictability of the query: that is, you should expect the query with the FILTER to return different results on different implementations. In my experience reasoning and trivial datatype entailment (xsd:string being equivalent to a plain literal, and perhaps numeric equality) are the only common forms of entailment regime changes; conversely, operator extensibility is very common, with IIRC some of the tests in the DAWG test suite even failing on a non-extended-operator implementation!
Received on Friday, 24 July 2009 04:30:19 UTC