Skip to content

Petite utilisation de l’API Sudoc isbn2ppn

11/06/2012

Il paraît que ce blog perd des places dans le feu classement Wikio (qui existe toujours, mais dont plus personne ne parle). C’est normal : il se passe plein de choses intéressantes en ce moment (le refoulement d’ACTA au Parlement européen, les confrontations étudiants-gouvernement au Québec, les premiers pas du premier gouvernement Ayrault notamment sur la LRU ou l’économie numérique, l’entrée en bourse de Facebook, la semaine de l’Open Data, etc. etc.)

J’espère que vous avez suivi tout ça !

Mais bon, comme je veux tout de même prouver que ce blog n’est pas mort (et moi non plus), je viens pondre un petit billet technique vite fait, sur une utilisation récente de l’API Sudoc isbn2ppn.

Je doute que ça serve à quelqu’un, mais je ne pouvais pas le « prouver » sans l’avoir expliqué au préalable. Donc je l’explique ici, et je conclurai par : vous voyez, ce n’était pas la peine d’en faire un billet

Situation de départ

Imaginez que vous êtes membre du réseau Sudoc, que vous y cataloguez et y récupérez vos notices, mais que de temps en temps vous êtes amené à charger des notices dans votre base locale (par exemple : plusieurs dizaines/centaines/milliers de ebooks).

Et paf ! Au lieu de générer de nouvelles notices, vous écrasez des notices existantes — qui n’ont rien à voir avec lesdits ebooks. Vous avez donc perdu quelques dizaines/centaines/milliers de notices bibliographiques.

Heureusement, l’outil qui produit les statistiques sur votre SIGB est un logiciel externe. Chaque nuit il duplique certaines données de la base bibliographique pour produire d’interminables tableaux de données et de jolis graphiques. Donc vous avez encore les données de la veille !

Bref, vous arrivez à récupérer, pour les notices perdues, un fichier avec les champs suivants :

  • Titre
  • Auteur
  • Editeur
  • ISBN
  • Date de publication
  • etc.

De quoi faire une petite notice — qui sera toujours plus correcte que celle du ebook auquel sont toujours rattachés 3 exemplaires localisés dans le fonds « Manuels – 1er étage » de votre BU…

Du tableau CSV ou Excel obtenu, vous vous apprêtez à faire un fichier Marc injectable dans votre SIGB.
(la partie « Conversion d’un tableau CSV en Marc XML ou iso2709 » est une autre histoire, que je vous raconterai à l’occasion si ça vous intéresse)

Mais si vous faites ça, ça va être difficile ensuite de refaire la jointure avec les notices Sudoc qui décrivent elles aussi vos mêmes exemplaires du fonds « Manuels – 1er étage ».

L’idée, simple, est de réinjecter les PPN dans le tableau avant l’import, afin de pouvoir ensuite aisément :

  1. donner  à l’Abes la liste des PPN à réextraire pour vous les envoyer
  2. les fusionner correctement avec votre base en écrasant vos notices à 4 champs
  3. avoir de nouveau de longues notices Sudoc, comme si rien ne s’était passé.

Quelques rappels sur ce qu’est une API (mais que cela ne vous empêche pas d’aller relire ce vieux billet)

Dans mes notices courtes telles que décrites ci-dessus, j’ai un champ « ISBN ».

Or il existe une API du Sudoc appelée isbn2ppn dont la fonction est la suivante : quand on lui donne un ISBN, l’API fournit un PPN (ou plusieurs, si plusieurs notices Sudoc ont ce même ISBN).

Cette API peut être décrite ainsi :

Cela signifie que quand je demande à mon navigateur d’ouvrir l’URL http://www.sudoc.fr/services/isbn2ppn/0195141156, il va m’ouvrir un fichier XML contenant le PPN correspondant à l’ISBN 0195141156.

Autre précision peut-être inutile sur les extensions de fichiers

Quand vous manipulez un fichier sur votre ordinateur, il a toujours une extension, généralement à 3 lettres : .pdf, .doc, .odt, .txt, .xml, .png, .etc etc.

