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

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.