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

Hi

Following your interesting discussion...

>I would have expected hydra:first to be the first view in the series,
>but following Elf, the @id of the collection can point to any page in
>the series, as the server chooses. In that case looking at hydra:first
>won't tell me if I am in the initial view.
>I just realized that there is no hydra:pageNo where we could say that
>the initial page is always no. 0 :-)
Actually with partitioning based i.e. on dates we cannot talk about pages!
These are indeed partial views but I hesistate to call it a page when the 
view is on daily basis.
Still, this doesn't change the general concept of a hydra:view.
The question is, shall these cases with different partitioning schemes be 
elevated to specific views?
Or are these just separate resources provided by the API? Consider these 
examples:
http://temp.uri/api/posts?page=1 - standard paging
http://temp.uri/api/posts?date=2015-10-22 - should be this rised as hydra 
view mechanism?
http://temp.uri/api/posts/2015-10-22 - or should it be a feature of the API 
to be implemented by the developer
http://temp.uri/api/posts/2015-10-22?page=1 - this still can be paged!
Still, it might be worth of having something in hydra to tell client on how 
to construct some iri templates. I can imagine these situations:
http://temp.uri/api/posts?page={?page} where ?page maps to vocab:pageNo
http://temp.uri/api/posts/{?year}/{?month}/{?day} - where ?year, ?month and 
?day maps to vocab:year, vocab:month, vocab:day
http://temp.uri/api/posts?filter={?freetextSearch} where ?freetextSearch 
maps to hydra:freetextSearch
http://temp.uri/api/posts?order-by={?property} where ?property maps to 
vocab:property
This enables client to handle and combine these effectively. I hesistated to 
put all of these into hydra, but haview few extra predicates in an extension 
is of no use either.

>> 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;
>absolutely not. So many variations, and really orthogonal to Hydra Core.
Well, hydra should not become a querying API, but should provide few simple 
mechanisms to address common scenarios experienced in the wilderness.

>>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

Ugh, these are heavy tools. SPARQL is not ReSTfull (yes, it supports GET and 
POST etc., but is not resource oriented) and it enforces it's own result set 
format.
OData unless some ORM like approach is used won't work with pure RDF (I 
think), TFP is something that I'm not familiar with thus I'll leave comments 
to other.
OpenSearch seems not to be ReSTfull as well.
None of these solutions in my opinion fits to restful APIs.

Regards

Karol Szczepański

Received on Thursday, 22 October 2015 20:21:15 UTC