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

On 5/31/13 11:17 AM, Mark Baker wrote:
> 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.

Yes, I think I acknowledged that point in an earlier response to Leigh.

>
> 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.

Yes, I agree. Will certainly look to incorporate that since we are 
currently working on improvements in this area.

>
> 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.
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen