RE: Filters as views (ISSUE-45)

On 11 Jan 2016 at 21:16, Ruben Verborgh wrote:
> Hi Markus,
> 
>>> 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.
> 
> It is a collection, according to the definition:
> http://www.hydra-cg.com/spec/latest/core/#hydra:Collection "A collection
> holding references to a number of related resources." And it certainly
> is a different collection, given that the elements are not the same.
> 
>> Just a different view onto an existing one.
> 
> The distinction between what is a view and what is a collection is not
clear-cut.

What's the difference between a PartialCollectionView and a Collection? IMO,
it's the same difference as the one between a filtered collection and the
collection itself.


> What is a view and what is a collection?
> How can we see/know if a resource is one of the other?

Just as in paging. The server tells the client.


>>> because after all, the result of filtering is just another collection
>> 
>> True
> 
> Now I'm confused ;-)

Yeah, I should have omitted that sentence :-)


>>> 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.
> 
> The argument that
>>>> Representations don't have identifiers in the form of URLs
> is not valid, because representations can have URLs
> (since the notion of resource/representation is relative).

Nope. I don't think that's true. URIs identify resources, not
representations thereof. A URI is a uniform *resource* identifier after all.
Anyway, I guess we don't need to discuss this further as it is not really
the topic of this discussion :-)


>>>> @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?
> 
> To use the composability of filters:
> the domain and range of fieldSelector can be Filter.

And the domain and range of fieldSelector?


> The "anyOf" mechanism can also be used for other things.

Right


>> Why should fieldSelector be
>> modelled different from filter?
> 
> It's a just choice in how you implement fieldSelector.
> In the example you gave, fieldSelector is defined as
> a boolean altering how the mapping should be interpreted;
> it could also have been a type on the mapping.
>
> These options are equally possible:
> 
> @id: "/person/markus",
> filter: {
>  template: /friends{?fields},
>  mapping: {
>    fieldSelector: true,
>    variable: "fields",
>    anyOf: [ "name", "birthdate", "address" ]
>  }
> }
> 
> OR
> 
> @id: "/person/markus",
> filter: {
>  template: /friends{?fields},
>  mapping: {
>    "@type": "FieldSelector",
>    variable: "fields",
>    anyOf: [ "name", "birthdate", "address" ]
>  }
> }

Right. But the structure or topology of the graph stays the same. Your
proposal changes the structure. I'm concerned about the generalizability and
composability of that structure. IMO, it introduces lots of variations.


>> How would you describe a filter that requires a POST for practical
reasons?
> 
> "practical reasons" is probably not the most interesting case,

With practical reasons I meant due to URL length limitations etc.


> but you can just add a hydra:method "POST" on the filter
> (just like we have a template attached to the filter).

Which would be a completely different thing than an operation then (at least
compare to the currently specified version thereof).


>>> 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?
> 
> Couldn't come up with a meaningful scenario, so here is
> "filter on whether gender OR (firstname and lastname) match":
> 
> @id: "/friends",
> filter: {
>   template: "/friends{?gender,firstname,lastname}",
>   combinator: "OR",
>   mapping: [{
>     variable: "gender",
>     property: "http://schema.org/gender"
>   },
>   {
>     combinator: "AND",
>     mapping: [{
>       variable: "firstname",
>       property: "http://example.org/firstname"
>     },
>     {
>       variable: "lastname",
>       property: "http://example.org/lastname"
>     }]
>   }]
> }

So the inner "filter mapping" is the same as the outer but it doesn't have a
template. It also means that a mapping has a mapping...


>>> I think we agreed to just cover AND filters for the time being!?
> 
> We certainly did; but part of the arguments for the new approach
> was extensibility, so we should check that whatever approach we take
> can at least be extended to cover other types of filters.

Sure


>>> 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?
> 
> Having to distinguish between collections and views.
> Good definitions of both would certainly be a precondition.
> 
>> If each member in a collection has an index assigned to it, than you can
>> paginate by filtering on that index.
> 
> Hmm, then we are placing a filter on the view
> instead of filtering the collection; these are different things.

Not sure I follow. Look at how pagination works. What I propose is to allow
to describe a view in terms of an IriTemplate and identify the parameters
that can be used as filters.


> (But if views are just collections, this is straightforward.)
> 
>> I struggle to see the reason why you
>> want to treat the two differently.

This is taken completely out of context. It looked like this:

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

So, I struggle to see the difference between pagination and filtering.


> On the contrary, I'm doubting the usefulness of views
> and think that, if everything is a collection,
> there is no need to treat anything special.

So, do you see the use of partial views in pagination or not? Does your
statement above just apply to filtering?


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 11 January 2016 21:14:01 UTC