RE: Filters as views (ISSUE-45)

On 9 Feb 2016 at 11:14, Ruben Verborgh wrote:
>>   https://www.w3.org/community/hydra/wiki/Collection_Interaction_Flow
> 
> This proposal delivers what we needed for a long time,
> and I will support it once its remaining issues have been resolved.

I'm glad to hear that.


> - In general, we need definitions of:
>    - collection
>    - view
>    - viewtemplate
>    It's important to know what exactly we are talking about.
>    In particular, we need to know whether a view is a collection,
>    and from the reuse of properties, this seems to be the case here.

No, IMO a view wouldn't be a collection. I would define a collection as a
set of resources that somehow belong together. A view is a specific
representation of a resource (in our discussion here of a collection). I
still have to find nicer ways to express it but the following definition [1]
of the word view comes quite close to what I want express:

   view: a particular manner of looking at something:

It's very similar to a database view [2]. A ViewTemplate is a
hypermedia-control that tells a client how to request a specific View of a
resource from the server.


> - Maybe the examples can be enhanced a bit with plaintext,
>    to understand what exactly the intended semantics are.

Sure. Any suggestions on what to add?


> - In GET /markus/friends, I don't understand view/ViewTemplate.
>    What is this supposed to express?
>    "The friends have a view that is a template that."?
>    I see conceptually what is going on,
>    but I have trouble linking this with the view predicate.

The resource /markus/friends has various views. Some of them might be
referenced via a direct link, other via more complex, parameterizable
hypermedia-controls. Effectively it resembles the difference between a link
and a templated link. We can discuss separately whether we want to subclass
IriTemplate or not (parametrization via a POST payload might be an argument
against it).


> - What is the domain of filterSpecification?
>    Is it something like "Expression"?

Yes, perhaps a BooleanExpression.


>    If so, does "operands" also take an expression?
>    (I.e., can we compose recursively?)

Yes, I would suggest to allow that.


> - Will the operators receive IRIs?
>    I.e., can I assume that "AND" is hydra:AND,
>    or was it intended as the string "AND"?

I'm fine either way. If we make it a BooleanExpression, the value space will
be closed and strings might be simpler in practice.


> - Is there a default semantics for viewtemplate? (AND?)

No. I don't think that buys us much in this design. 


> - With regard to naming, we still seem to have a "filter" concept.
>    We could/should get rid of this by renaming "filterSpecification".

Where do you see the "filter" concept? Or do you mean the filter in
*filter*Specification? If that's the case, what would you renaming it to?


> - In GET /markus/friends?first=Ruben,
>    I think the view flaw really becomes apparent.
>    The thing seems to have two views. That's not right.

Why is that not right? The first view would contain all members which match
first=Ruben but the server declines to materialize that view. Instead he
gives the client some metadata about it (I think that could be made
optional) and an alternative view.

>    It has one view (the page you're currently looking at),
>    and one control (find other friends).

Does the above makes sense?


> - GET /markus/friends?first=Ruben does not explicitly say
>    that Ruben is part of the view.
>    This might or might not be necessary.
>    I would argue it is necessary for transparency:
>    if the thing is attached to the view,
>    clients can just read its elements,
>    without having to care whether something is a collection or a view.

Not sure I follow... are you saying the response should say

   /markus/friends?first=Ruben hydra:member /ruben

instead? I think that would defeat the purpose of the view concept. The
server doesn't return any new data, it just gives a client a different
perspective on a resource.


> - With regard to the above, an alternative way
>    to express GET /markus/friends?first=Ruben
>    would be to make "/markus/friends?first=Ruben" the "main" resource,
>    to express Ruben as a member of that,
>    and relate the resource to its parent. ("viewOf"?)
>    Now, the "main" resource is the collection the view belongs to.
>    Same with paging.

I don't want views to be tied to certain classes like collections. I want
them to be separate to be reusable in various contexts.


> - GET /markus/friends: the "totalItems 10" correctly expresses
>    the number of items on the current page.
>    It does, however, not say anything about the other pages.
>    This might or might not  be desired.

... and the convo you had afterwards


On 9 Feb 2016 at 12:45, Ruben Verborgh wrote:
> On 9 Feb 2016 at 12:41, Tomasz Pluskiewicz wrote:
>> Hold on, I'm confused. Doesn't View's totalItems mean that the number of
items of filtered,
>> but unpaged collection? Why would it express the number of items on the
current page?
>> This can be determined by counting the members. 
>
> Maybe I'm confused then. This needs to be explained.

Various people (I think including Ruben) argued that counting members is not
always easy or performant. Thus I included the two views in the response

   /markus/friends?first=Ruben

and

  /markus/friends?first=Ruben&page=1

The first one gives total the number of items in the collection that match
the filter. The second gives the total number of items on the first page.
I'm fine with changing the semantics of totalItems on a paginated view to
express the number of items across all pages. But then the only way for a
client to get the number of items on a specific page would be to count them.
Is everyone fine with that?


> - PartialCollectionView definitely needs to become View.

I'm fine with that as long as we find a clear way to document which
properties a Hydra-conformant client must be able to understand in the
various use cases.


[1] http://dictionary.reference.com/browse/view
[2] https://en.wikipedia.org/wiki/View_(SQL)



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 10 February 2016 21:47:11 UTC