RE: Filters as views (ISSUE-45)

On 13 Jan 2016 at 10:57, Ruben Verborgh wrote:
> 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?

I'm afraid I don't understand that question.


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

No


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

No


> Are views also (a kind of) collections?

That's a tricky one but I lean towards no. I'd say they *may* hold metadata
about a collection.


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

View's don't have hydra:member for instance.


>>  {
>>    "@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)

What do you mean by "a more specific subordinate resource"? I wouldn't say
that a ViewTemplate is a more specific collection. It is a hypermedia
control, more concretely a specialization of IriTemplate.


> 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.
  >
  [...]
  >
  > - hydra:filter, a property to designate parameters/variables that act as
  >   filters. For the time being it's range is a boolean
(schema:rangeIncludes to
  >   keep the door open for extensions in the future)

Going beyond simple and filters will require more detailed descriptions. 

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

We have a whole lot of proposals [1] on how those descriptions might look
like but we didn't make much progress. I would thus like to try to reach
consensus on the basic design and ignore more sophisticated use cases at the
moment (obviously, we need to keep them in the back of our mind but they
shouldn't distract the discussion).


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

Possibly, but that's a different discussion :-)


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

I'm confused. Are you actually talking about the View**Template** on the
example above or about the PartialCollectionViews in the examples below?


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

Isn't the same true for pagination? We could also paginate by connecting
sub-collections (remember PagedCollection?) but we decided against it.


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

For which use cases does it matter?


> 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

Please excuse my ignorance, but I still don't see the difference.


>> I added totalItems to the PartialCollectionView as we discussed
previously.
[...]
> 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

You are right, that would need to be changed. Switching from
rdfs:range/rdfs:domain to schema:rangeIncludes/schema:domainIncludes is high
on my to do list. Using RDFS has been a mistake. But that, again, is a
different discussions.


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

This looks too complex for my taste. It also leaves the question open what
parent means in various contexts. Whether updating one resource
automatically updates the other etc.


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

One of the reasons we called it "view" in the first place was to reuse it
for other use cases and features.


> Summarizing, what I propose is:
> - there are only collections

... and views for pagination. So it is views + collections for almost any
practical scenario. 


> - collections can be filtered to more specific collections
> - collections can have a parent

Could you please define what this parenthood entails?


> - pages of a collection are just pages of a collection

Don't know how to interpret the sentence above.


> Both ideas might be reconciled if views _are_ collections.
> 
> My open questions for your proposal are:
> - precise definitions of collection and view

Did the answers I provided at the beginning of the mail help? I'd need some
time and probably a couple of iterations to come up with 2-3 sentence
definitions.

> - how filter can be used with multiple attributes (using AND semantics)

That's a separate discussion. See [1] for various proposals. I'd be fine
with replacing hydra:filter in the mappings with a hydra:filterSpecification
for instance. What I would like to decide in this discussion are the basics.


[1] https://www.w3.org/community/hydra/wiki/Filtering


--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 13 January 2016 21:47:03 UTC