good afternoon; On 2015-01-16, at 15:35, Andy Seaborne <[email protected]> wrote:
> james, > > (mostly offline driving yesterday) > > The algebra in ARQ extends the SPARQL algebra so the SSE forms have both > aspects. > > The SPARQL algebra part is, necessarily, stable. It reflects the design in > the SPARQL 1.1 doc. as expected - so long as one does not change their approach to argument order… > > The extensions, which are mainly generated by the optimizer to do things in a > "better way". > > Example: (topN). A Top N query - that is, the SPARQL query has ORDER/LIMIT > and the limit is some reasonable value - can be executed with an algorithm > that is O(x) fashion, avoiding the full O(x*log(x)) sort, where x is the > number of matches of the WHERE clause. What's more, it only need memory > proportional to the limit, not x. > > (topN) is not in the SPARQL 1.1 doc. > > Other operators are introduced to be better joins, where better algorithms > are possible but its still a join. e.g. (conditional) is a left-join without > worrying about variable scope. as the jena sparql implementation is conformant, it would have to be possible for us to either rewrite the special cases back to equivalent standard forms or - to the extent that we can, implement them directly. i would be very curious about any optimization form from which it were not possible to recover the standard equivalent. > > In reality, the algebra is stable even if not formally declared as such. > Other external systems depend on it; other modules in Jena use it; a lot of > execution and processing is via the visitor pattern so adding or changing it > is non-trivial work [*] . > > That does not give you a contract guarantee although the reality is very > close. If you are using just the SPARQL 1.1 algebra, it is fixed. Change in > the the optimization operations would most likely to add a new operator. All > the extended operators are the result of a optimization transform and each > and every one is switchable on and off. > > SSE also extends into ways to have data structures - graphs, result sets, > various other things. > > Would it help if 'Tags' was broken up into modules for the different SSE uses? it would be useful to know which of the operators enumerated in the tags file would be required to interpret a standard sse which are in jena's “optimized” realm. any purportedly conformant sparql 1.1 implementation (as ours is) would need to support just the standard forms and could ignore all the others. best regards, from berlin, --- james anderson | [email protected] | http://dydra.com
