Questions and comments on SPARQL 1.1 Graph Store HTTP Protocol draft

Hi,
I have a couple of questions for the WG on the last call draft:

1) In some of our applications of RDF we want to encourage a situation 
where a single RDF resource can have more triples in its representation 
than are understood by any single client. PUT has some significant 
disadvantages for RDF resources in this case.

Indeed, if you use PUT for update, each client is forced to GET all the 
triples, whether or not it understands them all, change some of the ones 
it does understand, and then carefully PUT them all back again. This can 
work, but the whole system relies on the good behavior of the clients.

This problem is avoided when using PATCH.

It's interesting to note that relational technologies have no equivalent 
of PUT. Relational UPDATE is conceptually more like PATCH - it allows you 
to update only the predicates you can name, with the current value of the 
other predicates being preserved by the server.

Has there been any discussions about this?

2) Using PUT to create a new resource requires the client to know the URI 
of the resource. In our RDF applications, the client typically doesn't 
know and the URI is set by the server. For this reason we favor using POST 
to create resources but I wonder whether there was any discussion about 
this?

3) For POST the draft specifies that "If the request URI identifies the 
underlying Graph Store, the origin server SHOULD create a new RDF graph 
comprised of the statements in the RDF payload and return a designated 
graph IRI associated with the new graph."

However, the draft is silent on how this IRI should be written in the 
"statements in the RDF payload" given that it isn't known by the client 
yet.

One convention we have adopted is to use the null relative URL (<> in 
Turtle, or "" in RDF/XML). I'd like to know whether there is a standard 
way of doing this. Maybe the spec should indicate one.

Thank you.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Received on Thursday, 2 June 2011 18:26:53 UTC