Re: Call for consensus for the pagination design (ISSUE-42)

Hi Markus

>Depends on what you mean by "direct connection". There's the
></an-issue/comments> hydra:view </an-issue/comments?page=3> .
>triple which directly connects the collection to the view.
>I consider inverse properties as an anti-pattern.
>There's no need to materialize an inverse property.
>It is easier to have to look for just a single one instead of two.
>From RDF point of view this is a directed graph:
</an-issue/comments> ----(hydra:view)----> </an-issue/comments?page=3>
You can say that </an-issue/comments> is in hydra:view relation with 
</an-issue/comments?page=3>, but the opposite is much weaker and you can 
only say that </an-issue/comments?page=3> is in some relation with 
</an-issue/comments>.
Depending on the use case - one relation may be more relevant tha the other.

> - each request to different view will modify the original collection by
> providing different members to the collection’s IRI; client could imply
> that the collection changes on every request – I’ve got problem with that

That's true. If it weren't defined differently, the client could indeed 
assume that. We are, however, writing a specification and it exactly defines 
how a client has to interpret such data. If the client doesn't respect the 
specification, all bets are off anyway.

>> This way we may end up that
>> each collection may be a view of itself! Actually I’m keen to agree
>> with that as the collection’s Url is somehow a virtual RDF resource
>> exposes for the sake of ReSTful approach and by definition is a view
>> of something else
>> - how to tell the client on the API documentation level what the
>> collection’s url actually returns? a collection? members of type X? a
>> collection of members of type X?
>Currently you would say it returns a hydra:Collection. I think it would be 
>valuable to be able to express of what type (or shape) the members of the 
>collection are as well.
Good to know.

>> - how to tell the client on the API documentation level on what are
>> other views? pointing only to the first page at that level is
>> irrelevant – client will need either to follow links on each request
>> making the API documentation obsolete or download everything if possible
>> and do the rest on it’s own again making a documentation obsolete
>We will discuss this separately, most likely as part of the discussion of 
>operations. ISSUE-42 (the one we are trying to close as result of this call 
>for consensus) is about the >representation of paginated collections. The 
>modification (or client-initiated selection) thereof will be discussed 
>separately. The reason why I want to keep the discussion really >focused is 
>because we got stuck on ISSUE-42 for way too long. Let's move forward step 
>by step without losing sight of the bigger goals and requirements.
OK.

>Apart from the fact that you associated the member to the view and not the 
>collection it is effectively exactly the same.
>We had this design with PagedCollection but run into problems exactly due 
>to the fact that the members are not associated a single, overall 
>collection.
>Unless you can provide some new insights or arguments why we should go back 
>to the previous design, I think that ship has sailed.
Understand. I acknowledge a collection as a union of all it's views, thus 
view's members are also members of the collection and with that relation 
isViewOf between view and collection. I think I just prefer approach when a 
view (child) knows it's collection (parent) than the opposite - it's much 
simpler to implement when a tree node knows its parent than the opposite. 
Anyway, if that is no more I see no point in returning to that.

>From the other hand, to support your last example it fits better to web 
linking and IANA's rel links as these would be attached to the collection 
itself, as from ReST point of view and assuming that view parameters are 
provided as query string all these Url are related to same ReST resource 
(RDF is in opposition here - it takes IRIs literaly).
Maybe indeed this approach is better.

>So, to summarize it, unless someone presents some new insights or arguments 
>against the proposed design, I think we should go ahead and declare 
>victory.
I think I have all my doubts solved by now.

>We can then either move on to the next item or start a separate discussion 
>on how to extend it if people are interested to do so right ahead.
I think real life scenarios will show if extensions are necessary. But what 
would be the next item?

Regards

Karol Szczepański

Received on Monday, 26 October 2015 21:45:10 UTC