Aller au contenu principal

IA et opac : mettre en place un moteur de recommandation dans un opac – 1/4 : quelques bases conceptuelles

04/11/2019

J’ai le plaisir d’accueillir Géraldine Geoffroy, collègue niçoise, pour une série de billets sur une utilisation de l’intelligence artificielle et du machine learning pour le développement d’un service en bibliothèque. En escomptant bien que cette série se prolongera par d’autres encore !

Un moteur de recommandation, pour quoi faire ?

A votre avis, pourquoi toutes les multinationales de e-commerce, les plateformes d’hébergement de vidéos, les réseaux sociaux proposent-ils un moteur de recommandations de contenus en plus de leur moteur de recherche ? Pourquoi Netflix a-t-il lancé en 2009 un challenge doté d’une récompense d’1 million de dollars pour qui développerait un algorithme de Machine Learning encore plus efficace pour son système de recommandations (sur la base de sets de données massives sur son catalogue et sur les évaluations de ses utilisateurs) ? Tout simplement, et évidemment, parce que la rentabilité attendue d’un bon moteur de recommandations vaut bien un investissement d’1 million. En effet, suggérer de façon proactive des contenus connexes est une manière implicite de susciter la découverte au sein d’un catalogue de références, non comme une fin soi (ce qui n’arrive jamais au demeurant) mais dans l’espoir de tomber « par hasard » sur un contenu intéressant. Plus le temps passé sur la plate-forme s’accroît et plus la probabilité d’un acte d’achat est optimisée (sans compter les sollicitations, issues des tendances web collaboratives, à devenir un acteur du jeu en laissant son avis ou affectant une note), alimentant de facto un peu plus la masse  de données utilisateurs ingérées par les algorithmes, renforçant ainsi la précision des profils prédictifs et la qualité des recommandations fortement personnalisées, donc le temps de navigation sur l’interface, et la boucle est bouclée ! Au fil du développement des capacités de stockage et de traitement de données relevant du Big data (massives, multi-formats et disponibles en flux continus) ainsi que de la standardisation des profils de Data Scientist, la mise au point de système de recommandations est ainsi devenue l’une des utilisations les plus courantes des algorithmes de Machine Learning 1.

Appliqué à nos catalogues de bibliothèques l’enjeu n’est évidemment pas le même, mais la “problématique” de la découverte se pose tout de même. En effet, en se plaçant côté utilisateur, donc du point de vue de la performance des moteurs de recherche mis en place par les bibliothèques, on peut à gros traits distinguer quelques tendances de long terme :

  • d’un côté des capacités techniques croissantes d’intégration et d’indexation de volumes de métadonnées dont les caractéristiques se rapprochent petit à petit elles aussi de celles du Big Data (gros volumes, variété des sources et des formats, gestion des flux de mises à jour). Conséquence logique : des résultats de recherche en nombre conséquent, notamment par exemple avec les outils de découverte souvent adossés à des index centraux ;
  • au niveau de la représentation elle-même des données au regard de l’utilisateur dans l’interface, les outils de recherche intègrent nativement des processus d’ordonnancement des résultats (de type affectation de scores de pertinence, opérations de fusion et FRBRisation…) qui sont censés aider l’usager dans son appréhension de listes de résultats kilométriques ;
  • enfin, la réponse apportée à la question de l’efficience de la recherche dans un catalogue s’est aussi déportée en amont sur la modélisation des données censée optimiser la réalisation des “User Tasks” identifiées par les modèles FRBR puis LRM. Ainsi en est-il des entités WEMI relatives aux données bibliographiques pour présenter des ressources regroupées autour d’une même œuvre, ou des données d’autorités modélisés en entités d’un graphe de connaissances et qui forment comme autant de points d’accès possibles dans le cadre d’une interface de recherche.

Un des objectifs est donc d’améliorer les catalogues (et leur visibilité, mais c’est une autre question) pour aider l’utilisateur à trouver ce qu’il cherche, mais comment lui permettre de trouver ce qu’il ne cherche pas ? Comment permettre à la fois l’identification précise d’un ressource et l’exploration des collections, le parcours du catalogue au fil des notices (et bientôt des entités) ? Autrement dit, s’il est question de donner sa place à la sérendipité, de ce point de vue un moteur de recommandations ajouté au moteur de recherche peut alors apporter une réponse.

Ceci étant dit…

Comment fonctionne un système de recommandations ?

Le concept de base de tout système de recommandation est celui de la similarité (similarité entre contenus, similarités entre usagers) et toute la problématique consiste alors à traduire opérationnellement cette notion de similarité.

