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

On 2016-02-11 22:38, Markus Lanthaler wrote:
> On 11 Feb 2016 at 22:23, Tomasz Pluskiewicz wrote:
>> On 2016-02-11 22:01, Markus Lanthaler wrote:
>>>
>>>> Both cases assume the client knows a lot about the server-side data structured.
>>>
>>> Sure. But we have mechanisms to tell a client anything it needs to know.
>>
>> Yes, but those mechanisms tell the client the details of representations
>> and not resources themselves.
>
> How does that distinction matter here?
>

It matters because the server may expose controls which work on the 
resource level and not representation level. The client shouldn't care. 
The case you give below (and my example) show exactly that. The age 
filter is significant in terms of resource but not representation.

>
>> If the server uses SQL or proprietary
>> binary format then it is useless to couple filters to representation
>> structured.
>
> Could you please be a bit more concrete? Can you perhaps illustrate based on my example in the Wiki why "defining filters in such a way that they do directly correspond to the underlying data" will make "no sense in such case"?
>
>
>>>> And again, what if the server actually stores non-RDF data and RDF is
>>>> used only for resource representations?
>>>
>>> That makes no difference. It's trivial to implement that for a
>>> traditional SQL or a NoSQL database.
>>
>> I don't follow. It's trivial to implement what?
>
> The filtering on the underlying data. We are discussing the following statements here:
>
>> On 10 Feb 2016 at 23:09, Markus Lanthaler wrote:
>>>> On 10 Feb 2016 at 14:03, Tomasz Pluskiewicz wrote:
>>>>> I'm not sure I understand correctly, but I'd point out that the filter doesn't
>>>>> necessarily have to directly correspond to you underlying data.
>>>
>>> I think we do want to define filters in such a way that they do directly
>>> correspond to the underlying data.
>
>
>>>> The above makes no sense in such case and I think it will be a
>>>> mistake to keep such assumption. Such decoupling is a cornerstone
>>>> on REST.
>>>
>>> Why does the above make "no sense in such case"? I completely agree
>>> that nothing in Hydra should dictate how the backend is implemented.
>>
>> Then we're in agreement. However I interpreted you statement that "we
>> want to define filters in such a way that they do directly correspond to
>> the underlying data" as being tightly coupled to RDF. While I realize
>> that for Hydra being RDF-based it's natural, this cannot extend to the
>> server-side implementation.
>
> OK. Maybe we are on the same page but talk past each other :-) What I meant with the underlying data is that if we have a collection of resources with representations like
>
>    {
>      "@id": "/markus",
>      "givenName": "Markus",
>      "familyName": "Lanthaler",
>      "friends": "/markus/friends",
>      ...
>    }
>
> And we filter on givenName that would be directly related to the property/value in that representation. You can't *filter* on "age" if that property is not there but just birthdate. Your response to Maxim suggested that (filtering by lat/long + radius even though the resources you filter only have lat/long).
>

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 where I replied to Maxim stating the such semantics should be 
defined by the "view function" so to speak and not by individual input 
parameters.

I hope this example also answers your other questions above.

Regards,
Tom

Received on Thursday, 11 February 2016 22:17:35 UTC