RE: Filters as views (ISSUE-45)

On 8 Feb 2016 at 20:21, Karol Szczepański wrote:
> I had a chance to review your examples and more and more I'm into dropping
> separate paging approach in favour of a more general solution.

... meaning that your start to favor a views-based solution?


> On 7 Feb 2016 at 20:45, Tomasz Pluskiewicz wrote:
>> I like it in general.

Good :-)


>> I'm just a bit uneasy about multiple PartialCollectionViews, each with
>> it's own totalItems.

Yeah, I find that a bit confusing as well but in order to make this unambiguous to a machine we need them I guess.


>> I think that there should only be one such view in
>> a response.

How would you communicate to a client then that the response was not only filtered, but that the server also decided to paginate it?


>> In my opinion, if GETting /markus/friends?first=Ruben
>> redirects (or uses Content-Location header) than the view is actually
>> the first page and not the initial target.

While that might work for the first page it would make it more difficult to get the total number of filtered items. Also, how would that work for page 2, 3 and so on?


>> Also I'm not sure about mixing both ViewTemplate and View on single
>> `view` property.

We can certainly split it into two properties but I'm not sure that would buy us much. What advantages would you see?


>> I'm thinking about a more general term instead of PartialCollectionView
>> on the grounds that views don't necessarily apply only to collections.
>> Would View and PartialView be enough? The former in cases where the
>> representation is complete but for example translated. The latter for
>> filtered collections and abridged representations alike (such as when
>> limiting the number of properties included).

I guess since we want to support properties like totalItems on them, PartialCollectionView makes some sense but you are probably right that it is over-restrictive. I don't like PartialView much as it doesn't really tell you anything.

Jumping back to Karol's reply:

> I fully support Tomasz' statement. We had these arguments with Ruben and by
> seeing an example of how a mix of these two (three?) "views" looks like
> makes the unified approach more solid.

If more people find PartialCollectionView to specific, I'd be fine going with just View for the time being. Please keep in mind however that it will make documentation of the vocabulary more difficult (the totalItems property only applies is it is a view of a collection; first/next/... only apply if the view is used in pagination; ...)


> Logically, the collection has many views which can overlap. Ultimately,
> union of all views builds a collection. In the examples my feeling is that
> paging and filtered views are disjoined, which obviously is untrue.
> Something in form of the one below seems more elegant and natural:
> 
> GET /markus/friends?first=Ruben
> {
>   "@id": "/markus/friends",
>   "@type": "Collection",
>   "totalItems": 578
>   "member": [...],
>   "view": [{
>       "@id": "/markus/friends?first=Ruben&page=1",
>       "totalItems": 10,
>       "first": "/markus/friends?first=Ruben&page=1",
>       "next": "/markus/friends?first=Ruben&page=2",
>       "last": "/markus/friends?first=Ruben&page=2"
>       "template": "/markus/friends{?first,last,page}",
>       "mapping": [
>         { "variable": "first", "property": "schema:givenName" },
>         { "variable": "last", "property": "schema:familyName" },
>         { "variable": "page", "property": "hydra:page" }

I already expected that you'd somehow sneak this into this discussion :-) But please, let's try to not conflate these two discussions. The server decides to paginate here, not the client. I used page=x as URL parameter for the sake of simplicity but I could (and probably should) have also used an arbitrary token which the client wouldn't be able to construct easily.

>       ],
>       "filterSpecification": {
>         "operator": "AND",
>         "operands": [
>           { "variable": "first" },
>           { "variable": "last" }
>         ]
>       }}}
> I dropped typing on purpose. I also dropped the "totalItems": 15 collection
> as I'm not quite sure how should I "acknowledge" it.

Right, and that's a major limitation. How would a client know that only 15 members matched the criteria? In quite a few use cases it is important to know beforehand how many items match. Triple Pattern Fragments is one of them by the way. So omitting that information is a no-go I'd say.


>> Lastly, I think that the filterSpecification will have to be discussed
>> in detail separately and must not hold us back from agreeing upon the
>> general view structure. Is it possible the we leave the filters a bit
>> underspecified and resolve views first?

We agreed on views already back in October [1-3]. This discussion is about ISSUE-45 [4], i.e., filters. That being said, I'm happy to re-open ISSUE-42 if new insights are presented. Your statement that PartialCollectionView might be too specific is certainly a first step in that direction.

And last but not least...

On 7 Feb 2016 at 23:26, Maik Riechert wrote:
> just a quick comment on the last example (/markus/friends?first=Ruben
> redirecting to /markus/friends?first=Ruben&page=1). The client would
> only find the /markus/friends?first=Ruben&page=1 PartialCollectionView,
> with totalItems=10. It would ignore /markus/friends?first=Ruben since
> this is not directly linked to anything there. And that in turn means the
> client couldn't access the count 15.

The client certainly knows what it actually requested, no? So it would easily be able to find /markus/friends?first=Ruben.
 

> I think in general the structure would be too confusing/complicated.

Yeah, looking at the example, I partly share this concern. That being said, even if we would get rid of

    {
      "@id": "/markus/friends?first=Ruben",
      "@type": "PartialCollectionView",
      "totalItems": 15
    }

the example wouldn't become much simpler. We definitely need the ViewTemplate and also the pagination information associated to /markus/friends?first=Ruben&page=1.

So, to summarize it there are concerns that PartialCollectionView is too restrictive and that it should be renamed and that the responses are too complex if filtering is combined with pagination (but no proposal has been put forward to convey the same information in a simpler manner).

Unfortunately, no one commented on filterSpecification so far. I would love to hear your thoughts about that.


Cheer,
Markus


[1] https://lists.w3.org/Archives/Public/public-hydra/2015Oct/0163.html
[2] https://lists.w3.org/Archives/Public/public-hydra/2015Oct/0204.html
[3] https://github.com/HydraCG/Specifications/issues/42
[4] https://github.com/HydraCG/Specifications/issues/45


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 8 February 2016 20:45:10 UTC