Re: relate a Collection and a PagedCollection

Hi Markus,

>> Note how "?page=3" is called a PagedCollection (but is a single page)
>> or how "?page=4" is the "next page" of the PagedCollection (only pages have a next page).
>> or how "?page=1" is the "firstPage" of "?page=3".
> 
> Yeah, I know. A PagedCollection is more like an "abstract" concept.

But this contradicts what you said earlier:

>>> The reason why it is called PagedCollection and not CollectionPage is that I
>>> see a PagedCollection as the sum of all the pages it consists of.

So is it:
a) the sum of all pages
b) a single page
c) both

At the moment, it behaves like c), which is quite unfortunate.

> The "problem" with renaming it to CollectionPage is that then we would indeed
> have to relate each page to a Collection to be able to express things like
> totalItems, firstPage, and lastPage.

That's where blank nodes come in handy:
    :p5 hydra:pageOf [ hydra:firstPage :p1 ].
meaning
    page 5 is a page of something, here is its first page

Seems to make more sense than
    :x hydra:firstPage :p1
which does *not* mean
    "here is the first page of x"
but
    "here is the first page of the thing that :x also is a page of"

> Especially the separation of
> firstPage/lastPage from nextPage/previousPage is something I do not like.

But it *is* like that in the real world.
A book has a first page and a last page.
A book doesn't have a next or a previous page.
Page 5 of the book has a next page and a previous page.
Page 5 of the book doesn't have a first page.

So you have the choice between modeling it as the real world:
- the domain of nextPage and previousPage is Page
- the domain of firstPage and lastPage is Collection
where the definition of those relations is simple:
- nextPage and previousPage get the relating pages of the current page
- firstPage and lastPage get the relating pages of the current collection

Or modeling it in an abstract way
- the domain of nextPage and previousPage is PagedCollection
- the domain of firstPage and lastPage is PagedCollection
where the definition of those relations is complex:
- nextPage and previousPage get the relating pages of the current ”page”
- firstPage and lastPage get the relating pages of the current “collection”

And this last part emphasizes indeed
that the current PagedCollection is a hybrid between a page and a collection.
So truly option c) above. Which is confusing and unclear modeling IMHO.

>>> Well… this certainly looks tidy but do you really need an "entry point"
>>> which just links to the first and last page but doesn't give you any
>>> members?
>> 
>> No, not an entry point, but it should be possible to refer to the
>> collection as a whole.
>> So think identifier (URI), not URL per se.
> 
> This is closely related to rdf:List. Also there you just refer to the first
> node (of type rdf:List) which then points to the next node (which, again, is
> of type rdf:List).

It's not related. With rdf:List, I can point to the list,
and I can point to the individual.

With the hybrid PagedCollection that acts both as a page and a collection,
I can point to neither.

> So I would say if you want to refer to the collection,
> just point to its first page

They are distinct concepts: the book is not the page.

"The item is on page 1"
is different from
"The item is in the book".

> (actually it doesn't really matter to which
> page you link as long as the client is able to find all pages).

I think you're thinking too much about one practical application now.
If the goal is just to find all pages of the collection, well yes… you can do that.
(And you could even do it with much simpler constructs.)

But the question is:
can Hydra correctly describe collections and their pages?
At the moment, it can't.

> Since we are consistent with how both rdf:List Paged Atom Feeds work
> (RFC5005) I'm leaning towards keeping PagedCollections as they are.
> Do you strongly disagree or could you live with that?

Strongly disagree.

First of all, we are not consistent with rdf:List,
because rdf:List distinguishes between the list and its members.
(Furthermore, rdf:List is structured as in Haskell with head/tail,
 so that's different altogether.)

Second: messy modeling.
Concrete concepts would be preferred over an abstract hybrid concept.

RFC5005 was not too picky about modeling BTW:
> "first" - A URI that refers to the furthest preceding document in
>       a series of documents.
A series of documents. Which series?
The series the current document belongs to?

So it actually expresses a relationship between a series
and its first document? But you express it on the current document?
Messy…

Best,

Ruben

Received on Wednesday, 23 April 2014 16:19:59 UTC