Re: LDP would benefit from being RESTful

Mark, are you familiar with RDF/POST encoding?
http://www.lsrn.org/semweb/rdfpost.html

On Wed, Nov 14, 2012 at 10:00 PM, Mark Baker <distobj@acm.org> wrote:
> 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:05:36 UTC