Re: Proposal to close ISSUE-19: Adressing more error cases, as is

We have several open issues related to affordances which should be a clear 
indication that the WG is aware that as it stands the spec is deficient in 
this regard.

I wish everyone would recognize that there are different ways this problem 
can be addressed and accept that every solution has its pros and cons we 
need to take into consideration.

Erik posted a summary of how he sees this:
http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0325.html

We also have a wiki page on the topic:
http://www.w3.org/2012/ldp/wiki/ISSUE-32

And John has posted some additional info to the WG list:
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0139.html

For what it's worth I consider this to be one of the two major issues left 
for us to tackle before we can go to Last Call.

Regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   mike amundsen <mamund@yahoo.com>
To:     Erik Wilde <dret@berkeley.edu>, 
Cc:     "public-ldp@w3.org" <public-ldp@w3.org>, Mark Baker 
<distobj@acm.org>
Date:   06/05/2013 01:27 PM
Subject:        Re: Proposal to close ISSUE-19: Adressing more error 
cases, as is
Sent by:        mca@amundsen.com



PMFJI, but i just want to say that, based on what i've seen of the LDP 
spec[1], LDP responses have such a low degree of self description and such 
a high degree of "surprisal"[2] that it's appeal to me is limited to that 
of simply following immutable links. If that's the primary goal, then I 
think you're on the proper path. 

However, if what you're working on is creating a spec that is meant to 
support both reading and writing data using something other than a one-off 
"bespoke" client, then I think you're missing some important runtime 
affordances. To that end, I think Erik (and Alexandre) are asking the 
right questions.

Just my POV.

Cheers.


[1]http://www.w3.org/TR/ldp/
[2] http://en.wikipedia.org/wiki/Self-information


mamund
+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 Wed, Jun 5, 2013 at 3:20 PM, Erik Wilde <dret@berkeley.edu> wrote:
hello mark.


On 2013-06-05 10:16 , Mark Baker wrote:
On Tue, Jun 4, 2013 at 5:57 PM, Erik Wilde <dret@berkeley.edu> wrote:
- a specific media type such as application/atom+xml points directly to 
the
spec that will allow you to understand how you can drive future 
interactions
(such as "i can now try to GET an entry, and since it has an 'edit' link, 
i
can also try to DELETE it") based on what you find in the representation.
That's not the case. Any URL can be DELETEd a priori without knowledge
of Atom or what rel=edit means. The resource may not be deleted of
course, due to permissions (e.g. 401), capability (e.g. 501), or other
issues, but that doesn't change the fact that the message's meaning is
unambiguous and required no additional information beyond the URI
itself.

c'mon mark, you're better than this. you cannot conveniently cherry-pick 
the one method that is hard-coded and requires no request body, and ignore 
all the much more interesting interactions you need in real-world 
applications where you need to know what you can and cannot PUT, POST, or 
PATCH, and what it actually means to do that.


what is the general mechanism that tells me how to go from "this is 
text/turtle" to "I can interact with it as defined in the LDP spec">
So to try to answer that again :) ... the mechanism is term grounding
via namespaces in RDF, but that only takes you to the tiny part of the
spec that defines that term; it cannot and should not inherit all the
conformance criteria of the totality of the referenced specification
(because there shouldn't be any there, as I've said before) or
anything else that would, in effect, change the (uniform) interface.

that's basically kingsley's argument saying that "since RDF can describe 
anything and everything this will probably also work. somehow. i am just 
not telling you how." so, please treat alexandre and me to explaining how 
the general model you're referring to solves the concrete question of 
figuring out (at runtime!) how interactions based on methods such as PUT, 
POST, and PATCH work, without having any prior knowledge of the vocabulary 
that's being used.

thanks,

dret.