Re: Trying to close ISSUE-14

hello all.

On 2013-04-03 12:17 , "Steve Speicher" <sspeiche@gmail.com> wrote:
>In thinking about it more as well, I see it as that as well (adding
>some protocol behavior into the representation).  If a client happens
>to take the triples and store what it gets as-is with these ldp:index
>triples, it then needs to understand that if it is mixing updates from
>further fetches of resources and that ldp:index value changes, it is
>then undefined for the first container/page representation.  I client
>that stores these resources, may decide to strip any triples with
>ldp:index as the predicate without concern.

just as an analogy: many data-driven web sites have rich interaction
support, allowing you to search, filter, sort, and view data in many and
rich ways. that's very useful, but looking at the REST side of this, when
i see a page containing the description of something (let's say a
government agency), that page mixes the description itself with (very
helpful) information about "see what other people looking at this agency
looked at", "related agencies", "how many time was this viewed". this is a
very rich way of putting the agency into the context i am currently
navigating: data exploration. in many cases, this is all i want.

however, if i want a "pure data view", then some sites have "download" or
"view item" links that will take you to de-contextualized representations,
at least de-contextualized from the browsing service (some links such as
"related agencies" might still be in there, of course). that latter part
often isn't even there, but maybe that "here's the naked data" link is one
design pattern that might be interested. stripping the naked data from the
contextualized representations may be hard, in particular when we get into
the tricky areas where you might have ldp: triples that actually are part
of the naked data (for example in a collection of LDP sample data).

cheers,

dret.

Received on Wednesday, 3 April 2013 20:33:11 UTC