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

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.


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

Yeah, I understood that. It's just that I don't think such complex functions are neither easily representable nor generalizable.


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

It wouldn't use a filter but some other control (that we haven't defined yet).



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

That's the thing I mentioned above. We need to make this more flexible to allow comparisons other than equality checks.


> 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"?

No. I think what we would need to do is to define a filter which takes a variable and compares that to a property with a specific operator. Something like

   variable: minPrice; comparison: >=; property schema:price
   variable: maxPrice; comparison: <=; property schema:price

I need to think a bit more about this to come up with a sensible design. Thank you very much for bringing up this issue!


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 11 February 2016 21:13:05 UTC