Aller au contenu principal

Utilitaire : détecter les doublons dans plusieurs fichiers

05/11/2018
Une des raisons qui expliquent que je blogue moins depuis mon arrivée à Paris (outre des raisons personnelles, comme d’avoir 3 enfants à la maison), est que la BnF dispose de canaux officiels de communication à destination des professionnels.
Lorsque je travaillais au SCD de Nice, et que je bricolais des trucs sur Zotero, XSL, JavaScript ou Yahoo Pipes, je n’avais pas d’espace institutionnel à disposition. Ce blog était donc le bon canal pour partager les trucs qui me semblaient intéressants.
Mais ce que je fais à la BnF et qui soit susceptible d’intéresser des collègues, peut déjà être diffusé, notamment via le site transition-bibliographique.fr, l’espace Github de Bibliostratus, ou les journées professionnelles. Je n’ai donc pas forcément besoin d’un espace supplémentaire pour vous raconter ma vie (professionnelle).
Encore que je vous promets prochainement un billet pour avoir une vue d’ensemble sur la FRBRisation du catalogue et la correction en masse des données (avec du Bibliostratus dedans, d’ailleurs, et d’autres trucs aussi).
Il y a 2 ans, j’indiquais comment installer Python sur un PC, avec l’idée de vous partager divers scripts pratiques. J’avais oublié alors le temps écoulé entre le moment où j’avais commencé à apprendre XSL, et celui où j’en ai fait des billets.
Bon, ça fait deux ans que je monte en compétences sur Python (dont une année de Bibliostratus), sans proposer des trucs sur ce blog pour faciliter la vie.
Donc voilà dedupe-multifiles, un petit utilitaire développé hors de mon temps de travail, et qui peut vous intéresser à l’occasion.
Imaginons le cas suivant (c’est un exemple) : dans un contexte intercommunal, vous projetez de fusionner 10 SIGB en une seule base. (Je passe sur le fait que, par ailleurs, Bibliostratus vous permettrait, en identifiant les ARK de chaque notice de chaque base, d’identifier les doublons bibliographiques.) Vous soupçonnez que certains codes-barres peuvent dans plusieurs SIGB. Il vous faut donc comparer chacun des CB à chaque CB de chacune des autres bases.
Vous voyez le problème…
Donc ce petit programme Python propose de le faire pour vous.
Je n’ai pas développé d’interface un peu plus jolie (un formulaire avec des boutons, etc.) : ça se passe dans un terminal en noir et blanc, mais il y a peu d’infos à mettre.
Préalable : vous devez avoir installé Python 3.7, la librairie openpyxl, et déposé ce fichier dedupe-multifiles.py dans un répertoire en local.
En entrée, vous devez disposer d’un lot de fichiers Excel, ou un lot de fichiers CSV (évitez de mélanger les formats, quand même). Dans chacun, la colonne « Code-barre » (ou tout autre identifiant dont il faut vérifier s’il est dans plusieurs fichiers) doit être au même endroit (par exemple : en 3e colonne)
Le programme vous demande :
  1. la liste des fichiers (le plus simple est de les mettre tous dans le même répertoire que le script, pour éviter d’avoir à gérer le chemin absolu ou relatif dans les répertoires, mais ce n’est pas une obligation)
  2. la colonne où se trouvent les identifiants à comparer (elle peut être désignée par son numéro de colonne, ou par son en-tête)
 2 options supplémentaires sont également proposées
  1. Si vous souhaitez ignorer certaines lignes, par exemple tous les exemplaires en statut « Pilonné » qui ne seront pas migrés
    (en précisant la colonne « Statut de l’exemplaire » où chercher la valeur « Pilonné »)
  2. Si vous souhaitez récupérer toutes les métadonnées associées aux identifiants doublons, et pas seulement les identifiants eux-mêmes (donc récupérer en sortie la ligne complète de ces identifiants)
Imaginons maintenant qu’on dispose des fichiers suivants :
3 fichiers, avec des codes-barres en commun en 3e colonne
Voici comment exécuter le script et renseigner les paramètres
Et donc, le script produit :
  • un état d’avancement et une analyse finale directement dans le terminal
  • un fichier en sortie contenant la liste des doublons

Et le fichier rapport.xslx (si on a choisi de conserver toutes les métadonnées)

(l’identifiant sur fond bleu, présent dans 2 fichiers, n’est pas sorti comme doublon car dans un des fichiers, l’exemplaire était marqué comme Pilonné)
Je vous laisse envisager les cas d’utilisations pertinentes d’un tel script.
Je ne sais plus quelle bibliothèque envisageait d’utiliser Bibliostratus pour aligner plusieurs catalogues (en vue d’une fusion) et utiliser les ARK BnF (ou les PPN) comme identifiant commun pour trouver les doublons.

Des milliers de ebooks (et de liens !) dans le catalogue de la BnF

09/07/2018

Posons le contexte

Depuis 2011, la BnF acquiert des ebooks. Parfois à l’unité, parfois en bouquets. L’ensemble, cumulé sur plusieurs années, avait fini par représenter 100.000 documents. Et pendant que les acquéreurs achetaient, les normalisateurs définissaient le format des notices cibles à obtenir.

A la fin, tout est prêt – il n’y a plus qu’à les mettre dans le catalogue. La BnF dispose évidemment d’un accès à l’API Worldcat et peut donc dériver en masse les notices.

Mais une simple dérivation signifiait qu’on allait générer 100.000 notices bibliographiques pas vraiment intégrées au catalogue :

  • Soit en ne générant aucun lien vers aucune notice d’autorité (les notices d’auteur, mais aussi l’indexation sujet)
    c’est à ça que ressemble les notices récupérées des éditeurs : description riche, mais aucun lien aux autorités
  • Soit en générant des notices d’auteur à la volée (récupération du nom + prénom et faire une fiche d’auteur minimaliste), alors qu’une partie d’entre eux existait déjà dans le catalogue

L’objectif d’un chantier qui a duré toute l’année 2017, a donc consisté à voir comment récupérer, pour chacun de ces ouvrages, le maximum d’informations :

  1. Sur ses auteurs
  2. Sur ses sujets

Et cela a donné le processus ci-dessous :

