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

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,
>>>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).
>Above I see two URIs, referring to two different resources, perhaps two
>LDP(C/R)s.

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

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

cheers,

dret.

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