Re: Using Labels in SPARQL

On Jun 1, 2007, at 1:24 PM, Bijan Parsia wrote:

>> Even though I'm not keen on specifying the extra triples in the  
>> query I'm not sure this warrants ad-hoc extensions to a standard.
>
> Well, it was more of a use case. I'm thinking about syntactic sugar  
> for sparql as a whole and this seems to be an important case.

I'd also prefer a general macro mechanism (no surprise). For example  
more annoying than the labels in the queries are the verbose  
expressions for restrictions and other owl class expressions that I  
have to write. But really I want to be able to encapsulate arbitrary  
sized portions of queries and let people write relatively simple  
expressions for useful queries.

I've been working with Jonathan a bit about this, so maybe he can  
chime in with what his ideas. Also, the Virtuoso folks have offered  
to prototype the macro mechanism if we come up with a spec, so we're  
going to try to get something in the next few weeks for them.

I can, of course, do lisp macro expansion in LSW  - I've done this  
before for other query systems, but haven't done so for SPARQL yet  
mostly because I've been presenting it and want everything to be  
vanilla, and without extra requirements for running.

Here are two kinds of ideas for macros in SPARQL.

1) Templating: You define a template with some blanks to substitute.  
"invocation" of the macro takes the arguments to it and replaces the  
macro call in the query with the filled in template.

2) Full programming language generation: You assume that there is a  
javascript interpreter embedded in the query parser. A macro  
invocation is a javascript function call that generates a replacement  
for itself (either as some sort of datastructure that is rendered  
into sparql, or, in a pinch, as text). Javascript is chosen because  
it is easy to embed and well known in the communities that we want to  
use this stuff.

Both of these proposals annoy Jonathan to a certain extent. Hopefully  
they will annoy him enough to cough up a worked out counterproposal :)


BTW, In both cases I would expect that there could be an extensible  
set of such macros that live in the triple store itself, and that  
would grow over time and easily be shared i.e. they would have an rdf  
representation of some sort.

-Alan