Re: Pagination of non-collections

Hello Ruben, Tomasz, Andrew.

Assuming I correctly understand the purpose of TPF, it looks to me like a
decent amount of integration between TPF endpoints and subject pages might
result in APIs that do not need a dedicated pagination construct.

Example: assuming we had a TPF endpoint at http://example.com/tpf and
http://example.com/alice knew too many other persons, wouldn't it be enough
to have something like:

GET http://example.com/alice#me

{
  "@context": {
    "subjectOf": {
      "@reverse": "ex:subject"
    }
  },
  "@id": "http://example.com/alice",
  "ex:subjectOf": [
    {
      "@id": "
http://example.com/tpf?s=http://example.com/alice&p=http://xmlns.com/foaf/0.1/knows
",
      "ex:predicate": "foaf:knows"
    }
  ]
}

and have the TPF endpoint output the TPF in JSON-LD ?


--

Jacopo Scazzosi
Developer
http://www.jacoscaz.com

On Sun, Feb 15, 2015 at 3:03 PM, Ruben Verborgh <ruben.verborgh@ugent.be>
wrote:

> Hi Tomasz,
>
> > We all concern ourselves with collections. But what about another kind
> of resources which are large enough so that it may be served in multiple
> smaller chunks. Like an object with multiple collections. Each collection
> may be small but together the size becomes significant.
> >
> > /person/Tomasz
> > /person/Tomasz/friends
> > /person/Tomasz/interests
> > /person/Tomasz/projects
> > /person/Tomasz/hobbies
> > /person/Tomasz/family
> > etc.
> >
> > Each URI above could contain a partial view of
> > /person/Tomasz and they would be linked by some custom properties.
>
> Note that the cases above are all covered by Triple Pattern Fragments:
> ask for triples with subject /person/Tomasz and the predicate of your
> choice.
>
> > Isn't this similar to paging collection?
>
> Similar, but not the same.
> Paging is extremely universal; it even transcends the Web.
>
> > My point is that a lot of time is being invested to define one very
> specific way for addressing partial representations (of collections) while
> a more general approach could be possible to tackle a multitude of similar
> cases.
>
> Sure, there might be a larger abstraction layer somewhere,
> but paging seems a more core concern than your case.
> Simple proof: you can apply paging to all of your examples
> (e.g., /person/Tomasz/friends?page=2),
> but your examples do not apply to all pages.
>
> > At the same time Hydra clients can be kept simpler because there is a
> general way for doing partial representation and for everything else there
> already are Links and IriTemplates...
>
> I don't think they would be simpler, because paging
> would almost certainly become more complex
> because of the added abstraction layer,
> and paging is—as argued above—more common by far.
>
> Best,
>
> Ruben
>