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
