RE: BSBM With Triples and Mapped Relational Data in Virtuoso

> > * 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

Received on Friday, 8 August 2008 19:28:08 UTC