> > * For the SPARQL community, BSBM sends the message that one ought to
> > support parameterized queries and stored procedures. This would be
> > a SPARQL protocol extension; the SPARUL syntax should also have a
> > way of calling a procedure. Something like select proc (??, ??)
> > would be enough, where ?? is a parameter marker, like ? in
> > ODBC/JDBC.
>
> Also a great idea and maybe something Ivan does not have on his list
> yet.
SPARQL already has parameterized queries! Because it has explicit (named)
variables, these can be used to set variables scoped just outside the query
string.
The ODBC /JDBC approach of positional parameters, and this is named parameters.
Semantics is it like joining in a one row table (because you can think of
variables in graph patterns as set-once assignments that allow reassignment of
th eame value but not a different value.
There is an issue of whether the parameterisation is applied client or server
side. If client side, no protocol changes are needed. It is a burden on a
client do some level of parsing to correctly substitute parameters but I think
it's just a (non-trivial) regex as it only has to deal with variable-like
syntax outside strings (c.f. the canonical JSON regex to check for safe
javascript). That means even simple clients that don’t do much more than
build/send SPARQL strings are still possible. No parser necessary.
Adding to the protocol might be nice but it's not a showstopper. This has
worked well in ARQ, for RDQL and SPARQL for a while.
ARQ has had stored procedures for a while. Property functions (with ists foir
subject and or object) seem to be preferred because it remains within strict
SPARQL syntax. They do get messy if the match to the S-list/P/O-list form is
not natural. Property functions don’t allow for expressions.
Andy
