- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 10 Feb 2016 23:09:52 +0100
- To: "'Hydra'" <public-hydra@w3.org>
On 10 Feb 2016 at 16:41, Maxim Kolchin wrote: > On 10 Feb 2016 at 14:03, Tomasz Pluskiewicz wrote: >> I'm not sure I understand correctly, but I'd point out that the filter doesn't >> necessarily have to directly correspond to you underlying data. I think we do want to define filters in such a way that they do directly correspond to the underlying data. >> February 10 2016 1:16 PM, "Maxim Kolchin" <kolchinmax@gmail.com> wrote: >>> In example, the location of a sensor, in the simplest case I can have >>> geo:lat and geo:long attached directly to a sensor's resource, but >>> what if I have the following use case: >>> >>> <> a apidoc:Sensor ; >>> geo:location [ >>> a geo:Point ; >>> geo:lat "..." ; >>> geo:long "..." >>> ] . >>> >>> I now I want to have a filter which should return apidoc:Sensor >>> instances if they fall in a circle defined by the coordinates of the >>> center and the length of its radius. As I understand such filter >>> should consist of 3 properties, e.g. schema:geoRadius, schema:latitude >>> and schema:longitude. There are a couple of options: - make filter specifications more expressive to support such things (that would quickly become quite complex) - do a rough query server side and refine it locally - define an operation with those semantics - introduce new resources (sub-collections; not practical in all cases) - ... probably a few more HTH, Markus -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 10 February 2016 22:10:22 UTC