Re: LDP would benefit from being RESTful

hello mark.

On 2012-11-14 12:00 , Mark Baker wrote:
>  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.

i would state that a little broader, but i think we're on the same page. 
RDF has no links, but with linked data, you can attempt to GET things. 
so what we have is a crawler-friendly approach, where you can happily 
GET anything that's being mentioned, and you assume GETing it will be a 
safe thing to do.

>> 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 :)

i am trying to be pragmatic. if all a container can expose as a service 
is "POST random RDF to me", then i don't see how what we're doing is 
different from GSP, in the sense that we're building interactions for 
RDF databases (i.e., services that opaquely manage any RDF). if we want 
to have meaningful interactions where services can expose capabilities 
beyond opaque RDF handling, there has to be some way how a service can say:

- POST some RDF here and i'll store it. if you POST a book order, i 
really don't care. i'll just store it and you can GET it later.

- POST a book order here and when you do, you'll order that book.

if all we can do is the former, we're doing GSP. if we want to add 
value, we need some way how a service can expose its capabilities beyond 
just saying "i can do RDF", so that i can link to it and tell people: 
"if you want to order a book, here's a link to the book order service. 
good luck!"

> 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 :)

we'll see about this. personally, i think it might be interesting to see 
where profiles might take us, as they might be able to expose a 
service's capabilities on the HTTP level, without the need to mint new 
media types for every service. i haven't played with that thought 
enough, but there has to be *some* way how service capabilities are 
reflected in HTTP, or we're back to where you started this thread: we're 
making special rules for using HTTP that are invisible to non-LDP 
clients, and we're building up a parallel universe.

cheers,

dret.

Received on Wednesday, 14 November 2012 20:37:44 UTC