Skip to content

Sparql Endpoint : pourquoi j’ai du mal à exploiter des résultats d’une requête

22/01/2016

Il y a plus de 3 ans, j’écrivais en toute innocence que finalement, on pouvait utiliser les SPARQL Endpoint comme on peut utiliser les API : dans les 2 cas on structure une URL correspondant à une requête dans une base de données, et le serveur renvoie un résultat dans un format structuré.

Un cas d’école : si je veux récupérer le PPN d’un ISBN donné, j’interroge l’API Sudoc idoine en structurant une URL de ce genre : http://www.sudoc.fr/services/isbn2ppn/0195141156.

Une des grosses différences, en tant qu’utilisateur, est que le SPARQL Endpoint permet de lancer une requête que l’administrateur du site n’aura pas prévu. Alors que l’API oriente l’usage qui peut en être fait. Ainsi, je ne peux pas utiliser l’API isbn2ppn pour récupérer le nom des directeurs de thèses de ceux qui ont publié au moins un livre dont l’ISBN commencent par « 019 » et qui sont par ailleurs docteurs (oui, SPARQL permet de faire plein de requêtes complètement absurdes, comme sortir de DBpedia ou Wikidata la liste des artistes nés il y a 69 ans).

Et donc depuis plusieurs années j’utilise un tas de feuilles XSL pour enrichir mes fichiers XML de données aspirées d’API. Et je pensais pouvoir aisément faire la même chose. La seule différence serait que l’URL contiendrait une requête SPARQL, au lieu d’une requête à la syntaxe spécifique à l’API.

Mais chaque fois que je demande à un SPARQL Endpoint une sortie au format XML (donc structuré, aspirable par ma feuille XSL) plutôt qu’une sortie HTML (le paramètre dans l’URL passant de &format=text/html à &format=application/sparql-results+xml), jamais mon navigateur ne m’affiche le résultat (artistes de 69 ans via DBpedia, format XML) comme il le fait pour une API (quand on clique sur l’URL d’une requête de l’API Sudoc isbn2ppn, ça s’affiche tranquillement dans Firefox) : à chaque fois, je suis obligé d’ouvrir le fichier avec un éditeur XML, car celui-ci est proposé au téléchargement exclusivement.

J’ai cru à un bug, un problème de configuration de mon navigateur, je ne sais quoi encore.

Mais en fait non.

Si j’ai bien compris, la réponse est en bas du formulaire de ce genre de pages :

The result can only be sent back to browser, not saved on the server, see details

En gros, je ne peux pas ouvrir un fichier XML résultant d’une requête SPARQL dans mon navigateur, et c’est fait exprès. Il y a certainement une explication logique, technique, sous-jacente à ça — mais ça ne m’arrange franchement pas.

Donc je ne peux pas avoir un fichier XML en entrée contenant par exemple une liste mots-clés Rameau, et pour chacun de ces mots-clés récupérer en sortie la liste des œuvres indexées par ces mots-clés dans data.bnf.fr : simplement parce que le fichier XSL ne peut pas ouvrir le résultat de chaque requête, tant que celui-ci n’est pas hébergé dans un fichier au moins temporaire.

Alors j’ai deux solutions :

  • soit (solution actuelle) je télécharge automatiquement l’ensemble des fichiers de résultats (merci DownThemAll) pour les exploiter ensuite en local
  • soit je prends le temps de comprendre la documentation vers laquelle me renvoie Virtuoso (qui gère la base de triplets RDF), pour connecter mon explorateur de fichiers Windows en WebDAV au serveur.

Enfin bon, je suis déjà content d’avoir compris d’où venait le problème.

N.B. : les résultats au format HTML s’affichent sans difficulté dans le navigateur, sans avoir besoin d’être téléchargées. Je suppose (mais il est possible que je me plante complètement, et j’attends avec impatience les explications d’une personne vraiment compétente) que c’est parce que les navigateurs sont conçus pour fonctionner avec un cache, où ce résultat HTML va spontanément se placer sur l’ordinateur pour pouvoir être affiché.

