Re: DBpedia now available as triple pattern fragments

Hi Ruben

Perceived performance vs. actual performance is very interesting. Giving the user the impression that *something* is happening often feels nice than a blank screen. However can also be frustrating not to know when the page will finish loading.

p.s. I don't see anything preventing a SPARQL endpoint from streaming results when possible (e.g. When no ORDER BY clause is present).

Regards,

John

On 1 Nov 2014, at 11:54, Ruben Verborgh <ruben.verborgh@ugent.be> wrote:

> Hi Simon,
> 
>> Regarding the slow query time: I've noticed that the results are
>> "dropping" in. If you do clever visualization this might not hurt as
>> much because you can already start drawing and the user sees some
>> progress happening. (How much sense this makes depends on the result
>> format of course)
> 
> That's a *very* interesting remark, because it goes to the core of a new query paradigm.
> Indeed, because the query processing happens locally, results are streaming.
> So even though it might take some time until _all_ of the results are there,
> you can already start acting on _each_ of the results as soon as they arrive.
> 
> So this means, with a SPARQL endpoint, the workflow is normally:
> - you ask, you wait, you do
> With streaming results, the workflow becomes:
> - you ask, and you do for each result that comes in
> 
> A graphical illustration of this concept is available here:
> http://www.slideshare.net/RubenVerborgh/querying-data-on-the-web-client-or-server/54
> 
> Especially for visualization, as you say, this might be cool.
> For instance, we could imagine a map
> and results get added to it as little dots as soon as they come in.
> 
>> This might not remove from the actual time the process takes, but it
>> might make it "feel" faster and more responsive - which is a thing
>> that should not be underestimated.
> 
> Well said :-)
> 
> Best,
> 
> Ruben

Received on Saturday, 1 November 2014 13:16:43 UTC