Plusieurs types d’approches et différents types de combinaisons entre elles sont possibles (et largement documentées), mais pour simplifier (beaucoup) on peut en distinguer principalement deux :

  • l’approche dite de filtrage par contenus (“content-based filtering”) : il s’agit ici d’évaluer la similarité entre contenus à partir de leurs caractéristiques intrinsèques et d’ensuite filtrer les données en fonction de l’utilisateur pour lui proposer l’information pertinente. Dans un contexte documentaire par exemple, la base de connaissance pour modéliser ce type de proximité entre documents repose donc sur les métadonnées bibliographiques des collections qui constituent les variables à partir desquelles on peut appliquer des algorithmes issus du domaine du NLP (traitement automatique du langage naturel).
    A première vue, on retrouve l’approche traditionnelle des bibliothèques quand elles proposent des rebonds vers d’autres ressources, mais la méthode ici diffère de nos pratiques métiers d’un point de vue essentiel (et cette différence est au cœur de l’utilisation d’algorithmes de Machine Learning ou Deep Learning) : le rebond sous forme de liens hypertextes dans un catalogue, à partir d’un mot sujet par exemple pour renvoyer vers d’autres ressources ayant été cataloguées avec ce même point d’accès, provient de l’application par des bibliothécaires de règles métiers, relatives à l’utilisation de Rameau par exemple, et ensuite exploitée dans une interface sous forme de liens. Cette pratique est la double conséquence logique de l’exploitation de l’expertise métier sur les liens entre métadonnées et les possibilités techniques offertes par nos outils de signalement. Ici par contre, la similarité entre chaque paire de documents n’est pas déterminée à priori par le catalogueur : certes la donnée métier est utilisée comme input par l’algorithme mais le calcul de proximité est ensuite effectué sur l’ensemble des métadonnées du corpus pour dégager des regroupements de documents similaires, ce qui serait infaisable à l’oeil nu.
  • l’approche de filtrage collaboratif (“collaborative filtering”) : dans cette perspective, c’est la similarité par l’usage qui est privilégiée, pour déterminer des associations entre usagers (“user-based filtering”) et/ou des rapprochements entre contenus (“item-based filtering”). On se base donc sur les comportements passés de tous les usagers pour “prédire” leurs préférences futures, et sur le double postulat selon lequel un utilisateur sera intéressé par des contenus proches de ceux qu’il a déjà consultés et/ou par des contenus déjà consultés par des utilisateurs similaires.
    Conceptuellement ce mode de recommandations correspond moins au mode de pensée des bibliothécaires, et ce pour diverses raisons (respect de la vie privée et des données personnelles de l’usager, difficultés techniques liée à la gestion de données d’usage produites en flux continu, compétences techniques il faut bien le dire aussi…). Quoi qu’il en soit en bibliothèque, en règle générale dans le cadre de cette approche, la stratégie adoptée consiste à extraire, nettoyer et traiter des données d’utilisation d’une plate-forme (les achats ou abonnements bien sûr, mais aussi les avis, notes et commentaires laissés par les usagers), de manière à élaborer une matrice2  des comportements d’achats ou de scoring dite user/item (c’est-à dire détaillée au niveau de chaque item et de chaque utilisateur), pour enfin tester et paramétrer des algorithmes de Machine Learning sur cette matrice. Techniquement plusieurs familles d’algorithmes sont disponibles (k-NN, co-clustering, et factorisation de matrice en tête), largement implémentées et prêts à l’emploi dans des librairies Python dédiées à l’apprentissage automatique (Scikit-learn, Surprise) .

Notons d’ailleurs qu’une des solutions de collaborative filtering les plus utilisées n’est autre que la technique de factorisation de matrice perfectionnée et popularisée à l’occasion du challenge Netflix évoqué plus haut (basée sur le paramétrage d’un algorithme de régularisation qui minimise l’effet d’entraînement dans le cadre d’un modèle de décomposition de matrice de type Singular Value Decomposition)

Et donc… [à suivre]

—————————–
↑ 1. Concrètement, face à une tâche à réaliser (proposer les recommandations individualisées de séries les plus pertinentes sur Netflix, détecter les images qui représentent des visages dans un corpus iconographique, adapter le moment des mises à jour d’un OS en fonction de l’usage qui est fait de l’ordinateur…), la stratégie de Machine Learning consiste à collecter le maximum d’observations pertinentes. On part du principe que ces observations sont les résultats d’une fonction mathématique dont il faudrait trouver la formule, l’équation, à déduire à partir des observations. Cette fonction restera toujours inconnue mais le but des algorithmes de Machine Learning est d’en fournir la meilleure approximation en se servant des données d’observation comme ensemble d’apprentissage. C’est donc une démarche “data-driven”, pilotée par les données et qui s’absout des règles métiers pour l’extraction d’informations.
L’application de méthodes de Machine Learning peut répondre à un vaste ensemble de problématiques, dans la mesure où il existe plusieurs familles d’algorithmes s’adaptant à plusieurs types de situation : des algorithmes de régression ou de classification, supervisés ou non supervisés, géométriques ou probabilistes, paramétriques ou non-paramétriques. La méthode quant à elle est bien éprouvée : elle consiste à déterminer la variable cible à prédire et les variables explicatives qui vont servir d’input (données en entrée), puis à diviser le jeu de données de départ en un set d’entraînement sur lequel l’algorithme va être élaboré, et un set de test sur lequel l’algorithme va être appliqué. La performance est ensuite évaluée en comparant la donnée cible prédite par l’algorithme sur le jeu de test et la vraie donnée.

↑ 2. Un tableau à double entrées de m lignes et n colonnes représentant les valeurs combinées de deux variables.

50.000 oeuvres calculées dans data.bnf.fr

31/10/2019
Depuis le 25 octobre, date de la dernière mise à jour des données dans data.bnf.fr, vous pouvez voir admirer plusieurs dizaines de milliers d’oeuvres générées automatiquement sur la plate-forme data.bnf.fr, au milieu des 270.000 autres oeuvres créées à la main depuis de nombreuses années par les catalogueurs de la BnF.
Elles ne sont pas accessibles de manière spécifique dans l’interface : en naviguant dans data.bnf.fr, soit via la liste des oeuvres soit en faisant des recherches dans l’interface, vous pouvez tomber dessus occasionnellement. Elles sont reconnaissables à leur mode d’affichage et à leur URL
oeuvre calculee
Ce premier chargement de masse est l’occasion de rappeler les étapes précédentes, le contour de ce qui a été chargé, et ce qui est prévu pour la suite

3 ans de travail

La naissance de RobotDonnées

