Skip to content

Intégrer un fonds dans un catalogue : utilisation systématique d’API (Sudoc, WorldCat, Aleph, Primo, et des ratons laveurs)

16/07/2012

Là, j’ai le choix entre un billet très technique, et quelque chose de plus simplement méthodologique.

Je vais commencer par la partie simple, et si vous voulez des détails, vous pourrez en demander par mail, en commentaire, par tweet, etc.

Donc sans me lancer dans une description technique exhaustive, j’aimerais vous permettre de voir dans quelle mesure les API peuvent grandement simplifier la vie. Ce billet est un prolongement de celui-ci.

Court rappel

Sur ce qu’est une API, je ne suis pas sûr de pouvoir faire mieux que ce billet. L’idée de base est :

  • habituellement, aller sur Internet, c’est ouvrir une page HTML avec un logiciel appelé navigateur.
    Le nom et le chemin de ce fichier HTML est son URL.
  • à côté, certaines interfaces permettent d’ouvrir des fichiers XML qui restituent les mêmes données, ou certaines données, que les pages HTML, mais dans un format structuré.
    Ainsi le fichier http://www.sudoc.fr/139555153.rdf est le pendant XML du fichier http://www.sudoc.fr/139555153 qui est une page HTML.
    [ce n’est pas tout à fait une API, mais c’est pas grave : c’est pour dire]

Situation

Nous avons un fonds de 15.000 ouvrages à récupérer et intégrer dans les collections. L’intégration se passe en plusieurs étapes. Ces collections, issues d’une bibliothèque de l’Université, ne sont pas décrites dans le Sudoc, mais dans un SIGB local, et de manière parfois assez brève.

  1. extraction des notices (biblio et exemplaires) dans un format XML à partir du SIGB initial
  2. désherbage, en fonction
    • de l’intérêt intellectuel de chaque document
    • de leur âge (date de publication)
    • de la présence éventuelle du document dans nos collections (doublons)
      si nous l’avons dans nos fonds, on peut d’emblée savoir si l’ouvrage déjà possédé a été emprunté récemment
    • de la présence éventuelle du document dans d’autres BU
  3. intégration des notices dans le SIGB local, en évitant les doublons avec les notices existantes
  4. envoi d’une liste à l’Abes pour exemplarisation automatique dans le Sudoc

Dans cette description assez classique, les API peuvent être extrêmement utiles aux étapes 2 et 3. En effet, si on réussit à exploiter un identifiant (ISBN, PPN, ou n° de notice WorldCat), des API nous permettent de récupérer par exemple :

  • l’indexation sujet du Sudoc ou le nom de la collection (permettant de déterminer plus facilement l’intérêt du document) : API Sudoc ou WorldCat, sur la base de l’ISBN
  • la présence éventuelle de l’ouvrage dans nos collections : API Sudoc (sur la base du PPN, récupéré à partir de l’ISBN)
  • le nombre de BU qui possèdent l’ouvrage : API Sudoc (sur la base du PPN)
  • la localisation éventuelle dans nos fonds : API Primo (sur la base du PPN)
  • la date du dernier prêt : API Aleph (sur la base du n° de notice bib, récupéré à partir du PPN)

Comparaison fichier initial fichier final

Voici un tableur Google :

  • Dans la première feuille, 10 notices, telles qu’extraites de la base : colonnes A-L
    (je n’ai pas mis tous les champs disponibles, qui n’avaient pas d’intérêt pour ce billet ni pour le traitement de la collection)
  • Dans la seconde feuille, ces mêmes 10 notices, enrichies (quand c’était possible) par les colonnes M et suivantes

