W3C home > Mailing lists > Public > public-lod@w3.org > August 2008

Re: BSBM With Triples and Mapped Relational Data in Virtuoso

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Sun, 10 Aug 2008 22:36:24 -0400
Message-Id: <BBEBFAB6-B4DC-46D9-B58E-097ED0264C85@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>
To: "Seaborne, Andy" <andy.seaborne@hp.com>

On Aug 10, 2008, at 10:48 AM, Seaborne, Andy wrote:

>> -----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:
>>> 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/ 
[2] http://purl.obofoundry.org/obo/obi/repository/trunk/src/tools/ 

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.


Received on Monday, 11 August 2008 02:37:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:20:41 UTC