- From: Karol Szczepański <karol.szczepanski@gmail.com>
- Date: Thu, 11 Feb 2016 20:15:23 +0100
- To: "Tomasz Pluskiewicz" <tomasz@t-code.pl>, "Maxim Kolchin" <kolchinmax@gmail.com>, "Markus Lanthaler" <markus.lanthaler@gmx.net>
- Cc: "Hydra" <public-hydra@w3.org>
Hi >>> No necessarily. The client is guided by hypermedia controls. >> >> Maybe I don't know enough about hypermedia controls, but I don't >> understand how a client should decide to use a filter with 3 >> properties (schema:geoRadius, geo:lat and geo:long) if he wants to >> filter sensors by geo:lat and geo:long properties defined by >> hydra:supportedProperty. >Maybe you would need two separate ViewTemplates. We haven't discussed that >before but maybe a way to assign view semantics is in order. Consider this: >... >In this example the /sensors collection can be viewed (filtered) by >providing exact coordinates and a surrounding circle. >I'm assuming that both would use the same properties for lat and lon >parameters. >However each view would use those parameters in order to filter the >members. >That difference however is that filtering semantics is not attached to the >parameters or mapped properties but to the view type. >So the client whether it wants to perform "ExactSensorSearch" or >"AreaSensorSearch". I fully agree with Tom's - I already implemented it that way. Server provides an endpoint that returns a collection of items with parameters expressed via an Iri template. It's up to the client on how it will fill those with values. I think we're mixing two things here. I understand the idea of filters to allow clients to build more sophisticated queries passed to the server as Iri templates are not only way of expressing these. Client could build a filter and send it in the request's body. For simpler cases, (i.e. those mentioned lat/long radius search) Iri templates without any filter specification are more than enough. I'm quite reluctant to put an advanced querying language within Hydra - ultimately it is OK to let the client build a SPARQL query and send it to the SPARQL endpoint if it want's some more sophisticated mechanism.
Received on Thursday, 11 February 2016 19:15:10 UTC