W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2010

ISSUE-49 (are graphs information resources?)

From: Gregory Williams <greg@evilfunhouse.com>
Date: Sun, 18 Apr 2010 14:55:39 -0400
Message-Id: <9090F623-6C27-4BEF-93B4-AF86333C3CD8@evilfunhouse.com>
To: SPARQL Working Group WG <public-rdf-dawg@w3.org>
Has there been any movement on ISSUE-49 (Is a graph an information resource)? I was talking with KjetilK the other day, and think this needs to be nailed down. It affects HTTP Update (and maybe Service Description). The relevant previous discussion seems to be in:


In particular, in that first email Chimezie cites section 8.2.2 of SPARQL 1.0:

> 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. The IRI identifies a resource, and the resource is represented by a graph (or, more precisely: by a document that serializes a graph).

and in the second Kjetil says,

> Concretely, this seems to imply that if you have a document  http://example.org/foo.rdf you cannot import this into a quad store with http://example.org/foo.rdf as the graph name, since it is an information resource. Moreover, if you did, you cannot return a 200 if has been imported, it would have to return a 303.

However, section 5.4 of HTTP Update [1] says,

> The HTTP GET method SHOULD be used to retrieve a graph representation of the networked RDF knowledge identified by the Request-URI.
> This is equivalent to the following SPARQL query:
> CONSTRUCT { ?s ?p ?o } WHERE { GRAPH <graph_uri> { ?s ?p ?o } }

Also, this might affect how graphs are referenced in a service description (though in part based on an ongoing discussion with Sandro, I *might* be off the hook here, since right now the SD doc suggests using a bnode to represent the graph, and having an sd:name(d) property hanging off of it).


[1] http://www.w3.org/2009/sparql/docs/http-rdf-update/#http-get
Received on Sunday, 18 April 2010 18:56:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:00 UTC