- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Sat, 1 Nov 2014 20:35:12 +0100
- To: John Walker <john.walker@semaku.com>
- Cc: "heimlersimon@gmail.com" <heimlersimon@gmail.com>, "public-hydra@w3.org" <public-hydra@w3.org>
Hi John, > However can also be frustrating not to know when the page will finish loading. Good point! We could probably derive heuristics. > I don't see anything preventing a SPARQL endpoint from streaming results when possible (e.g. When no ORDER BY clause is present). Sure; nothing holds SPARQL endpoints back from streaming their result; even if there is an ORDER BY clause, they might still stream because of indexes. But i haven't experienced streaming yet on any public SPARQL endpoint (let me know if you see one). This also reaches a fundamental point about how we ask queries. When you ask a server to solve a SPARQL query, you might not be concerned about adding possibly blocking operators such as SORT BY / MIN / GROUP BY / … The query paradigm is “ask – wait – do” anyway, so whether you or the server perform that blocking operations doesn't matter. However, things change if clients execute queries, where the paradigm becomes “ask – do as results arrive”. Maybe it's better then to drop the blocking operators, and to just perform them in an iterative way. For instance: lists can dynamically resort as new items arrive, instead of having to wait until the final, sorted result is ready. Best, Ruben
Received on Saturday, 1 November 2014 19:35:46 UTC