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.
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.
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?
Andy
[*] I have never found a way to have visitor pattern and extensibility
but maybe I'm missing something. The visitor pattern relies on
public void visit() { visitor.visit(this) ; }
where the type system cause a dispatch on the type of 'this'. It's
compile time.
On 14/01/15 15:10, james anderson wrote:
good afternoon;
On 2015-01-14, at 15:47, Andy Seaborne <[email protected]> wrote:
On 14/01/15 14:32, james anderson wrote:
good afternoon;
On 2015-01-14, at 14:56, Andy Seaborne <[email protected]> wrote:
[…]
ok. so, in the lisp sense, these two are the reader and the
package definitions. there still needs to be something which
defines the signatures, that is, the function types.
The functions define their signatures. Some are multi-arity;
some have keyword processing (e.g. distinct). And some
evaluations isn't even functional (e.g. &&).
that is, no one has compiled the information, the individual
function implementation source is the only source and if i use
the content of the Tags.java file to search the source i should
find everything?
Could you give some context as to why our asking? Is it to extend
ARQ? Or develop a similar system elsewhere?
we are implementing a jni layer to makes our native rdf store and
sparql processor available from java. the intent is to provide
performance on the order of a memory store with the persistence and
memory footprint of a disk-based store. we have advanced quite far
toward this goal and now would like to devote some of our effort to
ensuring interoperability by integrating it into the jena framework.
Much of this is internal machinery (well, except that much is
defined by the SPARQL spec :-) and gets added to and refined for
that purpose. I never conceived of the implementation as a
external contract.
to the extent that a parsed query is provided to an implementation of
a jena provider, the interface appears to treat the query ast as a
part of a contractual exchange of sorts, and the sse is the natural
externalization. we observe that the original sparql query expression
is present as well, but had understood that its existence in the
interface was somewhat less certain.
in practical terms, our query processor works with forms analogous to
the arq sse, but with slightly different signatures with respect to
argument order. its core involves their direct macro-expansion and
compilation into run-able queries, which means, to use the sse would
save the effort of reparsing the query string. if, however, your
message is that the the ast and/or the respective sse is not stable,
but the presence of the query string is to be ensured, the safer path
would be for us to re-parse.
best regards, from berlin, --- james anderson | [email protected] |
http://dydra.com
