W3C home > Mailing lists > Public > public-rdf-wg@w3.org > December 2011

Re: Graph-State Resources (was Re: graphs and documents Re: [ALL] agenda telecon 14 Dec)

From: Andy Seaborne <andy.seaborne@epimorphics.com>
Date: Thu, 15 Dec 2011 18:20:55 +0000
Message-ID: <4EEA3A87.1000107@epimorphics.com>
To: Sandro Hawke <sandro@w3.org>
CC: public-rdf-wg@w3.org

On 15/12/11 17:52, Sandro Hawke wrote:
> I'm looking for a class of things which have very similar behavior and
> attributes.  My most recent angle is trying to document how to use REST
> with these things.  I want to be able to talk about how HEAD, GET, PUT,
> and PATCH should work on these things.   RDFa documents have to be
> handled quite differently -- one could not, for instance, PATCH an RDFa
> document with an application/sparql-update patch.   I'm trying to focus
> on the class of things for which SPARQL Update is a meaningful PATCH
> language.

SPARQL Update + PATCH is sent to service endpoint, that applies the 
update to a graph store.

"endpoint URL" != "graph store URI"

Why not split GSR into the state and the process parts?

> The term "Graph-State Resource" is meant to convey something a bit
> broader than "Graph Container" or "G-Box".  Conceptually, GSRs have a
> lot more individuality.   Two g-boxes with the same triples are probably
> very similar; with GSR's there is less of that suggestion -- one GSR
> might be a furnace controller, and another might be just a g-box holding
> a recent copy of the state of the furnace controller.  The difference
> would be visible in the data about these items, in how they change over
> time, and probably in how they respond to a POST.

RFC 2616 defines POST to include:

     - Providing a block of data, such as the result of submitting a
       form, to a data-handling process;

The notion of process and service seem the important to the GSR beyond 
graph container.  A graph container as a specific set of 
services/data-handling process might work.

Received on Thursday, 15 December 2011 18:23:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:02 UTC