Re: forms, direction, query, etc Š

hello all.

On 2012-11-21 00:34 , "Roger Menday" <Roger.Menday@uk.fujitsu.com> wrote:
>This topic - the mechanism of discovering from a resource what can be
>done to it, and then doing it - has surely to be on the table for LDP (?)
>Not all the solutions require SPARQL, I am quite sure of that.

yes, this problem very clearly needs to be solved. and it's the most
challenging problem because we don't have a good framework we can just
use. for building data vocabularies, there's a lot of experience and
people do it all the time. for building interaction patterns (i.e.,
protocols), we have to find a path that works for us.

once we have the LDP model nailed down (the informal model in section
ISSUE-37, which describes both the data model and the interaction model of
the LDP protocol, it's basically the description of the media type), we
know *what* we need to build in terms of affordances. then we can decide
*how* to build it.

>In my opinion, it MUST be possible to build a single generic client,
>which can successfully be used to navigate and negotiate any LDP
>"service". that's the test for having done RESTful Linked Data, IMO.

yes, absolutely agreed. if generic clients are not possible, we have
failed. another test we have to pass is: when you build a client *or* a
server, what are the implicit implementation environment requirements we
defined for either side by making certain design choices? we should try to
minimize these in order to minimize coupling, and allow LDP to be used for
the largest possible set of implementations. for example, if i have an
existing platform that makes information available through feeds, can i
add a layer and also provide LDP-based access?

cheers,

dret.

Received on Wednesday, 21 November 2012 17:45:05 UTC