Re: Using Labels in SPARQL

On Jun 2, 2007, at 2:46 AM, Alan Ruttenberg wrote:

> 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).

I'm not surprised :)

But really, this is a bit orthogonal to my original point. I wasn't  
saying anything about the *mechanism* of implementation or  
specification, or at least I didn't mean to.

> 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.

I agree but that's a distinct *sort* of case, because it doesn't  
involve information from the to-be-queried-store. Also, quite a lot  
of good can be gotten out of designing a succincter variant of the  
expression language. It's not the *be all* or end all, obviously, but  
it's worth considering.

> But really I want to be able to encapsulate arbitrary sized  
> portions of queries and let people write relatively simple  
> expressions for useful queries.

Well, clearly that's where I was going with my straw example of how  
to define the labelFor/hasLabel "Function".

> 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.

Fun.

> 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.

Makes sense, obviously. It's pretty clear that raw sparql is a pretty  
bad deal (but then, so is raw SQL). What's bearly endurable can  
quickly become the uberyuck.

But then, there's the question of whether the query language is going  
to be "the" interface for a wide range of people.

> 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.

The familiar divide.

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

Seems like there are the usual trade offs.

> 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.

Should that be "e.g.,"? I mean, they could have an arbitrary syntax  
and live in literals. We could ask triple stores to have a special  
place. (not a huge burden one you've added the facility in the first  
place).

Cheers,
Bijan.

Received on Saturday, 2 June 2007 03:12:39 UTC