RE: BSBM With Triples and Mapped Relational Data in Virtuoso

Andy


Of course, SPARQL update is more fundamental than parameters.  But it is, as
far as we are concerned, a done deal.

The Virtuoso Jena interface routes SPARQL queries to Virtuoso.  It  has
Graph and QueryExecution interfaces.  The QueryExecution interface gives a
nott implemented exception for setting initial bindings.  We might as well
fix this.  This needs some minimal  server side support and a way of passing
name-value pairs over JDBC instead of positional parameters.  Simplethings,
it will be done in the near future.


On the protocol side, we plan to support parameters as
?param=literal-in-sparql-syntax in the request parameters.  This is quite
unobtrusive.  The ? will distinguish parameters from other implementation
specific options.  Ivan will later specify exact syntax and escaping etc.  

With this, there can be a cache from query text + parameter names to
compiled query.  There is no really great need for a JDBC like prepared
statement concept, as I see it, although this would save a little more
execution time.  The cache lookup is quick enough.

If you already have parameters in the protocol, we will make ours
interoperable.  Otherwise we could agree on the above or something else.

We support calling functions in expressions. These may also be SQL user
defined functions.  We also support returning expressions in selects,
including from subqueries.  There  are no output parameters and the number
of times any function is called is up to the query plan. The function
support is thus at the level where it is with SQL.

Calling a function once for side effect should however be a part of SPARUL.
I have no real preferences for synntax, but the semantic should be a single
call to a server side procedure  with side effects.  The rationale is
exactly the same as that of a SQL stored procedure.

On the side of SPARQL itself, we could imagine a pattern in the triple
patternn place consisting of a function and parameters.
Some of these parameters would be output, as for example the hit score with
a full text match function.  Does this further imply that a function can
produce multiple sets of output bindings?  And can such a function pattern
be called with different combinations of bound and unbound parameters?

We have something of the sort on the SQL side, called a procedure view.  MS
SQL Server calls such a thing a table valued function.  Anyway, it makes a
result set and can take parameters that give a fixed value to some of the
result columns.  Then there is a cost model hookthat allows specifying what
cardinality and cost implications binding or not binding a result column may
have.

This is quite complex and general agreement would seem improbable to me.

Please send a link to a description of how Arq addresses functions in
queries.  It is in principle possible that we could implement a compatible
syntax, for example on top of the aforementioned procedure views if the
functionality is close.

It seems to me that most of these issues fall in the scope of the W3C's
SPARQL work.
The parameters in the Jena CLI and our implementation thereof is a detail
that we'll just get out of the way.
But beyond this, there are some deeper API questions that might justify a
lightweight forum of some sort.

Specifically, for efficient integration of storage and reasoning, an API
with asynchronous execution and array parameters seems quite necessary.
But the  reasoner should be written in a certain way, multithreaded and/or
breadth first, so to say, for it to make use of such.  Scaling implies
latency tolerant and multithreaded algorithms and I do not know to what
degree the reasoning systems in the RDF space are designed with this in
mind.

Aside this, the API's seem quite sufficient as they are.

As for SPARUL, should we do something aside adding our name to the
submission?



Orri

Received on Tuesday, 12 August 2008 08:55:26 UTC