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