Le point d’entrée, c’est une liste d’ISBN fournie par chacune des plateformes (Wiley, ScienceDirect, Springerlink, etc.)

A la suite de ça : pour chaque ISBN

  • Récupération de la notice complète Worldcat en Marc21
  • Dans cette notice, on récupère la combinaison Titre + Auteur(s)
    • On cherche dans le catalogue BnF si cette combinaison Titre-Auteur renvoie un résultat
    • Si c’est le cas, on récupère les identifiants BnF
      • De chaque auteur
      • De l’indexation Rameau
      • De l’indexation Dewey
    • Dans tous les cas, on interroge le Sudoc (api isbn2ppn).
      Si la notice existe :

      • Si elle a des liens à des notices d’auteur IdRef, on les récupère
        • pour voir si la notice IdRef contient un équivalent BnF
      • Si elle a une indexation Rameau / Dewey, on les prend
        • Et on récupère dans les notices IdRef les identifiants BnF de ces concepts Rameau / Dewey
      • Au passage : si un catalogueur du réseau Sudoc a déclaré un homothétique papier (version imprimée équivalente à la version électronique) : on récupère l’ISBN, et on regarde s’il existe dans le catalogue BnF
    • L’indexation Rameau fait l’objet d’un traitement particulier :
      Les notices WorldCat fournissent uniquement une indexation LCSH
      Or 105.000 notices Rameau contiennent des équivalents LCSH
      Donc il est possible de convertir l’indexation LCSH en indexation Rameau :

      • A condition de respecter les règles d’utilisation Rameau (ne pas mettre en tête de vedette un concept utilisable seulement en subdivision, par exemple)
      • A condition que le concept LCSH ne soit pas déclaré équivalent à deux concepts Rameau (dans ce cas, quel concept Rameau choisir ?)
        Pour faire ça, je suis passé par un fichier XML intermédiaire, en local (pour éviter, à chaque libellé LCSH, d’interroger le catalogue de la BnF), qui contenait l’ensemble des alignements LCSH-Rameau et les règles d’utilisation des concepts Rameau

A la fin, on a agrégé un certain nombre d’informations :

  • La description textuelle du document (Titre, mention de responsabilité, date, éditeur, nombre de pages, etc.) : de WorldCat uniquement
  • Les liens aux notices d’auteurs :
    • Si l’imprimé existe à la BnF, du catalogue BnF
    • Si la version électronique a été cataloguée manuellement dans le Sudoc, du Sudoc
  • L’indexation Sujet :
    • du catalogue BnF, si on a la version imprimée
    • du catalogue Sudoc, si la notice du ebook a fait l’objet d’une indexation Rameau manuelle
    • de la conversion LCSH à Rameau
  • La déclaration d’homothétique papier : venant du Sudoc uniquement

 

On peut ensuite reconstruire la notice cible, avec un ordre de préférence : par exemple pour l’indexation Sujet, on préfèrera l’indexation BnF, puis l’indexation Sudoc, puis la conversion LCSH-Rameau.

Le cœur de ce dispositif, ce sont les alignements :

  • Alignements entre notices bibliographiques, qui permettent de reporter d’une notice à l’autre certaines informations
  • Alignements entre référentiels (LCSH-Rameau), qui permettent de convertir dans un vocabulaire ce qui a déjà été exprimé dans un autre.

Résultat quantitatif

Sur les 95.000 notices de ebooks rattachées à des bouquets, voici les liens générés

Nombre de notices avec au moins 1 lien $3 en zone 606 Indexation Rameau 77322 81,39%
Nombre de notices avec au moins 1 lien $3 en zone 676 Indexation Dewey 26239 27,62%
Nombre de notices avec au moins 1 lien $3 en zone 700 Liens auteurs 10234 10,77%
Nombre de notices avec au moins 1 lien $3 en zone 432 Homothétiques imprimés 1614 1,70%
Nombre de notices avec au moins 1 lien $3 en zone 710 Liens auteurs Organisations 956 1,01%
Nombre de notices avec au moins 1 lien $3 en zone 607 Indexation géographique 526 0,55%
Nombre de notices avec au moins 1 lien $3 en zone 600 Indexation personne 330 0,35%

Pour l’indexation Sujet, c’est plutôt très satisfaisant. L’essentiel vient des équivalences LCSH-Rameau alimentées par le Centre Rameau : cela se voit au fait que les liens vers les auteurs (zones 700) sont beaucoup moins importants ; on n’a de version imprimée que dans 10% des cas.

Evidemment, toutes ces notices sont récupérables.

Questionnement final

Chaque notice obtenue est donc le résultat de l’agrégation de plusieurs sources.

Il est possible de revenir au fichier intermédiaire (un énorme fichier XML) qui permet de voir, pour chaque ISBN, ce qui a pu être rapatrié de la BnF, du Sudoc et de WorldCat. Mais c’est complètement invisible dans la notice Marc finale. Par par manque de bonne volonté : mais parce que le format Marc prévoit de donner la source d’une notice (l’ARK BnF, le numéro WorldCat) – mais pas de sourcer un élément d’information au sein d’une notice.

Il sera très tentant de recommencer l’expérience sur des documents non encore indexés à la BnF, mais indexés ailleurs.

Les champs d’applications me réjouissent d’avance

Ci-dessus, une utilisation d’un web service Worldcat qui rend compte de l’indexation de chaque ouvrage, au sein de laquelle on peut identifier ce qui relève d’une mention « genre de l’œuvre »

Bibliostratus & le baromètre de la lecture publique : avoir des métadonnées homogènes

25/04/2018

Comme annoncé, je commence mes retours d’expérience sur l’utilisation de Bibliostratus, en commençant par le plus ancien (automne-hiver).

Mes utilisations constituent à chaque fois un détournement de l’intention première du logiciel, puisque en bonne logique je n’ai pas vraiment besoin d’aligner « mes » données (de la BnF) avec les données de la BnF — quoique… (mais ce sera pour une autre fois.)

Le baromètre des prêts de la lecture publique

Depuis 2014, le Ministère de la Culture missionne un prestataire (en l’occurrence TMO Régions) pour dresser un panel des « meilleurs prêts » (c’est-à-dire des ouvrages les plus empruntés) dans les bibliothèques de lecture publique.

