From SPARQL Working Group
Philip Fennell wrote:
> I've had a quick look in the archive but have not found anything the immediately answers my questions, which is: > >I'm not sure I understand the distinction between Direct Graph Identification and Indirect Graph Identification that uses the graph request parameter to identify a named graph. > >With respect to Direct Graph Identification (section 4.1 of the SPARQL 1.1 Graph Store HTTP Protocol) can I deduce from the following statements: > >'Per [RFC2616]<http://www.w3.org/TR/sparql11-http-rdf-update/>, the most common usage of a Request-URI is to identify a resource on an origin server or gateway. In our example, the >corresponding request URI (http://example.com/rdf-graphs/employees) is meant to identify RDF triples on the example.com server that describe employees. In addition, the request specifies the >GET method, which means that a representation of these triples should be returned. In this case, the preferred representation format is application/rdf+xml > >In this way, the server would route operations on a named graph in an Graph Store via its Graph IRI. However, in using a URI in this way, we are not directly identifying an RDF graph but rather the RDF graph content that is represented by an RDF document, which is a serialization of that graph. Intuitively, the set of interpetations that satisfy [RDF-MT]<http://www.w3.org/TR/sparql11-http-rdf-update/> the RDF graph that the RDF document is a serialization of can be thought of as this RDF graph content.'
> that by using 'Direct Graph Identification', the graph content that you would be addressing with:
> is a 'Named Graph' and an equivalent request would be, for example:
Yes, this is correct, assuming
Identifies a Graph Store managed by an HTTP service that is an implementation of this protocol and
is the graph IRI associated with an RDF graph within that Graph Store
We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.
Regards, Chime Ogbuji, on behalf of the SPARQL WG.