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

On 11 Feb 2016 at 13:07, Maik Riechert wrote:
> Am 11.02.2016 um 11:51 schrieb Tomasz Pluskiewicz:
>> February 11 2016 11:28 AM, "Maik Riechert" wrote:
>>> On 11 Feb 2016 at 11:12, Tomasz Pluskiewicz wrote:
>>>> 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.
>>> 
>> Of course :).
>> 
>>> 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
>>
>> It is important to decide whether we're talking about user agents
>> or autonomous clients. The latter would be great but it's been
>> effectively a holy grail. Haven't service discoverability attempts
>> to date all failed miserably? I'm afraid that Hydra will follow
>> such path if we're too ambitious.
>
> I'm all about autonomous clients.

+1 


> The problem I have with specific view
> template types is that I may want to combine properties of different
> APIs, for example properties from OpenSearch Geo & Time and... a
> property that filters by publisher name. Clients that understand these
> things individually would be clever enough to use them together.

Right. Following such an approach we would have to deal with a combinatorial explosion of possible controls.


> My point was just that types will not cut it in my opinion. I'm not
> saying that Hydra should focus on solving this problem once and for all.
> In my own project I apply some kind of fuzzy logic based on what
> properties I find in a template, e.g. "Ok, I found a radius, that means
> I can filter by a circle, which means I also need a lat and lon, and
> yay, I found that as well, all good". Something like that.

I think there are certain basic building blocks that will allow us to address 80-90% of the use cases. We should aim to address (and optimize) for those. There will always be highly specific scenarios in which a client would either need to rely on some heuristics or an additional, specialized vocabulary extending Hydra would have to be introduced. We need to ensure that we keep that possible but don't have to solve every special case ourselves.



--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 11 February 2016 21:56:33 UTC