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? 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 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.

> 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).

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

>   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 04:41:31 UTC