- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Mon, 11 Jan 2016 20:39:16 +0100
- To: <public-hydra@w3.org>
On 10 Jan 2016 at 20:58, Ruben Verborgh wrote: > Thanks for continuing to think about hydra:filter. > > Unfortunately, I like the previous line of thought much more, > in which hydra:filter is a subproperty of hydra:search > and gives access to a derived (sub)collection of things. > > I don't see the added value of having a view construct in between; The main advantage I see is to make it clear what it is. It is not a different collection. Just a different view onto an existing one. IMO this not only makes it easier to explain, but also clarifies that, for instance, adding a new member will affect the underlying collection and not just the (sub)collection the client is currently looking at. > because after all, the result of filtering is just another collection True > that is no more special than the initial collection. > The only "special" thing is that the result collection > has a relation to the original collection, > namely it has been passed through a filter, > and that filter is a hypermedia control clients can use. I'm not so sure about that. > Detailed comments below. > >> What we want to describe are different views onto an >> (abstract) resource - in our case a collection. This is similar to >> representations in REST but not the same. Representations don't have >> identifiers in the form of URLs - our views do. In other words, a view is a >> derived resource, not a representation. > > I don't mean to lecture about REST, > but it is necessary to point out that the arguments are not sound. > Even though I agree that a "view" as you propose it, > would be a resource, it is not for the argument you present. Which argument? The only thing I wanted to clear up here is that we shouldn't confuse views with representations in REST speak. >> We have been discussing introducing a hydra:filter property that takes a >> IriTemplate as value to reach such a filtered view. While this would >> technically work, I don't think it would be the best solution. It doesn't >> generalize nicely and is difficult to compose with other features. > > I don't see why not. > A filter that acts as a hypermedia control, > describing how client input goes from one collection resource to another, > is perfectly composable and generalizable. > >> Here's a simple example illustrating how I imagine it to work. Let's assume >> we have a collection /friends and want to filter it by the gender. This >> could be described as follows: >> >> @id: /friends >> member: [ ... ] >> view: { >> @type: ViewTemplate, IriTemplate >> template: /friends{?gender} >> mapping: { >> variable: gender >> property: http://schema.org/gender >> filter: true >> } > > The alternative with hydra:filter as proposed before: > > @id: "/friends", > filter: { > template: "/friends{?gender}", > mapping: { > variable: "gender", > property: "http://schema.org/gender" > } > } > >> One such use case might be to only return some >> fields of a resource: >> >> @id: /person/markus >> ... >> view: { >> @type: ViewTemplate, IriTemplate >> template: /friends{?fields} >> mapping: { >> variable: fields >> fieldSelector: true >> anyOf: [ name, birthdate, address, ... ] >> } > > Alternative: > > @id: "/person/markus", > filter: { > template: /friends{?fields}, > fieldSelector: { > variable: "fields", > anyOf: [ "name", "birthdate", "address" ] > } > } So you would nest a fieldSelector in a filter? Why should fieldSelector be modelled different from filter? How would you describe a filter that requires a POST for practical reasons? > Plus: filters are recursively composable; > an AND filter can be composed of OR filters, etc. Could you please sketch an example of how you imagine that to look like? > Is this the case with the filter-as-view proposal? I don't see why it wouldn't be possible to support it but it is not part of the current proposal. I think we agreed to just cover AND filters for the time being!? >> You might wonder what the result of a GET on the ViewTemplate is. My current >> thinking is that, in the case of a collection, it should be a >> PartialCollectionView. > > Alternative: simply a hydra:Collection, > indicating that it is part of the parent collection. That would work as well but IMO reusing PartialCollectionView is the cleaner design here. Pagination is just a special filter. > To summarize, I think that: > - expressivity and generalizability are no different > - the proposal needs (too) complex views What exactly do you find complex about the proposal? > In general, this makes me wonder what the difference is > between a collection and a partial collection view. > Do we really need to distinguish? > Seems much simpler is everything is just a collection, > with a relation to its parent collection. > Way fewer classes; much easier to explain. > > Best, > > Ruben > > PS For paging, I see the use of a partial view: > after all, there are more "parts" in the series. > But for filters, there's just one part: the parent, > and a possible child, which is just another filter. If each member in a collection has an index assigned to it, than you can paginate by filtering on that index. I struggle to see the reason why you want to treat the two differently. -- Markus Lanthaler @markuslanthaler
Received on Monday, 11 January 2016 19:39:49 UTC