On Aug 10, 2008, at 10:48 AM, Seaborne, Andy wrote:
-----Original Message-----
From: Alan Ruttenberg [mailto:[EMAIL PROTECTED]
Sent: 09 August 2008 17:54
To: Seaborne, Andy
Cc: Chris Bizer; [email protected]; 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:
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.
Actually I was thinking in terms of the SPARQL protocol which is
currently the only API that is standardized. When you say "SPARQL has
xxx", I look to the SPARQL specifications (language or protocol) to
see where xxx is specified, and if they aren't specified there I am
(and was) confused.
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.
I'm aware of that, as I pointed out in my post. See me taking
advantage of such at [1][2] which take an OWL file as input and
builds a new one out of the result of a set of templated queries
based on the input
[1] http://purl.obofoundry.org/obo/obi/repository/trunk/src/tools/
build/external-templates.txt
[2] http://purl.obofoundry.org/obo/obi/repository/trunk/src/tools/
build/create-external-derived.lisp
However the benefit that I believe is more important at the protocol
level (because otherwise there's just no other way to support it, as
contrasted with client side parameterized queries), and the one that
Orri was speaking about was the server side preparation for reasons
of improving performance.
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.
We're obviously miscommunicating. I *am* talking about efficiency,
and this was the basis of the initial message. Sorry for the tone of
my message - I reacted the "it's already done" attitude, when it
seemed like you were missing the point. Orri specifically asked about
side effect (i.e. preparation) and web protocol, both of which, it
turned out on reading the "it's already done" message, were not done.
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 implemented with the same
semantics.
I do see how having the protocol modified to support this, if
stateful, *could* be a disadvantage. I don't see how the semantics
would need to change. And the change doesn't have to be stateful. For
example, the support might be optional, and if provided, the call to
prepare could return an opaque string to be passed back to the
client, and which needs to be passed back for future runs of the
"prepared" query. However, if the server did provide state and pre-
compilation it could just pass back a key to the prepared query. If
you really wanted to be careful, one could insist that the original
query be always passed in addition. You pay a small price in network
bandwidth, but my understanding is that this isn't where the cost
savings is to be had.
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!!
http://jena.sourceforge.net/ARQ/extension.html#propertyFunctions
Thank you. I googled ARQ stored procedures originally. My bad. For
extensions the syntax is reasonable. I'd hope for something better
for 2.0. But more on that some other time.
Regards,
-Alan
