W3C home > Mailing lists > Public > public-lod@w3.org > August 2008

RE: BSBM With Triples and Mapped Relational Data in Virtuoso

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Fri, 8 Aug 2008 19:26:43 +0000
To: Chris Bizer <chris@bizer.de>, "public-lod@w3.org" <public-lod@w3.org>, "Orri Erling (by way of Ted Thibodeau Jr)" <erling@xs4all.nl>
Message-ID: <B6CF1054FDC8B845BF93A6645D19BEA345D541746D@GVW1118EXC.americas.hpqcorp.net>
> > * 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
> 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.


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:15:52 UTC