Re: Filters as views (ISSUE-45)

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 is a view and what is a collection?
How can we see/know if a resource is one of the other?

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

Now I'm confused ;-)

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

>>> @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.
The "anyOf" mechanism can also be used for other things.

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

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

"practical reasons" is probably not the most interesting case,
but you can just add a hydra:method "POST" on the filter
(just like we have a template attached to the filter).

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

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

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

(But if views are just collections, this is straightforward.)

> I struggle to see the reason why you
> want to treat the two differently.

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.

Best,

Ruben

Received on Monday, 11 January 2016 20:16:39 UTC