On 14/01/15 13:28, james anderson wrote:
good afternoon;
On 2015-01-14, at 14:12, Andy Seaborne <[email protected]> wrote:
On 14/01/15 12:39, james anderson wrote:
good afternoon;
the documentation notes for jena’s sparql s-expression syntax ends with the
following passage.
SSE Grammar
@@ insert grammar here
whereby, the document itself actually already describes all of the
distinguishing features of the grammar.
the missing information is the enumeration of the operator names and their
signatures.
it would not even be necessary to have their definitions, as those would likely
follow from the sparql grammar and language semantics.
is such a list hidden somewhere in the source tree?
https://github.com/apache/jena/blob/master/jena-arq/Grammar/sse/sse.jj
Tokens are very literal.
as they well should be.
This is styled like lisp - the way the data structure gets used defines the
operators (I presume you mean SPARQL algebra?
yes,
SSE used elsewhere as well) not the syntactic language.
but i guess i do not understand the difference, since the point of
s-expressions is to muddy the distinction between surface and abstract syntax.
https://github.com/apache/jena/blob/master/jena-arq/src/main/java/com/hp/hpl/jena/sparql/sse/Tags.java
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. &&).
The idea of a general data structure is that it does not prescribe the
functions or usage.
The SPARQL algebra defines that for it's usage.
All "dynamic" in style.
Andy
best regards, from berlin,
---
james anderson | [email protected] | http://dydra.com
