RE: request for verification: paging in TPF

Hi,

> On November 5, 2015 at 11:16 PM Markus Lanthaler <markus.lanthaler@gmx.net>
> wrote:
>
>
> On 5 Nov 2015 at 23:07, Ruben Verborgh wrote:
> >> I find this clear but a bit clumsy.
> >
> > I agree about clumsy.
> > It's hard to strike a balance between clarity and exactness.
> >
> > For instance, do we need "_directly_ following" or not?
> > For sure, everybody assumes this implicitly,
> > but technically, page 4 also follows page 1, just not directly.
> >
> > I like the advice by Manu Sporny in hist post about the JSON-LD spec [1],
> > but I've not been able to obtain it yet in the current document.
> >
> >> What about something along the lines of
> >> this
> >>
> >> If there exists a page following the current page, it MUST be
> >> referenced from the current page using hydra:next. A page referenced
> >> by hydra:next SHOULD NOT be empty.
> >> Still needs some wordsmithing but I think the gist is clear.
> >
> > Maybe we can still do simpler, more instructive. Just trying:
> >
> > The page MUST link to the next page using hydra:next,
> > unless the next page would be empty (then it SHOULD NOT be linked).
> > I think that goes into the right direction. Correct, concise, clear.
>
> I like that. Another minor tweak
>
> The page MUST use hydra:next to reference the next page. If the next
> page
> would be (is?) empty, however, it SHOULD NOT be referenced.
>
 
So to deconstruct this a little, you are in effect saying:
a. If there is a next page, the current page MUST use hydra:next to reference
the next page
b. The first page of a fragment MAY be empty
c. Subsequent pages SHOULD NOT be empty
 
Where by 'empty' we mean that the page contains zero data triples.

>
> >> Should we
> >> really talk about pages here? What about talking about fragments, partial
> >> fragments, fragment views or something similar instead?
> >
> > I think pages is the simplest. They are really pages for me.
>
> Yeah I understand. I just saw all the confusion about "pages" we had in the
> core vocab and think we should try to establish a shared terminology across
> our specifications.
>
>
> > [1] http://manu.sporny.org/2014/json-ld-origins-2/
>
>
> --
> Markus Lanthaler
> @markuslanthaler
>
>
 
John