Re: FROM and FROM NAMED: To fetch or not to fetch?

On Jun 2, 2012, at 11:42 PM, David Booth wrote:

> When a SPARQL query is issued to a server using the FROM <U> (or FROM
> NAMED <U>) syntax, is the server supposed to fetch that graph from U or
> is it supposed to only look among its existing named graphs for U?
> 
> Sec 13.2 says:
> http://www.w3.org/TR/sparql11-query/#specifyingDataset
> [[
> The FROM and FROM NAMED keywords allow a query to specify an RDF dataset
> by reference; they indicate that the dataset should include graphs that
> are obtained from representations of the resources identified by the
> given IRIs (i.e. the absolute form of the given IRI references).
> ]]
> 
> And sec 13.2.2 further says:
> http://www.w3.org/TR/sparql11-query/#namedGraphs
> [[
> The FROM NAMED syntax suggests that the IRI identifies the corresponding
> graph, but the relationship between an IRI and a graph in an RDF dataset
> is indirect.
> ]]
> 
> These sections certainly make it sound like the server is supposed to
> fetch from the URI (or perhaps use a cached version if it is fresh).
> But I just tried this with three different SPARQL servers, and only one
> fetches from the URI.  The others only look among their existing named
> graphs.
> 
> There is a big difference between fetching and not fetching.  As a query
> writer I need to know which behavior is correct.  
> 
> Personally, although the fetching behavior seems convenient for some
> things, I think the non-fetching behavior seems more sensible, because: 
> 
> 1. If the correct behavior were to not fetch, then named graphs could be
> fetched using LOAD INTO GRAPH anyway.
> 
> 2. If the correct behavior were to fetch then I don't know how one would
> specify multiple already-loaded named graphs to be used as the default
> graph in a query.
> 
> 3. If the spec is intentionally ambiguous about fetching or not fetching
> then that would be a problem, because I certainly would not want a
> server trying to fetch without my control.
> 
> Clarification please?

David,

As Andy mentioned[1], SPARQL has never defined how a dataset is constructed. SPARQL 1.0 left that to implementations to decide, and nothing about that has changed in SPARQL 1.1. I mentioned previously[2] that SPARQL 1.1 Service Descriptions could be used to indicate that an endpoint uses dereferencing behavior to construct a dataset. Beyond that specific claim, service descriptions provide an extensible way for an endpoint to describe any more complex behavior it might exhibit. Moreover, as I said in [3], implementation flexibility in defining a dataset can provide real benefit in situations where SPARQL 1.1 Update (and its "LOAD" operation) are either not implement or not made accessible to arbitrary users of the system.

As dataset construction is not something that has changed in SPARQL 1.1, and introducing a mechanism that would restrict how datasets may be constructed (e.g. with your proposed "FETCH" keyword) could be viewed as a backwards incompatible change for some queries on systems conforming to SPARQL 1.0, the working group has decided to leave the definition of FROM and FROM NAMED as they currently exist.

We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.

Regards, Gregory Williams, on behalf of the SPARQL WG.

[1] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Jun/0005.html
[2] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Jun/0028.html
[3] http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2012Jun/0039.html

Received on Friday, 6 July 2012 15:35:25 UTC