Le Ministère et le prestataires ont identifié un fournisseur de SIGB qui couvrait une assez grande diversité d’établissement, et qui s’occupe de l’extraction des bases de données : liste des prêts de l’année et métadonnées bibliographiques associées.

Les premières années, les analyses ont porté  sur quelques dizaines de bibliothèques, clientes de C3RB et utilisatrices de son logiciel Orphée. Plus récemment, l’étude s’est élargie à 146 (2016) puis 167 bibliothèques (2017), en incluant aussi des extractions venant d’instances Koha et Infor.

L’analyse 2016 a été mis en ligne fin avril 2017, je suppose que 2017 ne tardera plus.

<mise à jour du 27/04/2018>C’est en ligne — et un article de LivreHebdo s’en fait l’écho</mise à jour>

Problème 1 : le modèle de données

Le problème pour ce genre d’analyse, c’est (pour l’instant !) le modèle de données utilisé dans les catalogues de bibliothèques : une notice par ISBN, c’est à dire une notice par produit éditorial. Vous n’avez pas la possibilité de regrouper facilement plusieurs ISBN qui sont des rééditions d’une même oeuvre (dans différentes langues ou à travers le temps, chez différents éditeurs, etc.).

Dans l’idéal, il aurait fallu pouvoir disposer d’un catalogue FRBR dans lequel retrouver tous les ISBN extraits des 167 catalogues.

Mais bon, puisqu’on en n’est pas là, il faut le faire spécifiquement pour l’occasion : pour identifier les oeuvres (et non les livres) les plus empruntées au niveau national, il faut donc réaliser des regroupements par auteur identique & titre identique.

Oui mais…

Problème 2 : qualité des données

Si vous prenez 167 catalogues de bibliothèques différents, vous aurez des métadonnées très différentes — toutes de qualité, très certainement, mais toutes ayant fait des choix ou choisi des sources diverses : Electre, Moccam, BnF, catalogage local, Worldcat, dérivation + reprise, dérivation sans reprise, …

Donc les titres ne se ressemblent pas toujours :

  • Thorgal. Les mondes de Thorgal. Kriss de Valnor, 1
  • Kriss de Valnor, tome 1
  • Kriss de Valnor, Je n’oublie rien (1). Les mondes de Thorgal
  • Les mondes de Thorgal. Je n’oublie rien.
  • etc

Sans compter les problèmes d’accents, de majuscules, d’abréviations, d’initiales, etc.

TMO Régions a donc contacté le Département des métadonnées de la BnF pour voir s’il était possible d’avoir des métadonnées homogènes pour chacun des ISBN associé à au moins un prêt dans une bibliothèque.

La BnF, des métadonnées homogènes ?

Disons que le catalogue BnF a une histoire complexe, qui compose un joli patchwork ressemblant parfois à un lent processus de balkanisation.

Mais :

  • les prêts 2017 dans les bibliothèques publiques portent pour l’essentiel sur des ouvrages de moins de 20 ans, donc les règles de catalogage, même si elles évoluent un peu chaque année, ont généré sur cette période un ensemble plutôt cohérent
  • la base d’autorités est unique : donc au moins les noms d’auteur sont orthographiés de la même manière sur l’ensemble des notices bibliographiques

Méthodologie et remarques

Je ne vais pas vous décrire ici l’ensemble de la procédure suivie. J’en dégagerai quelques traits intéressants, et pour le détail je vous renvoie à ce document (PDF – 6 p.).

  • Le corpus comptait 150.000 ISBN (120.000 pour des prêts antérieurs à 2017, et 30.000 d’ISBN nouvellement apparus dans les prêts 2017).
  • Dans 94% des cas, un ARK BnF, ou à défaut un PPN (Sudoc) a pu être trouvé.
    Dans 3% des cas, plusieurs identifiants ont été trouvés.
  • la demande ne consistait finalement pas à faire un alignement propre : il fallait fournir des métadonnées fiables et homogènes pour chaque notice, si bien qu’il n’était pas indispensable d’identifier l’édition exacte correspondant au prêt initial avec certitude. Si la recherche par ISBN ne fonctionnait, une recherche simple « Titre+Auteur » suffisait au besoin.
  • il a fallu définir une stratégie, une méthode, pour obtenir le taux d’alignement le plus haut avec le moins de faux positifs possible. L’outil traite les données qu’on lui donne. Mais il réagit différemment si on lui donne beaucoup ou peu d’informations.
    Donc il faut vraiment prendre conscience de ce qu’il fait concrètement, même s’il le fait automatiquement. Pour l’essentiel, c’est décrit dans ce document (Word – 10 p.)
    (il est toujours possible d’être plus précis, mais que c’est long !).
  • Une utilisation par cycles (ou on refait passer plusieurs fois les « restes » du passage précédent) s’est révélée très intéressante

Conclusion

Ce fut une expérience très intéressante, pour tester la montée en charge du logiciel sur plusieurs dizaines de milliers de notices.

Concernant le taux de recouvrement avec le catalogue BnF + Sudoc, je ne sais pas s’il vous semble élevé ou frustrant (surtout que le recours au Sudoc n’est pas du tout marginal !). Il y a plusieurs explications (que je détaillerai une autre fois si ça vous intéresse) concernant l’absence d’ISBN d’ouvrages relevant manifestement du Dépôt légal (édités en France ou diffusés en France). Sachez qu’on y travaille — mais que trouver une solution satisfaisante pour tous types de cas de figure n’est pas simple !

Néanmoins, 97% de taux d’alignement en cumulant BnF et Sudoc, sachant que les deux sont engagés dans la Transition bibliographique et travaillent de concert, c’est très rassurant :

Cela signifie que quand une bibliothèque voudra aligner son catalogue avec la BnF, elle trouvera forcément des taux inférieurs.
Mais les documents réellement empruntés dans ces bibliothèques sont bel et bien référencés soit dans le catalogue BnF soit dans le Sudoc. Donc la FRBRisation couvrira bien la partie la plus vivante des collections.

Or c’est sur ces collections que les lecteurs feront des recherches dans les catalogues. La FRBRisation par les agences couvrira donc les fonds qui les intéressent. Et après tout, c’est pour eux qu’on fait tout ça ! #nelesoublionspas

