Re: PROPOSAL for ISSUE-66, a way to detect the ldp:Container has updated during pagination

On Wed, Jun 19, 2013 at 2:29 PM, Henry Story <henry.story@bblfish.net>wrote:

>
> On 19 Jun 2013, at 17:57, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
>
> > hello all.
> >
> > On 2013-06-19 1:33 , "Steve Speicher" <sspeiche@gmail.com> wrote:
> >> Discussion yesterday on this issue led an action for me to propose a way
> >> for a client to detect if the LDPC has changed while a client is
> flipping
> >> through the pages.
> >> The proposed solution is for a LDP Server to include in each page a
> >> non-member-property that indicates when the LDPC was last changed.  The
> >> typical piece of data would be the entity tag of the LDPC.
> >> PROPOSAL: Close ISSUE-66, saying to help clients detect when the LDPC
> >> they are paging has changed, servers MAY include <ldpc-uri, ldp:etag,
> >> etag>.
> >
> > this looks like an unfortunate way of designing the protocol. ETags are a
> > part of the web's uniform interface in HTTP, and should be exposed in the
> > way defined by that interface: in the ETag HTTP header. if you hide that
> > information somewhere else, standard HTTP interactions can not take
> > advantage of it, and the main reason why it is exposed in the interface
> is
> > that it can be used in HTTP interactions. the golden rule of REST on the
> > web: if you are exposing interaction semantics, and the uniform interface
> > has a way of exposing them, then expose them through the uniform
> > interface. this way, everybody (*including intermediaries*, who have no
> > idea who's talking to whom) can use it.
>
>
> The ( or a ) semantic web way of thinking about this is the following, what
> would happen if you merge various pages? You'd end up having something like
>
> <> a ldp:Container;
>    ldp:etag "tag1", "tag2", "tag3" ....


> since there is no way of telling which etag is earlier than another,
> this is not giving you what you need logically. You should have something
> from
> the first page to the next version of the first page.
>
> <?firstPageEtag1>  a ldp:Page;
>    ldp:pageOf <.>;
>    ldp:nextPage <?p2Etag1>;
>    ldp:laterVersion <?firstPageEtag2> .
>
> You could build the next pages from the etag, and so always have
> unique pages. If you find an ldp:laterVersion on the first page
> of the series you are following, then you'd know you should start
> again.
>
>
I don't see this as a problem, as a client I have the last page in hand.  I
can first look at the ldp:etag before blindly merging.  This proposal seem
to add a bunch of complexity.  What you have defined I'm not sure works
either, seems like you are painting implementers in a paging model they
that may not want.  For example, a typical pattern I've seen is paging with
page of resources with a certain modification time (yes there are problems
with this but bare with me).
<> a ldp:Page
   ldp:pageOf <../container1>;
   ldp:nextPage <?q=lastModfied<20130608&lastModified>20130601>.

The bake into the ldp:nextPage URL the set of membership triples to fetch.
 I'm not sure how what you propose fits in here or makes it simpler/cleaner.

- Steve Speicher


>
>
> >
> > cheers,
> >
> > dret.
> >
> >
>
> Social Web Architect
> http://bblfish.net/
>
>