- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 15 Dec 2011 18:20:55 +0000
- 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.
Andy
Received on Thursday, 15 December 2011 18:23:56 UTC