RE: Filters as views (ISSUE-45)

Replying to whole a lot of mails at once which unfortunately makes this mail
rather long.

On 13 Jan 2016 at 23:23, Ruben Verborgh wrote:
>>> Negative points (for me):
>>> - filter as a boolean on parameters just won't cut it.
>> 
>> I agree and mentioned that in my initial mail:
>> 
>>  On 10 Jan 2016 at 18:13, Markus Lanthaler wrote:
>>  This is easily expandable. We can either allow more complex values for
>>  hydra:filter or introduce additional properties.
> 
> Okay, but what is the meaning then of:
> - hydra:filter?
> - a boolean as value of hydra:filter?
> I just don't understand how to interpret this.

Interpret it as "this parameter acts as a filter, multiple filters are
combined with AND".


On 13 Jan 2016 at 23:46, Ruben Verborgh wrote:
> Here's a first go at definitions:

Thanks for taking the time to write these down


> - A collection is a set of members that somehow logically belong
> together.
> - A view is a subset of those members of a collection that
> satisfy a particular condition.
> - A page is a view that selects members
> based on their position in a specific ordering of the collection.

I'm fine with those (modulo some minor wordsmithing to avoid that views are
collections, Pierre-Antoine's tweaks fix that).


> Alternative definition of view if it is going to be a subclass of
> collection:
> - A view is a collection which contains those members of a parent
>   collection that satisfy a particular condition.
> I would really argue for this, since then we can reuse all the
> collection stuff on view.


On 14 Jan 2016 at 10:30, Maik Riechert wrote:
> +1 to the alternative definition, seems more clean. I always found it
> strange that the current "view" definition doesn't really contain
> anything, except the navigation controls.

The reason for that is to have the members attached to the collection
itself:

   /collection hydra:member a, b, c, ...

instead of

   /collection?page=1 hydra:member a
   /collection?page=2 hydra:member b
   /collection?page=3 hydra:member c
   ...

and none attached to /collection itself.


On Thursday, January 14, 2016 8:14 PM, Pierre-Antoine Champin wrote:
> Hi all, I ended up with a rather long mail, so here is the executive
> summary: I propose to refine Ruben's definitions as follow (including
> a definition of 'parent', required by Markus):

Moved the parent stuff further down


> - A collection is a set of members that somehow logically belong together.
> - A view on a collection is a resource describing a subset of the members
>   of that collection, based on a particular condition.
> - A page is a view that selects members based on their position in a
>   specific ordering of the collection.

These definitions would be fine for both proposals AFAICT. 


> Now for the detail:
> I am a bit confused, Ruben, because it seems to me that yout
> alternative definition contradicts one of your previous points.

[...]

> So there is IMO an important difference of nature between
> </collection?page=2>, which describes members of </collection>, and
> </collection?n=Markus>, which describes members of itself, and

That's exactly the point were we seem to disagree. To me /collection?page=2
is no different than /collection?n=Markus in that regard. Both describe
members of /collection.


> indirectly relates them to </collection> (through its 'parent'
> relation). For me, the notion of "view" captures the former idea,
> while the notion of "collection" captures the latter (while a
> collection may have no parent, of course).

I agree with that, but does it need to be that way?


> This is why I don't understand Ruben's alternative definition, which
> conflates views and collections.
> 
> Just to be sure I understand each one's point of view correctly:
> * Markus would like to have only basic collections (no notion of parent),
>   and unify all searches, filters and pages as views.

Right. I would like to unify all ways to look at the same data under the
umbrella of views.


> * Ruben would like to keep searches/filters as full-fledge collections
>   (while explicitly relating them to their parent collection), and keep
>   the notion of view for paging only -- thus renaming them "pages"
>   instead of "views".
> 
> Did I get it right?
> 
> I tend to lean towards Ruben's model: I like the idea that filtered
> collections can be handled by a client as a first-class collection,
> without having to care about the fact that it is part of a larger
> collection.

Wouldn't the same apply to "pages" as well? Anyhow, also with views a client
would handle collections as a first-class collection. The only difference is
the URL it uses to GET the collection.


> I would not discard so quicky the notion of "view", though; I'm not
> convinced that there are no other use-cases than paging.

I think what I would like the least is having abstract concepts like views
for some features and highly specific ones for a select few. Where would we
draw the line?


On 14 Jan 2016 at 20:34, Ruben Verborgh wrote:
> On Thursday, January 14, 2016 8:14 PM, Pierre-Antoine Champin wrote:
>> - A collection may have a parent collection, which is a superset of
>> that collection (every member of the collection is also a member of
>> the parent)
> 
> Possible gap: is every collection that has a parent collection
> necessarily a view? If not, do you have an example?

The definition doesn't talk about views, I assume you are interested in the
behavior. While the definition above ensures that all members of the
filtered collection (child) are also members of the collection itself,
additions would be unambiguous. Removals aren't though. If a client removes
a member from the child collection, is it automatically removed from the
parent collection as well?


[...]
> I'm okay with following Markus' new proposal,
> but I additionally suggest making view a subclass of collection
> (unless somebody can make a definition that allows distinguishing either).

That would probably mean that we would need to change pagination again to
have a uniform design (it would also mean that views only work for
collections, but we can avoid that by just making PartialCollectionView a
subclass of collection).

So, let's assume there's an an issue. The client goes and retrieves it. It
would get the following statement:

  /an-issue :comments /an-issue/comments

With the current pagination design, the client would then do a
GET /an-issue/comments which would yield (taken directly from the spec):

  {
    "@context": "http://www.w3.org/ns/hydra/context.jsonld",
    "@id": "http://api.example.com/an-issue/comments",
    "@type": "Collection",
    "totalItems": "4980",
    "member": [
      ... a subset of the members of the Collection ...
    ],
    "view": {
      "@id": "http://api.example.com/an-issue/comments?page=3",
      "@type": "PartialCollectionView",
      "first": "/an-issue/comments?page=1",
      "previous": "/an-issue/comments?page=2",
      "next": "/an-issue/comments?page=4",
      "last": "/an-issue/comments?page=498"
    }
  }

So the members are associated to the collection, not the view. How would you
envision that to work look like when PartialCollectionView is a subclass of
Collection? Where would you put the first/previous/next/last links? Where
the totalItems count (of both the page and the entire collection)?



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 14 January 2016 21:28:39 UTC