La Transition bibliographique : Bibliostratus, un logiciel pour avancer ensemble

20/04/2018

Présentation

Le groupe Systèmes & Données du programme Transition bibliographique propose désormais aux bibliothèques un nouvel outil pour entrer de plein pied dans la Transition bibliographique : Bibliostratus (pour une Stratégie d’alignement des URIs).

Bibliostratus : menu d’accueil

Parce que c’est bien beau de suivre des formations, de faire de la veille sur le sujet, etc. Concrètement, on fait quoi ?

Alors justement, comme cela a été évoqué lors de la dernière journée Systèmes & Données, la démarche proposée est la suivante :

  • Les agences bibliographiques, l’Abes et la BnF, font du calcul de masse pour construire du LRM dans leurs catalogues (plus d’explications ici)
  • Les autres bibliothèques sont invitées à profiter de ces calculs

Le problème, si vous êtes une de ces « autres bibliothèques », c’est que vous ne savez pas forcément quelle notice de votre catalogue correspond à quelle notice BnF (pour l’Abes, cette question-là est plus facile : les SCD cataloguent dans le Sudoc donc leurs notices contiennent des PPN Sudoc).

Donc quand la BnF aura fini (si c’est jamais « fini »…) de LRMiser son catalogue : quand pour chaque « notice bibliographique » BnF, devenue entre temps manifestation, aura été associée une expression et une oeuvre (ou plusieurs) — comment saurez-vous ce qu’il faut récupérer ?

Pour le savoir, il vous faut aligner vos données avec celles de la BnF, c’est-à-dire réaliser cette identification, cette correspondance, entre vos notices et celles de la BnF. Rappel : si vous avez des FRBNF, ils ne sont pas assez fiables !

Donc plutôt que d’attendre la fin de la LRMisation du catalogue BnF, ce travail d’alignement peut être commencé dès aujourd’hui, pour injecter dans vos catalogues, soit les notices BnF complètes (en écrasant les vôtres), soit juste les ARK dans la zone adaptée.

Un chantier de ce genre a été présenté le 14 novembre, à travers l’exemple de la BM de Montpellier, la BnF et la BM de Montpellier ont collaboré pour définir une méthode et des outils pour réaliser cette opération d’alignement.

Copie d'écran : alignements en cours N° notice - ARK BnF

Copie d’écran : alignements en cours N° notice – ARK BnF

Et c’est aujourd’hui et dans les jours à venir que ces outils et cette méthode vont être proposés, à travers :

Doivent être publiées aussi prochainement des vidéos pour faciliter la prise en main.

Limites

Le logiciel n’est pas encore complètement débuggué. Il a tendance à croire que les données qu’on lui donne sont propres et fiables. Plus exactement : il les contrôle, mais tous les cas de figure aberrants n’ont pas encore été identifiés, de même que si l’utilisateur y met met n’importe quoi par manque de vigilance, Bibliostratus peut planter…

C’est pour ça qu’il y a un forum, notamment :

  • pour vous aider à comprendre les erreurs à ne pas commettre
  • pour nous aider à améliorer le logiciel

Questions de méthodes

Par ailleurs, Bibliostratus se contente de réaliser en algorithme des règles métier : il compare des métadonnées entre elles, celles qu’on lui donne (de votre catalogue) et celles qu’il trouve (de la BnF). Si ces métadonnées sont lacunaires ou fautives (d’un côté ou de l’autre), les alignements proposés sont peu fiables.

De même, si vous proposez une liste d’ISBN, c’est plus fiable qu’une liste de Titre-Auteur-Date. S’il y a tout ça, c’est mieux : le logiciel fera une recherche sur ISBN, et contrôlera ensuite que le titre et la date sont identiques. Donc selon la manière dont chaque alignement est obtenu (et le logiciel précise de quelle manière il est obtenu), les propositions seront plus ou moins fiables.

Il faut donc le considérer comme un facilitateur conçu pour gagner du temps, pas comme un outil magique 🙂

Et pour la suite ?

Outre les types d’informations que j’ai mentionnées plus haut et que vous trouverez soit sur Github soit sur le site Transition-bibliogaphique.fr, j’aurai l’occasion de revenir sur Bibliostratus ici-même pour vous raconter aussi comment moi-même j’en ai l’utilité — car si je n’ai a priori pas besoin d’aligner les données BnF avec les données BnF, pourtant je rencontre des situations où Bibliostratus peut se révéler très utile.

Et je me dis que ça pourra l’être aussi pour vous.

Donc on s’en reparle bientôt.

Pour les remarques, commentaires, problèmes, n’hésitez pas : c’est par là !

20-21 mars 2018 : Deux journées professionnelles sur les métadonnées

04/04/2018

Fin mars se sont tenues à la BnF deux journées professionnelles, dont les vidéos seront bientôt en ligne :

  • Le 20 mars : une journée sur la diffusion des données BnF, sous le titre « Quelles contributions de la BnF à la circulation des données ? »
  • Le 21 mars : un sommet ARK international

Photo @iladpo – Twitter

Je ne vais pas vous en faire un résumé (d’autant que j’ai malheureusement raté une partie de la seconde), mais dégager quelques points saillants.

Commençon par souligner que manifestement chacune répondait à une attente forte, pour différentes raisons.

Première présentation officielle du SRU BnF

Depuis son lancement à l’automne dernier, c’est la première présentation en auditorium du SRU de la BnF (c’est-quoi-un-sru). Il est encore tout jeune, et je pense qu’il va mettre du temps à trouver son public.

