- From: Karol Szczepański <karol.szczepanski@gmail.com>
- Date: Mon, 26 Oct 2015 22:26:43 +0100
- To: "elf Pavlik" <perpetual-tripper@wwelves.org>, "Dietrich Schulten" <ds@escalon.de>
- Cc: "Hydra" <public-hydra@w3.org>
Hi elf >If you use URI of the view as subject of hydra:member ></an-issue/comments?page=3> hydra:member <some_member_21>,<some_member_22> >. >Where would information below come from? ></an-issue/comments> hydra:member <some_member_21>, <some_member_22> . Either by calling it directly or or indirectly by implying that if </an-issue/comments?page=3> isViewOf </an-issue/comments>, view's members are members of the collection the view presents. Collection is a union of all it's views. >I guess hydra:isViewOf would need to define it somehow... Exactly >, or it doesn't >even matter to have those triples if each view describes the very same >resource? eg. foaf:Group I'm not sure if I understand. All views are depending on it's "parent" collection, which is same resource in this case. >As long as we can clearly recreate underlying relations between >resources which hydra:Collection describes (e.g. foaf:member of >foaf:Group) and know how to stitch the graph together from all those API >responses IMO we stay on the right path. Actually I never wanted to build a whole graph from all API requests - I wasn't considering such a case. In ReST API usually I don't need whole graph - I receive a resource, modify it's state and send it back. Stiching something from various API calls may be considered a violation of the ReST approach in my opinion. >Maybe we all can take few days to write code which will page members of >Hydra CG and this way compare various approaches based on actual >implementation experience? Interesting - I'm in the middle of a POC angularJS client application that will utilize a Hydra API description, but I'm still not at the pagers yet. Regards Karol
Received on Monday, 26 October 2015 21:26:57 UTC