Re: 404 Re: Comments on the Triple Patterns Fragments draft

On Friday 01 August 2014 00:00:52 Kjetil Kjernsmo wrote:
> On Thursday 31. July 2014 22.55.59 David Booth wrote:
> > I should add that requiring the client to special case the 404 result
> > may be particularly unpleasant for the client programmer, because it
> > breaks separation levels: it forces an error code to be reinterpreted as
> > a legitimate data result, so the code cannot cleanly process error codes
> > separately from legitimate data results.  It is qualitatively different
> > from, for example, deciding at the business logic level to process 1
> > result differently than 5 results.
> 
> I'm with Ruben here, I would certainly not be required to interprete the
> payload of the error separately. I don't know about other environments
> though.
> 
> The whole difference is that with a 200, I would have to parse the payload
> to see if there was an empty result, with 404, I can safely conclude
> already once the HTTP response is parsed.
> 
> For a SPARQL implementation on the top of LDF, that sounds like huge win to
> me: If a single triple pattern of a BGP returns a 404, I can stop processing
> that BGP and return an empty result for the whole BGP, while I would have
> to parse the result if it returned a 200 for every triple pattern.

It's not going to be such a huge win I am afraid. The time it requires to 
process an incoming TPF locally is negligible compared to the time it requires 
to (i) request the TPF, (ii) wait for the server to prepare its response, and 
(iii) retrieve the response---and spending a little bit more local processing 
time to parse the body of the TPF is not going to change that, in particular 
because the body of TPFs with an empty result can be expected to be very 
small.

I did similar experiments in the context of my work on traversal-based query 
execution over Linked Data on the WWW. My results show that the fraction of 
query execution time that is required for the local processing is negligible. 
For instance, in Figure 7.6 of my dissertation [1] (page 158) you will notice 
a difference of several orders of magnitude between overall query execution 
time and the (cumulative) local-processing time.

So, potential performance improvements of SPARQL over an LDF collection cannot 
be used as an argument for indicating empty TPFs by a 404.

Best,
Olaf

[1] http://olafhartig.de/files/DissertationOlafHartig.pdf


 
> Cheers,
> 
> Kjetil

Received on Friday, 1 August 2014 01:22:38 UTC