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

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

hi Mike, 

It's been clear to me for a while now, that we (LDP) are going to fall short on delivering all of what you describe above. Some the pieces are missing. FWIW, I believe that it we will be able to address that kind of thing in follow-up activity. 

Roger


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