Skip to content

Automatisation Colodus/JavaScript : extraction des infos du SIGB (Aleph)

24/09/2015

Tous les billets de la série « Automatisation Colodus avec JavaScript »

Le circuit organisationnel

Pendant la semaine, les acquéreurs voient passer les ouvrages qu’ils ont commandé, valident l’attribution de la cote et les mettent dans un statut (« statut de traitement ») particulier, qui signifie en gros : « prêt à être exemplarisé dans le Sudoc ».

Tous les lundis matins, un service Aleph tourne. Il tourne autant de fois qu’il y a de BU, pour générer un rapport distinct par RCR. Donc pour chaque RCR il identifie la liste des exemplaires « marqués » par les acquéreurs la semaine précédente.

La génération du rapport

Ce fichier de rapport est un fichier XML, qui s’affiche dans Aleph grâce à une feuille XSL. Sur la base des infos présentes dans ce fichier XML, la feuille XSL fait tout un tas d’opérations. En gros :

  1. elle récupère les infos d’exemplaires
  2. elle récupère les infos de la notice bib d’Aleph
  3. elle essaie d’identifier la notice Sudoc correspondante :
    1. la notice locale a déjà un PPN –> le script récupère ce PPN (et le met à jour au passage avec l’API merged qui indique si éventuellement ce PPN a été fusionné avec un autre)
    2. la notice locale n’a pas de PPN –> si elle a un ISBN, elle va interroger l’API isbn2ppn de l’Abes pour récupérer, si possible, le PPN de la notice correspondante.
      S’il y a plusieurs PPN en réponse, aucun exemplaire n’est créé mais le rapport final proposera la liste des PPN possibles

Voici un schéma de la manière dont le rapport est généré

 

Exemplarisation Colodus pour les acquisitions courantes (structure de la feuille XSL)

Remarque : le fichier XSL peut constater qu’aucune exemplarisation n’est nécessaire, si le RCR est déjà localisé sous cette notice.

Le contenu du rapport

  1. le code JavaScript à faire glisser en favori Firefox
  2. la liste des PPN qui sont l’objet d’une exemplarisation (pour faire facilement des contrôles aléatoires)
  3. la liste des notices Aleph pour lesquelles aucun PPN n’a été trouvé (ou plusieurs PPN ont été trouvés)
  4. la liste complète des exemplaires concernés par le traitement (qu’un PPN ait été trouvé ou non, qu’il faille exemplariser l’ouvrage ou non)
  5. Pour chaque notice, un ensemble de contrôles bibliographiques sont effectués, sur le modèle de ce qui a été décrit dans ce billet.
    Jusque-là, ces contrôles qualité se faisaient au chargement, lors de la redescente des notices dans la base locale. Ils se font désormais lors de l’exemplarisation.

isbn2ppn ???

Je sais déjà qu’il va y avoir plein de questions sur la fiabilité de cette API. Je vous invite à lister en commentaires les questions ou inquiétudes que ça peut générer, pour voir si j’arrive à y répondre ou non, et quels genres de contrôles sont possibles (soit déjà présents, soit à rajouter).

Je précise tout de même que nous avons déjà réalisé (avant l’apparition de Colodus) des milliers d’exemplarisations dans le Sudoc grâce à cette API, dans le cadre de chantiers de réinformatisation de bibliothèques associées (que nous avons fait monter dans le Sudoc), et ces bibliothèques ne se sont encore jamais plaintes, après plusieurs années de fonctionnement, que leurs notices ne correspondaient pas du tout à leurs ouvrages.

 

One Comment
  1. B. Majour permalink
    24/09/2015 09:46

    Intéressant tout ça.
    Vraiment intéressant.
    B. Majour

Les commentaires sont fermés.

%d blogueurs aiment cette page :