Re: LDP would benefit from being RESTful

hello all.

thanks for the discussion, i think this is very helpful to move this 
whole effort forward.

On 2012-11-18 7:04 , Ruben Verborgh wrote:
> As one of the people who discussed this with Kjetil,
> I think it *really* makes sense to try so see things from this perspective.
> Just like Mark said, I believe we’re too much in the process
> of making a protocol at HTTP level,
> while LDP is the chance to do something different.
> So the crucial question is:
> is it still possible to go in a fundamentally different discussion
> than the one we’re going in right now (even if it’s just trying)?

maybe i am pointing out the obvious here, but i want to make sure that 
we're not conflating two different things here, which, when conflated, 
make it much harder to have a coherent discussion. designing something 
and describing something are two very different things. RESTdesc and the 
link mark provided seem to be about describing REST services. that's a 
useful thing to have (and REST painfully lacks a good way that would 
make it easier for authors of any RESTful service to provide structured 
documentation of that service), but a description of a thing isn't the 
design of the described thing itself. it's a reflection of a design in 
whatever description model the describer happens to use.

our job as a WG is most definitely not to invent a description language 
for RESTful RDF-based services. our job is to define one specific 
RESTful RDF-based service. we could choose to do that using some 
vocabulary that allows clients to find links and interact with them. we 
could choose to do that purely based on HTTP Link headers, leaving links 
to the RFC 5988 framework and data to the RDF framework.

whatever we end up with as a design hopefully would be easy to describe 
in description framework for RESTful services, and if it's not, then 
that would be a good indication that either our design has some 
problems, or these description models. but starting with a description 
of the service without having a definition of it seems a bit backwards 
to me, and given that our fact as a WG is very explicitly to define *one 
RESTful service" and not a general framework, i think we might be better 
off not trying to build a general-purpose framework.

maybe yet another analogy helps: there have been various attempts to 
factor out hypermedia controls in RESTful services and provide a general 
framework for them; mike kelly's HAL is one such approach.  there may be 
utility in having such a framework, if it hits the magic 80/20 mark. but 
whatever your thought are about this, the absence of such a generic 
framework doesn't prevent anybody from designing RESTful services in 
JSON and XML, it's just that they have to be designed from the ground up 
(because just like RDF, JSON and XML have no concept of links), instead 
of being based on a framework such as HAL, which provides linking as a 
first-level citizen.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Sunday, 18 November 2012 20:59:31 UTC