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

Am 11.02.2016 um 10:12 schrieb Tomasz Pluskiewicz:
> 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}"
>      }
>    ]
> }
You mean @type instead of @id for the views I guess.

This is a relevant example for me as well. There's OpenSearch Geo & Time 
(http://www.opengeospatial.org/standards/opensearchgeo) which defines 
exactly such URL templates and properties essentially. And those 
properties have a combined meaning when used together, so there would 
have to be some way to express that. The simplest of course would be 
"@type": ["ViewTemplate", "OpenSearchGeoTime"] but I guess the question 
is whether it would be advantageous to define these details also 
individually, because otherwise you will end up creating a bunch of 
types for various APIs and you would essentially end up with hard-coded 
APIs again, which is what hydra wants to avoid. I'm not sure what the 
best way here is, but I have a feeling types are not the best way.

Cheers
Maik


>
> 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:27:54 UTC