W3C home > Mailing lists > Public > public-ldp-wg@w3.org > June 2013

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

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 19 Jun 2013 20:29:24 +0200
Cc: Steve Speicher <sspeiche@gmail.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-Id: <7036B375-9CA9-42BD-B22E-15167456A690@bblfish.net>
To: "Wilde, Erik" <Erik.Wilde@emc.com>

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.

 

> 
> cheers,
> 
> dret.
> 
> 

Social Web Architect
http://bblfish.net/
Received on Wednesday, 19 June 2013 18:29:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:51 UTC