En juin 2016, Logilab, le prestataire en charge du développement de data.bnf.fr, livrait une plate-forme spécifique qui reprenait certains algorithmes de data.bnf.fr, en permettant à l’utilisateur professionnel de les exécuter en faisant varier certains paramètres pour les exécuter sur des corpus dédiés. Cette plate-forme fut baptisée RobotDonnées.
RobotDonnees
RobotDonnées contient notamment 3 algorithmes qui peuvent être utilisés successivement afin d’identifier et générer des oeuvres :
  • extraction des formes de titre : pour un auteur ou une liste d’auteurs, on extrait les formes de titre de leurs ouvrages
    Exemples de paramètres disponibles :
    • le code fonction qui détermine qu’un auteur est un auteur (un illustrateur est-il un auteur et doit-il remonter au niveau de l’oeuvre ? un réalisateur ? un adaptateur ? un préfacier ? un éditeur scientifique ?)
    • qu’est-ce qu’un titre : que faire des « autres formes de titre », du titre original, du titre d’ensemble, du titre de partie ?
    • les titres sont extraits pour être ensuite regroupés dans des « clusters » : n’y a-t-il pas des mots à nettoyer des titres, qui empêcheraient ce regroupement.
      Si on a « Bérénice, drame en 5 actes » d’un côté, « Bérénice, de Jean Racine » (oui, souvent l’auteur mentionné sur la page de titre a été mis dans la zone de titre et ça ne gênait pas grand monde), les 2 titres contiennent trop de mots différents
      On peut donc supprimer des mots vides (« en », « drame », actes », « de ») mais aussi demander à nettoyer le titre à partir de la chaîne de caractères « , drame » ou « , roman »
  • regroupement des formes de titre : pour chacun des auteurs dont on a extrait les titres, on veut les regrouper quand ils sont suffisamment proches.
    Une certaine différence peut être tolérée (ou pas) : dans RobotDonnées, ça se calcule par nombre de mots à remplacer, supprimer, ajouter, entre 2 formes de titre, et c’est une distance (dite « de Jaccard« )
  • génération de notices d’oeuvres à partir des regroupements :
    • pour un cluster de notices bibliographiques, identifiant du document le plus ancien
    • récupération de la date, de l’auteur, du titre de l’oeuvre et des autres formes de titre (présentes dans la notice du document le plus ancien, ou dans les notices des éditions ultérieures)
    • constitution avec toutes ces métadonnées d’un fichier JSON que data.bnf.fr est capable d’absorber

RobotDonnées / ReLire

Le tout premier utilisateur de cet outil à son lancement fut le projet ReLire (ou Les indisponibles du XXe siècle). Pour les plus jeunes d’entre nous, je rappelle succinctement que ce projet visait à identifier les oeuvres d’auteurs du XXe siècle devenues introuvables dans le commerce, et dont le contenu justifiait une seconde vie sous forme d’édition numérique, la numérisation s’appuyant sur les collections de la BnF et sur la commercialisation par des éditeurs spécifiques. Ce projet fut contesté par des auteurs qui n’avaient rien demandé, passa ensuite par des péripéties autant judiciaires que mouvementées qui aboutit à son interruption.
Ce qu’on peut en retenir tout de même, c’est qu’on trouve là un cas d’usage excellent (quoique non évident) de l’intérêt du modèle FRBR : car pour identifier qu’une oeuvre est devenue indisponible, il faut certes s’appuyer sur une base commerciale qui indique que pour chaque livre édité, tous les exemplaires ont été vendus ou liquidés ; mais il faut également pouvoir rattacher toutes les rééditions à une même oeuvre (pour constater qu’elles sont toutes épuisées), donc constituer au moins une partie de l’arbre FRBR.

Les imprimés d’auteurs français du XXe siècle

Mais la BnF doit aussi dérouler sa stratégie concernant l’implémentation de la Transition bibliographique, et transformer progressivement ses données. Toutefois, tant que son catalogue est géré dans un outil conforme au modèle ISBD, il n’est pas possible d’y stocker des notices FRBR : on peut néanmoins essayer d’y systématiser ce qui existe déjà et nous permet de nous approcher de ce modèle. Donc si pour le moment on n’a nulle part où stocker ce que pourraient être des expressions, on peut en revanche multiplier les notices d’autorité Titre, qui ressemblent beaucoup à ce que sont les oeuvres FRBR.
Donc la FRBRisation passe par la création d’oeuvres, en partant des notices bibliographiques existantes.
Le corpus de départ : les auteurs français du XXe siècle, pour les raisons suivantes :
  • on a commencé à y travailler avec ReLire, donc on a un petit capital de connaissances sur la bonne manière de nettoyer et regrouper les formes de titre (sous quelle forme sont susceptibles d’apparaître dans les zones de titre des mentions d’auteurs ou d’éditions qui n’ont rien à faire là… mais s’y trouvent quand même)
  • si l’auteur est assez récent, la langue n’a pas trop évolué sur un siècle : on n’a pas à redouter des évolutions orthographiques d’une édition à l’autre, ou des titres saisis selon les règles du livre ancien ; ou encore des titres en latin incluant des mentions d’auteur au génitif
  • le dépôt légal peut être considéré comme exhaustif (autant qu’on peut l’être), ce qui autorise à calculer la date de création de l’oeuvre à partir de l’édition la plus ancienne (supposée première édition). C’est de moins en moins vrai quand on remonte dans le XIXe siècle.
L’année 2018 a été consacrée à traiter par lot les 400.000 auteurs français du XXe siècle (textes imprimés uniquement) identifiés dans le catalogue de la BnF, et à créer plusieurs centaines de milliers d’oeuvres.

Contrôle de données

Dès les premières créations d’oeuvres, on a vu remonter tout un ensemble de problèmes, de plusieurs sortes :
  • ceux liés aux limites de RobotDonnées : celui-ci ne permet pas de tout faire, de tout nettoyer, de tout clusteriser.
    Il a fallu donc faire évoluer certaines fonctionnalités de RobotDonnées, certains paramétrages.
  • ceux liés à la manière dont on s’est servi de RobotDonnées : il y a des subtilités non perçues, des comportements non anticipés, qui avait pour conséquence qu’une oeuvre française traduite en 2 autres langues générait 3 clusters : celui qui regroupait toutes les éditions ; et un par langue de traduction
  • ceux liés aux données sources : soit erreurs de catalogage, soit manque de structuration des données, soit bonne application de consignes du XXe siècle qui nous posent problème aujourd’hui
    Ainsi, si vous cherchez « Thèse de doctorat » dans le moteur de recherche de data.bnf.fr, vous tomberez sur un lot d’oeuvres générées à partir de notices de thèses, où l’on voit bien que le titre de « l’oeuvre » ne correspond pas au titre de la thèse elle-même
