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: Tue, 20 Nov 2012 12:57:38 -0500
To: Linked Data Platform Working Group <public-ldp-wg@w3.org>
CC: Roger Menday <roger.menday@uk.fujitsu.com>, "nathan@webr3.org" <nathan@webr3.org>
Message-ID: <CCD102EE.C322%erik.wilde@emc.com>
hello nathan.

On 2012-11-20 2:38 , "Nathan" <nathan@webr3.org> wrote:
>>>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,
>>> I do GET /bugs?inline=bugs:has_bug, then I can make this more
>>> One question is related to issue.32: how can I discover this (rather
>>> have query string construction algorithms).
>Above I see two URIs, referring to two different resources, perhaps two

these are two URI references referring to the same resource, one having a
query parameter, the other not having one. when dereferenced, both result
in interactions with the same resource.

>There is no relation between the two URIs any more than there is between
><x> and <y>.

why would there be no relation? they refer to the same resource, that's a
pretty strong relation.

>If there is any relation between the two resources, then it should be
>expressed in a visible way, not based on magic that's hidden behind the
>uniform interface.

the visible way is the media type or whatever we create that is ts
equivalent. i.e., a client would need to be able to find out at runtime
that there is a query parameter called "inline", and what its allowable
values are. the uniform interface just tells you that you must expose this
information in a way that allows a generic HTTP client to GET it, but that
client would need to understand LDP concepts to understand the URI

>The ldp: vocabulary already provides a way to expose the relation
>between the two LDPRs, using ldp:membershipSubject and
>ldp:membershipPredicate. What else is needed?

sorry, i don't quite follow you here. there has to be some way how a
client knows that composing the URI /bugs?inline=bugs:has_bug is a
sensible thing to do, right? how would it know that, without
knowing/finding rules how to do that?


Received on Tuesday, 20 November 2012 17:58:25 UTC

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