Review of HTTP Update

Hi all!

I'm finally back after a hiatus caused by partly uncertainty if our W3C 
membership would be extended by our management and partly by a broken leg. 
Well, I'm not really back, since I'm on paternity leave right now, but the 
baby is sleeping. :-) Before I start, I have to apologize if what I write 
below has already been dealt with while I was away.

I feel that the Update Protocol is not ready for FPWD, not so much because 
of the document itself, Chimezie has done a good job although I have some 
objections to the wording too.

The problem, as is reflected in the document, is that it is rather nebulous 
what our goal with the HTTP update protocol is, and that the design issues 
have never been properly articulated, at least not a consensus around it.

For example: Should we adhere strictly to REST principles? Who is the 
primary audience we target with the update protocol?  To what extent is it 
important that SPARQL/Update Language features have a corresponding feature 
in the update protocol? 

The thing is that I cannot wrap my head around how the proxy graph stuff 
can possibly be RESTful. One of the fundamental principles of REST is that 
messages, including metadata, should be self-descriptive. Fielding was 
perhaps not very explicit about what this means, but it is clear that if 
you GET a graph, it contains no information about the service endpoint ( it 
doesn't mention the "proxy graph identifier") that you can use to 
manipulate the graph, unless we do something clever, like adding an HTTP 
header that says something about it. As opposed to the GET, PUT, DELETE and 
POST operations, where you only need to know the graph URI and the 
available verbs, which is therefore self-descriptive. It is possible that 
my understanding of REST principles are inadequate, but at least we should 
articulate if these are principles that we intend to follow and if so, what 
we believe they entail. I would personally prefer that only straightforward 
REST is required, further exploration is on a time-permitting basis.

So, to my criticism of the document: I feel the language is too heavy and 
too geared towards the semweb community. To an outsider, I'm not so sure it 
is so easy to understand, even though what we are doing is very 
straightforward and built on principles understood by a huge number of 
people, the basic message should be "a graph is a bunch of triples, just 
throw your triples at the graph URI, and the store will do what you 
expect". So, the challenge is to express that in a formal way :-) This is 
relevant to the question of audience.

Also, I don't like the definition of "Resource": "Resource - A network-
accessible data object or service identified by an IRI, as defined in 
[RFC2616]. See [WEBARCH] for further discussion on Resources."

I guess this definition works OK in the context of the Atom Publishing 
Protocol, which I assume it comes from, but it doesn't work very well in 
our context, and it is quite far from the discussion in WEBARCH, I feel.

Only information resources are network-accessible, and there are many 
resources that are not in our world. Importantly, the graph URI may not be 
dereferenceable, which is the main complicating matter in the protocol.
The use of "object" may also confuse people, "is it the object of a 
triple?"

Finally, the term "Networked RDF knowledge" is problematic. I'm agnostic 
myself (it is all just rdfs:labels to me ;-) ), but I have colleagues who 
would absolutely cringe at the idea that knowledge can be networked. In 
their world, knowledge is something that only humans can have, so RDF can 
only become knowledge through a heap of highly complex cognitive processes. 
We don't want to get them started, believe me, this could be a 
permathread... ;-) (besides, I think they have a point)

I was about to start compiling a post with links to earlier discussions on 
the topic, to form a basis for strawpolls in the teleconf, but the baby 
just woke up, so it seems won't happen today... 

Cheers,

Kjetil
-- 
Kjetil Kjernsmo
kjetil@kjernsmo.net
http://www.kjetil.kjernsmo.net/

Received on Tuesday, 6 October 2009 11:19:29 UTC