On 5/31/13 11:17 AM, Mark Baker wrote:
On Thu, May 30, 2013 at 10:33 AM, Kingsley Idehen <kide...@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
smime.p7s
Description: S/MIME Cryptographic Signature
