Re: Pagination (ISSUE-42)

> On Feb 3, 2015, at 10:14 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:
> 
>> Again, IMO, separate Page and Collection types is probably going too far
> 
>> Each Collection resource provides first/last/previous/next links, as well as itemsPerPage/totalItems.
> 
> The above statements seem mutually exclusive to me:
> the previous and next relationships should be functional,
> but if they are attached to the collection, they are not.
> If they are attached to the page, then the page is a separate type.
> 
> Concretely, we can't meaningfully have:
>   </collection> :nextPage </collection/page/2>
> and
>   </collection> :nextPage </collection/page/3>
> at the same time.
> 
> We can have
>   </collection/page/1> :nextPage </collection/page/2>
> and
>   </collection/page/2> :nextPage </collection/page/3>
> and then we can still choose whether we attach
> :firstPage and :lastPage to the collection or a page.

This sort of gets to the "is a Collection an RDF resource" bit, as it's really intended to convey semantic relationships between subject and object. However I don't see an issue here, as you'd have the following:

</collection> :nextPage </collection?offset=10> .
</collection?offset=10> :nextPage </collection?offset=20> .

They are all typed Collection, but are distinct "resources" from an operational perspective. As I said, within the underlying datamodel I don't think they persist.

>> We also don't need to mandate what query parameters are used, and could simply be "?page="; why should a client care? It's entirely determined by the collection metadata.
> 
> Exactly. Note that :nextPage could even be "?offset=200&limit=100";
> so even if the API supports offset/limit, we can still do simple paging.
> This approach is currently taken in http://data.kbodata.be/fragments.
> 
> Best

+1

Gregg

> 
> Ruben

Received on Tuesday, 3 February 2015 20:29:52 UTC