Re: LDP would benefit from being RESTful

On 11/16/12 10:29 PM, Mark Baker wrote:
> 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.
>
>
>
+1

Much appreciated reminder of what's already been explored in the past 
re., this realm too!


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen