RE: Filters as views (ISSUE-45)

On 10 Jan 2016 at 20:58, Ruben Verborgh wrote:
> Thanks for continuing to think about hydra:filter.
> 
> Unfortunately, I like the previous line of thought much more,
> in which hydra:filter is a subproperty of hydra:search
> and gives access to a derived (sub)collection of things.
> 
> I don't see the added value of having a view construct in between;

The main advantage I see is to make it clear what it is. It is not a
different collection. Just a different view onto an existing one. IMO this
not only makes it easier to explain, but also clarifies that, for instance,
adding a new member will affect the underlying collection and not just the
(sub)collection the client is currently looking at.


> because after all, the result of filtering is just another collection

True


> that is no more special than the initial collection.
> The only "special" thing is that the result collection
> has a relation to the original collection,
> namely it has been passed through a filter,
> and that filter is a hypermedia control clients can use.

I'm not so sure about that.


> Detailed comments below.
> 
>> What we want to describe are different views onto an
>> (abstract) resource - in our case a collection. This is similar to
>> representations in REST but not the same. Representations don't have
>> identifiers in the form of URLs - our views do. In other words, a view is
a
>> derived resource, not a representation.
> 
> I don't mean to lecture about REST,
> but it is necessary to point out that the arguments are not sound.
> Even though I agree that a "view" as you propose it,
> would be a resource, it is not for the argument you present.

Which argument? The only thing I wanted to clear up here is that we
shouldn't confuse views with representations in REST speak.


>> We have been discussing introducing a hydra:filter property that takes a
>> IriTemplate as value to reach such a filtered view. While this would
>> technically work, I don't think it would be the best solution. It doesn't
>> generalize nicely and is difficult to compose with other features.
> 
> I don't see why not.
> A filter that acts as a hypermedia control,
> describing how client input goes from one collection resource to another,
> is perfectly composable and generalizable.
> 
>> Here's a simple example illustrating how I imagine it to work. Let's
assume
>> we have a collection /friends and want to filter it by the gender. This
>> could be described as follows:
>> 
>>  @id: /friends
>>  member: [ ... ]
>>  view: {
>>    @type: ViewTemplate, IriTemplate
>>    template: /friends{?gender}
>>    mapping: {
>>      variable: gender
>>      property: http://schema.org/gender
>>      filter: true
>>  }
> 
> The alternative with hydra:filter as proposed before:
> 
> @id: "/friends",
> filter: {
>    template: "/friends{?gender}",
>    mapping: {
>      variable: "gender",
>      property: "http://schema.org/gender"
>   }
> }
> 
>> One such use case might be to only return some
>> fields of a resource:
>> 
>>  @id: /person/markus
>>  ...
>>  view: {
>>    @type: ViewTemplate, IriTemplate
>>    template: /friends{?fields}
>>    mapping: {
>>      variable: fields
>>      fieldSelector: true
>>      anyOf: [ name, birthdate, address, ... ]
>>  }
> 
> Alternative:
> 
> @id: "/person/markus",
> filter: {
>   template: /friends{?fields},
>   fieldSelector: {
>     variable: "fields",
>     anyOf: [ "name", "birthdate", "address" ]
>   }
> }

So you would nest a fieldSelector in a filter? Why should fieldSelector be
modelled different from filter?

How would you describe a filter that requires a POST for practical reasons? 


> Plus: filters are recursively composable;
> an AND filter can be composed of OR filters, etc.

Could you please sketch an example of how you imagine that to look like?


> Is this the case with the filter-as-view proposal?

I don't see why it wouldn't be possible to support it but it is not part of
the current proposal. I think we agreed to just cover AND filters for the
time being!?


>> You might wonder what the result of a GET on the ViewTemplate is. My
current
>> thinking is that, in the case of a collection, it should be a
>> PartialCollectionView.
> 
> Alternative: simply a hydra:Collection,
> indicating that it is part of the parent collection.

That would work as well but IMO reusing PartialCollectionView is the cleaner
design here. Pagination is just a special filter.


> To summarize, I think that:
> - expressivity and generalizability are no different
> - the proposal needs (too) complex views

What exactly do you find complex about the proposal?


> In general, this makes me wonder what the difference is
> between a collection and a partial collection view.
> Do we really need to distinguish?
> Seems much simpler is everything is just a collection,
> with a relation to its parent collection.
> Way fewer classes; much easier to explain.
> 
> Best,
> 
> Ruben
> 
> PS For paging, I see the use of a partial view:
> after all, there are more "parts" in the series.
> But for filters, there's just one part: the parent,
> and a possible child, which is just another filter.

If each member in a collection has an index assigned to it, than you can
paginate by filtering on that index. I struggle to see the reason why you
want to treat the two differently.


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 11 January 2016 19:39:49 UTC