- From: David Booth <david@dbooth.org>
- Date: Sat, 02 Jun 2012 23:42:22 -0400
- To: public-rdf-dawg-comments <public-rdf-dawg-comments@w3.org>
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? Thanks -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Sunday, 3 June 2012 03:42:55 UTC