Re: Filters as views (ISSUE-45)

Hi Markus,

> I think the definitions we currently have in the spec are mostly fine
> (emphasis mine):
> 
>  A collection holding references to a number of related resources.
> 
>  A PartialCollectionView describes a partial view of a Collection. Multiple
>  PartialCollectionViews **can** be connected with the the next/previous
>  properties to allow a client to retrieve all members of the collection.

For me, those definitions are not enough
to distinguish between a collection and view.
If I derive something from a collection,
is that by definition a view or not?

If something is connected with next/previous,
is it by definition a view or not?

If something allows creating more specific views,
is that thing by definition a collection or not?

Are views also (a kind of) collections?

What is the tangible difference between a view and a collection?
(Asking this because views seem to share some properties of collections.)

Without a definition that answers these questions,
it's hard to meaningfully discuss anything.
We need to get this straight.

>  {
>    "@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:
– the page is describing the collection (and a part of its members)
– the page is a view of the collection

>  {
>    "@id": /collection",
>    "@type": "Collection",
>    "view": {
>      "@type": "ViewTemplate",
>      "template": "/collection{?n}",
>      "mapping": {
>        "variable": "n"
>        "property": "name"
>        "filter": true
>      }
>    }
>  }

Positive points (for me):
– the idea that the collection has a more specific subordinate resource
   (we had this already with [filter as a subproperty of] hydra:search)
Negative points (for me):
– filter as a boolean on parameters just won't cut it.
   This is not apparent from the above example,
   because there is only one property.
   With multiple properties, the desired default semantics is "AND",
   but this cannot be realized with a property attached to individual parameters.

BTW, would your proposal mean that hydra:search becomes extinct?

As far as the above example is concerned,
I like the modeling of "a collection has subordinate resources" idea.
However, whether such subordinate resources are views
(and not simply [sub-]collections), depends on the definitions.

> This would tell a client, that it can filter the members of /collection by
> the property "name" (could be mapped to schema.org/name for instance).
> The GET /collection?n=Markus would then yield this result:
> 
>  {
>    "@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.
(Thanks BTW for the examples, they allow me to break down my arguments.)

That design obliges clients to be aware of views,
whereas "the collection of things named Markus"
could just be approached as a collection.
For some use cases, it might not matter
that this thing is a view of some other collection;
for all the client knows, this is just another collection.

So 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
   }
 }

For me, there really *is* a difference with paging:
– the goal of paging is to view one collection as multiple parts
– the goal of filtering is to obtain one subset of one collection

> I added totalItems to the PartialCollectionView as we discussed previously.
> Now let's assume the collection is much bigger and the server decides to
> paginate the filtered result. The response would then look as follows (I
> omit the template for clarity, but just as before, it could obviously be
> included):
> 
>  {
>    "@id": /collection",
>    "@type": "Collection",
>    "totalItems": 2489,
>    "member": [
>      { "@id": "/markus", "name": "Markus" },
>      ... other members that match the filter ...
>    ],
>    "view": {
>      "@id": "/collection?n=Markus",
>      "@type": "PartialCollectionView",
>      "totalItems": 58
>      "first": "/collection?n=Markus",
>      "next": "/collection?n=Markus&page=2",
>      "last": "/collection?n=Markus?page=6"
>    }
>  }

The view also has a totalItems property;
note that this makes the view a collection:
http://www.hydra-cg.com/spec/latest/core/#hydra:totalItems


In my proposal, it would simply be the same mechanism
as for the parent collection:

 {
   "@id": /collection?n=Markus",
   "@type": "Collection",
   "totalItems": 58,
   "member": [
     { "@id": "/markus", "name": "Markus" },
     ... other members that match the filter ...
   ],
   "view": {
     "@id": "/collection?n=Markus&page=1",
     "@type": "PartialCollectionView",
     "first": "/collection?n=Markus&page=1",
     "next": "/collection?n=Markus&page=2",
     "last": "/collection?n=Markus&page=6"
   },
   "parent": {  // or "viewOf", or "up" (cfr. previous/next)
     "@id": /collection",
     "@type": "Collection",
     "totalItems": 2489
   }
 }

Since "view" in this proposal is only used for paging,
it could be renamed accordingly.

Summarizing, what I propose is:
– there are only collections
– collections can be filtered to more specific collections
– collections can have a parent
– pages of a collection are just pages of a collection

Both ideas might be reconciled if views _are_ collections.

My open questions for your proposal are:
– precise definitions of collection and view
– how filter can be used with multiple attributes (using AND semantics)

Cheers,

Ruben

Received on Wednesday, 13 January 2016 09:58:31 UTC