W3C home > Mailing lists > Public > public-ldp@w3.org > June 2013

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

From: Erik Wilde <dret@berkeley.edu>
Date: Tue, 04 Jun 2013 14:57:43 -0700
Message-ID: <51AE62D7.3050102@berkeley.edu>
To: Mark Baker <distobj@acm.org>
CC: Alexandre Bertails <bertails@w3.org>, Henry Story <henry.story@bblfish.net>, Kingsley Idehen <kidehen@openlinksw.com>, "public-ldp@w3.org" <public-ldp@w3.org>

we really cannot redefine how the web works, only because RDF has chosen 
to do things in some ways in which other metamodels have made other 
design decisions. let's try to look at things with a little less "my 
metamodel eats your metamodel for lunch" spirit. i think alexandre asked 
a specific question here, and you guys just squirrel around without 
actually answering his (very simple) question.

On 2013-06-04 14:17 , Mark Baker wrote:
> On Tue, Jun 4, 2013 at 2:26 PM, Alexandre Bertails <bertails@w3.org> wrote:
>> My question was simple and yet you didn't answered it: 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".
> That's the question I answered. I suppose it depends what you mean by
> "interact"; I assume because you were unsatisfied with my response,
> that you have far more in mind than I do about how to interact with
> the LDP specification.
> RDF itself points you to the LDP spec via the namespace for whatever
> LDP term happens to be mentioned in the turtle. But all that tells you
> is the definition of the term. If you're looking for anything else,
> such as conformance criteria, then you're right, there's no way to
> follow your nose from the turtle, there. But it's also not-RESTful to
> do so, and a bad practice for all Web development, as it makes
> messages non-self-descriptive and introduces a high degree of
> client/server coupling.

let's start with a bookmark, a resolvable HTTP URI. you GET it. we have 
two possible paths here, and both are working designs, deployed today on 
the web:

- 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. you need to read the specs to be able to implement a 
client that shows you a "would you like to look at some entries or try 
to delete them" UI.

- a generic media type (one of the RDF ones, let's say text/turtle) 
allows you to construct an RDF model and then you see LDP properties in 
it. interaction affordances a.k.a. links ("use these URIs to engage in 
these interactions by following these interaction rules") will have to 
be exposed through the LDP vocabulary, and again you will need to read 
the spec to understand how that works. nothing in RDF makes any 
statements about how to use HTTP, certainly not at the level that LDP 
needs (non-GET interactions, for starters).

there really is no fundamental difference in dependencies here: at the 
end of the day, somebody needs to implement the spec that allows a 
client to drive its interactions based on the representations it finds; 
there is no way how you can avoid reading the spec in either case. if 
your client implements a vocabulary, you're good to go. if it doesn't, 
your stuck.


Received on Tuesday, 4 June 2013 21:58:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:35 UTC