RE: Filters as views (ISSUE-45)

On 14 Jan 2016 at 23:55, Ruben Verborgh wrote:
>>>>> Okay, but what is the meaning then of:
>>>>> - hydra:filter?
>>>>> - a boolean as value of hydra:filter?
>>>>> I just don't understand how to interpret this.
>>>> 
>>>> Interpret it as "this parameter acts as a filter, multiple filters are
>>>> combined with AND".
>>> 
>>> The "AND" interpretation is not possible,
>>> because the hydra:filter property is attached to individual mappings.
>>> The AND-ness should be decided on the level of all mappings.
>>> (in other words: you cannot AND a single mapping,
>>> you need at least two).
>>> Plus, I'm still not in favor of this boolean.
>>> Just "this acts as a filter" is not too interesting.
>> 
>> Well, you couldn't have combinations with ORs etc. but you can surely
have
>> other variables which don't act as filters. But you are right, it's not
very
>> flexible. As already said, I'm more than happy to change either the value
of
>> hydra:filter or move hydra:filter from the IriTemplateMapping out to the
>> ViewTemplate
> 
> That would be necessary I think.
> Perhaps hydra:filter can disappear in its entirety for now.
> It would be interesting if the view could somehow indicate
> what parameters should be filled out to obtain it.

I think we can't get rid of hydra:filter (or a similar property) if we want
features to stay composable. If we move it out of IriTemplateMapping to
ViewTemplate the example I posted previously could perhaps be modified to
look as follows instead:

  {
    "@id": /collection",
    "@type": "Collection",
    "view": {
      "@type": "ViewTemplate",
      "template": "/collection{?n}",
      "filter": {
        "operator": "AND",
        "property": [ "name" ]
      },
      "mapping": {
        "variable": "n"
        "property": "name"
      }
    }
  }


>>>> {
>>>>   "@context": "http://www.w3.org/ns/hydra/context.jsonld",
>>>>   "@id": "http://api.example.com/an-issue/comments",
>>>>   "@type": "Collection",
>>>>   "totalItems": "4980",
>>>>   "member": [
>>>>     ... a subset of the members of the Collection ...
>>>>   ],
>>>>   "view": {
>>>>     "@id": "http://api.example.com/an-issue/comments?page=3",
>>>>     "@type": "PartialCollectionView",
>>>>     "first": "/an-issue/comments?page=1",
>>>>     "previous": "/an-issue/comments?page=2",
>>>>     "next": "/an-issue/comments?page=4",
>>>>     "last": "/an-issue/comments?page=498"
>>>>   }
>>>> }
>>>> 
>>>> So the members are associated to the collection, not the view. How
>>>> would you envision that to work look like when PartialCollectionView
>>>> is a subclass of Collection?
>>> 
>>> Exactly the same.
>> 
>> Really? So http://api.example.com/an-issue/comments?page=3 would be a
>> collection with no members?
> 
> Certainly not :-)
> It might just be that the representation does not list membership
explicitly.
> 
> But yes, that would not be too handy for clients just looking at the
collection.
> Another way is to add membership to the view,
> as it can be implied/inferred that they must necessarily also be members
of the collection
> (the other way round is not guaranteed).

Right... it would mean, however, that we would need to change pagination
again.


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 17 January 2016 18:42:03 UTC