- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Thu, 11 Feb 2016 23:22:56 +0100
- To: public-hydra@w3.org
On 2016-02-11 22:12, Markus Lanthaler wrote: > On 11 Feb 2016 at 10:07, Maxim Kolchin wrote: >> Maybe the initial example is a bit confusing, so let me refine it and >> provide one more. >> >> EXAMPLE A: To filter sensors by they location. In API documentation we >> define a sensor as follows: >> >> apidoc:Sensor a hydra:Class ; >> hydra:supportedProperty [ hydra:property geo:lat ], >> [hydra:property geo:long ] . >> >> I can't use geo:lat and geo:long as filter properties, because I'll >> have to provide exact values, e.g. 60.000001 and 50.000001, a filter >> with these values won't return a sensor at 60.000000 and 50.000000, > > That's a very good point actually. We kind of instinctively assumed equality checks. I guess we need to make this a bit more flexible to allow other comparisons as well. > I wouldn't be so sure. It may be true for numbers and dates but strings? Aren't these most commonly assumed to be filtered with a "contains" function? Or maybe "starts with"? Case-sensitive or not? Bottom line is how much of that information does the client need to understand other than: 1. here are the parameters 2. these parameters can take certain values 3. here's a URI template where you put these variables Best, Tom
Received on Thursday, 11 February 2016 22:23:38 UTC