(avec les dernières versions des systèmes d’exploitation Windows, la configuration par défaut est de masquer ces extensions)

Ces extensions sont utiles pour le fonctionnement de l’ordinateur : il peut générer une icône, déterminer quel logiciel utiliser pour l’ouvrir , indexer ou non le fichier, etc.

Mais si vous modifiez manuellement un fichier .doc pour mettre à la place « .pdf », ça ne vous empêche pas de l’ouvrir avec Word (et ce serait inutile d’essayer de l’ouvrir avec Acrobat Reader).

Donc quand vous demandez au navigateur d’ouvrir l’URL http://www.sudoc.fr/services/isbn2ppn/0195141156, vous lui demandez simplement d’afficher un fichier XML, qui n’a pas d’extension .xml — mais qui est tout de même un vrai fichier XML.

Et donc, ce fichier XML, je peux l’ouvrir avec un navigateur, mais je peux aussi l’ouvrir avec un éditeur XML. Par exemple XML Copy Editor (open source)

Et alors ?

Alors ensuite, il suffit d’avoir un fichier XML contenant la liste des ISBN. Par exemple sous la forme

Et de connaître le language XSL permettant de dire :

  • Pour chaque ISBN, voici le nom du fichier à ouvrir (en fait, l’URL du fichier XML en ligne)
  • Dans ce fichier, voilà où se trouve le PPN à récupérer
  •  produire en résultat
    {ISBN} (issu de la liste);{PPN} (issu du fichier) <saut de ligne>

La feuille XSL

Je peux difficilement réexpliquer tout XSL ici. Je vous renvoie à la série idoine, et je vais me contenter de mettre le code XSL permettant de décrire les opérations ci-dessus, en le commentant.

Version simple
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<xsl:output method="text" indent="no" omit-xml-declaration="yes"/>
<xsl:template match="/">
<xsl:for-each select="//item">
<xsl:variable name="url" select="concat('http://www.sudoc.fr/services/isbn2ppn/', isbn)"/>
<xsl:variable name="file">
<xsl:copy-of select="document($url)//sudoc"/>
</xsl:variable>
<xsl:value-of select="."/>
<xsl:value-of select="$file//ppn"/>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Cette feuille s’applique donc au fichier ci-dessus listant les ISBN, où les ISBN sont dans des balises <item>

Maintenant, avec les commentaires (entre <!– et –>)

<?xml version="1.0" encoding="UTF-8"?>
<!--La version de XSL utilisée est la version 2.0, qui permet d'autres fonctions, notamment document()-->
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="2.0">
<!--La précision du format avec xsl:output de sortie est en général inutile :
le plus souvent, on produit du HTML ou du XML. Là, je veux du CSV, c'est-à-dire un
fichier texte avec les séparateurs ";" Donc je le précise pour éviter notamment
l'indentation et l'ajout du de la "xml-declaration", c'est à dire de la ligne
<?xml version="1.0"?> qui sans cela serait ajoutée en tête du document
produit en résultat-->
<xsl:output method="text" indent="no" omit-xml-declaration="yes"/>
<xsl:template match="/">

<!--Pour chaque <item>, càd pour chaque ISBN, on va aller récupérer le fichier XML produit par l'API du Sudoc-->
<xsl:for-each select="//item">

