Re: LDP would benefit from being RESTful

just jumping in here...

first, i've been watching the thread and am happy that some of my efforts
may create a helpful spark here.

second, my H-Factor work was designed to name and catalog affordance
patterns in use on the Web today. if folks here notice things missing or
think a pattern i've identified does not actually exist, i'd love to hear
about it. feel free to write me off-list.

now, as for Mark's comments...

<snip>
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".
</snip>
not sure what the "difference between idempotent and non-idempotent methods
doesn't matter at all from a hypermedia POV" means exactly. i can tell you
when *implementing* hypermedia-driven systems, it's been important for the
clients i build to be aware of the idempotency of the operation. possibly
this is not important to clients you build, tho. i'd like to hear more.

it's possible you are saying something about the relationship between the
words "hypermedia" and "idempotent" (outside of implementation details) and
if so, i'd be interested in hearing more on that.

<snip>
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;
</snip>
my attempt here was to identify and chronicle affordances in use, not set
any particular aspects up as "good" or "desirable", etc. in the case of
indicating protocol-level methods within the affordance, this occurs in
HTML, VoiceXML, and Siren (as yet unregistered MT i'm seeing in a few
places). there may be other designs that support this, too.

<snip>
IMO, that's the opposite of what you want as the client is solely
responsible for the meaning of the messages that it sends.
</snip>
again, i'm not sure of the meaning of this phrase. "what you want" is
addressed to David? me? the LDP folks? everyone?

as for "responsibility" i don't think anything in my H-Factor model assigns
responsibility. however, i'd be interested in hearing more on why you say
that "the client is solely responsible for the meaning of messages that is
sends" i think that's a tautology, but could be missing the point.

Cheers.


mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen


On Fri, Nov 16, 2012 at 10:29 PM, Mark Baker <distobj@acm.org> 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.
>
>