- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Wed, 8 Jul 2015 21:55:58 +0200
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-linked-data-fragments@w3.org, Miel Vander Sande <Miel.VanderSande@UGent.be>, Joachim Van Herwegen <Joachim.VanHerwegen@ugent.be>, Laurens De Vocht <Laurens.DeVocht@UGent.be>
>> That's right; and in our opinion, it is much more meaningful to define such features >> then to define all "interesting" combinations up front, >> because we don't know which features a server would like to combine. > > This part worries me a bit but let's see how it turns out. I'll take that as a “you can start rolling”? ;-) We would create spec stubs one of the following days then, because we'd include them in the camera-ready versions of the ISWC papers. >> Why would that be? If the client understands the pieces, it understands >> the whole. > > Because I'm afraid that clients will cut corners and not implement all > pieces. There's no problem with that actually: clients can choose which pieces they want to understand. E.g., for a simple autocompletion client, it probably only makes sense to support substring search, not the other interface. If the server does not support substring search, well, autocompletion was going to be terribly slow anyway, so better not to offer it to users then. >> I don't really follow, why would the application on top of the client be adapted? > > If you know that servers never support FILTER REGEX(?literal, "abc") > efficiently, you wouldn't build an application that executes the query > above. If you do happen to develop against a server which does and then > later move to a server which doesn't, your app basically breaks as it would > need to retrieve every single triple and then execute the regex locally. For > developers not knowing the whole stack in detail that might be very > surprising and hard to debug. The client could actually just say that: "estimated query cost: 12,000 requests”. For the other server, it would say: “substring search interface found, estimated cost: 5 requests”. > I'd say they are independent but not unrelated. Depending on how long those > specs turn out to be it might make sense to keep those features in a single > document. Let's defer this discussion till we have something concrete to > look at. Alright. One of the reasons I'm for separate documents is that this allows us to declare certain features fixed, while continuing working on others. Independent evolution. > Cool. Thanks a lot for your patience and for pushing this forward! Thanks again for hosting TPF in the Hydra group :-) Cheers, Ruben
Received on Wednesday, 8 July 2015 19:56:31 UTC