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

> Terrific example! Why wouldn't you allow filtering on age when the property you have is birthdate? For example I may wish expose a view which in natural language reads "limit members of /users to only those over X years of age"? I could define the following a view template regardless of there being an explicit age property in the members' representation.
>
> {
>  "@type": "ViewTemplate",
>  "template": "/users?minAge={minAge}",
>  "mapping": [
>    { "variable": "minAge", "property": "ageYears" }
>  ]
> }
>
> Now the client can use /users?minAge=20 to get people over twenty. Is that something illegal/incorrect in current state of affairs?

This is exactly what I wanted to ask when I started this thread :)
When I looked at [0], I understood it like your example above (with
birthdate and age) and my EXAMPLE A are incorrect, because there is no
such hydra:supportedProperty as used in the filter, i.e. instances
don't have "age", therefore you can't have a filter which use "age" as
a property.

I'm okay with this constraint, because it answers my another question:

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

The client will use the filters which have the given
hydra:supportedProperty in their mappings as a hydra:property.

I think we could represent Tomasz's example and my EXAMPLE A somehow
else. But I don't know how yet.

[0]: https://www.w3.org/community/hydra/wiki/Filtering

Maxim

On Fri, Feb 12, 2016 at 1:22 AM, Tomasz Pluskiewicz <tomasz@t-code.pl> wrote:
> On 2016-02-11 22:12, Markus Lanthaler wrote:
>>
>> 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.
>>
>
> I wouldn't be so sure. It may be true for numbers and dates but strings?
> Aren't these most commonly assumed to be filtered with a "contains"
> function? Or maybe "starts with"? Case-sensitive or not?
>
> Bottom line is how much of that information does the client need to
> understand other than:
>
> 1. here are the parameters
> 2. these parameters can take certain values
> 3. here's a URI template where you put these variables
>
> Best,
> Tom
>
>

Received on Friday, 12 February 2016 14:01:18 UTC