- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 8 Jul 2015 23:42:59 +0200
- To: "'Ruben Verborgh'" <ruben.verborgh@ugent.be>
- 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>
On 8 Jul 2015 at 21:55, Ruben Verborgh wrote:
>>> 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"? ;-)
Yes, of course :-)
> 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.
I assume you would like to create stable URLs in that paper. What do you
propose?
http://www.hydra-cg.com/spec/latest/...?
Or would you just reference
http://www.hydra-cg.com/spec/latest/linked-data-fragments/
or something else?
>>> 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".
Fair enough. Just let's make sure we clearly communicate this in the spec.
--
Markus Lanthaler
@markuslanthaler
Received on Wednesday, 8 July 2015 21:43:30 UTC