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: Sun, 10 Aug 2008 14:48:02 +0000
To: Alan Ruttenberg <alanruttenberg@gmail.com>
CC: 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: <B6CF1054FDC8B845BF93A6645D19BEA345D5417578@GVW1118EXC.americas.hpqcorp.net>

> -----Original Message-----
> From: Alan Ruttenberg [mailto:alanruttenberg@gmail.com]
> Sent: 09 August 2008 17:54
> To: Seaborne, Andy
> Cc: Chris Bizer; public-lod@w3.org; Orri Erling (by way of Ted Thibodeau Jr)
> Subject: Re: BSBM With Triples and Mapped Relational Data in Virtuoso
> On Aug 8, 2008, at 3:26 PM, Seaborne, Andy wrote:
> >>> * 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.
> I presume you mean ??var1, ??var2, i.e. named parameters?
> >>
> >> 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.
> Except that there's no way (I know of) to do that setting. Could you
> give an example?

It's an API issue surely?  See below for how it can be done client-side without involving the server by substitution without needing full parsing.

> Also, there's no standard way to precompile/prepare
> the query, obviating the benefit of having a parameterized query in
> the first place. Unless I'm missing something in the spec (which I
> would be pleased to discover).

The value is not just preparing queries and overhead,  Query templates allow a separation of code and queries.

> > 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.
> Not having it in the standard/protocol is like not having it.

As it is not about efficiency, my point about client-side substitution shows there does not need to be a feature in the protocol.  A client can still have templates, no need for a full SPARQ parser and not need a protocol change.

> > This has worked well in ARQ, for RDQL and SPARQL for a while.
> Sure, and lots of people (including me) have done similar for SQL. I
> solves some problems (e.g. constructing queries that are
> implementation dependent, ability to do object relational mapping
> without explicit db support), but not others (e.g. avoiding the cost
> of compiling a query for frequently used queries).

Again - this seems to be about common API.  Making the SPARQL web protocol complicated and potentially stateful (e.g. prepared queries) has a downside - the simplicity of the design means it is more widely deployed and more widely implmeneted with the same semantics.

> > ARQ has had stored procedures for a while. Property functions (with
> > lists for subject and or object) seem to be preferred because it
> > remains within strict SPARQL syntax.
> Example please, as I'm not following what you mean.

Alan - the ARQ documentation is online and googlable!!


> >   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.
> An example where it is messy would help too.
> Best,
> Alan


Received on Sunday, 10 August 2008 14:49:47 UTC

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