Re: Pagination (ISSUE-42)

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

Received on Saturday, 14 February 2015 09:07:47 UTC