Re: Filters as views (ISSUE-45)

On 2016-02-11 21:11, Ruben Verborgh wrote:
>>> - 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.
>
> Fair enough.
>
>> A view is a specific
>> representation of a resource (in our discussion here of a collection).
>
> …containing a set of resources that somehow belong together
> (because they are together in one view).
>
> I know it sounds like nitpicking, but it's really important
> that we nail unambiguously what a view is,
> and if it should not be a collection,
> that this directly follows from that definition.
>
>>> - 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?
>
> The meaning of the new predicates introduced.
> What does "view" etc. mean.
> (Because see below: it both points to a subset of a collection
>   and a control to achieve such a subset.)
>>> - 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.
>
> I think we then conflate a view and a control to generate such a view;
> we are conflating controls and the resources their instantiations point 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?
>
> Conflation of "view" and "control to generate a view".
>

Does there seem to be a consensus to separate views and view templates?

>>> - 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?
>
> Yes.
>
>> I think that would defeat the purpose of the view concept.
>
> Not really.
> A view gives access to a specific part of a collection.
>
> (Closely related to my question if it is at all possible
>   to define a view such that it is not a collection.
>   If this is not possible, views are subcollections.)

Haven't you just above agreed that view don't necessarily have to be 
collections?

>
>> The
>> server doesn't return any new data, it just gives a client a different
>> perspective on a resource.
>
> There's no requirement for data to be new.
>
>> I don't want views to be tied to certain classes like collections.
>
> Try to define it as such then ;-)
> I think it will be really hard _not_ to make a view a collection.

Ditto. I like the term derived resource. And let me illustrate an 
example I mentioned earlier of views used outside of collections 
https://www.w3.org/community/hydra/wiki/Views_of_non-collection

Is that a compelling example?

>
>> he 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?
>
> I'm not. Let's just define a predicate for items per page, like we had before.
> It's very common on pagination anywhere else on the Web.
>

Exactly. "totalItems" and "items". No harm here :)

Thanks,
Tom

Received on Thursday, 11 February 2016 21:03:41 UTC