Skip to content

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

22/11/2012

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/&gt;
PREFIX dbpedia-owl: <http://dbpedia.org/ontology/&gt;
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/&gt;
PREFIX dbpedia-owl: <http://dbpedia.org/ontology/&gt;
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#&gt;
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.

4 commentaires
  1. B. Majour permalink
    22/11/2012 17:37

    A quoi ça sert, tout ça ? … Ce n’est pas pourquoi tant de haine ? :o)

    En plus, je ne disais pas « tout ça », mais je te demandais quel usage tu comptais dégager de ton expérimentation.

    Si je résume ce que explique dans ce billet, ton soucis est d’aller piocher dans DBpedia (et d’autres bases de données) pour enrichir ou nourrir ton OPAC.

    Ceci de manière simple (enfin si possible simple), via un utilitaire tel que Sparql…

    On interroge une base de données.
    On obtient des données.
    On tente de les incorporer dans son OPAC.
    C’est ça ?

    Question : est-ce que c’est long à mouliner avec Sparql via PHP ?
    Parce que si le PHP lance la requête à chaque fois, les pages de l’OPAC vont mettre un peu/beaucoup de temps à s’ouvrir.

    Autre point, de l’OPAC gourmet, on risque de passer à l’OPAC vorace et là, attention à l’obésité informationnelle ! ;o)

    Ayant suivi les liens que tu proposes, j’ai regardé un peu Dbpedia. Site riche, avec pas mal de rebonds possibles. En particulier les « dbpedia-owl:wikiPageExternalLink » qui peuvent conduire à des ressources intéressantes. (quand les liens sont encore valides !)

    Si j’ai bien regardé, Dbpedia récupère les infos de la Wikipedia et les mets en arbre XML.
    Visiblement, DBpedia pioche aussi ailleurs, et là, ça m’interpelle un peu beaucoup.

    Les OPAC peuvent aller piocher dans la DBPedia… mais quand servent-ils à leur tour de bases sources, de bases ressources.

    On se sert du travail des autres. A quel moment alimente-t-on le vorace informationnel ?
    A quel moment les Opac vont-ils devenir des arbres XML ?

    Le sont-ils déjà ?

    Si demain ils le deviennent, ça veut dire que tout le monde pourra piocher dans les Opac des uns et des autres… Ce sera le premier catalogue interconnecté. La première forêt de catalogues interconnectés.

    C’est vrai, je rêve. Il faudrait penser l’Opac comme un fichier XML. Mais ça ne me semble pas impossible. Au contraire, on est toujours dans une base de données, la transposition ne doit pas être si difficile.

    Hum, tout ça est à cogiter. 🙂
    Comme ton expérimentation étincelante.

    Tiens, au passage, j’ai noté une petite introduction sur ce site, pour les premières commandes à maîtriser :
    http://web-semantique.developpez.com/tutoriels/jena/arq/introduction-sparql/

    En tout cas, merci d’avoir fait siffler mes oreilles😉, je comprends mieux le sens de ta démarche.

    Bien cordialement
    B. Majour

  2. 23/11/2012 20:42

    @B. Majour :
    dans ton commentaire, il y a beaucoup de points que j’aimerais reprendre et nuancer. Je ne suis pas sûr de ne point en oublier.

    1. « Si je résume ce que explique dans ce billet, ton soucis est d’aller piocher dans DBpedia (et d’autres bases de données) pour enrichir ou nourrir ton OPAC. »
    Non : mon billet vise à dire que

    1. Si on sait exploiter des API, on sait exploiter des résultats de requêtes SPARQL (la « seule » compétence à ajouter est donc de savoir formuler une requête en SPARQL)
    2. Tout ce qui est possible avec des API peut le devenir avec des données RDFisées

    En fait, on dispose parfois dans nos universités ou nos bibliothèques d’informaticiens qui ont eu il y a quelques années une formation les rendant capables d’exploiter des API, mais pas de lancer des requêtes SPARQL. En revanche si la requête est faite, on peut leur demander d’en exploiter les résultats sur la base de compétences qu’ils ont déjà.
    Mais par ailleurs : l’utilisation d’API, ce n’est pas que pour enrichir ou nourrir mon opac. A Nice, nous nous en servons notamment dans Aleph pour enrichir les rapports de chargements Sudoc (ça gagne 1/4 d’heure par jour à ma collègue en temps d’analyse sur les cas problématiques) ou pour préparer les chargements de données lors d’intégration de nouveaux fonds (j’en ai fait un billet il y a quelque temps).
    Mais le fond de l’histoire est : on manque souvent d’imagination (quand ce n’est pas de compétence) pour penser à exploiter des données disponibles sous forme d’API ou de données RDFisées.
    C’est un peu comparable à Google N-gram Viewer : aura-t-on jamais fait la liste exhaustive de tout ce qu’on pourrait en faire ?

    2. « Question : est-ce que c’est long à mouliner avec Sparql via PHP ? »
    Je ne sais pas trop, mais je suis plutôt impressionné par les temps de réponses.

    3. « Ayant suivi les liens que tu proposes, j’ai regardé un peu Dbpedia. Site riche, avec pas mal de rebonds possibles. En particulier les « dbpedia-owl:wikiPageExternalLink » qui peuvent conduire à des ressources intéressantes. (quand les liens sont encore valides !) »
    C’est plutôt l’inverse : les « dbpedia-owl:wikiPageExternalLink », ce sont plutôt des liens non sémantisés.
    Ainsi, dans la page DBpedia sur Romain Gary, on trouve

    dbpedia-owl:wikiPageExternalLink resource:Chien_Blanc

    donc ce n’est pas vraiment une indication que Chien Blanc a été écrit par Romain Gary.
    Alors que dans la page Chien Blanc, on trouve :

    dbpedia-owl:author resource:Romain_Gary

    D’où d’ailleurs ma requête, qui cherche les resources DBpedia dans lesquelles Romain Gary est mentionné comme auteur, au lieu de chercher dans la ressource « Romain_Gary » la liste de ses oeuvres.

    4. « Si j’ai bien regardé, Dbpedia récupère les infos de la Wikipedia et les mets en arbre XML. »
    Non : DBpedia les met en données RDFisées.
    Il me faudrait de longues explications pour développer ce que ça change (Gautier Poupeau l’a déjà fait avant moi, et quand je le lisais, il y a un ou deux ans, je ne le comprenais pas).
    L’idée de base est la suivante : une information dans un arbre XML n’a de sens que dans le contexte de son fichier XML. Un triplet est toujours vrai.
    Ainsi :

    http://fr.dbpedia.org/resource/Chien_Blanc dbpedia-owl:author http://fr.dbpedia.org/resource/Romain_Gary

    peut être mise en ligne dans n’importe quelle base de triplets, elle reste vraie.

    A l’inverse, si je prends le fichier XML suivant :

    <livre>
      <titre>Chien Blanc</titre>
      <auteur>Romain Gary</auteur>
    </livre>
    

    et que je veux en retirer un noeud XML (c’est l’unité de base du fichier XML), par exemple : <auteur>Romain Gary</auteur>
    celui-ci n’a aucune « valeur » hors du contexte du fichier XML complet.

    Mais je ne réponds pas complètement à ta question posée : là, j’en suis à constater des possibilités.
    J’ai déjà eu l’occasion, très concrète, d’utiliser des API au boulot (et j’en ai parfois rendu compte ici), mais pas encore des données RDFisées. Mais quand ça se produira, c’est promis, tu le sauras🙂

  3. 27/11/2012 11:51

    Merci !

    C’est très exactement la question que je me posais, ayant de plus en plus de mal à suivre sans expérimenter moi-même. Et outre le temps qui manquait, les freins à l’expérimentation étaient que je n’avais pas compris le but final.

    Là, ça y est. Ça prend corps et sens. Et ouais, ça a l’air puissant.

Trackbacks

  1. Bibliothèques [reloaded] : Utiliser les SPARQL Endpoint comme si c’était des API | Bibliolab, l'atelier des hybrides | Scoop.it

Les commentaires sont fermés.

%d blogueurs aiment cette page :