Les bibliothèques qui récupèrent les données de la BnF via le serveur Z39.50 disposent là d’un outil qui fonctionne et répond à leurs besoins actuels. Lui substituer le SRU pour faire la même chose revient pour l’instant à juste dépenser de l’argent (développements et implémentation prestataire) et du temps pour un service équivalent, alors que le Z39.50 ne s’arrêtera pas tout de suite. Donc il faut retenir plusieurs choses :

  • de nouveaux services peuvent être envisagés, et conçus bien plus facilement en se greffant sur un SRU qui utilise les technologies du web (HTTP, XML) qu’en allant chercher le Z39.50 (techno ancienne, inutilisée hors des bibliothèques).
    Il faut donc espérer que se constitue peu à peu un ensemble de retours d’expériences, et de partage de logiciels ou bibliothèques de fonctions, autour de cette base de données désormais accessible.
    A noter que ces services / outils peuvent être de type

    • synchrone : affichage en temps réel dans une interface web d’informations récupérées dynamiquement du SRU
    • asynchrone : fonction d’export et de récupération pour alimenter un fichier, une page web, une base de données
  • notamment, il y a des services/outils/plateformes à envisager qui combinent diverses sources, dont le SRU — mais aussi data.bnf.fr, Gallica, et des trucs hors BnF : ISTEX, un SRU Sudoc, etc.
  • Les bibliothèques doivent peu à peu (au gré des marchés de réinformatisation) demander un module d’import SRU plutôt que Z39.50 pour récupérer les notices BnF :
    • les critères de recherche sont plus nombreux, notamment sur les autorités
    • les limitations techniques (nombre de notices récupérables) sautent
    • le SRU n’est pas dépendant de l’iso2709 (format standard d’échange des notices en Marc),
      • qui ne permet pas de faire passer des notices trop longues
        (il faut qu’elles soient très longues : une zone peut avoir jusqu’à 10.000 caractères. Mais ça se trouve !)
      • qui est très contraignant et fragile : c’est illisible (cf. 3 notices Unimarc en iso2709), on rencontre toujours des problèmes sur les encodages, etc.

Astuce pour extraire une liste de notices en format Marc du SRU

Si vous avez une liste d’ISBN, ou une liste de numéros de notices : vous pouvez les chercher dans le catalogue public, bien sûr. Mais si vous voulez d’emblée regarder le formqat Marc des notices, vous pouvez copier-coller la liste des ISBN ou des n° de notices (ou ARK) dans le critère de recherche idoine

Ce qui vous permet d’afficher une liste de notices Marc
(plus rapide que de lancer une requête dans le catalogue, sélectionner les notices en haut de la liste, puis bouton « Voir la sélection »)

C’est ce genre de cas d’utilisation qu’il faut progressivement identifier pour être amenés à utiliser le SRU à bon escient, comme complément du catalogue et du serveur Z39.50.

De plus en plus d’ISNI

Il y a actuellement 1,8 millions de notices d’autorité Personnes dans le catalogue BnF. Dont 83% avec ISNI. Si l’ISNI est adopté par toute la chaîne du livre qui publie et diffuse la production éditoriale, le circuit de traitement des ouvrages en sera grandement facilité, y compris dans la manière dont le catalogage courant en FRBR pourra être mis en place.

Créer une nouvelle zone Marc, c’est facile ?

Mon passé d’administrateur de SIGB au SCD de Nice m’avait laissé complètement ignorant de la manière dont, dans de très nombreuses bibliothèques, la collaboration avec le prestataire SIGB se passe. A l’Abes comme à la BnF, comme dans un SCD, l’établissement est autonome sur l’évolution du format de catalogage : si une nouvelle zone s’avère nécessaire, l’administrateur SIG (ou catalogue) la configure dans le module de catalogage, on paramètre l’indexation, les facettes, l’affichage — et voilà.

Mais dans de très nombreuses bibliothèques la création d’une zone, et la configuration de l’outil pour l’exploiter, passe par une prestation.

Donc lorsque l’Abes crée la zone 219 pour le Sudoc (nouvelle zone Unimarc de date conforme à RDA-fr), les SCD l’intègrent sans trop de difficulté (du moins je le suppose — en tout cas je sais qu’à Nice ça n’aurait pas posé de problème particulier) ; la BnF suit le même choix parce que les agences collaborent — et en soi c’est une bonne chose. Sauf que les bibliothèques qui récupèrent les notices BnF ne sont pas comparable au bibliothèques universitaires. Et ce peut être compliqué que de choisir de payer une prestation au fournisseur du SIGB, pour un gain de service à peu près nul (si ce n’est pour éviter une non régression).

Data.bnf.fr a mis à jour son modèle de données

C’est la petite toilette de printemps annuelle.

Simplifications dans les URI du graphe

(pour voir directement les schémas, c’est sur la page Comprendre le modèle de données de data.bnf.fr)

Les URI ont été harmonisées : au lieu d’avoir des oeuvres en URI_ark#frbfr:Work, des personnes URI_ark#foaf:Person, des collectivités en URI_ark#foaf:Organization, tout est passé en #about.

