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

>> ldp-ISSUE-38 (filtering, inlining): filtered representations and inlining
>> [Linked Data Platform core]
>> http://www.w3.org/2012/ldp/track/issues/38
>> Raised by: Roger Menday
>> On product: Linked Data Platform core
>> Section 5.1.2 describes a how to retrieve non-member properties of a
>> resource. It might be good to generalise retrieving a 'filtered'
>> representations. An further extension might be a way of specifying how to
>> "inline" representations of linked resources.
> 
> repeating my IRC comment for the issue tracker log: AtomPub has a model
> for that as well, which is that the client decides how to add entries
> (inlined or referenced), and this is opaque for the server. the server
> just operates on the structures known to the service, so it just blindly
> regurgitates whatever has been stored by clients. that's the only job the
> server has: accept things, and then retrieve them on demand. if we want to
> implant any specific knowledge of the things we manage into the server, we
> have made the problem much much bigger.

This specific issue wasn't about the 'storing' (the 'write') part.  
I was specifically concerned with the reading part. 

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

Roger

> 
> cheers,
> 
> dret.
> 
>