Re: Filters as views (ISSUE-45)

Hi Markus,

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;
because after all, the result of filtering is just another collection
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.

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.

The relation resource–representation is a relative one.
What is a representation from one viewpoint,
can be a resource from another.

Example:
    "This video is really funny, but the audio in its AVI version is broken."
Then we have the video resource:
    /videos/funny-video
which has several representations (AVI, MOV, MP4).
In order to make the statement above,
we also need to identify the "representation",
which thereby acts as a resource:
    /videos/funny-video.avi
This resource itself can have representations in turn.

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


Plus: filters are recursively composable;
an AND filter can be composed of OR filters, etc.
Is this the case with the filter-as-view proposal?

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



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


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.

Received on Sunday, 10 January 2016 19:58:53 UTC