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

hello nathan.

On 2012-11-20 11:04 , "Nathan" <nathan@webr3.org> wrote:
>I'm 99.9999999% sure that it's incorrect, <http://example.org/foo?1> and
><http://example.org/foo?2> and <http://example.org/foo> do not all refer
>to the same resource.

yup, you're right, they are different resources.

>>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.
>No matter how you word the specification, they would always be two
>different resources, with two different representations.

not necessarily different representations, but yes, you could GET both,
and would GET different data. in most designs i see, the assumption would
be that /bugs would provide affordances that can take you to
/bugs?inline=bugs:has_bug, and there are three basic patterns i know of:

- you find typed links. for example, in a feed, you might find <link
rel="next" href="/feed.xml/page=2"/> to get to the next page, but since
URIs are opaque, you wouldn't know the construction rule for this URI, so
to get to page 42, you would need to page through 41 "next" pages.

- you find URI templates in some shape or form, which represent the
construction rules that allows you to construct /feed.xml/page=42 directly
from /feed.xml and the URI template that was embedded in there or linked
from there.

- the media type might hardcode patterns (the OpenSearch model) that
clients knowing that media type have hardcoded as well. if you GET
something that is using that media type, you know that you can construct a
URI and it should work as hardcoded in the media type.

getting back to the question of how these resources are linked: in case 1,
both resources are linked by a typed link. in case 2, both resources are
linked by a URI template that is used to create concrete URIs. in case 3,
both resources are linked by URI construction rules hardcoded into the
media type.

cheers,

dret.

Received on Tuesday, 20 November 2012 22:39:25 UTC