RE: BSBM With Triples and Mapped Relational Data in Virtuoso

> -----Original Message-----
> From: Orri Erling [mailto:erling@xs4all.nl]
> Sent: 09 August 2008 18:36
> To: Seaborne, Andy; 'Chris Bizer'; public-lod@w3.org
> Subject: RE: BSBM With Triples and Mapped Relational Data in Virtuoso
>
>
>
> Andy
>
>
> We might as well make an interoperable implementation of SPARQL protocol and
> client API's for supporting stored procedures and parametrized queries.
>
>
>
> What is the Arq way to call a procedure for side effect exactly once over
> the web protocol?

There are many variations on the concept of stored procedures - the aspect I'm focusing on is the ability to include custom code in query processing.  Java in the case of ARQ.

Stored procedures (and property functions) are pure functions and should not have side effects.  They take arguments and return results in variables.

>
> As I recall, the Jena query execution factory interface did not have
> provisions for parametrized queries.  Now, maybe there is such but what is
> it?

It does - it's called "initial bindings".

e.g. QueryExecution.create(Query, Dataset, QuerySolution initialBinding)

>
> Passing bindings for named SPARQL variables as an outermost scope for the
> query sounds OK.  Aside this, we do positional parameters  SQL style but
> then only through SQL CLI's  or SQL procedures.
>
> If there are no parameter markers syntactically distinct from variables,
> then the set of bound parameters is part of the  query's text, so to say.
> So we cache a query's compilation as a function of the source text and the
> set of parameter names plus protocol request options.  This is possible.  At
> first glance, named parameters seem OK. This is a notch prettier than
> positional since the SPARQL syntax is not affected.
>
> So, if you have a complete spec, re API's and protocol, let's implement it.

Does this imply the Jena-Virtuoso adapter does not provide SPARQL-level access to the Virtuoso query engine?  ARQ allows various places where adapters can plug in depending on the sophistication of the adapter.  One level is having a query engine registry that enables adapter to route a whole query to their internal execution processes.

> Parameters will save 1/3 of BSBM execution time, so we might as well have
> them now.
>
>
> Orri

One observation - spending time on common APIs (for language X, Y and Z) has benefits for application developers, but it must be balanced with the fact there is only some much wideband for standardization (de facto, de jure).  I do wonder if there are higher priorities - I see SPARQL/Update as more important.  We would need to find a suitable forum for common API development (not W3C).

        Andy

Received on Sunday, 10 August 2008 15:09:14 UTC