- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Thu, 11 Feb 2016 22:01:22 +0100
- To: "'Hydra'" <public-hydra@w3.org>
On 11 Feb 2016 at 10:51, Tomasz Pluskiewicz wrote: > February 10 2016 11:11 PM, "Markus Lanthaler" wrote: >> On 10 Feb 2016 at 16:41, Maxim Kolchin 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. >> > > I find this dangerous, because in the end Hydra filters would have to work like OData. Also > there seems to be an overlap with Triple Pattern Fragments. Of course, Triple Pattern Fragments are based on Hydra so that's by design. > 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. > 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. > 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. -- Markus Lanthaler @markuslanthaler
Received on Thursday, 11 February 2016 21:01:56 UTC