<!--Définition d'une première variable : le nom du fichier XML et son chemin. Comme c'est un fichier en ligne, ça donne donc une URL. On concatène une chaîne de caractères (URL racine de l'API) et l'ISBN (càd la valeur du noeud en cours
Pour rappel : écrire "." là où est attendu l'indication d'un noeud XML est une manière raccourcie d'écrire : self()
Pour les expressions XPath qui permettent d'accéder aux noeuds, voir ici-->
<xsl:variable name="url" select="concat('http://www.sudoc.fr/services/isbn2ppn/', .)"/>

<!--Deuxième variable : le contenu du fichier. On ouvre l'URL et on récupère tout le contenu compris entre les balises <sudoc> et </sudoc> dans le fichier. On stocke ce contenu dans la variable $file-->
<xsl:variable name="file">
<xsl:copy-of select="document($url)//sudoc"/>
</xsl:variable>

<!--Là, on génère ce qui sera produit dans le fichier en sortie. D'abord le contenu du noeud en cours (donc le "for-each" de tout à l'heure, càd le contenu de la balise <item>, càd l'ISBN à traiter. Puis on ajoute un point-virgule-->
<xsl:value-of select="."/>;

<!-Ensuite on va chercher dans le contenu de la variable $file le contenu de la balise PPN. Le chemin plus précis serait : $file/sudoc/query/result/ppn, mais pourquoi s'embêter à tout détailler ainsi ?--->
<xsl:value-of select="$file//ppn"/>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Version plus complète

En réalité, il y a des cas où l’API Sudoc renvoie 2 résultats (ou plus), ou aucun résultat. Il faut donc en tenir compte dans la récupération des réponses. Voici la feuille de style réellement utilisée :
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="text" indent="no" omit-xml-declaration="yes"/>
<xsl:template match="/">
<xsl:for-each select="//item">
<xsl:variable name="url" select="concat('http://www.sudoc.fr/services/isbn2ppn/', isbn)"/>
<xsl:variable name="file">
<xsl:copy-of select="document($url)//sudoc"/>
</xsl:variable>
<xsl:value-of select="."/>
<xsl:choose>
<xsl:when test="count($file//ppn) = 1"><xsl:value-of select="$file//ppn"/></xsl:when>
<xsl:when test="count($file//ppn) = 0">pas de réponse</xsl:when>
<xsl:otherwise>
<xsl:value-of select="count($file//ppn)"/> réponses
</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Avant de mettre la valeur du PPN, on compte combien de balises PPN se trouve dans le fichier XML correspondant à l’URL produite.

S’il y a un seul PPN, on le met dans le fichier résultat. S’il y en a 0 (test="count($file//ppn) = 0"), on indique « Pas de réponse ». S’il y en a plusieurs (tous les autres cas), on indique le nombre de réponses, suivi du mot « réponses ».

Outils pour mise en pratique

Pour éditer la feuille XSL, vous pouvez utiliser un éditeur XML comme XML Copy Editor.

En revanche il sera incapable d’appliquer la transformation, car il est limité au XSL-1. Donc vous pourrez utiliser Kernow pour cela.

Quelles applications possibles ?

On n’est pas là dans une utilisation  en ligne d’une API (qui permettrait par exemple d’enrichir un opac). Et je veux espérer que la suppression par erreur de milliers de notices ne vous arrivera pas.

Comme je le disais, c’était donc un billet inutile. CQFD.

Toutefois il m’est déjà arrivé plusieurs fois d’utiliser l’API isbn2ppn dans un autre type de contexte : quand il a fallu intégrer dans les collections des BU des fonds signalés hors SIGB, à savoir soit dans un autre SIGB ou une base de données, soit dans un fichier Excel.

Dans ces cas-là, avant d’ajouter les notices dans notre catalogue pour ensuite demander au Sudoc une exemplarisation automatique, j’ai ajouté au passage les PPN, sur la base des ISBN trouvé dans mon fichier initial. Ainsi les PPN se retrouvaient dans notre SIGB, et nous pouvions demander une exemplarisation plus « sûre » et plus rapide.

13 commentaires
  1. Marie_Idille permalink
    11/06/2012 10:51

    Merci pour ce billet! ^_^
    Voui, alors quand même, c’est pas que ça servait à rien, mais c’est dommage que tu aies pris comme exemple le scénario très improbable de l’écrasement de milliers de notices dans le SIGB par des notices ebooks (je ne vois pas bien comment ni pourquoi ça arriverait) et l’exemple justement peu concluant des lots de notices ebooks, ceux chargés par les éditeurs étant actuellement de très mauvaise qualité et ayant souvent pour défaut, notamment, de mentionner l’ISBN de l’imprimé au lieu d’un nouvel ISBN d’ebooks, ce qui augmente considérablement les risques de double réponse à la recherche par ISBN.
    Bref, le premier paragraphe laissait entendre assez clairement qu’il y avait plus important dans la vie que isbn2ppn et, déterminé à prouver que le billet était superflu, on pourrait croire que tu as tout mis en oeuvre pour le plomber.
    Le cas réel que tu évoques à la fin, celui d’intégration de bibliothèques et de leurs catalogues sur fichiers ou bases de données diverses, là c’est intéressant, parce que ça on le fait assez régulièrement, et un outil qui peut permettre de simplifier la récupération des PPN, c’est bon à prendre! Il faudra que j’en parle avec notre coordinatrice pour voir comment elle procède de son côté!
    Je te remercie donc à nouveau d’avoir surmonté tes réticences et d’avoir accepté de partager ton expérience avec cette API, et je me garde le billet sous le coude!🙂

  2. 11/06/2012 12:07

    @Marie_Idille : eh ! ce n’est pas ma faute si j’ai eu besoin de cette API pour cette opération précise !
    Je suis bien brave d’avoir envisagé d’autres situations🙂

    En cas de question sur des cas pratiques, n’hésite pas à garder aussi mon mail sous le coude.

  3. Stéphanie permalink
    11/06/2012 13:02

    « c’est dommage que tu aies pris comme exemple le scénario très improbable de l’écrasement de milliers de notices dans le SIGB par des notices ebooks (je ne vois pas bien comment ni pourquoi ça arriverait)  »
    moi je vois très bien comment et pourquoi ça arriverait. Encore merci Lully😉

  4. Marie_Idille permalink
    11/06/2012 14:12

    Mais c’est basé sur une histoire vraie alors!?! ^_^ Et, pour éviter la même mésaventure, il serait possible de savoir comment c’est arrivé?
    Pardon pour ce premier commentaire un peu rude alors que tu as gentiment et sur demande rédigé un billet clair et instructif qui propose différents usages pour cette API. Je ne voyais pas concrètement comment l’utiliser et dans quels cas ce pouvait être un gain de temps, j’y vois plus clair.
    Me reste à acquérir de bonnes bases en programmation pour bien saisir tous les aspects techniques!🙂

  5. 11/06/2012 14:17

    @Marie_Idille : Une histoire vraie, oui. Tu veux le générique de fin avec les noms des acteurs ?😉
    « Pour éviter la même mésaventure » : c’est juste lié à une étape oubliée dans la procédure d’import de notices dans Aleph, sans demande de rejet en cas de doublons.

  6. 11/06/2012 19:37

    Oui, ça arrive IRL… Merci Lully

  7. 11/06/2012 19:40

    Vous avez importé des notices d’ebooks, qui ont écrasé les notices des livres papier correspondant? parce que le SIGB a reconnu des ISBN et a considéré qu’il s’agissait de doublons ?

  8. Stéphanie permalink
    11/06/2012 19:48

    non je ne crois pas, juste une étourderie (c’étaitpour MAJ de notices, mais étape du matching sur identifiant de la notice existante oubliée > écrasement des premiers milliers de notices). Bref. Rien de bien grave au final.

  9. 11/06/2012 20:00

    @27point7 : En fait, le fichier initial des ebooks avait une numérotation automatique de notices à charger, incrémentée de 1 à XXXX.
    Et ces notices ont donc écrasé les notices de la base numérotées 1 à XXXX, indépendamment de leur contenu.

  10. Carlos permalink
    22/12/2012 18:56

    Merci pour cet article, toujours aussi intéressant.
    L’autre histoire : « Conversion d’un tableau CSV en Marc XML ou iso2709″ m’intéresserai bien….

  11. 23/12/2012 14:30

    @Carlos : OK, je me note ça pour la rentrée. Si fin janvier vous n’avez toujours rien vu venir, n’hésitez pas à me relancer

Trackbacks

  1. Intégrer un fonds dans un catalogue : utilisation systématique d’API (Sudoc, WorldCat, Aleph, Primo, et des ratons laveurs) « Bibliothèques [reloaded]
  2. Petite utilisation de l'API Sudoc isbn2ppn « Bibliothèques [reloaded] | Veille sur les SIGB nouvelle génération , SIGB Mutualisé | Scoop.it

Les commentaires sont fermés.

%d blogueurs aiment cette page :