ob-sparql should support variables

[alf]

I'm implementing this and would like to discuss some details.

In my original pull request #32, I used '$' as the variable marker. The problem with this is that in SPARQL both '?' and '$' function as query variable markers and the variable '$var' is the exact same variable as the variable '?var'.

I've now changed the code to use '%' as the variable marker as mentioned in that pull request.

However, I'm wondering whether this is the correct choice for the following reasons:

• We're introducing a third variable marker to the mix
• The use of $ as the variable marker is used elsewhere in org babel

In addition I'm wondering if it might actually be a feature that we use the same variable marker as used in SPARQL. The reason for this is that I can write a general query where I use variable ?x as an unbound. My query does not return quite what I'm interested in, so I decide to bind ?x to a known property to debug the query. Using org-babel I could then add :var x="<prop>" to replace ?x with <prop> without changing the query. I could test different bindings for ?x by using #+call etc.

My new favourite solution is that we support both ? and $ as variable markers.

Note: The way variable substitution works is that we look for and replace only the variables declared in the :var header.

[alf]

An additional reason why supporting both is good is that users can keep using their preferred variable marker in SPARQL and use the other one in ob-sparql.

This assumes of course that people don't mix '$' and '?' in the same query...

[ljos]

I seem to not have been very clear. I am sorry about that. What I meant was that you should use both keys that SPARQL uses, not a third one. E.g. if you have the query

#+BEGIN_SRC sparql :var x="friend:Julia"
  SELECT * WHERE {
    ?x foaf:name ?name.
    $x foaf:email ?email.
  }
#+END_SRC

it becomes

SELECT * WHERE {
  friend:Julia foaf:name ?name.
  friend:Julia foaf:email ?email.
}

You replace both since they are identical in SPARQL.

[alf]

Excellent, then we are in agreement.

[alf]

Created new pull request for this: #35

[ljos]

Closed by #35