Re: Relationship between filter properties and hydra:supportedProperty (was Re: Filters as views (ISSUE-45))

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,
since the values are not equal, though very close to the requested
coordinates. Therefore usually to filter things by location, we use
polygons, circles, etc. I.e. provide coordinates of the center and the
radius of the circle, and then if a thing falls in the circle it
selected by the filter.

> 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.

EXAMPLE B (maybe it's a better illustration): To filter laptops by the
price and the display size. In API documentation we define a laptop as
follows:

@prefix ceo: <http://www.ebusiness-unibw.org/ontologies/consumerelectronics/v1#>
.

apidoc:Laptop a hydra:Class ;
    hydra:supportedProperty [ hydra:property schema:price ],
[hydra:property ceo:hasDisplaySize ] .

It's natural to filter such properties by min (e.g. schema:minValue)
and max (e.g. schema:maxValue) values. So to filter by price and
display size we will need to create 2 filters with the same filter
properties, e.g. schema:minValue and schema:maxValue.

How should a client distinguish which filter should be used for a one
of the hydra:supportedPropeties?

P.S. I know Schema.org has schema:minPrice and schema:maxPrice
properties, but is it feasible to have such min* and max* properties
for each hydra:supportedProperty in "the world"?

Thanks!
Maxim

On Thu, Feb 11, 2016 at 1:09 AM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> 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 Thursday, 11 February 2016 09:08:44 UTC