- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Tue, 29 Mar 2011 16:44:00 +0100
- To: Paul Gearon <pgearon@revelytix.com>
- CC: Lee Feigenbaum <lee@thefigtrees.net>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 29/03/11 16:15, Paul Gearon wrote: >> Right -- as in, it's identical as far as the spec concerned, which means it >> > too is implementation-defined. The spec doesn't say (nor would it really >> > have license to say) that a processor must use the same algorithm for >> > figuring out the triples in g via USING as it does via FROM, does it? > I think you're right here, though it wasn't my intent. In this case I > was trying to aim for USING to simply be a syntactic replacement for > the word FROM. Therefore, whatever the specific store does for FROM is > also what I would expect from USING. However, since you point out that > the definition is loose, then I suppose that means that graphs to use > in the WHERE clause can vary by context (by "context" I mean queries > vs. update operations). > In query, the local graphs can be regarded as a cache of the web so FROM acting locally to determine <http://example/graph> is OK. That's rather harder if the local graph can be changed without changing the web copy. Which <http://example/graph> is it now? Does any system allow a mixture of remote and local graphs in a single operation? Using the word "identical" creates the presumption that an update service and a query service do the same thing. While I think it is much better to, by definition, limit USING to the store only (security for example, because we have an operation LOAD that is a clear point where a system does out to the web (or file or ...)), if there were wording that made it clear that there wasn't that presumption, I might be able to accept it. But it seems the intent is to force equating the two at some server (update service and query service are separate but it is now clear that the intent is to relate the FROM behaviour to USING behaviour. Andy
Received on Tuesday, 29 March 2011 15:44:43 UTC