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

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?


> 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).


--
Markus Lanthaler
@markuslanthaler

Received on Thursday, 11 February 2016 21:38:45 UTC