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