W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

RE: ACTION-115: Note on proxy graph URI

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sun, 11 Oct 2009 19:59:53 +0000
To: Kjetil Kjernsmo <kjetil@kjernsmo.net>, "public-rdf-dawg@w3.org" <public-rdf-dawg@w3.org>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA3693F7D3979@GVW1118EXC.americas.hpqcorp.net>
Good questions to bring out assumptions ...

> 1) The HTTP Update protocol is required to be RESTful. (+1, yes; 0,
> preferred, but not required; -1, it could be anything)

REST is a style (abstract architecture) with principles.  It's not really something that you can always say "yes" or "no" to in every case - some things are clearly not RESTful, some things clearly are, lot of a lot of things are grey and it depends on who you ask.

I don't see how we can "require" it.  Rather, take the principles and makes a concrete design that addresses the usage we want to cover.

> 2) The protocol must specify how to use POST, PUT, GET and DELETE on a URI
> identifying information resource graph. (+1, yes, required; 0, optional;
> -1, WG shouldn't spend time on it)

I believe that the update protocol is simply using the correct meaning of the verbs PUT, GET and DELETE as defined by RFC 2616 in the context of RDF graphs held in a graph store/update service [*].

In the case of POST, which is too broad to defined enough to fix the meaning here, and we apply a specific meaning to the verb but it is completely inline with the definition in RFC 2616.

I'd rather say "will show" than say "must specify".

> 3) The protocol must specify how to use manipulate a graph with a proxy
> graph identifier. (+1, yes, required; 0, optional; -1, WG shouldn't spend
> time on it)

I don't like the term proxy because:

A/ (minor) "proxies" in HTTP occur in a lot of places so it's a bit overloaded 

B/ Having two names for the same thing is just something that happens on the web. Both names have the same status. 

It's the same graph, accessible through a different name.  Each name is as valid as the other and one is not a second class name; "proxy", for me, sort of implies it's not a first class name.  

Actually, let's be realistic, a common case is going to be that it's a copy of the graph stored under the URL used to GET at some point in time, and so the http://service/graphURL is referencing that (or http://service/?graph=url - URIs are opaque, ?query=SELECT returns a representation of a result set).

A name of the graph in the dataset is also (the encoding of):

http://host/service?query=CONSTRUCT { ?s ?p ?o { GRAPH <uri> { ?s ?p ?o } }

I could see the Request-URI as a sub-resource of the service [*] endpoint referring to that graph.

	Andy

[*] update service / graph store, depending on how that terminology works out.

Received on Sunday, 11 October 2009 20:01:34 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT