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

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. If the server uses SQL or proprietary 
binary format then it is useless to couple filters to representation 
structured.

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

Received on Thursday, 11 February 2016 21:23:55 UTC