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

I collected thoughts from this thread and described a proposal for the
mappings which allows to clarify and cover aforementioned use cases:

https://www.w3.org/community/hydra/wiki/An_extented_mappings_for_collection_filters

P.S. My English may be not mature enough to write formal texts, so
please correct or clarify phrases if it's needed :)

Maxim

On Fri, Feb 12, 2016 at 5:00 PM, Maxim Kolchin <kolchinmax@gmail.com> wrote:
>> 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 Saturday, 13 February 2016 14:32:16 UTC