W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2012

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

From: Roger Menday <roger.menday@uk.fujitsu.com>
Date: Mon, 19 Nov 2012 17:19:53 +0000
CC: Linked Data Platform Working Group <public-ldp-wg@w3.org>
Message-ID: <32A83E4A-2AE9-4F60-8511-D5D77FB09038@uk.fujitsu.com>
To: "Wilde, Erik" <Erik.Wilde@emc.com>
>> 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). 


> cheers,
> dret.

Received on Monday, 19 November 2012 17:20:46 UTC

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