Re: Again on endpoint server limits [WAS Re: Public SPARQL endpoints:managing (mis)-use and communicating limits to users.]

On Thu, May 30, 2013 at 10:33 AM, Kingsley Idehen
<kidehen@openlinksw.com> wrote:
> On 5/30/13 9:13 AM, Andrea Splendiani wrote:
>>
>> Hi,
>>
>> let me get back to this thread for two reasons.
>> 1) I was wondering whether the report on DBPedia queries cited below was
>> already published.
>> 2) I have recently tried to use DBPedia for some simple computation and I
>> have a problem. Basically a query for all cities whose population is larger
>> than that of the countries they are in returns a random number of results. I
>> suspect this is due to hitting some internal computation load limits, and
>> there is not much I can do with limits, I think, as results are no more than
>> 20 o so.
>>
>> Now, I discovered this by chance. If this due to some limits, I would much
>> better prefer an error message (query too expensive) than partial results.
>> Is there a way to detect that these results are partial ?
>
> Of course, via the response headers of the SPARQL query:
>
> 1. X-SQL-State:
> 2. X-SQL-Message:
>
> We are also looking at using HTTP a bit more here i.e., not returning 200 OK
> if the resultset is partial.

Kingsley - The problem isn't with HTTP, it's with SPARQL's mapping to
HTTP, so the solution isn't to patch HTTP, it's to fix the mapping.

The correct-by-HTTP way of doing this is for the server to publish a
GET form/template (even if just as documentation, if you don't want to
go the extra mile) which constructs a URI that returns the desired
data. By virtue of publishing this form/template/docs, the server is
acknowledging its support of this potentially expensive query, which
suggests that they'd need to do one or both of a) creating an index
specific to this query, b) enabling caching so that the query only
needs to be performed when there's a reasonable chance that the data
has changed, and also falls below some internal cost-of-servicing
value set by the publisher.

BTW, it's great to see the problems I discussed with SPARQL/HTTP many
years ago described so well by a SPARQL user;
http://www.markbaker.ca/blog/2006/08/sparql-useful-but-not-a-game-changer/

Mark.

Received on Friday, 31 May 2013 15:18:15 UTC