theses.png
Dans les notices bibliographiques source, la zone de titre (245$a en intermarc, 200$a en Unimarc) contient le nom de l’Université et de la faculté, ainsi que le titre du diplôme : c’est rigoureusement la transcription de ce que contient la page de titre.
Suite à ces constatations, une demi-douzaine de chantiers relatifs aux titres (ou à d’autres zones, mais quand même surtout aux titres) a bien occupé la fin 2018 et le début 2019, afin de corriger les données du catalogue.

Le chargement dans data.bnf.fr

Le premier semestre 2019 a aussi été consacré à mettre à jour data.bnf.fr pour être capable de recevoir en masse ces milliers d’oeuvres : le module de chargement ne supportait pas bien la montée en charge (on n’a d’ailleurs pas encore dépassé, durant les tests, les 200.000 oeuvres, sachant que le contexte en production apporte toujours de subtiles différences par rapport aux tests).
Il a aussi fallu mettre à jour l’interface web pour qu’elle identifie ces oeuvres et documente le projet (c’est le texte cliquable « Page générée automatiquement », présent sur toutes les pages d’oeuvres calculées, qui permet de fournir une documentation sur le projet à quelqu’un qui tomberait sur une telle page.
Les oeuvres chargées sont toujours celles calculées en 2018 : il a été exclu de les recalculer pour ce chargement dans data.bnf.fr.
En effet, sur ce projet data.bnf.fr n’est pas un outil de diffusion de données validées mais un outil d’expérimentation. 
L’équipe chargée de leur génération a beaucoup travaillé sur la relecture de tableaux Excel pour pister les problèmes et les erreurs, mettre au point la méthodologie, la manière d’utiliser les algorithmes, les contrôles à mettre en place à divers endroits. Mais une fois passées plusieurs semaines à regarder des tableaux, on en vient à se dire : ce qui se serait formidable, ce serait d’avoir une interface de navigation où l’on puisse consulter ces dizaines/centaines de milliers d’oeuvres de manière beaucoup plus agréable, et où le cerveau ne s’engourdirait pas au bout de 25 minutes. Réponse : tiens oui, on pourrait envisager de faire une telle interface, et on pourrait même la baptiser « data.bnf.fr ».
Donc data.bnf.fr retrouve ici son rôle de bac à sable, de la même manière qu’il nous sert depuis le début à expérimenter la modélisation en FRBR à partir des données du catalogue.
On a déjà mis en place un certain nombre de filtres : vous ne verrez pas toutes les oeuvres calculées, car seront filtrées systématiquement :
  • celles dont le titre est vide
  • celles dont le titre contient le nom de l’auteur
  • celles dont la date est aberrante
  • celles dont le titre est suspectement trop long (> 500 caractères)
On ose espérer que la plus grande partie des oeuvres déjà chargée a été correctement calculée, même si on en saura plus dans quelques semaines.
On sait également que certaines oeuvres sont problématiques, et qu’on n’a pour l’instant pas de méthode pour les identifier (par exemple : un titre qui s’appellerait « Un balcon en forêt. Un beau ténébreux » de Julien Gracq).
Bref, en RDF toutes les oeuvres calculées sont identifiables de la manière suivante
  • rdagroup1elements:statusOfIdentification « provisional »@en
    signifie que l’identifiant de la ressource est temporaire
  • prov:wasGeneratedBy <http://data.bnf.fr>
    Cette notice a été générée par data.bnf.fr

Pour la suite

Seules 50.000 oeuvres ont été chargées le 25 octobre. Si la technologie absorbe correctement le passage à l’échelle, il devrait y en avoir prochainement 360.000 de plus : on aurait donc avant fin 2019 dans data.bnf.fr
  • les 280.000 oeuvres créées manuellement par les catalogueurs depuis de nombreuses années
  • 410.000 oeuvres calculées, que l’on pourra ainsi explorer plus aisément, identifier les problèmes et travailler à les corriger
Et dans quelques mois pouvoir charger plusieurs centaines de milliers d’oeuvres supplémentaires, liées à des notices d’autorité « élémentaires » actuellement absentes de data.bnf.fr parce que filtrées au chargement. Ces notices d’autorité élémentaires (constituées généralement uniquement d’un nom et d’un prénom) sont le résultat de chargements antérieurs qui sont venus alimenter le catalogue de la BnF au gré des chargements. Dans l’idéal, chacune de ces notices élémentaires devrait être complétée, dédoublonnée, enrichie. Dans les faits, on sait que le temps va manquer — avec une nouvelle échéance qu’est la mise en place, à échéance de 2 à 4 ans, d’un nouvel outil de catalogage qui n’accueillera plus de notices bibliographiques/notices d’autorité, mais des entités conformes au modèle LRM.
Bref, il faut aussi FRBRiser ce pan du catalogue qui est rattaché aux notices élémentaires, et qui représente environ la moitié des notices de personnes physiques, pour 40% des notices bibliographiques environ.
Les charger dans data.bnf.fr d’abord, c’est une manière de prendre en charge ces notices dans la trajectoire de la FRBRisation du catalogue.
Car c’est bien le catalogue qui est visé : l’espoir pour l’instant est de pouvoir inspecter ces oeuvres dans data.bnf.fr durant 6 mois, et croire avoir fait le tour des problèmes d’ici là, pour s’autoriser à recalculer ensuite intégralement les oeuvres (et bénéficier de toutes les corrections du catalogue qu’on aura faites entre temps, notamment sur les titres) et les charger non plus dans data.bnf.fr, mais dans le catalogue.
Une fois dans le catalogue, elles auront des ARK (identifiants pérennes) et on les retrouvera naturellement dans data.bnf.fr à travers le catalogue.

Et parallèlement

Car oui, il se passe des choses parallèlement : sont en cours de traitement d’autres corpus, et en particulier les films, et les auteurs anglophones du XXe siècle.
On s’efforce également d’aller aussi loin que possible (c’est « possible », le mot important) sur la bonne manière d’exploiter les agrégats (ces documents qui contiennent plusieurs oeuvres, émanant éventuellement de plusieurs auteurs). Mais là dessus ce serait tout un autre aspect du travail réalisé qu’il conviendrait de présenter.
Arrêtons nous donc là pour le moment, en espérant pouvoir y revenir quand data.bnf.fr comptera 700.000 oeuvres.

Devenez précurseur avant tout le monde (ou : devenez responsable de l’équipe Analyse et traitement des données à la BnF)

26/09/2019

J’ai contribué il y a quelques semaines à faire diffuser sur le site emploi.bnf.fr, et sur Poppee, le poste suivant : Adjoint(e) au chef du service Ingénierie des métadonnées et responsable de l’équipe Analyse et traitement de données, poste ouvert au mouvement national des conservateurs de bibliothèques, à pourvoir au 1er janvier 2019.

Ces aspects administratifs étant posés, permettez-moi de vendre ma came. Et quand je parle de came, je ne parle pas seulement de marchandise que j’essaierais de refourguer, mais bien de quelque chose qui me fait vivre et m’épanouit (rien que ça !). En effet, ce poste, je le connais bien, vu que c’est encore le mien à ce jour, et que si je le quitte aujourd’hui, c’est par un jeu de taquins comme notre profession en voit quotidiennement : aujourd’hui je suis cet adjoint, et pour le 1er janvier je me cherche un adjoint.

Donc il s’agit de travailler avec moi, ainsi qu’avec d’autres collègues tout aussi compétent·e·s et passionné·e·s.

Profil vu de face

Portrait de Dora Maar - Pablo Picasso - 1937

Portrait de Dora Maar – Pablo Picasso – 1937

Concrètement, en quoi consiste ce poste ? Comme responsable d’équipe, il fait dialoguer le projet data.bnf.fr (exposition des données de la BnF selon le modèle FRBR et la technologie RDF) et une équipe de correcteurs du catalogue (modèle ISBD, format MARC, technologie plus « traditionnelle »). Traditionnellement, ces derniers oeuvrent à l’amélioration des notices BnF (qui en ont bien besoin !), et depuis plusieurs années axent leur activité sur les corrections nécessaires à la FRBRisation du catalogue de la BnF, avec l’idée que ces notices bientôt FRBRisées bénéficieront à de nombreuses bibliothèques.

Data.bnf.fr et FRBRisation des notices existantes, voici le coeur de l’activité du responsable de l’équipe Analyse & Traitement des données.

A priori, il paraît donc que c’est essentiellement du pilotage et de la coordination (faire bosser les autres, en somme). Ce n’est pas faux (et d’ailleurs je passe pas mal de temps en réunions).

Mais le défi que pose ce poste, et qui en fait tout l’intérêt, est qu’il faut inventer, concevoir et mettre en oeuvre la méthode et les outils pour réaliser cette transition bibliographique du data legacy, aka rétrospectif.

En effet la plupart des choses qu’on veut faire ne sont pas simples, voire pas possibles, en l’état. La normalisation (transposition de RDA en RDA-fr) n’est pas terminée, le futur format de catalogage est en cours de conception, les outils pour fabriquer des oeuvres à partir des notices bibliographiques existantes sont encore très jeunes et ne fonctionnent pas pour tous les cas de figure, les notices elles-mêmes sont diverses et les documents qu’elles décrivent également — bref, il faut faire preuve de beaucoup d’imagination pour envisager, concevoir, tester, rater (voire réussir !) des solutions.

Et pour tout ça, on n’est pas tout seul : le responsable de l’équipe Analyse & Traitement des données n’est pas dans son coin. Il bosse (certes avec le chef de service Ingénierie des métadonnées, dont il est l’adjoint, mais également) avec les experts du catalogue, les acteurs de la normalisation, les porteurs du projet d’outil de catalogage FRBR-LRM (outil baptisé « Noemi »), et avec plein d’autres encore. Et franchement, ça fait beaucoup beaucoup d’experts qui connaissent leur sujet et qui sont motivés.

Une des compétences que doit apporter le responsable d’équipe, c’est la dimension d’ingénierie. Il me semble qu’avant d’être technique, cet aspect consiste surtout à savoir inventer des solutions. Ces solutions sont généralement organisationnelles, procédurales (mise en place de workflows), avant d’être techniques.

Ensuite, il est certain qu’il faut acquérir une certaine maîtrise dans le traitement de données. Pour ceux que cela ferait peur : le critère de recrutement sur ce point n’implique pas de savoir déjà faire du traitement de données. Il implique simplement d’être prêt à apprendre.

Le temps et l’accompagnement seront préservés pour permettre cette montée en compétences, la cible étant de savoir manipuler les données issues de différents flux entrants possibles (RDF venant d’une requête SPARQL, fichiers tabulés, réponses XML à des requêtes dans le SRU du catalogue de la BnF, etc.) et en extraire de l’information, des données nettoyées, etc.

C’est bien la cible, pas un préalable. Et les technologies à manipuler peuvent être de différents niveaux de complexité. On peut déjà faire beaucoup de choses avec un Excel bien maîtrisé. On peut aller encore plus loin avec OpenRefine. Et la programmation (dans le service, on utilise surtout Python pour des raisons pratiques et historiques) n’est pas la seule méthode légitime.

Mais ce que je trouve particulièrement pertinent dans ce poste, c’est que ce genre de compétences (ingénierie dans toutes les dimensions du terme) se révèle extrêmement précieux pour n’importe quel établissement. Toute bibliothèque a la charge de gérer et manipuler des données (« méta » ou non), charge pour laquelle les compétences font souvent défaut (ou au moins pour laquelle des compétences accrues seraient toujours bénéfiques).

Mon pari est que ces compétences font partie de celles qui tracent l’avenir du métier de bibliothécaire.

L’information aujourd’hui se présente comme des masses de données disponibles, protéiformes. Se contenter de traiter son catalogue local en Unimarc n’est pas suffisant pour concevoir une offre de services telle qu’attendue par les lecteurs. Et même pour des besoins internes, on est amené à devoir traiter des données souvent avec difficulté.

Faire du conservateur de bibliothèque un développeur ?

Alors non. Pas du tout. Le développeur a son propre métier, ce qui implique des concepts, des méthodes, une culture professionnelle très différente. Il anticipe les questions de versioning, de portabilité du code, applique des principes d’architecture trois tiers. En termes de compétences, ce profil de poste devrait plutôt s’apparenter aux chercheurs qui conçoivent des scripts ou une petite base de données pour pouvoir manipuler leur corpus (avec une vision métier qui oriente différemment l’activité). Un script, un bout de code, n’est pas un logiciel.

La gradation qui sépare Excel d’OpenRefine, OpenRefine de R, et R de Python (ou Go, Perl ou Ruby) peut être laissée à l’appréciation de chacun ; sachant que la liste n’est pas terminée, que les technologies évoluent, et qu’il devient urgent par exemple de s’intéresser au machine learning et aux réseaux neuronaux. Mais il me semble logique de vouloir toujours aller un cran plus loin, même si on n’arrive jamais au bout. Et ce poste est l’occasion d’aller un peu plus loin. Avec un bénéfice d’acquis qui pourra être utile ensuite pour n’importe quel autre poste : à mon sens, ça n’enferme pas un profil dans une nouvelle tour d’ivoire « expert uniquement utile à la BnF ».

Vous aurez noté, j’espère, que j’ai glissé progressivement d’un descriptif institutionnel de fiche de poste dans son contexte, à une vision personnelle du métier qui n’engage que moi. Il est tout à fait possible d’être intéressé par le poste sans être pour autant convaincu que c’est the avenir de la profession 🙂

Un logiciel de contrôle de noms de fichiers : parce que ça peut servir parfois

07/01/2019

Présentation

Si vous gérez une bibliothèque numérique, par exemple, et devez contrôlez que l’ensemble des fichiers images a un nom correspondant bien à la nomenclature attendue… ou pour toute situation où ça peut rendre service : voici un petit logiciel qui permet de lancer un contrôle sur un ensemble de répertoires.

Le principe est relativement simple : il suppose que vous avez quelque part sur votre disque dur un ensemble de fichiers dont les noms doivent correspondre à certaines règles.

Par exemple : tous doivent avoir

  • 1 à 8 caractères alphanumériques
  • suivis d’un tiret court –
  • suivi de 1 à 5 chiffres
  • suivis d’un tiret court –
  • suivi de 3 chiffres
  • suivis d’un underscore _
  • suivi de 1 à 8 caractères qui peuvent être des chiffres ou des tirets
    et seules certaines extensions sont prévues.C’est cette règle qui est appliquée dans la copie d’écran ci-dessus.

    • GAT154-9876-414_2018-12.JPG est conforme
    • THZ 20181247146.JPG ne l’est pas

Options

Une option permet de sortir les fichiers non conformes à la règle indiquée. Ou l’inverse.

Comme l’utilisateur peut être amené à utiliser systématiquement la même règle (ou utiliser 2 ou 3 règles distinctes à tour de rôle) :

  • la règle dans le formulaire est modifiable à l’exécution
  • On peut modifier la règle qui s’affiche par défaut, dans un fichier de configuration (fichier config/prefs.json)
  • Un fichier de logs en local enregistre toutes les exécutions successives du programme, avec les paramètres utilisés, pour pouvoir rejouer une règle donnée (fichier config/logs.txt)

L’installation est simple.

Les expressions régulières

Le seul hic : il faut savoir écrire des expressions régulières (il faudrait dire « expressions rationnelles », c’est une traduction fallacieuse de regular expressions, ou regex).

Mais il y a plein de tutoriels en ligne, de mémos qui rappellent les principales classes abrégées, et c’est une compétence qui peut servir en plein d’endroits : Python, LibreOffice, Open Refine, Notepad++, pour trouver ou corriger des chaînes de caractères.

Personnalisation

Un des trucs intéressants : le logiciel est conçu pour être personnalisé au niveau d’un établissement. Imaginons que vous coordonnez une chaîne de traitement (liée à l’alimentation d’une bibliothèque numérique, par exemple), mais que ce n’est pas vous qui assurez le contrôle du nommage des fichiers par le prestataire. Vous pouvez

  1. télécharger et décompresser le logiciel
  2. ouvrir le fichier config/prefs.json pour modifier l’expression régulière par défaut
    (attention : pensez à mettre des doubles \\ au lieu de simples \ pour que le JSON les interprète correctement)
  3. rezipper l’ensemble du dossier
  4. distribuer en interne le logiciel aux collègues en charge des contrôles au nommage, afin qu’ils n’aient plus qu’à lancer le contrôle, sans avoir à écrire eux-même l’expression régulière (même par copier-coller).

C’est du Python pré-compilé. Le code source est disponible sur Github, et vous pouvez le récupérer et le modifier (par exemple : le rapport est déposé par défaut dans le répertoire analysé, et s’ouvre à la fin de l’exécution. C’est un truc qui peut vous déranger).

Et le programme s’appelle : File name checker. Je sais, c’est nul. Je suis nul — en nommage.

Les chantiers de correction de données liés à la FRBRisation à la BnF

13/12/2018

Depuis plusieurs mois, l’équipe Analyse & traitement des données (département des Métadonnées) prépare data.bnf.fr à accueillir progressivement plusieurs centaines de milliers d’œuvres, générées par calcul automatisé à partir des notices bibliographiques du catalogue.

Si besoin (ou intérêt), d’autres présentations rendront compte de la méthodologie suivie pour le calcul de ces œuvres. Mais la présentation faite lors de la dernière journée Systèmes & Données du 6 novembre 2018 (à partir de 4h48’40 — suite à un problème technique, le son n’arrive qu’au bout de 8 minutes) en donne déjà une idée, ainsi que la présentation assurée par Raphaëlle Lapôtre, cheffe de produit data.bnf.fr, à la conférence SWIB à Bonn (28/11/2018 – vidéodiaporama — il y a du son, mais c’est en anglais).

Donc pour changer, j’aimerais donner un peu à voir l’envers du décor, non pas le processus de calcul lui-même, mais ce qui se passe avant.

En effet, travaillant de concert avec les porteurs du projet data.bnf.fr, une équipe de collègues travaillent sans relâche sur les données source du catalogue.

Cette équipe existe depuis des années, chargée de l’amélioration des données bibliographiques du catalogue (et plus particulièrement de la reprise des notices produites par l’énorme chantier mené au pas de course de la « conversion rétrospective informatisée », ou CRI). Mais avec le calendrier de la Transition bibliographique, l’activité de cette équipe s’est concentrée essentiellement sur les conditions de la transformation du catalogue en œuvres, expressions, manifestations.
Parce qu’il apparaît rapidement que si on se contente d’exploiter les notices en l’état, ça va être… compliqué.

Commençons par les œuvres

Puisque c’est ce que nous créons en premier, voyons un peu à quelles conditions on peut avoir de belles œuvres à mettre dans data.bnf.fr.

Il faut pour cela :

  • regrouper correctement les notices bibliographiques en œuvres
    Donc : pour un auteur donné, que toutes les éditions d’une œuvre se regroupent parce que les titres successifs se ressemblent suffisamment
  • Eviter de laisser une notice bibliographique de côté
  • Eviter de faire entrer dans le regroupement un truc qui n’a rien à voir (le manuel de mathématiques pour Terminale S n’est pas le même que celui pour Terminale L, les deux fussent-ils du même auteur)
  • générer des métadonnées d’œuvre satisfaisantes, une fois les « clusters » de notices bibliographiques constitués : Dans notre outil actuel (baptisé RobotDonnées), les métadonnées calculées pour les œuvres sont :
    • Titre (original)
    • Autres formes de titre
    • Date de création
    • Langue de l’œuvre
    • AuteursChacune de ces métadonnées doit donc être correctement renseignée dans les notices bibliographiques pour pouvoir remonter proprement au niveau de l’œuvre

Autant de chantiers possibles pour alimenter ou corriger les notices.

Je précise d’emblée qu’étant donné le calendrier, nous sommes obligés de travailler sur « un effet de masse » : certes, la BnF travaille depuis Charles V et pour l’éternité, mais pour l’instant il faut surtout faire en sorte que les œuvres qui seront injectées à partir de fin 2019 dans le catalogue seront les plus correctes possibles.

Et comme le corpus exploré en premier est celui des auteurs français du XXe siècle, on dépasse le million d’œuvres à générer.

Pour chacun de ces éléments d’informations, nous essayons donc d’identifier les moyens d’augmenter significativement la qualité et la richesse des notices, dans un temps court.

[les zones ci-dessous sont exprimées en Unimarc, même si la BnF catalogue en Intermarc. J’espère vous trouver sensibles à mes efforts pour communiquer avec les « territoires » ]

Les dates de publication

Le premier chantier mené, en 2017, a porté sur les dates de publication.

La date est présente dans deux zones dans les notices Unimarc :

  • transcrite telle qu’elle apparaît sur le document, en zone 210$d (on va donc y trouver des valeurs comme « 2017 », mais aussi « DL 2017 » ou « cop. 2017 », ou « an II [1793-1794] »)
  • sous une forme normalisée en zone 100 : uniquement sur 4 chiffres

Or pour 30.000 notices, la forme normalisée n’était pas renseignée alors que la 210$d contenait bien une mention de date.
On a donc réinjecté la date, nettoyée, dans la zone 100 — celle qui est utilisée de préférence par l’algorithme de RobotDonnées.

Les titres et autres formes de titre

Les dates ont été enrichies par anticipation : on savait que les zones étaient vides et que c’était dommage, vu que l’information n’était pas loin.
Pour les titres, toutes les notices ont bien sûr un titre. On n’est donc pas dans le cas où on alimente une zone vide. Ce qui ne veut pas dire qu’il n’y a pas de souci.

C’est la génération des premières œuvres durant les tests du premier semestre 2018 qui ont permis de se rendre compte d’un certain nombre de problèmes : la notion de titre pour une notice bibliographique ne porte pas les mêmes enjeux que pour l’œuvre contenue dans le livre.

Les règles de catalogage en cours il y a quelques décennies ne sont pas sans poser quelques problèmes :

  • pour les thèses, les titres contiennent très souvent la mention de l’Université et de la Faculté dans le titre
  • On va trouver dans le titre (zone 200$a) : le nom de l’auteur (en début ou en fin), le sous-titre, le genre de l’œuvre, la mention d’édition, les diverses collaborations, etc.
    Toutes informations qui ne sont pas très gênantes dans une liste de résultats : on y décrit un document qui contient bien ces informations sur la page de titre.
    Mais prétendre que le père Octave Bischoff a écrit Nouveau livre de prières du travailleur, par le père Bischoff est moins satisfaisant : le titre de l’oeuvre doit être Nouveau livre de prières du travailleur

Plusieurs chantiers ont donc été ouverts pour essayer, non pas de tout nettoyer, mais de restructurer en masse cette information (avec une volumétrie suffisamment significative pour que ce qui en restera ne sera pas ce qu’on verra systématiquement quand on ira sur data.bnf.fr) :

  • Nettoyage des titres de thèses
    • En récupérant la notice Sudoc
    • ou en restructurant la chaîne de caractères
  • Exploitation de la zone « autre forme de titre » pour restructurer la zone de titre ou pour qualifier l’autre forme, afin qu’elle soit exploitée par le RobotDonnées pour générer un « alternate_title »
  • Nettoyage des titres se terminant par le nom de famille de l’auteur, sous toutes formes :
    • , par Prénom Nom
    • , par Initiale. Nom
    • , par le professeur Prénom Nom
    • , traduit du japonais par le P. Nom
    • etc.

Pour chacun de ces chantiers, la méthodologie est la même : un script Python

  • interroge le SRU du catalogue de la BnF,
  • extrait les notices liées aux auteurs français du XXe siècle,
  • regarde si le titre correspond aux conditions du script (thèse, titre se terminant par le nom d’auteur, etc.)
  • génère dans un tableau Excel les formes actuelle et à venir.

Le tableau Excel est confié à un expert du catalogue qui constate les erreurs, les cas non traités, etc. et recommande des évolutions.
Puis le script est amendé, un nouveau fichier Excel est généré, etc.
Jusqu’à ce que le tableau Excel soit pleinement satisfaisant, à savoir :

  • on traite le plus grand nombre de cas automatisables (c’est-à-dire qu’on n’inclut pas ce qui relève de scories, de cas particuliers, etc.)
  • on évite tous les faux positifs (s’il y a un risque de générer une erreur, le programme prend en compte la possibilité de doute et met la notice de côté)


Et au bout, si tout se passe bien, ce sera chargé dans le catalogue

Oeuvres multiples et fautes de frappe

Claude Rostand aurait écrit 2 œuvres :

La seconde œuvre est évidemment due à une faute de frappe dans le titre (coquille décidément trop fréquente !), qui a empêché le classement de la dernière notice avec les autres.
Un nouveau chantier a donc été planifié à l’issue de la constitution du million d’oeuvres : les œuvres quasi-identiques
Quand plusieurs œuvres ont été générées pour un même auteur, et que le titre de ces œuvres est quasi-identique (à une ou deux lettres près) : c’est suspect.
L’identification des œuvres au titre quasi-identique permet de relever des fautes de frappes, présentes actuellement dans les notices bibliographiques, et qu’on propagerait dans les œuvres ensuite.

Dans certains cas c’est plus subtil : la variation de graphie « Plate-forme » / « Plateforme » empêche le rapprochement entre deux titres, car le tiret est considéré comme un séparateur : le premier titre contient donc deux mots, le second titre n’en contient qu’un. Il faut donc non pas corriger les notices (elles retranscrivent ce qui est présent sur la page de titre) mais les compléter en y ajoutant une information commune, qui permettra la clusterisation à l’issue du traitement.

Là aussi, un script a analysé l’ensemble des oeuvres générées pour extraire celles portant quasiment le même titre pour un même auteur. Une analyse manuelle vient confirmer ou infirmer la validité de l’oeuvre (et corriger éventuellement le catalogue).

Les auteurs

RobotDonnées permet de travailler sur un lot d’homonymes : si deux auteurs ont le même nom et le même prénom, et s’ils ont écrit une œuvre de titre identique (ou quasi identique), RobotDonnées va proposer, soit de fusionner les deux notices d’auteur, soit de réattribuer toutes les notices bibliographiques de titre identique à l’un des deux auteurs (pas de manière aléatoire : il y a des règles métier qui s’appliquent).

Mais une fois que nous avons généré le million d’œuvres, nous nous sommes rendu compte que, de même qu’il y a des titres quasi-identiques, il y a aussi des quasi-homonymes.
Imaginons deux auteurs : Fernand Arlong et Fernand Arloing. Tous deux ont écrit un traité Des Techniques bactériologiques, biologiques et vaccinothérapiques de Wright en collaboration avec un certain René Biot. On a donc deux notices :

  • notice1 : René Biot, Fernand Arlong, Des Techniques bactériologiques…
  • notice2 : René Biot, Fernand Arloing, Les Techniques bactériologiques…

Et quand RobotDonnées génère les œuvres de René Biot, on a donc une œuvre à 3 auteurs :

  • Des Techniques bactériologiques…, de René Biot, Fernand Arloing et Fernand Arlong
    résultat de la clusterisation de notice1 et notice2

Il est donc possible d’extraire du million d’œuvres générée l’ensemble des co-auteurs dont les noms de famille sont identiques, à une lettre près.

Et encore ?

Et il y a encore d’autres chantiers en cours ou en préparation, notamment autour des expressions :

  • analyse et reprise des mentions d’éditions
    (zone 205 — du moins en théorie)
  • reprise des notices associées à un auteur par un code fonction « indéterminé » (9990) : que faire dans LRM d’une « relation indéterminée » ? Va-t-on associer cet agent à l’œuvre, à l’expression ou à la manifestation ?
    Donc il faut, autant que possible, identifier la nature du lien pour qu’elle permette ensuite des regroupements corrects.
    Dans de très nombreux cas, la personne dont le rôle est soit disant indéterminé est mentionné ailleurs dans la notice, avec mention de son rôle !

    Là aussi, un chantier est donc en cours pour reprendre ce qu’il est possible de reprendre rapidement

Conclusion

Pas de conclusion pour l’instant : nous sommes en plein dedans. A part celui sur les dates, tous ces chantiers sont ouverts.

Les bénéfices ne seront pas pour data.bnf.fr en réalité : toutes ces oeuvres ont été déjà calculées, et en attente de chargements progressifs dans data.bnf.fr pour le 1er semestre 2019. C’est précisément leur génération qui a permis d’identifier et de lancer tous ces chantiers. Mais la raison d’être de ces chantiers, c’est bien le catalogue lui-même, dont les données doivent être progressivement d’équerre avec le nouveau modèle LRM.

Les notices corrigées sur les prochains mois bénéficieront au nouveau calcul des oeuvres, pour le même corpus, qui se fera ultérieurement — pour être versées dans le catalogue, cette fois-ci.

En tout cas c’est l’objectif !

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 »