Principe de base

  1. si on a un ISBN, on peut facilement récupérer le PPN (API isbn2ppn du Sudoc)
    A partir du PPN, on peut

    1. ouvrir la notice Sudoc en XML (l’URL de cette notice sera : http://www.sudoc.fr/ppn.rdf)
    2. récupérer l’indexation
    3. récupérer le nombre de bibliothèques qui possèdent le document
    4. savoir si nous possédons le document
  2. A défaut d’ISBN, on peut utiliser une API WorldCat : en générant une URL de requête avec Titre, auteur et date, on peut récupérer la liste des OCN (identifiant WorldCat)
  3. A partir de l’OCN, on peut
    1. ouvrir la notice WorldCat et récupérer l’indexation, ainsi que le nom de la collection
    2. récupérer le PPN (API Sudoc ocn2ppn)
    3. et à partir du PPN, refaire les choses décrites ci-dessus : le nombre de bibliothèques, etc.
  4. Dès qu’on a un PPN, on peut exploiter les API de notre opac, et savoir s’il y a un n° de notice correspondant
  5. A partir du n° de notice, on peut récupérer la localisation exacte (bibliothèque, fonds, cote) et la date du dernier prêt

Liste des étapes

J’ai récapitulé les étapes successives. Il est probable qu’il aurait pu y en avoir moins, mais

  1. ça aurait rendu les feuilles XSL encore plus compliquées
  2. je pouvais ainsi contrôler le résultat à chaque étape, et décompter ce que chaque enrichissement m’avait apporté.
Voici la liste des traitements successifs, pour lesquels j’ai utilisé Kernow. L’utilisation proprement dite des API commence à l’étape 5.
<update>Tous les fichiers XSL + un fichier de 2 notices-exemples sont sur Github</update>
  1. Fichier XML initial exporté du SIGB :  Ouvrages.xml
    14114 notices

    Pour certaines notices, il y avait une balise <Isbn>, mais le contenu n’en était pas toujours propre. J’ai donc commencé par extraire ces <Isbn> pour les retravailler dans un tableau Excel et les nettoyer, afin de pouvoir ajouter à chaque notice, en plus du champ <Ibns>, un champ <IsbnPropre>
  2. Ajout en fin de fichier de l’ensemble des ISBN propres et ISSN de collections + évacuation des notices sans titres ou dont la cote = 000000
    –> fichier 2-Ouvrages-isbnpropre.xml
  3. Fusion des ISBN propres et ISSN de collection au sein des notices
    1. entrée : 2-Ouvrages-isbnpropre.xml
    2. feuille XSL : 2-isbnpropres.xsl
    3. sortie : 3-Ouvrages-avec-isbn.xml
      On a à ce stade 4311 ISBN propres
  4. Nettoyage des PPN existants (champ RefImpt)
    Pour près de 2000 notices, un champ (à nettoyer) mentionnait déjà un PPN.

    1. entrée : 3-Ouvrages-avec-isbn.xml
    2. XSL : 3-ppn-propre.xsl
    3. sortie : 4-Ouvrages-ppn.xml
      On a à ce stade 1976 PPN
  5. Utilisation de l’API isbn2ppn pour récupérer le PPN des ISBN (dont les notices n’ont pas encore de PPN)
    1. entrée : 4-Ouvrages-ppn.xml
    2. XSL : 4-enrichissement-avec-api-Sudoc-isbn2ppn.xsl
    3. sortie : 5-ouvrages-ppn.xml
      On a à ce stade 7172 PPN avec

      • 5214 notices avec 1 PPN
      • env. 750 notices avec plusieurs PPN

      8130 notices sans PPN :

      • 146 notices avec ISBN
      • 7984 notices sans ISBN
  6. Utilisation de l’API OCLC pour enrichir les notices en OCN, soit sur critère ISBN, soit sur Titre-Auteur-Date
    1. entrée : 5-ouvrages-ppn.xml
    2. XSL : 5-ouvrages-api-ocn.xsl
    3. sortie : 6-ouvrages-ocn.xml
      On obtient à ce stade 6298 OCN (traitement uniquement sur les 8130 notices sans PPN)

      1. avec
        • 648 notices avec 1 OCN
        • env. 1000 notices avec plusieurs OCN
      2. 5961 notices sans OCN :
        • 88 notices avec ISBN
        • 5873 notices sans ISBN
  7. Pour les OCN trouvés, utilisation de l’API Sudoc ocn2ppn pour revenir si possible à des PPN
    1. entrée : 6-ouvrages-ocn.xml
    2. XSL : 5-ouvrages-api-ocn2ppn.xsl
    3. sortie : 7-ouvrages-ocn2ppn.xml
      Cela permet de récupérer 1833 PPN
      On obtient à ce stade

      1. Notices avec PPN
        • 6052 notices avec 1 PPN
        • env. 1000 notices avec plusieurs PPN
      2. Notices sans PPN avec OCN
        • 422 notices avec 1 OCN
        • env. 500 notices avec plusieurs OCN
      3. Notices sans identifiant
        • 88 notices avec ISBN
        • 5873 notices sans ISBN
  8. Pour les PPN trouvés, utilisation de l’API Primopour voir s’il y a une notice Aleph
    1. entrée : 7-ouvrages-ocn2ppn.xml
    2. XSL : 7-ouvrages-api-Primo-no.xsl
    3. sortie : 8-ouvrages-no-aleph.xml
Et la dernière étape : Enrichissement des notices : indexation Sujet, Collection, Localisation Aleph. Feuille de style exploitant les identifiants Aleph, PPN et OCN :

  • Si no Aleph : ajout de localisation, nb d’exemplaires, dates de dernier prêt
  • Si PPN : ajout du nb de bibliothèques détentrices, indexation sujet (si pas d’indexation locale)
  • Si OCN : ajout collection, indexation sujet (si pas de PPN)
    1. entrée : 8-ouvrages-no-aleph.xml
    2. XSL : 8-extract-infos-aleph-sudoc-worldcat.xsl
    3. sortie : 9-infos-aleph-sudoc-oclc.xml
Au final, sur le fonds en question, j’ai pu récupérer des PPN pour 50% des notices.

Si vous voulez des détails sur une ou plusieurs de ces étapes (obtenir la feuille XSL, en fait), il suffit de demander.

Je ne les ai pas directement mises en ligne, parce qu’il m’aurait fallu les commenter un peu. Et l’idée était surtout de convaincre qu’il faut impérativement réfléchir ce genre de traitement en tenant compte de l’existence d’API. Elles peuvent changer la vie🙂

Je ne l’ai pas précisé, mais évidemment, à partir du dernier fichier XML (9-infos-aleph-sudoc-oclc.xml), il y a une dernière transformation pour produire un tableau intégrant une mise en forme et des liens hypertextes.

Chargement des notices dans le SIGB avant l’exemplarisation dans le Sudoc

Toutes les étapes qui précèdent facilitent le désherbage : dans le tableur complet, les collègues peuvent indiquer si l’exemplaire sera conservé ou désherbé.

S’il est conservé, ils indiquent le PPN de la notice Sudoc (quand il n’a pas déjà été identifié, ou quand il faut sélectionner parmi plusieurs PPN « proposés »).

Ensuite on charge dans le SIGB les notices, avec Titre, Auteur, données d’exemplaire — et PPN.

Après, on extrait ces données du SIGB pour envoi à l’Abes : un tableau CSV avec

  • PPN
  • N° notice SIGB
  • RCR, Bibliothèque, localisation
  • CB, n° d’inventaire, cote
  • règles de prêt et de PB

Et ça roule.

6 commentaires
  1. mloiz permalink
    30/05/2013 23:23

    Bonjour et merci grandement pour la diffusion de votre travail.
    J’utilise les API du sudoc et je cherche maintenant à interroger automatiquement le sudoc avec le titre des livres uniquement. Est-ce possible ?
    merci,

  2. 03/06/2013 13:42

    @mloiz : non, pour l’instant, pas d’API Sudoc sur des mots clés, mais uniquement sur des identifiants (pour en obtenir diverses infos)
    C’est d’ailleurs une des raisons qui m’ont amené à utiliser les API WorldCat.

    Sinon, il vous reste la possibilité d’exploiter le chargement du dump Sudoc dans Sindice, si les notices qui s’y trouvent vous suffisent et si vous parlez SPARQL.

  3. mloiz permalink
    10/06/2013 15:06

    merci pour votre réponse,
    ne peut-on utiliser le Z3950 à ces fins ?
    http://www.abes.fr/Sudoc/Services-disponibles-autour-du-Sudoc/Profil-Z3950

  4. 11/06/2013 10:06

    Oui et non : en fait le z39.50 est une toute autre technologie que le web, donc pas de formats XML avec retraitements, etc.
    Mais c’est précisément à ça que sert SRU/SRW : faire du Z39.50 sur le web, avec des flux XML au lieu de requêtes et réponses en z39.50.
    Donc logiquement si on a accès à un serveur SRU/SRW et qu’on lui lance des requêtes, on obtient des résultats en XML, qu’on peut réexploiter comme s’il s’agissait de réponses par API. Mais je ne l’ai jamais fait pour ma part, et je n’ai jamais vu que le Sudoc disposait d’un serveur SRU/SRW

Trackbacks

  1. Intégrer un fonds dans un catalogue : utilisation systématique d’API (Sudoc, WorldCat, Aleph, Primo, et des ratons laveurs) | Ebooksinfo | Scoop.it
  2. Intégrer un fonds dans un catalogue : utilisation systématique d'API ... | Veille sur les SIGB nouvelle génération , SIGB Mutualisé | Scoop.it

Les commentaires sont fermés.

%d blogueurs aiment cette page :