Re: Pagination (ISSUE-42)

Just to make sure, this is what we are talking about (at least I am):






2015-02-14 10:07 GMT+01:00 László Lajos Jánszky <laszlo.janszky@gmail.com>:

> I think the minimum information we need to distinguish a Page from the
> whole Collection is a memberOf property or it's inverse: member. (So
> if the Collection contains another Collection as member, then it can
> assume that this member is a page.) Now if we have nested collections,
> then we have hard time to distinguish the items from the pages. That's
> why we have to define a Page class, which should be a Collection
> subclass. My approach would look like something like this in your
> terms:
>
>     {
>         "@id": "http://api.example.com/an-issue/comments?whatever=3",
>         "@type": "Page",
>         "first": "/an-issue/comments",
>         "previous": "/an-issue/comments?whatever=2",
>         "next": "/an-issue/comments?whatever=4",
>         "last": "/an-issue/comments?whatever=498",
>         "member": [
>             {
>                 "memberOf": [
>                     {
>                         "@id": "http://api.example.com/an-issue/comments"
>                     },
>                     {
>                         "@id":
> "http://api.example.com/an-issue/comments?whatever=3",
>                     }
>                 ],
>                 ...
>             },
>             ...
>         ],
>         "size": 20,
>         "memberOf": {
>             "@id": "http://api.example.com/an-issue/comments",
>             "@type": "Collection",
>             "size": 10000
>         }
>     }
>
> (Note that I have almost zero experience with JSON-LD and RDF vocabs. :D)
>
>
>
> 2015-02-12 23:41 GMT+01:00 Markus Lanthaler <markus.lanthaler@gmx.net>:
> > It seems, there's quite some pushback to separate paginated collections
> into collections and pages. My feeling is that even getting rid of the
> PagedCollection type seems to be the preferred approach at the moment. This
> would mean that there's always a sequence of collections but if there's
> just one, there's obviously no need to link to others.
> >
> > Let me try to gauge the preferences by making an alternative design
> proposal:
> >   - remove the type PagedCollection
> >   - rename itemsPerPage to numberItems
> >   - drop the "Page" suffix from firstPage, nextPage, previousPage,
> lastPage
> >
> > I'm a bit worried about dropping the "Page" suffix, but wanted to bring
> it up nevertheless.
> >
> > With this new design, a paginated collection would look like this:
> >
> >   {
> >     "@id": "http://api.example.com/an-issue/comments?whatever=3",
> >     "@type": "Collection",
> >     "first": "/an-issue/comments",
> >     "previous": "/an-issue/comments?whatever=2",
> >     "next": "/an-issue/comments?whatever=4",
> >     "last": "/an-issue/comments?whatever=498",
> >     "member": [ ...]
> >   }
> >
> > What we lose by this is the ability to distinguish whether a single
> "page" or the complete collection was referenced. It would always be the
> complete collection. A client is thus expected to (potentially) retrieve
> the entire collection to find the information it was looking for. AFAICT,
> this shouldn't be a problem in practice as our collection design doesn't
> allow any inferences; all the relationships have to be defined explicitly.
> >
> > Ruben, I would be especially interested in hearing your opinion since
> you created ISSUE-42 [1] and mentioned that by implementing the LDF server
> it occurred to you that the current design is confusing. Do you see any
> practical issues with such a design?
> >
> >
> > --
> > Markus Lanthaler
> > @markuslanthaler
> >
> >
> >
>