Re: LDP would benefit from being RESTful

Hi Erik,

On Wed, Nov 14, 2012 at 1:28 PM, Erik Wilde <dret@berkeley.edu> wrote:
> the problem with "making LDP RESTful" (according to the definition you refer
> to and the definition i was referring to above) is that RDF isn't RESTful it
> itself because it's not a hypermedia format.

I think I see what you're saying, but wouldn't quite couch it like that.

>From a read-only, non-parameterized transitions POV (aka no query
parameters), RDF is very much a hypermedia format (well, it's
serializations are). The problem is that when one wants to mutate
resources, there's no standardized vocabulary to do so beyond the
implicit and symmetric nature of PUT (GET a representation, PUT it
back). That leaves a gap with respect to the use of POST and of
parameterized GETs. It's why I wrote RDF Forms.

> and we as a group cannot change
> this (it is way outside what we're chartered to do),

Well, you seem to be attempting to fix the POST problem in the
container discussion :)

> this is just a
> limitation of the current state of affairs with RDF. this means that yes, we
> have to define vocabularies (as you say), but what we would need to do is
> define media types, which are a mix of data vocabularies (the
> representations) and interaction vocabularies (the affordances in
> representations provided by links). what you are asking us is to do this
> latter thing, and it would be great if we could do this, but unless we
> define our own framework for turning RDF into a hypermedia format, i have a
> hard time imagining how we could do it cleanly.

Ah, I think I finally understand why you talk about different media
types. I've never seen the need, and still can't quite say that I do,
at least in the sense of "need" that derives from working within the
constraints of REST. But I could see some practical utility in
deploying it - I just hope it's not more than one new type :)

> what you want us to do (i think) is to define a vocabulary in hyperRDF (i
> just made that up) that clearly defines both the representations we are
> designing interactions around, and the links that can be used by any
> hyperRDF-aware client to identify the interaction affordances provided in
> those representations. if that's what you want, then i agree that this would
> be the way to go, but sadly, there is no hyperRDF. am i interpreting
> correctly what you would like us to do? and if yes, given that there is no
> hyperRDF, what would you like us to do?

Well, I'm not so sure that there's two vocabularies in play here. I
think it might be just one, and looks something like RDF Forms.

Mark.

Received on Wednesday, 14 November 2012 20:01:12 UTC