- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 13 Jan 2016 22:46:30 +0100
- To: <public-hydra@w3.org>
On 13 Jan 2016 at 10:57, Ruben Verborgh wrote: > Hi Markus, > >> I think the definitions we currently have in the spec are mostly fine >> (emphasis mine): >> >> A collection holding references to a number of related resources. >> >> A PartialCollectionView describes a partial view of a Collection. Multiple >> PartialCollectionViews **can** be connected with the the next/previous >> properties to allow a client to retrieve all members of the collection. > > For me, those definitions are not enough > to distinguish between a collection and view. > If I derive something from a collection, > is that by definition a view or not? I'm afraid I don't understand that question. > If something is connected with next/previous, > is it by definition a view or not? No > If something allows creating more specific views, > is that thing by definition a collection or not? No > Are views also (a kind of) collections? That's a tricky one but I lean towards no. I'd say they *may* hold metadata about a collection. > What is the tangible difference between a view and a collection? > (Asking this because views seem to share some properties of collections.) View's don't have hydra:member for instance. >> { >> "@id": /collection", >> "@type": "Collection", >> "view": { >> "@type": "ViewTemplate", >> "template": "/collection{?n}", >> "mapping": { >> "variable": "n" >> "property": "name" >> "filter": true >> } >> } >> } > > Positive points (for me): > - the idea that the collection has a more specific subordinate resource > (we had this already with [filter as a subproperty of] hydra:search) What do you mean by "a more specific subordinate resource"? I wouldn't say that a ViewTemplate is a more specific collection. It is a hypermedia control, more concretely a specialization of IriTemplate. > Negative points (for me): > - filter as a boolean on parameters just won't cut it. I agree and mentioned that in my initial mail: On 10 Jan 2016 at 18:13, Markus Lanthaler wrote: > This is easily expandable. We can either allow more complex values for > hydra:filter or introduce additional properties. > [...] > > - hydra:filter, a property to designate parameters/variables that act as > filters. For the time being it's range is a boolean (schema:rangeIncludes to > keep the door open for extensions in the future) Going beyond simple and filters will require more detailed descriptions. > This is not apparent from the above example, > because there is only one property. > With multiple properties, the desired default semantics is "AND", > but this cannot be realized with a property attached to individual parameters. We have a whole lot of proposals [1] on how those descriptions might look like but we didn't make much progress. I would thus like to try to reach consensus on the basic design and ignore more sophisticated use cases at the moment (obviously, we need to keep them in the back of our mind but they shouldn't distract the discussion). > BTW, would your proposal mean that hydra:search becomes extinct? Possibly, but that's a different discussion :-) > As far as the above example is concerned, > I like the modeling of "a collection has subordinate resources" idea. > However, whether such subordinate resources are views > (and not simply [sub-]collections), depends on the definitions. I'm confused. Are you actually talking about the View**Template** on the example above or about the PartialCollectionViews in the examples below? >> This would tell a client, that it can filter the members of /collection by >> the property "name" (could be mapped to schema.org/name for instance). >> The GET /collection?n=Markus would then yield this result: >> >> { >> "@id": /collection", >> "@type": "Collection", >> "totalItems": 2, >> "member": [ >> { "@id": "/markus", "name": "Markus" } >> ], >> "view": { >> "@id": /collection?n=Markus", >> "@type": "PartialCollectionView", >> "totalItems": 1 >> } >> } > > Here is the point where I start disagreeing. > (Thanks BTW for the examples, they allow me to break down my arguments.) > > That design obliges clients to be aware of views, > whereas "the collection of things named Markus" > could just be approached as a collection. Isn't the same true for pagination? We could also paginate by connecting sub-collections (remember PagedCollection?) but we decided against it. > For some use cases, it might not matter > that this thing is a view of some other collection; > for all the client knows, this is just another collection. For which use cases does it matter? > So I would expect more something like: > > { > "@id": /collection?n=Markus", > "@type": "Collection", > "totalItems": 1, > "member": [ > { "@id": "/markus", "name": "Markus" } > ], > "parent": { // or "viewOf", or "up" (cfr. previous/next) > "@id": /collection", > "@type": "Collection", > "totalItems": 2 > } > } > For me, there really *is* a difference with paging: > - the goal of paging is to view one collection as multiple parts > - the goal of filtering is to obtain one subset of one collection Please excuse my ignorance, but I still don't see the difference. >> I added totalItems to the PartialCollectionView as we discussed previously. [...] > The view also has a totalItems property; note that this makes the view a > collection: http://www.hydra-cg.com/spec/latest/core/#hydra:totalItems You are right, that would need to be changed. Switching from rdfs:range/rdfs:domain to schema:rangeIncludes/schema:domainIncludes is high on my to do list. Using RDFS has been a mistake. But that, again, is a different discussions. > In my proposal, it would simply be the same mechanism > as for the parent collection: > > { > "@id": /collection?n=Markus", > "@type": "Collection", > "totalItems": 58, > "member": [ > { "@id": "/markus", "name": "Markus" }, > ... other members that match the filter ... > ], > "view": { > "@id": "/collection?n=Markus&page=1", > "@type": "PartialCollectionView", > "first": "/collection?n=Markus&page=1", > "next": "/collection?n=Markus&page=2", > "last": "/collection?n=Markus&page=6" > }, > "parent": { // or "viewOf", or "up" (cfr. previous/next) > "@id": /collection", > "@type": "Collection", > "totalItems": 2489 > } This looks too complex for my taste. It also leaves the question open what parent means in various contexts. Whether updating one resource automatically updates the other etc. > Since "view" in this proposal is only used for paging, > it could be renamed accordingly. One of the reasons we called it "view" in the first place was to reuse it for other use cases and features. > Summarizing, what I propose is: > - there are only collections ... and views for pagination. So it is views + collections for almost any practical scenario. > - collections can be filtered to more specific collections > - collections can have a parent Could you please define what this parenthood entails? > - pages of a collection are just pages of a collection Don't know how to interpret the sentence above. > Both ideas might be reconciled if views _are_ collections. > > My open questions for your proposal are: > - precise definitions of collection and view Did the answers I provided at the beginning of the mail help? I'd need some time and probably a couple of iterations to come up with 2-3 sentence definitions. > - how filter can be used with multiple attributes (using AND semantics) That's a separate discussion. See [1] for various proposals. I'd be fine with replacing hydra:filter in the mappings with a hydra:filterSpecification for instance. What I would like to decide in this discussion are the basics. [1] https://www.w3.org/community/hydra/wiki/Filtering -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 13 January 2016 21:47:03 UTC