Re: Call for consensus for the pagination design (ISSUE-42)

Hi Dietrich,

Am 21.10.2015 um 19:00 schrieb Dietrich Schulten:
>
>
> Am 21.10.2015 11:40 schrieb elf Pavlik <perpetual-tripper@wwelves.org>:
> >
>
> >
> > We could also mention that this only applies to 'default paging', in
> > case of using some alternative paging mechanism. Response from:
> >
> > GET /an-issue/comments
> >
> > may include some other kind of view on that particular collection. For
> > example chat messages posted to this collection (ChatChannel) today 
> with
> > prev control to show them day by day. Similar to what we can see on
> >
> > http://socialwg.indiewebcamp.com/irc/social/2015-10-20
>
> That is an interesting point. A microblog server may choose to respond 
> with a view that represents the current day as the initial response, 
> i.e. the last page is the first view the client receives. An event 
> service might respond with current events as the first page and allow 
> to go to the past and the future from there.
>
> Proposal: "the client must not make assumptions which partial view it 
> receives as initial response, it has to rely on available navigation 
> controls".
>
+1
>
> But this poses a question. Currently we have only the page number to 
> qualify the current view. Somehow I want to be able to recognize that 
> I am back at the initial page. Can the initial page be No.  0, with 
> positive and negative page numbers? Should the PartialCollectionView 
> have an optional title which could give a human readable string like 
> 'Today' , 'Yesterday' , 'Tomorrow' or so - or maybe even a predicate 
> to say exactly which range I am looking at? The latter gets 
> complicated fast ;)
>
To get to know whether you are on the first, page, why not just look at/ 
compare with the "first" link?
Why not provide the title as dct:label or rdfs:label?
I can well understand the latter problem you describe, it would be very 
nice to make the client more aware of the semantics behind the paging scheme
so that it can freely choose it according to it's own needs. This would 
be very useful if a client
is looking only for data in a certain time frame for example.
The problem with this is that Hydra should not become an API querying 
vocab I think; but this would effectively happen if we only start with a 
single predicate like this
(ok, there is freetextQuery but this is very generic and for me a 
compromise to have a very common concept in the vocab before there are 
established alternatives).
Some approaches that can do a better job:

- TPF
- OData  (not sure whether there is an RDF based vocab yet)
- SPARQL

But we all know the issues associated with the latter two at least.

Received on Thursday, 22 October 2015 05:18:35 UTC