Donc

  • les propriétés associées à la notice (date de création, date de dernière modification, lien au catalogue, FRBNF) sont associées à l’URI contenant l’ARK seul (exemple : http://data.bnf.fr/ark:/12148/cb13896861p)
  • les propriétés associées à la « chose », personne, oeuvre, etc. (titre, nom, date de création ou de naissance) sont associées à l’ARK#about (exemple : http://data.bnf.fr/ark:/12148/cb13896861p#about)
    Les URI #foaf:Person, #frbr:Work, etc. sont déclarées comme owl:sameAs l’URI#about, mais ne portent plus aucune propriété

Et on a pu supprimer la double URI #frbr:Expression et #Expression (jusque là, suite à un bug historique, le type d’expression, la langue et le lien à la manifestation étaient supportées par l’URI #Expression, tandis que les mentions de responsabilités étaient portées par l’URI #frbfr:Expression, les 2 étant reliées par un owl:sameAs).

Par exemple, avant, pour aller de l’ISBN au nom d’auteur, il fallait faire :

ISBN > manifestation > expression > frbr:expression 
          > auteur#about > auteur#foaf:Person > nom d'auteur

Désormais :

ISBN > manifestation > expression > auteur#about > nom d'auteur

Ce qui est plus logique et plus court.

Les anciennes URI restent valides, avec des owl:sameAs pour pouvoir continuer à les exploiter

Autres mises à jour

  • les ISBN sont décrits d’une manière plus souple :
    • les ISBN10 comme bnf-onto:isbn & bibo:isbn10
    • les ISBN13 comme bnf-onto:isbn & bibo:isbn13
      Il est donc possible de les distinguer, ou de les récupérer de manière indifférenciée
    • Par ailleurs, jusque là seul le 1er ISBN de la notice était récupéré. Ils le sont désormais tous.
  • Suite notamment au hackathon et au début de gros chantiers autour de Rameau, les alignements avec des référentiels extérieurs ont été enrichis.
    • les alignements avec les LCSH (vocabulaire de la Bibliothèque du Congrès) sont ceux validés un à un par les experts du centre Rameau, au lieu d’être calculés à la volée dans data.bnf.fr
    • Pour le domaine musical, on trouve de nouveaux alignements vers MusicBrainz depuis les auteurs (exemple : Mozart) ou les oeuvres (exemple : Let it be)
  • Et quand même : une amélioration notable des temps de réponse de l’interface (mais je ne dénoncerai personne)
  • un petit truc sympa : si vous prenez une notice bibliographique du catalogue (et que son auteur est dans data.bnf.fr) et si dans l’URL vous remplacez « catalogue.bnf.fr » par « data.bnf.fr », vous avez un beau fichier RDF/XML qui s’affiche.
    C’est un peu l’équivalent de l’extension « .rdf » dans les notices Sudoc

Plutôt que des identifiants pérennes, des identifiants gérés

La preuve que cette journée était bien concue : à l’issue de la présentation introductrice (présentation des principes et des concepts) par @SebPeyrard, les questions posées par l’assistance trouvaient systématiquement comme réponse : « Alors justement, ce sera approfondi à tel moment de cette journée — mais voici déjà quelques éléments ». C’est dire si le programme initial correspondait aux attentes de la salle !

Si vous n’avez pu participer à cette journée, vous avez donc tout intérêt à en guetter la rediffusion vidéo !

C’est une leçon essentielle de la journée ARK : les identifiants sont le premier service en ligne que nous devons rendre aux utilisateurs de nos ressources. Et si certaines ressources peuvent ne pas être pérennes (un document retiré pour raisons de droits, ou corruption de fichier, ou parce qu’on ne souhaite plus utiliser le concept décrit dans le référentiel des mots-matières), leurs identifiants doivent l’être.

D’ailleurs, il vaut mieux éviter de se donner un objectif de identifiants pérennes, qui a un goût d’éternité un peu angoissant. En revanche il faut se donner des moyens d’avoir des identifiants gérés.

Cela implique plusieurs choses :

  • un même identifiant ne doit pas servir à décrire successivement des choses différentes
  • si la ressource disparaît ou change d’endroit, l’identifiant doit demeurer
    • soit en fournissant une redirection (automatique ou pas) vers la ressource
    • soit en donnant des informations sur « ce qui s’est passée », ne serait-ce que « Ressource supprimée » — tout plutôt qu’une erreur 404
  • le fait de se préoccuper d’avoir des identifiants pérennes va de pair avec le projet d’une mise en ligne de ressources. Il n’est pas nécessaire d’avoir au niveau de l’établissement des missions patrimoniales, il n’est pas nécessaire que ce soit un gros projet ambitieux. Par contre il vaut mieux que ce soit fait proprement, et dès le début
  • la pérennité des identifiants permet de traverser plusieurs prestataires successifs au-delà de leurs solutions techniques et de leurs briques technologiques.
    Ce qui peut sembler une manière de les indifférencier, peut finalement être pour eux une manière de se distinguer, et devenir un critère de choix dans un appel d’offres. De même qu’en choisissant un SIGB qui vous permette à la fin d’un cycle d’exporter toutes vos données pour les réimporter dans un autre système  — et que vous ne choisiriez pas un SIGB qui ne propose pas de fonction d’extraction du catalogue et de la liste des prêts en cours !
  • quand on commence à envisager ces problèmes et à vouloir les résoudre, on rencontre assez vite ARK sur son chemin, comme un ensemble d’outils qui viennent accompagner la mise en place de solutions.

« Accompagner » n’est pas « résoudre ». L’outil n’est pas la solution. Il faut encore que l’établissement se dote d’une politique, qu’elle communique (en interne aussi !) sur cette politique. D’où ces préconisations de la BnF sur sa propre politique.

Théoriquement et techniquement, les ARK BnF ne peuvent désigner qu’une seule ressource. Mais techniquement rien n’empêche quelqu’un de récupérer une notice, de la vider et d’y décrire un autre document (ou une autre personne à la place). Drôle d’idée ? Pourtant ça se rencontre, et il y a toujours une « bonne raison ».

Ce qui prouve bien que l’enjeu sur les identifiants est avant tout une question de politique d’établissement, et de service rendu aux utilisateurs — avant d’être un problème technique.

De manière générale, au vu d’échanges, et de tweets, passés ces derniers mois, j’ai l’impression que beaucoup d’établissements se sentaient jusque là assez seuls, sans interlocuteurs ou partenaires identifiés, pour se poser les bonnes questions concernant leurs identifiants, et étaient contraints de tout redécouvrir individuellement. Cette journée est la première pierre dans la constitution d’une communauté professionnelle française/francophone. C’est une excellente nouvelle.

FRBRisation des imprimés français du XXe siècle

29/03/2018

Ceci est la suite du précédent billet.

Je re-précise tout de suite : on ne fait pas du vrai FRBR à ce stade. On identifie l’étape suivante pour avancer vers le modèle FRBR. Potentiellement, on découvre en cours de route que cette étape doit être précédée d’un certain nombre de choses — qu’on traite progressivement jusqu’à arriver au bout du projet. Puis on se donne un autre objectif.

Il y a deux raisons principales qui font qu’on ne peut pas convertir les notices concernées en FRBR pur :
(si on supposait que la normalisation est terminée, que le format de catalogage a été finalisé pour implémenter ce modèle, et que la manière d’alimenter ce format a été déterminée. Sinon ça en fait trois de plus)

  1. l’outil de catalogage n’est pas prévu pour, on ne saurait pas comment décrire, stocker, afficher, naviguer dans les entités créées
  2. les données sur lesquelles on travaille sont ce qu’elles sont

Les limites de l’environnement de travail

La BnF dispose de deux plateformes distinctes sur lesquelles (re)travailler ses données avec en vue le modèle FRBR : le catalogue, qui stocke les notices en (Inter)Marc, et data.bnf.fr, qui gère les données dans une base de données et les expose en RDF. Le catalogue alimente data.bnf.fr

Depuis 2011, data.bnf.fr s’efforce de « faire du FRBR » aussi bien que possible avec les données disponibles. Donc data.bnf.fr permet de tester des trucs en avance de phase, et quand c’est possible on les reverse ensuite dans le catalogue. Ce fut le cas de 185.000 liens entre notices bibliographiques (considérées comme autant de « manifestations ») et notice d’autorité Titre (considérées comme des « oeuvres ») ajoutés automatiquement, en plusieurs fois, depuis fin 2015.

Aujourd’hui dans le catalogue ne peuvent exister que deux types de notices :

  • les notices bibliographiques, décrivant les documents
  • les notices d’autorité, décrivant les autorités, notamment les auteurs Personnes physiques et organisations, ainsi que le vocabulaire Rameau

Parmi les notices d’autorité ont été créées plusieurs dizaines de milliers de « notices d’autorité Titre« , permettant notamment de faire de l’indexation matière pour dire que tel ouvrage est une étude sur Madame Bovary, par exemple. Si on veut créer davantage d’oeuvres (pour progresser dans l’implémentation du modèle FRBR), on peut donc créer davantage de notices d’autorité Titre et faire comme s’il s’agissait d’oeuvres au sens du modèle.

En revanche dans cette base de données du catalogue BnF rien ne permet de positionner correctement des Expressions. Or le modèle LRM les met finalement bien plus en valeur que l’oeuvre elle-même. Cela ne veut pas dire qu’on ne va rien faire (je parlerai des expressions dans un autre billet), mais qu’il sera impossible d’avoir des expressions dans le catalogue sauf à changer complètement d’outil et/ou de base de données.

Il est donc possible de travailler d’abord à la création automatique des oeuvres : parce qu’on peut expérimenter quelque chose dans data.bnf.fr et envisager ensuite de reverser le résultat (si satisfaisant) dans le catalogue.

Que veut dire « créer automatiquement des oeuvres »

Le principe consiste à identifier par algorithmes un ensemble de métadonnées comme permettant de décrire une même oeuvre.

Le mécanisme est le suivant, pour un auteur donné :

  • récupération de tous les titres dans les notices bibliographiques qui lui sont associées
  • regroupement des titres par similarité de chaîne de caractères
    (« Guerre et paix » de Tolstoï doit être associé à « La Guerre et la paix »)
  • évacuation des regroupements
    • qui contiennent déjà un lien vers une notice d’autorité Titre
      (il ne faudrait pas recréer une notice d’oeuvre Guerre et paix, ça ferait tâche)
    • qui contiennent des mélanges : agrégats, ou manifestations agrégatives, selon la terminologie LRM — toutes ces Oeuvres complètes qui peuplent abondamment le catalogue de la BnF et Gallica
      (là aussi, il serait risible qu’on révèle au monde que Balzac a écrit un chef-d’oeuvre inconnu, intitulé Oeuvres complètes)

L’outil de traitement : RobotDonnées

Ainsi que cela a été présenté le 14 novembre dernier, la BnF met ce projet en place en utilisant RobotDonnées, un outil qui exploite certains programmes développés dans le cadre du projet data.bnf.fr. Je réalise que dans le diaporama mis en ligne sur le site de la Transition bibliographique, toutes les copies d’écran se superposent (diapo 22) — toutes mes excuses !

Du coup voici, pour les diapos relatives à RobotDonnées, la version Google Drive, qui permet d’afficher les images une à une.

Un corpus pour démarrer : les imprimés français du XXe siècle

En réalité, outre le projet data.bnf.fr, la BnF a conduit ces dernières années une autre expérimentation de FRBRisation. Indépendamment de ce qu’il est advenu de l’aventure, le projet ReLire a bel et bien eu besoin de travailler au niveau des oeuvres, afin de constater que toutes les éditions successives sont épuisées.

L’équipe Analyses & Traitement des données a donc capitalisé sur l’expertise de l’équipe ReLire, et son utilisation de RobotDonnées, pour travailler sur les ouvrages imprimés des auteurs français du XXe siècle. On choisit donc :

  • une production pour laquelle la BnF est censée avoir l’exhaustivité, tant sur le plan géographique que chronologique
  • une langue stable, qui évite les évolutions de graphie des termes
  • des données propres
    … ou pas ?

Les données manipulées

RobotDonnées prend en entrée une liste d’auteurs. L’idée est, pour ces auteurs, d’extraire les formes de titres, de regrouper les formes identiques et de générer des oeuvres.

Un deuxième projet s’est greffé là-dessus : pour les éditions agrégeant plusieurs oeuvres, voir s’il était possible de lier la forme de titre à une notice d’oeuvre pré-existante — à condition que dans la notice bibliographique on puisse correctement associer la forme de titre avec son auteur (soit parce qu’il y a un seul auteur mentionné dans toute la notice, soit parce que la notice est suffisamment structurée pour éviter tout risque de confusion).

Or ce sont les mêmes auteurs dont les oeuvres sont publiées tantôt sous forme d’agrégats, tantôt sous forme de monographies.

Donc une première extraction des formes de titres a permis de sortir tout ce qui était suffisamment structuré pour considérer que le titre en question était bien associé à l’auteur en entrée

Pour tout ça, on est évidemment tributaire des données du catalogue.

Suivant ce processus, il faut éviter de faire croire que Pagnol a écrit une oeuvre intitulée « César, Marius, Fanny »

Nous menons donc un double travail :

  • affiner les paramétrages pour que ce qui sort des traitements automatiques soient propres (ou à peu près)
  • identifier des chantiers de reprise et de correction des données : dans les cas où la correction peut être appliquée en masse, rendre les notices plus conformes aux consignes de catalogage actuelles (sans les rendre parfaites pour autant), et améliorer les notices d’oeuvres produites par RobotDonnées
    Parmi ces chantiers :

    • l’attribution d’une date en zone codée, lorsque celle-ci était présente ailleurs dans la notice
      (pour calculer la date de création de l’oeuvre à partir de sa manifestation la plus ancienne)
    • le nettoyage des zones de titres structurées ainsi :
      Nom d’auteur. Titre d’ouvrage
      Ce genre de pratique n’est pas gênante pour accéder au document. Mais on ne va pas mettre dans data.bnf.fr qu’Emile Zola a écrit « Emile Zola. L’assommoir ».
    • la correction des rôles indéterminés : il y a dans data.bnf.fr près de 200.000 expressions liées à leurs auteurs par un rôle indéterminé. Ce qui, avec les codes de langues, va se révéler gênant quand on voudra travailler sur les expressions.
    • le nettoyage des notices analytiques (ou sous-notices, dont le rôle est d’assurer le dépouillement du contenu d’un ouvrage quand on le juge utile) quand elles signalent des « préfaces »
      Cette information doit être convertie en rôle « préfacier » au niveau de la notice principale, pour éviter de créer des milliers d’oeuvres intitulées « Préface », « Introduction », etc.

Calendrier et volumétrie ?

M’avancerai-je sur un calendrier ? Disons que vous devriez trouver des oeuvres « calculées automatiquement » dans data.bnf.fr courant 2018, pas mal de choses sont en bonne voie. La bonne nouvelle est que la phase « Regroupement par formes de titres » a déjà été réalisée pour 100.000 auteurs.

Sur la volumétrie, c’est encore plus compliqué : on part sur un ensemble de 400.000 auteurs. A partir de là, on ignore encore :

  • combien chacun a publié de livres
  • combien d’oeuvres (regroupements de formes de titres) pourront être identifiées
  • combien de regroupements contiendront des agrégats (pour lesquels ils ne sera donc pas encore possible de calculer des métadonnées d’oeuvres)

Donc il n’est pas vraiment possible d’identifier encore le nombre d’oeuvres qui seront ainsi générés dans le cadre de ce chantier.

Et ensuite ?

Quand on aura fait tout ça et que tout le monde 95% de tout-le-monde sera content du résultat, on pourra aller un cran plus loin :

  • corpus d’autres périodes
  • corpus autres que textuels
  • injection des données dans le catalogue
  • expérimentations sur les expressions
  • articulations avec les notices de regroupements générées dans le Sudoc (voire d’autres réservoirs)
  • et il sera prochainement question aussi de la manière dont d’autres bibliothèques pourront plus facilement récupérer tout ce travail (dans la continuité de cette présentation)

Préparer la FRBRisation, c’est déjà FRBRiser

27/03/2018

Depuis cette expression mémorable concernant le grand soir catalographique (ou plutôt son absence) pour les bibliothèques, on a toujours l’impression d’aller vers le modèle FRBR , ou — pire — de l’attendre. Mais on n’a jamais vraiment l’impression d’être en train de FRBRiser. Tout ne semble que prémisses à la vraie FRBRisation qui viendra un jour.

Pourtant il faut avoir l’audace de s’y résoudre : il n’existe pas d’étape de pré-FRBRisation, puisque par principe la Transition bibliographique consiste à avancer progressivement vers l’horizon LRM. Donc ce que nous réalisons aujourd’hui, ce n’est pas encore du FRBR, mais c’est déjà de la FRBRisation

Photo FlickR de Lee Varis – CC-BY-NC-ND-2.0

« Ce que nous faisons aujourd’hui », à la BnF, a été présenté pour partie à la journée Systèmes & Données du 14 novembre 2017. Il est convenu que les deux agences nationales ont nécessairement un rôle à jouer différent des autres structures — et je reviendrai une autre fois sur les étapes plus spécifiques aux bibliothèques de lecture publique.

Pour le moment, je vais me contenter de parler un peu de ce qui se passe à la BnF — et j’espère avoir le courage et le temps d’en faire plusieurs billets.

Le passage progressif à un nouveau modèle de données

Il y a plusieurs actions, à différents niveaux, qui font converger la BnF vers le modèle LRM. Parmi ceux-ci, citons :

  • normalisation : la participation aux lieux d’échanges internationaux et nationaux sur la normalisation, la définition même du modèle à implémenter
  • évolution du format de catalogage : la définition de la trajectoire du format de catalogage (Intermarc à la BnF, qui lui est propre et qu’elle peut donc choisir de modeler selon ses besoins, mais en anticipant aussi les besoins des réutilisateurs de ses données, qui pour la plupart récupère une version Unimarc de ses notices)
  • évolution des règles de catalogage : L’injection progressive du code de catalogage RDA-fr en règles de catalogage pour les diverses voies d’entrée des documents dans les collections.
    Du fait des spécificités, de l’organisation, des missions, de la taille des différentes équipes qui alimentent le catalogue de la BnF, il faut nécessairement définir des règles spécifiques (qui sont parfois identiques, parfois non) pour :

    • le Dépôt légal : exigence de qualité mais aussi de rapidité dans la perspective du CBU, volumétries croissantes et effectifs constants. A chaque nouvelle règle de catalogage envisagée, il faut multiplier la consigne par 80.000 notices et se demander dans quelle mesure cette nouvelle règle aura un impact sur les délais de mise à disposition des métadonnées.
    • les acquisitions (étrangères) : l’exigence de qualité est moindre, puisqu’on dérive les notices de Worldcat pour les acquisitions étrangères, et que la BnF n’est pas bibliothèque de référence pour les métadonnées hors domaine français. Néanmoins il faut veiller à la cohérence globale du catalogue (sinon des outils aussi utiles que les critères de recherche ou les facettes du catalogue en ligne n’ont plus de raison d’être)
    • le rétrospectif (catalogage / corrections) : étant donné la stratification du catalogue, les différents canaux par lesquels sont arrivés les actuelles 13 millions de notices bibliographiques, celles-ci sont pleines de problèmes qu’il n’est pas possible de laisser en l’état
  • évolution de l’outil de catalogage : celui actuellement utilisé a permis et permet toujours de travailler en articulant notices bibliographiques et notices d’autorité.
    Il n’est pas adapté à un catalogage nativement LRM, qui est l’objectif à atteindre. Il faut donc faire évoluer l’outil lui-même (ou en changer).

A présent que sont posées ces différentes dimensions, je reviendrai dans un prochain billet sur la partie qui m’intéresse le plus, parce qu’elle relève en grande partie du traitement des données (automatisé ou pas) : comment FRBRiser rapidement 13 millions de notices ?

[spoiler] On commence par le plus simple !