- From: Erik Wilde <dret@berkeley.edu>
- Date: Wed, 05 Jun 2013 12:20:39 -0700
- To: "public-ldp@w3.org" <public-ldp@w3.org>
- CC: Mark Baker <distobj@acm.org>
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.
Received on Wednesday, 5 June 2013 19:21:00 UTC