SPARQL/BASIL convention outside of query

[rosalinedehaan]

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.

[rlzijdeman]

@rosalinedehaan thank you very much for your response and willingness to look into compatibility between grlc and TriplyDB query notation. You appear to be modest about the advantages your solution has and only state that TriplyDB is different from GRLC and how GRLC could change things to be compatible.

Would you please highlight the advantages of the TriplyDB query notation over the current grlc/basil approach?

[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?

[rosalinedehaan]

Performing a mapping operation between TriplyDB and grlc queries may create unforeseen issues such as the user writing a query with variable name ?var in it, expecting ?var to be included in the resultset, but receiving ?_var_iri instead.

I think this discussion is about whether we want to include the API description in the SPARQL query itself, or whether we want to (optionally) de-couple the API description (eg as a decorator) and the SPARQL query part (the actual SELECT/CONSTRUCT). In TriplyDB we chose the latter, as this makes the API description more explicit, flexible (you'd run into limitations with what you can encode in a SPARQL variable name), and eventually more user friendly.

That being said, I agree that backwards compatibility is important here. Do you expect difficulties supporting both methods? (describing API variables via the variablenames themselves, and supporting it via a decorator syntax)

cc @LaurensRietveld

[c-martinez]

Hi @rosalinedehaan,

I think it would be technically possible to have a decorator which defines the variable naming convention (e.g. BASIL by default, something else when indicated by the decorator).

I guess the motivation (having queries stored on Triply and executed via grlc) is a good one.

I think we might need a design session to plan how this could be implemented and if that would meet your requirements and be backward compatible. @albertmeronyo -- maybe we can have a call sometime and discuss this?

[rosalinedehaan]

Hi @c-martinez,

Sounds good to me, thank you very much. @albertmeronyo @rlzijdeman, also thanks for your input.

Could you keep me updated?

[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