W3C home > Mailing lists > Public > public-ldp@w3.org > November 2012

Re: LDP would benefit from being RESTful

From: Kjetil Kjernsmo <kjetil@kjernsmo.net>
Date: Mon, 19 Nov 2012 11:14:38 +0100
To: public-ldp@w3.org
Cc: Martynas Jusevičius <martynas@graphity.org>
Message-Id: <201211191114.39191.kjetil@kjernsmo.net>
Mandag 19 november 2012 01:23, skrev Martynas Jusevičius:
> It is workable as the example was a simplified state machine version
> of Graphity LDP implementation :) Take a look here:
> https://github.com/Graphity/graphity-ldp
> I've been doing Linked Data client work on this platform for a while now.

Very cool! Indeed, practical implementations go a long way to prove the 
workability. I just haven't gotten very far with my own implementation 
yet. :-)

> > However, I think it is important to have write operations explicit, so
> > that clients doesn't have to just guess what they are allowed to
> > expected to do, as that wouldn't scale if many operations are possible.
> It is important, but with HTTP clients don't have to guess -- there is
> the OPTIONS method that shows available methods for a resource:
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2

Yup, and AFAICS, the current spec has the Allows header on HEAD (why not 

> If we define the Linked Data CRUD operations unambiguously and
> generically as HTTP methods, then the resources become self-describing
> during the whole read/write lifecycle. I think the best way to achieve
> this is to keep as close to the HTTP semantics as possible, that's
> what I tried to do in my post.

Actually, I think the opposite: I think it is important to keep as close to 
what people actually expect to do. I.e. rather say something with "ex:put", 
say "ex:replaced", since what you do when putting to a resource that 
already exists is to replace it. I think this is important both since it 
allows more intuitive uses of the properties and using different verbs on 
the protocol if they are found to be more appropriate at some point, and 
then, other possible protocols. I think modular design practice is a good 
motivator for this.

> You might say that HTTP methods such as OPTIONS are not explicit
> enough in terms of RDF metadata, but this can be bridged using HTTP
> vocabulary in RDF: http://www.w3.org/TR/HTTP-in-RDF10/

I think a HTTP vocab would be important in this, but I'd prefer if all the 
attempts didn't just end in a WD... :-P

> In this case it would serve a similar purpose as your general HM
> vocabulary. In general I don't see why a vocabulary is better than

There are mainly two reasons for that: One is that it isn't *immediately* 
obvious. You have to do another HTTP request, which is one of the things 
people are troubling with with the whole 303 thing, even though their 
client does it automatically... I think a good guiding principle is that if 
you have the representation of a resource, you should know what you can do 
with it.

The other thing is that you can't describe it any further, i.e. you can't 
define what you mean by a method: Something that the WG has to resolve is 
e.g. what it means to POST, does it mean that you do an RDF Merge of the 
payload into the resource, or does it mean doing a Union between the two 
graphs? OPTIONS can't tell you that, but an RDF vocab can trivially (thus 
hm:mergeInto in my example). Stuff like that has to be in the message for 
the protocol to be RESTful. 

Moreover, well, I guess it is a rather contrived example, but I couldn't 
come up with a better right now: Say you have a pizza representation: You 
could then just order it, or you could add more toppings, both resulting in 
PUT operations. You'd like to describe the distinctions, but again OPTIONS 
can't do that, RDF can. Though, I admit that it would be better to come up 
with a real, distinguishing use case. :-)


Kjetil Kjernsmo
PhD Research Fellow, University of Oslo, Norway
Semantic Web / SPARQL Query Federation
kjetil@kjernsmo.net           http://www.kjetil.kjernsmo.net/
Received on Monday, 19 November 2012 10:15:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:09 UTC