- From: Karol Szczepański <karol.szczepanski@gmail.com>
- Date: Mon, 21 Dec 2015 20:14:33 +0100
- To: "John Walker" <john.walker@semaku.com>, "Tomasz Pluskiewicz" <tomasz@t-code.pl>
- Cc: <public-hydra@w3.org>, "Thomas Hoppe" <thomas.hoppe@n-fuse.de>
Hi >Just to share my experience within this area, in one of our projects we've >approached that scenario with HTTP Expect Header where we've used SPARQL >like property paths to define which properties/graphs to >return/explode/block. >>The problem with that approach was that it introduced coupling, where the >>client required intimate knowledge about the data structures (used terms >>and the graph layout) >>>With regards to coupling, is this an issue? If the API were able to >>>publish some kind of summary of the classes and properties used, then a >>>client would be able to make smart choices >>>here without a priori >>>knowledge. Indeed, both Iri template and header approaches are vulnerable with same possibile coupling issue. Either the vocab will be hardcoded in the client or the client could elevate the description provided (like Hydra's supported classes mechanism) to decouple. In both cases client needs to craft a list of properties to be selected. Regards Karol
Received on Monday, 21 December 2015 19:14:47 UTC