Re: Filters as views (ISSUE-45)

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):

– A collection is a set of members that somehow logically belong together.
– 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)
– 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.

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. You wrote:

>  {
>    "@id": /collection",
>    "@type": "Collection",
>    "totalItems": 2,
>    "member": [
>      { "@id": "/ruben", "name": "Ruben" }
>    ],
>    "view": {
>      "@id": /collection?page=2",
>      "@type": "PartialCollectionView",
>      "first": "/collection?page=1",
>      "previous": "/collection?page=1",
>      "last": "/collection?page=2"
>    }
>  }

> Okay, I like the above:

>  {
>    "@id": /collection",
>    "@type": "Collection",
>    "totalItems": 2,
>    "member": [
>      { "@id": "/markus", "name": "Markus" }
>    ],
>    "view": {
>      "@id": /collection?n=Markus",
>      "@type": "PartialCollectionView",
>      "totalItems": 1
>    }
>  }

> Here is the point where I start disagreeing.
> (...) I would expect more something like:

>  {
>    "@id": /collection?n=Markus",
>    "@type": "Collection",
>   "totalItems": 1,
>    "member": [
>     { "@id": "/markus", "name": "Markus" }
>    ],
>    "parent": {  // or "viewOf", or "up" (cfr. previous/next)
>       "@id": /collection",
>      "@type": "Collection",
>      "totalItems": 2
>    }
>  }

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 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).

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

On Thu, Jan 14, 2016 at 10:30 AM, Maik Riechert <maik.riechert@arcor.de>
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. Makes more sense to me to
> attach those directly to the collection page.
>
> Cheers
> Maik
>
> Am 13.01.2016 um 22:46 schrieb Ruben Verborgh:
> > Dear all,
> >
> > Here's a first go at definitions:
> >
> > – 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.
> >
> > 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.
> >
> > Best,
> >
> > Ruben
>
>
>