Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-12 Thread Stas Malyshev
Hi! > The Linked data fragments approach Osma mentioned is very interesting > (particularly the bit about setting it up on top of an regularily > updated existing endpoint), and could provide another alternative, > but I have not yet experimented with it. There is apparently this: https://github.

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-12 Thread Neubert, Joachim
It's great how this discussion evolves - thanks to everybody! Technically, I completely agree that in practice it may prove impossible to predict the load a query will produce. Relational databases have invested years and years in query optimization (e.g., Oracles cost based optimizer, which re

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-12 Thread Markus Krötzsch
On 12.02.2016 10:01, Osma Suominen wrote: 12.02.2016, 10:43, Markus Krötzsch wrote: Restricting queries syntactically to be "simpler" is what we did in Semantic MediaWiki (because MySQL did not support time/memory limits per query). It is a workaround, but it will not prevent long-running queri

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-12 Thread Osma Suominen
12.02.2016, 10:43, Markus Krötzsch wrote: Restricting queries syntactically to be "simpler" is what we did in Semantic MediaWiki (because MySQL did not support time/memory limits per query). It is a workaround, but it will not prevent long-running queries unless you make the syntactic restrictio

Re: [Wikidata] SPARQL CONSTRUCT results truncated

2016-02-12 Thread Markus Krötzsch
On 12.02.2016 00:04, Stas Malyshev wrote: Hi! We basically have two choices: either we offer a limited interface that only allows for a narrow range of queries to be run at all. Or we offer a very general interface that can run arbitrary queries, but we impose limits on time and memory consumpt