Re: Filters as views (ISSUE-45)

Hi all,

* As other people, I don't like using the same "view" property for both
views and view templates; for me those are different kinds of objects, and
their relation to the collection are different kinds of relations.

* I have no problem with multiple views, although I would find it more
logical if they were recursively embebed : </markus/friends> has view
</markus/friends?first=Ruben>, which has view
</markus/friends?first=Ruben&page=1>.

* I can live with the fact that the top level is the collection rather than
the view. It has the nice feature that the "member"s are related to the
collection itself (which is, I think, what the clients want to know), and
always at the same depth of the JSON structure, regardless of the fact that
there is pagination or not (for those clients who naively use the JSON with
no interest in the LD part).

That last point being state, I feel sympathy with Ruben's idea that views
could be considered as collections of their own. I have proposed an
alternative in that sense here:

https://www.w3.org/community/hydra/wiki/Collection_Interaction_Flow_with_views_as_collection

It has the nive feature that each view can be considered as a collection
(with its own members), the client may not care that it is a view of a
bigger collection. On the other hand, the client may decide to browse
horizontally (next, first, last) or vertically (viewOf), and discover the
"bigger picture".

My main problem with this alternative ist that "member"s of
</markus/friends> are not explicitly described as such, but rather as
members of a view on that collection. Of course, we could state that [
member o viewOf+ => member ], so
* smart clients using RDF could infer from that JSON-LD that those are
indeed members of the top-level collection,
* naive clients using the JSON structure would still find the members in
the same place, and would be happy with that.
However, some clients may read this as RDF triple without any inferences,
and for those clients, this structure might be misleanding.

So I see benefits in both proposals (Markus', with the minor issues raised
at the top of this e-mail, and mine). None is perfect, in my view, they are
just different trade-offs.

Now, should we really decide on this trade-off? Appart from the "member"
relations, they contain exactly the same information. Couldn't Hydra allow
both patterns, explaining the pros and cons (those that I mentioned, plus
some that I may have overlooked), and letting implementers decide which
suits their needs best?

On Thu, Feb 11, 2016 at 6:03 PM, Maik Riechert <maik.riechert@arcor.de>
wrote:

> Hi Markus,
>
> just a small comment about your proposed use of Content-Location for the
> paged case in /markus/friends. I disagree that Content-Location is the
> correct thing to use here. This should only be used if you want to point
> to a concrete representation when directly returning an entity response
> following some kind of content negotiation. E.g. GET /image with
> Accept:image/gif could return Content-Location: /image.gif and directly
> return the binary gif instead of redirecting to /image.gif, saving a
> request. This works because these things are conceptually the same. But
> a collection and a first page of it are not the same, and therefore this
> cannot be used. Unfortunately I don't know of a redirect-free
> alternative for that case.
>
> Cheers
> Maik
>
> Am 07.02.2016 um 16:51 schrieb Markus Lanthaler:
> > Hi,
> >
> > I think there might have been some confusion and misunderstanding
> regarding
> > the proposal I sent out a while ago. I slightly refined it and wrote
> down an
> > exemplary interaction flow at
> >
> >     https://www.w3.org/community/hydra/wiki/Collection_Interaction_Flow
> >
> > Please have a look and let me know what you think. If you disagree we
> > certain aspects and want to propose an alternative, please either create
> a
> > new (!) page or describe your proposal based on an example in a mail.
> >
> >
> > Thanks,
> > Markus
> >
> >
> > --
> > Markus Lanthaler
> > @markuslanthaler
> >
> >
> >
> >
> >
>
>
>