Re: LDP would benefit from being RESTful

Hej Kjetil,

>> would I be right to understand that "hypermedia as the engine of
>> application state" is basically a state machine, where state is
>> described as RDF and managed with HTTP?
>
> Well, yes, basically. Just that you can use any suitable description and
> any protocol, but RDF and HTTP is the most practical for us.

Well even if it would be possible to make this kind of state machine
protocol-independent, I think for most practical Linked Data purposes
anything else than HTTP is irrelevant (just like any other data model
than RDF is). That seems to be the position of the current LDP draft
and it's also my scope of interest. Otherwise things would get way
over-complicated.

>
>> In that case, I was proposing the same approach, summarized in this post:
>> http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0004.html
>
> Yeah, that's nice! However, I think it needs to be explicit about write
> operations, I can't see that it is. So, that's mostly what I do with my
> vocabulary proposal, e.g. hm:replaced (for a PUT to an existing resource).
> They can then be refined for more detailed uses (such as updating your pizza
> order). That's the idea anyway, it remains to see if it is workable. :-)

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.

> 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

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.

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/
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
OPTIONS.

Martynas
graphity.org

Received on Monday, 19 November 2012 00:23:40 UTC