9 commentaires
  1. 23/01/2016 19:35

    En fait, tu poses deux questions dans ton billet : pourquoi Firefox n’affiche pas directement le résultat de la requête SPARQL et force le téléchargement ? Cela a-t-il des conséquences pour son exploitation ?

    Commençons par la 1ère question : une réponse d’une requête HTTP est composée d’une entête (head) et d’un corps (body) (à ne pas confondre avec le head et le body du flux HTML), le corps contient la réponse elle-même et l’entête contient des métadonnées sur ce flux de réponse. Parmi ces métadonnées, tu retrouves le mime type, c’est à dire le format de la réponse. C’est grâce à cette information que ton navigateur va savoir interpréter le flux de réponse : si c’est du HTML, il déclenche son parser HTML pour afficher la page Web et si c’est du XML, il t’affiche directement l’arborescence XML. Dans le cas d’une requête SPARQL, conformément à la recommandation du W3C (cf. https://www.w3.org/TR/rdf-sparql-XMLres/#mime ), le type mime est application/sparql-results+xml. Or, ce type mime est inconnu de ton navigateur, donc dans ce cas il télécharge le fichier automatiquement. Tu dois avoir un moyen d’indiquer à ton navigateur son comportement en fonction du type mime et de l’assimiler à celui du type mime XML (application/xml ou text/xml).

    Quant au problème que cela te pose, j’avoue que je ne comprends pas vraiment : quelle est la différence entre le fait qu’il te l’affiche directement dans le navigateur et le fait qu’il le télécharge ? Dans les deux cas, le fichier est sauvegardé sur ta machine. Toujours est-il que si tu appliques ta XSL à ton flux de réponses via un petit programme en PHP (puisque tu t’es mis au PHP😉 ) ou dans n’importe quelle autre langage de programmation, tu n’auras aucun problème. Si tu n’as pas envie de te prendre la tête à programmer, je t’invite à regarder tous les logiciels d’ETL ou de data pipeline qui te rappelleront Yahoo Pipes que tu aimais tant comme Talend Open Studio : http://www.talend.com/download/talend-open-studio#t4 ou Knime : https://www.knime.org/knime Très pratique une fois que tu les as pris en main. Il faudrait d’ailleurs que je fasse un billet à l’occasion sur le sujet.

    Voilà, j’espère que cette réponse est claire et te permettra de résoudre tes soucis🙂

  2. 23/01/2016 23:10

    Bonjour Étienne,
    je venais répondre un truc assez semblable mais Gautier l’a fait de manière bien plus précise, j’ajoute juste un lien qui complète ce qu’il dit pour FF et un bug qui avait été remonté pour du MathML : https://bugzilla.mozilla.org/show_bug.cgi?id=124709 . Je n’ai par contre pas trouvé de solution simple sur FF pour afficher le XML (et pas de compliqué non plus, mais je me suis arrêté de chercher à ce moment là)

  3. 24/01/2016 08:24

    Merci à tous les deux, mais le problème rencontré ne concerne pas que Firefox : quand je lance un script XSL avec Kernow, il n’arrive pas à ouvrir des résultats d’une requête Sparql avec la fonction document (), comme il le fait pour une requête sur une API (je vous donne un exemple dès demain).

  4. 24/01/2016 09:37

    Je pense que c’est pour la même raison : kernow (voire la fonction document() de XSL mais je n’ai pas trouvé de doc à ce sujet) vérifie le mime type du flux et attend application/xml ou text/xml et comme ce n’est pas ce qui est renvoyé par la requête HTTP, il ne parse pas le résultat. Essaye en scriptant ton appel avec un autre programme ou logiciel et tu n’auras aucun problème, je peux te l’assurer.

  5. 24/01/2016 17:07

    Étienne,
    pour compléter (et valider) l’hypothèse de Gautier, voici un petit script PHP qui récupère le XML de ton exemple et le renvoie selon deux mimetype différents :
    http://www.geobib.fr/tmp/proxy.php?mimetype=xml
    http://www.geobib.fr/tmp/proxy.php?mimetype=sparql
    Le premier envoie un header text/xml et s’affiche bien sur mon FF, le second utilise le header application/sparql-results+xml et en chargeant les deux on voit bien la différence de comportement du côté du navigateur. La seule différence est sur le content-type envoyé dans le header, voir le code ici : https://gist.github.com/symac/5e7a800fd9adec00fddc

  6. B. Majour permalink
    30/01/2016 17:59

    Mon constat, qui revient au même que Gautier ou Sylvain.

    – Quand j’ouvre la page « la liste des artistes nés il y a 69 ans) », le logiciel ouvre un fichier sans extension.

    – Quand on renomme ce fichier avec .xml, le navigateur l’ouvre comme du XML

    Est-ce pareil pour Kernow ?
    Tu as essayé de renommer d’abord les fichiers avec les bonnes extensions et de voir si la procédure fonctionne ?
    B. Majour

Trackbacks

  1. Sparql Endpoint : pourquoi j'ai du mal à...
  2. Sparql Endpoint : pourquoi j'ai du mal à...
  3. Sparql Endpoint : pourquoi j’ai du mal à exploiter des résultats d’une requête – Veille juridique

Les commentaires sont fermés.

%d blogueurs aiment cette page :