- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Thu, 11 Feb 2016 22:03:02 +0100
- To: public-hydra@w3.org
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