Utiliser les SPARQL Endpoint comme si c’était des API

En fait, le titre du billet est peut-être incorrect : faudrait-il plutôt dire « utiliser les bases de triplets comme si c’était des API » ? Enfin bref, vous allez comprendre quand même.

Ce billet est en partie une répnose à la légitime interpellation de Bernard Majour quand je me lançai à la découverte de SPARQL disant en substance : A quoi ça sert, tout ça ? (et non pas « Pourquoi tant de haine ?« , quoique cette question eût été tout aussi légitime.

Une API ? (pour mémoire)

Une API branchée sur une base de données fonctionne de la manière suivante :

• vous lui fournissez une URL contenant un ou plusieurs paramètres
• elle vous renvoie un fichier structuré (XML ou Json) avec une ou plusieurs réponses.

Par exemple : on demande à l’API Multiwhere du Sudoc qui possède l’édition originale de Mein Kampf, et elle renvoie ce fichier en réponse.

Il faut bien sûr être capable ensuite de traiter le fichier en question (par exemple en réexploitant une seconde API qui à laquelle on donne le résultat de la première, pour disposer d’une réponse plus « lisible »). Il faut aussi être capable d’injecter ces réponses au sein d’une interface web, par exemple au sein d’une liste de résultats d’opac, pour proposer une alternative (exemple : sur une requête lancée dans mon catalogue, afficher les 5 premiers résultats de la même recherche si elle était lancée sur le Sudoc).

Les limites fonctionnelles des API sont nombreuses. En voici déjà trois :

• le langage n’est pas standardisé, chaque API a sa structure, et il faut lire la documentation qui lui est associée pour savoir ce qu’on peut en faire
• on est tributaire des requêtes prévues par le fournisseur de l’API.
  Donc on ne peut lancer des requêtes qu’il n’aurait pas envisagé de proposer (la recherche par titre sur le Sudoc n’existe pas via une API, par exemple)
• on ne choisit pas les informations qui seront renvoyées dans les résultats
  Dans l’exemple ci-dessus, l’API renvoie le n° du RCR, le « shortname » et les coordonnées spatiales de la bibliothèque. Pour avoir toutes les infos sur ce RCR (libellé « normal », site web de la bibliothèque, etc.) je dois relancer une nouvelle requête sur une autre API.

Mais bon, gardons cela en tête : une API, c’est une URL qui renvoie des résultats structurés.

Une requête SPARQL, c’est pareil

La fiche Wikipedia de Romain Gary contient une bibliographie de ses oeuvres. On retrouve donc cette même liste dans la page DBpedia correspondante.

On trouve donc dans DBpedia des triplets du type :

dbpedia_fr:Romain_Gary dbpedia-owl:author dbpedia_fr:Chien_Blanc

(dbpedia_fr étant le préfixe remplaçant : http://fr.dbpedia.org/resource/)

Donc je peux construire sur le SPARQL Endpoint de la DBpedia francophone une requête pour extraire cette liste :

PREFIX db: <http://fr.dbpedia.org/resource/>
PREFIX dbpedia-owl: <http://dbpedia.org/ontology/>
select distinct * where {?oeuvre dbpedia-owl:author db:Romain_Gary}

(cette requête cherche en réalité dans toutes les resources DBpedia là où Romain Gary est mentionné comme auteur : il part donc des oeuvres, en s’appuyant sur la « relation » author, et non de l’auteur lui-même)

Dans le SPARQL Endpoint, on peut spécifier que les résultats soient en XML ou en JSON

Ce qui me donne le résultat ci-dessous

qui correspond à cette URL :
http://fr.dbpedia.org/sparql?default-graph-uri=&query=PREFIX+db%3A+%3Chttp%3A%2F%2Ffr.dbpedia.org%2Fresource%2F%3EPREFIX+dbpedia-owl%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3Eselect+distinct+*+where+%3Foeuvre+dbpedia-owl%3Aauthor+db%3ARomain_Gary&format=application%2Fsparql-results+xml&timeout=0&debug=on

Dans l’URL, on retrouve

• la racine du SPARQL Endpoint : http://fr.dbpedia.org/sparql?
• la requête (paramètre query)
  PREFIX+db%3A+%3Chttp%3A%2F%2Ffr.dbpedia.org%2Fresource%2F%3E%0D%0APREFIX+dbpedia-owl%3A+%3Chttp%3A%2F%2Fdbpedia.org%2Fontology%2F%3E%0D%0Aselect+distinct+*+where+{%3Foeuvre+dbpedia-owl%3Aauthor+db%3ARomain_Gary}
  si cette requête n’est pas claire pour vous, vous pouvez la copier-coller dans ce formulaire et cliquer sur « Decode »
• le format en sortie : format=application%2Fsparql-results+xml
• le timeout (on renonce à la requête en cas de temps de réponse trop long du serveur)
• le paramètre debug, qui m’indiffère au plus au point

En résumé, pour une URL donnée contenant les paramètres d’une requête (des variables), on obtient un résultat structuré (en XML ou JSON)

Les avantages du SPARQL sur l’API

En comparant simplement les deux, quelques petites choses me sautent aux yeux

• pas besoin de lire la doc sur l’API : je lance une requête SPARQL et je vois ce qui sort. Avec une API, on ne peut pas lancer de requête à l’aveugle, il faut d’abord savoir comment elle fonctionne
• le langage de requête est standard, il suffit de l’apprendre (allez hop, au boulot)
• on peut envisager n’importe quelle requête sur les données, même celles non envisagées par le fournisseur. Seule condition : que les données soient là.
• on peut décider de récupérer les informations qu’on veut rapatrier dans les résultats

En effet, je peux tout à fait trouver insatisfaisant les résulats XML ci-dessus : pour mon opac, j’aurais plutôt besoin des titres des livres que des URL pointant vers dbpedia : donc remplacer

http://fr.dbpedia.org/resource/Chien_blanc
par
Chien blanc

Il me faut donc récupérer dans la requête les libellés de ces oeuvres.

La requête sera celle-ci :

PREFIX db: <http://fr.dbpedia.org/resource/>
PREFIX dbpedia-owl: <http://dbpedia.org/ontology/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
select distinct * where {?oeuvre dbpedia-owl:author db:Romain_Gary.
?oeuvre rdfs:label ?titre.}

L’URL des résultats sera ici (en XML) ou là (en HTML)

Et les résultats eux-mêmes (en XML) ressembleront à ça :

Donc si je connais un peu de PHP (ou de JavaScript ?), je peux afficher dans mon opac, sous chaque ouvrage, la bibliographie de l’auteur extraite de DBpedia, avec une variable Auteur qui est présente dans l’URL de requête.