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: Wilde, Erik <Erik.Wilde@emc.com>
Date: Mon, 19 Nov 2012 16:36:40 -0500
To: Linked Data Platform Working Group <public-ldp-wg@w3.org>
CC: Roger Menday <roger.menday@uk.fujitsu.com>
Message-ID: <CCCFE4FA.BD62%erik.wilde@emc.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:42 UTC