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

hello 

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

Did I say something to suggest otherwise .. ? 

I'm definitely *not* making assumptions about the back-end, only that it can get exposed as a Graph. That's it. 

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

I would be interested in seeing that ... where is this design at the moment ? 

I think that something link driven must be possible. i.e. like on a shopping site, where the facets change according to which other facets are selected previously, etc etc ... I think that this kind of mechanism can be copied, such that the query strings can be "built up". 

regards, 
Roger

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