Re: LDP would benefit from being RESTful

On Fri, Nov 16, 2012 at 1:57 PM, Kjetil Kjernsmo <kjetil@kjernsmo.net> wrote:
> On Wednesday 14. November 2012 13.58.33 David Booth wrote:
>> On Wed, 2012-11-14 at 10:28 -0800, Erik Wilde wrote:
>> > [ . . .  ] RDF isn't
>> > RESTful it itself because it's not a hypermedia format.
>>
>> Huh?  I'm baffled by that comment.  Why do you say RDF is not a
>> hypermedia format?   For one thing, RDF is composed almost entirely of
>> URIs, i.e., links.  How much more link-ful can you get?
>
> Erik is partially right: By itself, RDF is a hypermedia format only on a
> very, very superficial level.
>
> I'd like to encourage everybody to do the exercise to go Mike Amundsen's
> hypermedia classification: http://amundsen.com/hypermedia/hfactor/
> You will quickly realize that RDF, out of the box, is a hypermedia only on
> the LO level.
>
> However, as I show in my ESWC LAPIS2012 presentation, see
> http://folk.uio.no/kjekje/2012/lapis2012.xhtml
> RDF can be made to be a very powerful hypermedia type by fairly trivial
> means. In fact, it can easily meet all but one of Amundsen's criteria (I
> just realised that LE can be met using data URIs).
>
> I've been talking with people F2F on ISWC about this, and I hope I have
> convinced some that this is the direction one should be going. And I really
> don't think this is out of the scope of the charter, to the contrary, if
> this is done right, it is what the charter really means. :-)

I agree in general, but have reservations about the use of H Factor,
both as a method of evaluation, but more importantly, as a tool for
motivating a solution. Consider that the difference between idempotent
and non-idempotent methods doesn't matter at all from a hypermedia
POV, but what does matter is whether the state transition can occur in
the absence of additional information. This makes "LI" meaningless,
along with its distinction from "LN". Also, "CM" as a factor seems to
derive solely from HTML's unification of GET and POST forms, and
appears to extrapolate from that, that it's desirable to have the
server prescribe the method used by the client; IMO, that's the
opposite of what you want as the client is solely responsible for the
meaning of the messages that it sends.

Anyhow, I am glad to see discussion head in this direction and agree
that even what you describe in your slide deck would be an improvement
over the current form of the LDP specification (FWIW, the same goes
for Ruben's RESTdesc, which also uses explicit methods). I'd encourage
you to have a look at RDF Forms, as I consider it to be alone the same
lines as your proposal, but enhanced in some of the ways discussed
above. To illustrate that evolution, this page captures some notes
that were a precursor to RDF Forms, but shares a lot more similarity
to your and Ruben's work;

http://www.markbaker.ca/2002/03/RestRDF/

Mark.

Received on Saturday, 17 November 2012 03:29:59 UTC