SPARQL/BASIL convention outside of query

Problem / Use case

When using an API variable in GRLC the SPARQL/BASIL convention needs to be applied in the query string, thus requiring user to specify within the query which variable is the API variable and of what type it is (e.g. ?_genre_iri rather then just ?genre).

In TriplyDB this is currently implemented outside of the query string. The only requirement is that the API variable has the same name as the variable inside the query string. The API variable (outside of the query string) can then also be of a certain type an have a default value or a list with allowed values (that you define as enumerate, I think). I personally don’t see the added value of using the BASIL convention in this case. But maybe I am missing something here.

The problem we have is that the BASIL convention inside of the query string makes compliance between GRLC queries and triplyDB queries complicated.

Desired Feature

We would like a feature that allows for the use of API variables without having to specify within the query string which variable is the API variable. A solution could be to have the BASIL convention in the GRLC comment section (and therefore query strings do not need to be adjusted). And therefore still include information about the variable type and indicate that it is an API variable.

#+   - ?_genre_iri: http://dbpedia.org/resource/Rock_music

PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX schema: <http://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?band ?album WHERE {
  ?band rdf:type dbo:Band .
  ?album rdf:type schema:MusicAlbum .
  ?band dbo:genre ?genre .
  ?album dbo:artist ?band .
} LIMIT 100

I would like to hear your thoughts on this.

[albertmeronyo]

After today’s discussion, this is the spec we’re targeting on both grlc’s and Triply’s side:

#+ parameters: # This disables BASIL syntax
#+   - genre:
#+      - description: Genre of bands to get
#+      - required: true
#+      - default: http://dbpedia.org/resource/Rock_music
#+      - type: iri
#+      - values:
#+  		- http://dbpedia.org/resource/Rock_music
#+      	- http://dbpedia.org/resource/Jazz

PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX schema: <http://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?band ?album WHERE {
  ?band rdf:type dbo:Band .
  ?album rdf:type schema:MusicAlbum .
  ?band dbo:genre ?genre .
} LIMIT 100

[albertmeronyo]

Hi @rosalinedehaan thanks for your suggestion.

Pros: This would make sense as we already put quite some load into the query metadata. So having there the parameter-variable mappings is perfectly possible. It wouldn’t force clients to stick to any variable convention. Cons: On the other hand, grlc query strings are valid SPARQL, so I don’t see why TriplyDB can’t e.g. map ?_var_iri into a parameter ‘var’ from your internal API specification? I’m just assuming there is one. Another issue would be making this backwards compatible with existing grlc APIs.

An interesting outcome though is that this would force us to put more thinking into a proper API-SPARQL mapping specification (e.g. nested declarations of variable types, enumerations, multiple values, etc.), something we’ve been postponing for quite some time.

@c-martinez what do you think? Perhaps signaling to the wider community could help?