- From: Tomasz Pluskiewicz <tomasz@t-code.pl>
- Date: Thu, 11 Feb 2016 10:12:37 +0000
- To: "Maxim Kolchin" <kolchinmax@gmail.com>, "Markus Lanthaler" <markus.lanthaler@gmx.net>
- Cc: "Hydra" <public-hydra@w3.org>
February 11 2016 10:09 AM, "Maxim Kolchin" <kolchinmax@gmail.com> wrote: > >> 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: { "@id": "/sensors", "view": [ { "@id": [ "ViewTemplate", "ExactSensorSearch" ], "template": "/sensors/exact{?lat,lon}" }, { "@id": [ "ViewTemplate", "AreaSensorSearch" ], "template": "/sensors/around{?lat,lon,radius}" } ] } 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". Also notice how I introduced new identifiers for views. This is a matter of opinion but maybe this way server-side code would be easier. > > 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? > See my reply to Markus. And in this example I think you could think in more primitive terms and declare multiple template parameters. For example "/laptops{?minPrice,maxPrice,minDisplaySize,maxDisplaySize}"
Received on Thursday, 11 February 2016 10:13:33 UTC