Re: ldp-ISSUE-38 (filtering, inlining): filtered representations and inlining [Linked Data Platform core]

hello roger.

On 2012-11-19 09:19 , "Roger Menday" <roger.menday@uk.fujitsu.com> wrote:
>This specific issue wasn't about the 'storing' (the 'write') part.
>I was specifically concerned with the reading part.

given that LDP is a service and a service should only expose its service
surface, you cannot make any assumptions that you reach deeply into some
back-end storage. all you can interact with are LDP concepts, unless the
service exposes additional affordances that give you more interaction
capabilities.

>e.g. from GET /bugs, I'll get a list of links to individual bugs, but,
>then I need to cycle through the list to find out about each one. But, if
>I do GET /bugs?inline=bugs:has_bug, then I can make this more efficient.
>One question is related to issue.32: how can I discover this (rather then
>have query string construction algorithms).

REST would require you to expose this in a way that clients can construct
those URIs at runtime, just by interacting with the LDP server. since you
cannot assume any specifics about the back-end, all you could do is have a
framework for how servers can expose additional interaction affordances,
in this case probably through a URI template. and then there would be a
magical parameter that would be entirely opaque to LDP, that would be
exposed by the LDP service. we are currently just in the process of
designing such a "query template" media type (so that exposing query
capabilities becomes a little bit easier because there's a standard way of
doing it), but afaict, there is no such thing around at this point in time.

cheers,

dret.

Received on Monday, 19 November 2012 21:37:18 UTC