- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Tue, 03 Feb 2015 08:29:02 +0000
- To: public-hydra@w3.org
Forwarding to list February 2 2015 11:49 PM, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote: > Hi folks, > > As announced (and promised) for a while, I would like tackle pagination > next. While implementing Linked Data Fragments, Ruben made an interesting > observation, namely that by just giving someone the URL of a > "PagedCollection" it is unclear whether it is a single "page" or a > "collection of pages". His proposal was to rename hydra:PagedCollection to > hydra:Page and to introduce two new properites hydra:pageOf and > hydra:hasPage. A paginated collection would then look as follows in JSON-LD > > { > "@id": "http://api.example.com/an-issue/comments?page=3", > "@type": "Page", > "previousPage": "/an-issue/comments?page=2", > "nextPage": "/an-issue/comments?page=4", > "pageOf": { > "@id": "http://api.example.com/an-issue/comments", > "@type": "Collection", > "firstPage": "/an-issue/comments?page=1", > "hasPage": "/an-issue/comments?page=4", > "lastPage": "/an-issue/comments?page=498" > }, > "member": [ ...] > } > > In contrast, with the current design it would look as follows > > { > "@id": "http://api.example.com/an-issue/comments?page=3", > "@type": "PagedCollection", > "firstPage": "/an-issue/comments", > "previousPage": "/an-issue/comments?page=2", > "nextPage": "/an-issue/comments?page=4", > "lastPage": "/an-issue/comments?page=498", > "member": [ ...] > } > > The advantage of Ruben's proposal is that it becomes possible to address the > whole collection as well as individual pages. With the current design that's > not possible. The property referencing a PagedCollection would need to > define what is meant. The advantage is an overall simpler design that aligns > more closely with what developers are used from Atom or even HTML pages. > > Another design I have been tinkering with was to rename PagedCollection to > something like PartialCollection and *perhaps* move the pagination controls > into a separate resource or blank node: A I was actually thinking that given a separate Page class we will only need a single type of Collection. I actually see now that in the example above you did write { "@id": "http://api.example.com/an-issue/comments?page=3", "pageOf": { "@id": "http://api.example.com/an-issue/comments", "@type": "Collection", } Do we really require PagedCollection/PartialCollection? Also I don't think that moving pagination links to a separate object is necessary. I think that paging controls could belong on both Collection and Page. Otherwise it seems that there isn't one place to look for say firstPage. > { > "@id": "http://api.example.com/an-issue/comments?page=3", > "@type": "PartialCollection", > "pagination": { > "firstPage": "/an-issue/comments", > "previousPage": "/an-issue/comments?page=2", > "nextPage": "/an-issue/comments?page=4", > "lastPage": "/an-issue/comments?page=498" > }, > "member": [ ...] > } > > I would propose we collect alternative designs and then discuss all of them. > I created a Wiki page to collect the designs. > > https://www.w3.org/community/hydra/wiki/Pagination > > If you have something to propose, please add it to the page but *also* send > it to the mailing list. I would say we collect designs till the end of the > week and start discussing them beginning of next week. I'm also open to > other proposals on how to address this process-wise. > > Cheers, > Markus > > -- > Markus Lanthaler > @markuslanthaler
Received on Tuesday, 3 February 2015 08:29:55 UTC