Aller au contenu principal

L’indexation matière en transition : de la réforme Rameau à l’indexation automatique

22/01/2020

Début décembre paraissait un ouvrage dont j’ai tardé à vous rendre compte ici, avec les bousculements du quotidien dûs aux grèves puis aux vacances de Noël.
Et pourtant je suis très heureux d’y avoir contribué, et très fier du résultat.
Cet ouvrage, doté du bel ISBN 978-2-7654-1623-4, fait avant tout le point sur l’actualité normative — c’est du moins le motif initial : la réforme Rameau est difficile à appréhender, car elle est complexe à mener. Elle touche à des données intriquées, héritées de plusieurs années de pratiques qui posent problème aujourd’hui pour la cible visée. Et justement cet ouvrage rend compte à la fois de la cible (en espérant vous convaincre de son bien-fondé), et du processus pour y conduire.
Rameau à 40 ans. Pour qu’il vive au moins aussi longtemps, et si possible davantage encore, il faut résoudre un certain nombre de problèmes structurels, sans renoncer à toute sa richesse. Cette révision en profondeur qui vise à passer d’un manuel de 400 pages à un mode d’emploi de 20 pages. Dans sa course, elle touche évidemment les notices bibliographiques existantes qui utilisent Rameau.
Deux chapitres sont donc consacrés à cette réforme : évoquant le pourquoi, et le comment. La conclusion du livre complète la méthode sur la manière d’en bénéficier, sans pour autant apporter de solution simple : car de fait, ce n’est pas simple à suivre ni à implémenter (que ce soit pour la BnF, pour l’Abes, ou pour les bibliothèques qui réutilisent les données de ces deux agences, et qui indexent en Rameau).
Mais outre ces deux chapitres et la conclusion, les autres chapitres qui éclairent divers aspects très actuels autour de l’indexation matière et des utilisations qu’on peut en faire : visualisation, politique documentaire, actions de médiation, etc.

Indexer : pourquoi ? comment ?

Plutôt que de vous redonner le contenu en vrac et en phrases, voici la table des matières :
Introduction [Etienne Cavalié – @lully1804]
Partie 1 : le contexte normatif et la Transition bibliographique
    Chapitre 1. Indexation et grammatisation [Bruno Bachimont]
    Chapitre 2. Le sujet dans le modèle IFLA LRM [Françoise Leresche]
    Chapitre 3. La réforme de Rameau : principes, méthode, étapes [Florence Ménard]
    Chapitre 4. Perspectives d’évolution de Rameau après la réforme [Ewa Nieszkowska-Serlan
    Chapitre 5. Des nouvelles de la classification décimale Dewey [Jean Maury]
Partie 2 : l’indexation comme contexte au sein d’une collection
    Chapitre 6. Analyser les données d’indexation : comment ? pourquoi ? [François Pichenot]
    Chapitre 7. Les chantiers d’indexation rétrospective à la Bibliothèque nationale de France  [Etienne Cavalié – @lully1804]
    Chapitre 8. Indexation automatique des documents : de nouvelles métadonnées pour de nouveaux services [Jean-Philippe Moreux – @jpmoreux]
Chapitre 9. La formation à l’indexation dans l’enseignement supérieur : approche comparative des diplômes visant une insertion en bibliothèque de lecture publique [David Guillemin – @esDOC_DG]
Partie 3 : l’indexation comme appui à une offre de services
    Chapitre 10. Plaidoyer pour une indexation collaborative… Mais laquelle ? [Hélène Cavalié]
    Chapitre 11. Utiliser l’architecture de Rameau pour naviguer dans les données d’un catalogue [Pierre Bournerie]
    Chapitre 12. Indexation et médiation [Bernard Strainchamps – @Bibliosurf]
    Chapitre 13. L’indexation comme outil de politique documentaire [Géraldine Geoffroy]
    Chapitre 14. Visualiser l’indexation : au-delà de la cartographie [Raphaëlle Lapôtre – @RLapotre]
Conclusion  [Etienne Cavalié – @lully1804]
6 contributeurs viennent de la BnF, 6 contributeurs (pas tous les mêmes) sont membres d’un groupe de la Transition bibliographique. Mais il y a tout de même une part de lecture publique et du monde universitaire !
A propos de Transition bibliographique : le chapitre de Françoise Leresche est la première présentation complète, au sein d’une publication française, du modèle LRM (implicitement : il serait dommage de s’en priver !).
Je relève encore deux choses qui me plaisent dans le résultat obtenu :
  • la diversité des types de contributions : les premier et dernier chapitres relèvent plus de l’article académique, les chapitres 7 ou 13 sont des retours d’expérience, tandis que les numéros 6 et 12 sont plus exploratoires — et ainsi du reste. A travers ce kaléidoscope de chapitres, chaque page contribue à poser des jalons qui permettent de construire une réflexion sur l’indexation d’aujourd’hui et de demain
  • Des bouts de code commentés ont pu être conservés dans certains chapitres, afin de donner à voir le mécanisme de traitements informatiques, tout en facilitant la possibilité de les survoler (de les ignorer ?) rapidement : donc plusieurs niveaux de lecture sont possibles. Mais comme vous avez pu le constater précédemment si vous êtes familier de ce blog : j’aime bien donner à voir le code, qui pourrait devenir un type de texte aussi familier pour des professionnels de l’information qu’une notice au format Marc pour un catalogueur (dans les deux cas, ça relève de culture professionnelle de la maîtrise de l’information)
Vous pouvez aussi consulter mes propres contributions déposées sur HAL : intro + conclusion, et le chapitre 7

Gratification et gratitude

J’ai énormément appris à travers cette aventure éditoriale, et je remercie chaleureusement à la fois Martine Poulain et Muriel Amar, qui m’ont précieusement conseillé sur la maturation et la mise en forme du livre. J’adresse également toute ma gratitude aux auteurs dont les noms figurent ci-dessus, car ce fut un réel plaisir de travailler avec eux. J’estime devoir un remerciement plus particulier à ceux qui n’ont pas trop l’habitude de ce genre d’exercice d’écriture, et qui ont accepté malgré tout de me faire confiance. De mon point de vue, le résultat est à la hauteur des espérances, et même au-delà.
Vous trouverez certainement des défauts, des carences : d’abord parce que j’ai une certaine tournure d’esprit qui, parce que subjective, a tendance à insister sur certains points et à en considérer d’autres comme négligeables. Par ailleurs, l’année 2019 (implémentation d’évolutions fortes de Rameau) nous a beaucoup appris, et les textes ont été rédigés à l’hiver 2018-2019 (le rythme éditorial…). Je suis convaincu que le résultat est perfectible, mais de mon point de vue ce n’est pas grave : le livre n’est pas censé être auto-suffisant. Il vient compléter la littérature professionnelle là où il y avait un complément à apporter, notamment autour de la réforme Rameau et de la Transition bibliographique, en recontextualisant ces problématiques sous un certain angle. Les sites Transition-bibliographique.fr et rameau.bnf.fr continuent d’exister, ainsi que d’autres médias (réseaux sociaux, sites pro, etc.). Ce qui y manque sera publié sous d’autres formes, par d’autres canaux (puisque, malheureusement, il semble bien qu’il va falloir renoncer à la collection Bibliothèques du Cercle de la Librairie, et c’est bien regrettable).
Donc merci de votre indulgence : c’était pour moi toute une initiation que de coordonner seul un tel ouvrage, j’aurais certainement encore beaucoup à apprendre. Mais en l’occurrence chacun a fait du mieux qu’il a pu, et je pense sincèrement que ce livre peut rendre de nombreux services, en rendant compréhensible ce qui peut être encore confus, en ouvrant des perspectives, et suggérant des projets.

Promotion

Pour les Parisiens et Franciliens (de résidence ou de passage) : le livre fera l’objet d’une présentation suivie d’un débat le 11 mars en fin d’après-midi à la Bibliothèque nationale de France (site Tolbiac).

Tester Annif : quelles données, quelles métadonnées ?

06/01/2020

Je rappelle préalablement que je ne suis un expert ni en indexation automatique, ni en machine learning, ni en intelligence artificielle. Bref, je rends compte ici de mes périples au fur et à mesure, avec potentiellement des erreurs de compréhensions ou de manipulations que tout un chacun est invité à corriger. Merci de votre indulgence et de votre bienveillance.

Le prochain billet sur ce logiciel sera consacré à la prise en main concrète d’Annif, pas à pas. Mais il se trouve que, après l’étape d’installation, ce n’est pas l’utilisation même de l’outil qui vient, mais : « quelles données je vais bien pouvoirlui fournir ? »

Rappelons les 3 étapes d’utilisation pour cet outil qui sert de surcouche d’indexation sujet automatisée à des algorithmes de traitement du langage par machine learning1 :

  1. fournir des données déjà indexées pour s’appelle l’entraînement (training) de l’IA
  2. vérifier, sur un autre jeu de données déjà indexées, si l’IA produit le même résultat (évaluation)
  3. fournir un jeu de données non indexées, à enrichir

Quel corpus à indexer ?

Pour ma part, j’ai envie de tester l’indexation automatique sur un corpus un peu ancien (antérieur à Rameau, lequel a été créé en 1980).

Premier écueil : il ne faudrait pas indexer des documents qui n’ont pas à l’être (la fiction…). Donc je sélectionne une cote idoine. Gardons pour le moment le lettrage Clément F, qui à la BnF contient des documents sur le droit.

Mais une fois le corpus de documents déterminé, quelles métadonnées extraire ?

  • Le titre, bien sûr (mais en fait, toutes les zones de titre, titre original, autre forme de titre, titre de forme, etc.)
  • les zones de notes ? Si elles contiennent des informations sur le contenu, c’est bien, mais si la note dit « Bibliogr. » ou « Suivi d’annexes », qu’en faire ? Et comment distinguer les notes intéressantes des autres ?
    Il faut sans doute prévoir un nettoyage pour supprimer les mots non signifiants (nettoyage peut-être différent pour les formes de titre et les informations de contenus)
  • les tables des matières et résumés (rarement renseignés dès qu’on remonte un peu dans le temps)
  • le titre de la collection peut-il aider à identifier le contenu ?
  • la langue des textes : n’extraire que les documents en français (dès lors qu’on entraîne l’IA avec un corpus français)
  • la date est-elle importante ? J’y reviens plus bas

L’objectif est d’identifier les métadonnées qui puissent être associées, de manière pertinente et anticipables, à une indexation. Un livre intitulé Histoire de la France rurale a de fortes chances d’avoir (entre autres ?) une indexation de type « Agriculture — France — Histoire ». C’est plus dur à deviner d’un titre comme Les Modèles de simulation comme outil pour la construction de fonctions de production. Donc il faut identifier dans la notice les zones contenant les métadonnées exploitables, associables à l’indexation.

Quelles (méta)données d’entraînement ?

Une des choses retenues des quelques lectures déjà faites, est qu’il ne faut pas entraîner notre IA avec n’importe quelles métadonnées : il lui faut le meilleur ! Et toutes les notices n’ont pas le même niveau de qualité et de richesse. On va donc lui expliquer qu’elle doit faire aussi bien que les notices du dépôt légal sur les années les plus récentes.

J’ai donc extrait toutes les notices (indexées en Rameau) du Dépôt légal des 20 dernières années, en en mettant 20% de côté pour l’évaluation. Ce qui me donne :

  • ~600.000 documents pour l’entraînement
  • ~125.000 documents pour l’évaluation

Pour les métadonnées à en extraire, mêmes questionnements — et, a priori, mêmes réponses.

Pan sur le bec

Je ne vais pas tenir le suspense plus longtemps : selon le processus décrit plus haut, on rencontre déjà plein de problèmes :

  • Jus de fruit et livre

    Un petit jus de fruit pour mieux faire passer le code civil ? – photo Pixabay

    des textes qui ne sont pas en français
    Notamment, pour un corpus juridique, on retrouve beaucoup de latin, ou de titres en latin (alors que le texte est dit selon la notice être en français).
    Donc en donnant comme corpus d’entraînement le dépôt légal, plein de manuels scolaires et de livres de cuisine, on risque de faire croire à la machine que le mot Jus permet d’indexer l’ouvrage avec « Jus de fruits« 

  • des métadonnées trop lacunaires : quand la notice contient seulement un titre, et que celui-ci est « La Bohême », quelle indexation espérer ?
    Faut-il ne prendre en compte que les titres ayant une longueur minimale (dont on puisse supposer que, passer un certain nombre de caractères, on y trouvera un semblant de description du contenu) ou enrichis de notes diverses ?
  • les concepts des parutions des 20 dernières années ne sont pas du tout les mêmes que ceux de publications juridiques des années 1750-1930 :
    • on ne trouve pas beaucoup dans ces vingt dernières années de publications d’arrêtés du Parlement ou autres édits royaux
    • un ouvrage d’actualité sur un crime fameux portait alors un titre comme Le crime de la rue Mouffetard. Sur le même sujet aujourd’hui, l’ouvrage s’appellerait plutôt La Mondaine : histoire et archives de la police des moeurs
      Il faut donc vraisemblablement que l’écart temporel ne soit pas trop long entre le corpus d’entraînement et le corpus à indexer
  • La phase n°2 dite d’évaluation consiste à confronter ce qu’aurait fait l’IA face à un corpus nouveau pour elle, et la manière dont celui-ci a réellement été indexé. Pour autant, même en cas de différences fortes, cela ne signifie pas que l’indexation proposée n’est pas fausse : on n’est pas dans une perspective de classification
  • la distribution statistique, c’est compliqué

Régression logistique, assurances et classifications

C’est notamment sur ce point que j’espère particulièrement des retours de bâton (sur le bec ?) qui me permettront de progresser plus vite.

Revenons sur le principe initial de l’indexation automatique. Je vous invite à consulter la documentation sur FastText (l’algorithme développé par Facebook et mis en open source), ou au moins son tutoriel pour la classification de textes :

Text classification is a core problem to many applications, like spam detection, sentiment analysis or smart replies

La présence de certains termes dans une chaîne de texte permet de reconnaître (avec un taux d’erreur/de fiabilité lié au contenu du corpus d’entraînement) si un texte relève de telle ou telle catégorie, par un processus de text classification.

C’est la mise en oeuvre de régressions logistiques, tant utilisées notamment dans les assurances : par exemple, j’indique à mon assureur si je suis célibataire/en couple, avec/sans enfants, fumeur/non fumeur, fonctionnaire/salarié/sans emploi/etc., 21-30 ans/31-40 ans/41-50 ans/50…, et en combinant les différents critères, il me met dans la catégorie des conducteurs très sûrs, moyennement à risque ou très risqués. Il réduit un ensemble de critères catégoriels (non chiffrés) à une valeur unique dans un référentiel. La corrélation entre « avec/sans enfants » et « prudent/à risque » est établi par les statistiques d’accidents des années antérieures2.

De même, si dans un corpus d’entraînement j’ai un ensemble de textes indexés à « Guerre mondiale (1939-1945)« , et que certains de ces textes ont des titres contenant les mots Hitler, Camps de concentrations, Nazisme, Pearl Harbor ou Collaboration, l’indexation me proposera le même genre d’association pour les textes non indexés ayant des titres similaires.

On traite donc l’indexation comme une forme de classification, où chaque titre est à ranger dans une (ou plusieurs) catégories.

J’y vois deux problèmes essentiels : l’un conceptuel, l’autre statistique :

  • Conceptuel : Si on définit des cases en amont, et que seules ces cases-là seront des cibles autorisées pour l’IA, cela veut dire que l’ensemble des cases à définir, ce n’est pas le vocabulaire Rameau (190.000 concepts), mais toutes les chaînes d’indexation possibles… Or les combinaisons sont à peu près infinies. A défaut, pourrait-on se dire qu’un gros catalogue, comme le sont ceux de la BnF et du Sudoc, contiendrait suffisamment de documents indexés pour être considérés (faute de mieux) comme l’univers des possibles ?
    Tout en sachant que c’est évidemment faux, et qu’il suffit que soit traduit un livre sur les relations entre deux pays un peu éloignés de la France, donc sur un sujet assez rare — du point de vue des collections françaises — pour que ce qui est possible pour Rameau (Relations internationales — Pays 1 — Pays 2) ne le soit pas pour l’IA qui ne connaît pas cette combinaison-là.
  • Statistique : on a un vrai problème de distribution
    Si ce sont les chaînes d’indexation qui définissent les catégories, cela veut dire que chaque « case » sera plus rare que si on considérait les concepts Rameau individuellement : si les catégories sont les concepts Rameau eux-mêmes, il y aurait alors au maximum 190.000 cases ; si ce sont les chaînes d’indexation, il y en a potentiellement une infinité, dont certaines ne sont représentées, dans le corpus d’apprentissage, qu’une seule fois.
    Or de même que pour qu’une IA sache correctement ce qu’est un chat, il faut lui fournir beaucoup d’images de chats, de même pour chaque chaîne d’indexation définie comme une case, il faut le plus possible d’exemples.

Le fait de définir pour l’IA les chaînes d’indexation comme la cible a comme conséquence immédiate que chaque case envisagée aura peu d’exemples pour l’apprentissage (ou moins que si on avait considéré les concepts « nus »).

Pour bien s’en rendre compte, voici la distribution pour les documents (monographies imprimées) des 20 dernières années du dépôt légal, à la fois pour les chaînes d’indexation (qui peuvent ne contenir qu’un seul concept) et pour les concepts eux-mêmes :

 

  • Nombre de chaînes d’indexation : 848.299
  • Nombre de chaînes d’indexation distinctes : 263.454
  • Nombre de chaînes d’indexation utilisées 1 à 2 fois : 182.840
  • Nombre de chaînes d’indexation utilisées 100 fois et plus : 728

 

  • Nombre de concepts utilisés : 2.381.009
  • Nombre de concepts distincts : 54.147
  • Nombre de concepts utilisées 1 à 2 fois : 18.538
  • Nombre de concepts utilisés 100 fois et plus : 2680

Cela signifie que quand on prend en compte les chaînes d’indexation, dans 21% des cas on n’a qu’une ou deux occurrences dans le corpus d’entraînement pour faire comprendre à l’IA dans quel cas appliquer cette chaîne d’indexation. Autant dire qu’il faut que le titre soit le même pour qu’il s’y retrouve…

Alors que si on considère les concepts (notez au passage que le DL 1999-2019 pour les monographies imprimées n’utilise qu’un quart du vocabulaire Rameau…), cela ne concerne que 0,8% des concepts : la plupart sont utilisés 3 fois et plus.

Et de l’autre côté de la distribution : seuls 728 (0,2%) chaînes d’indexation sont utilisées 100 fois et plus ; alors que 2680 concepts sur 54.147 (soit 5%) sont utilisés plus de 99 fois.

Peut-on décider de demander à l’IA de proposer des concepts (en la nourrissant avec des chaînes d’indexation éclatées, donc) ? L’IA serait ainsi en mesure de nous suggérer plus facilement des « mots-clés ». Mais suivant les règles d’utilisation actuelles de Rameau, cela ne nous servirait à rien, puisque ça ne correspondrait pas une indexation Rameau valide.

Mais nous n’en sommes heureusement qu’au début de cette exploration. J’espère bien que des pistes se dégagent au fur et à mesure ! L’année commence à peine !

——————————————-

1. Kamoulox !

2. Il est possible que j’aie mal compris ques mécanismes sous-jacents — ou que ça dépend des algos — et que ça fonctionne plutôt comme un modèle de graphes (façon Gephi) : quand on entraîne l’IA, à chaque association d’un terme/expression d’un titre avec un mot-clé, elle resserre la proximité entre l’expression et le mot-clé, et génère un graphe où les noeuds sont les mots-clés et les termes libres. Dès qu’on lui donne un terme ou une expression, il propose le mot clé le plus proche. Ou peut-être est-ce encore un autre modèle que je ne soupçonne même pas (hypothèse encore plus vraisemblable !)

Bref, j’ai installé Annif

09/12/2019

Depuis le temps que je connaissais son existence, que j’en entendais parler… Je lui tournais autour de loin, sans trop m’approcher. Peut-être que j’avais un peu peur, en fait. Si j’avais su !

Annif est un logiciel développé par la bibliothèque nationale de Finlande, visant à faire de l’indexation automatique. Il associe un ou plusieurs mots-clés à une chaîne de caractères en entrée. On peut tester sur annif.org ou télécharger le logiciel sur Github.

Ce que j’en savais avant de le télécharger : il est conçu pour qu’on puisse y mettre son propre vocabulaire (référentiel) avant d’y mettre ses propres données. Je ne voyais pas trop comment c’était possible : soit il est déjà « instruit » donc on lui a défini une indexation attendue comme cible, et ça permet de faire une démo sur annif.org, soit il ne l’est pas encore, et je ne comprends pas ce qu’il peut apporter.

Bref, je n’avais rien compris. Et puis je l’ai installé.

C’était il y a 2 jours, donc je n’ai certainement pas encore tout compris, mais je peux sans doute vous fournir quelques informations complémentaires.

Etape 0 : l’installation

En fait, ça s’est bien passé, assez vite. Il se trouve que j’avais déjà Python sur mon PC. J’ai appris pour l’occasion à mettre une machine virtuelle en suivant simplement les étapes d’installation fournies dans la documentation :

  • création d’un répertoire qui va être consacré au projet (je l’ai baptisé annif, je suis toujours aussi nul pour le nommage)
  • dans ce répertoire, je suis passé en ligne de commande pour exécuter les différentes instructions de la doc, ce qui a
    • généré un dossier annif-venv (pour annif / virtual environment)
    • rapatrié les différentes librairies utiles
  • Pour lancer annif sous Windows, il faut ensuite
    • ouvrir le terminal puis lancer l’environnement virtuel en utilisant le fichier annif-venv\Scripts\activate.bat
    • l’instruction annif permet de lister les différentes commandes possibles

Etape 1 : utilisation définition

Je garde le récit de mes premiers tests pour plus tard. Il me semble plus utile de vous expliquer ce qu’est Annif et pourquoi c’est un outil intéressant.

Démarche générale

Si vous êtes une bibliothèque et que vous vous intéressez à l’intelligence artificielle pour faire de l’indexation automatique, vous commencerez par vous intéressez aux méthodes de machine learning, qui vous proposent :

  • de vous doter d’une IA qui sache apprendre (comme TensorFlow ou Scikit-Learn)
  • d’une extraction de votre catalogue, que vous allez diviser en 2 parts :
    • les notices déjà indexées, à séparer là encore en 2 :
      • [lot1] 80% de ces notices pour expliquer à l’IA quel genre d’indexation vous attendez à partir des métadonnées en entrée
      • [lot2] 20% mis de côté pour tester l’IA après l’avoir instruite
    • [lot3] les notices à indexer (à mettre de côté pour plus tard)

Sur les 2 premiers lots, vos données vont donc ressembler à un tableau à 2 colonnes :

  • colonne 1 : les métadonnées d’une ressource (titre, auteur, date, etc.)
  • colonne 2 : l’indexation qui lui a été associée manuellement

Le message qu’on donne à l’IA est clair : si tu vois le même genre de métadonnées plus tard, tu devras lui appliquer le même genre d’indexation.

Et à côté de ça vous allez avoir un référentiel : la liste des valeurs cibles autorisées (mettons : une extraction de Rameau).

Ensuite vous allez :

  1. injecter le lot1 comme données d’entraînement
  2. injecter le lot2 comme données d’évaluation : l’IA prend les métadonnées, calcule une indexation d’après ce qu’elle a compris du lot1, et regarde si l’indexation réellement mise lui correspond
  3. [si le chargement du lot2 est satisfaisant] injecter le lot3 pour récupérer une indexation matière pour vos données non indexées

Du générique au bibliothéconomique

Les IA comme TensorFlow ou Scikit-learn servent à faire plein de choses. Même en restant dans le monde des bibliothèques, vous avez pu voir avec les 4 billets de Géraldine Geoffroy sur la recommandation qu’on peut en faire aussi un algorithme de recommandation. Mais comme vous le savez aussi, ces outils peuvent faire de la reconnaissance d’images, de l’aide à la décision en matière juridique et médicale, etc.

Donc un bibliothécaire qui voudrait utiliser TensorFlow pour faire de l’indexation automatique va devoir concevoir autour une surcouche pour spécifier le besoin consistant à indexer des métadonnées ou du texte intégral en fonction d’un référentiel métier.

C’est cette spécificité qu’Annif fournit. Le logiciel a été conçu comme une surcouche à Tensorflow (et autres fonctions incluses) précisément adaptée à la fonction d’indexation. Cela ne garantit pas en soi l’efficacité du processus, mais ça facilite grandement le travail pour pouvoir le tester.

Ainsi, il existe plusieurs algorithmes de calculs de similarité entre corpus textuels. Deux parmi les plus connus sont :

La bibliothèque nationale de Finlande a pu en choisir un des deux (ou un autre encore) suite à ses expérimentations, l’ayant jugé plus pertinent. Mais elle a intégré ces deux là (et d’autres) dans Annif comme des paramètres : quand vous concevez un projet d’indexation sur un corpus précis et avec un référentiel précis (Rameau, Dewey ou un autre), vous allez pouvoir associer ce projet à un de ces algorithmes sans avoir à l’implémenter vous-mêmes. Mais l’implémentation d’un autre mécanisme est même prévu, lui aussi.

De même, sont intégrées comme paramètres des bibliothèques de nettoyage de chaînes de caractères : pour vos métadonnées vous pouvez vous contenter de nettoyer seulement la casse et la ponctuation, ou vous pouvez demander une stemmatisation ou une lemmatisation des mots rencontrés.

Le plus difficile : les jeux de données en amont et leur analyse en aval

Cela signifie qu’en quelques minutes on peut disposer d’une IA clé en main pour y injecter des jeux de données.

Tout n’est pas résolu, loin s’en faut ! mais au moins le fait même de disposer d’une IA sur sa machine ne pose pas de problème d’appropriation, puisqu’on ne manipule de fichiers que dans des formats connus :

  • le référentiel : un tableau à 2 colonnes (libellé + URI) avec extension .tsv
  • le corpus de données indexées (lot1 et lot2) : un tableau à 2 colonnes (métadonnées + indexation) avec extension .tsv
  • le corpus de données à indexer (lot3) : un tableau à une colonne (métadonnées) avec extension .tsv

Et cela permet de se poser très rapidement les vraies questions, scientifiques, sur ce que doit être l’indexation.

Ce qui fera l’objet d’un autre billet… (ce sont les questions qui feront l’objet du billet. Pour les réponses, eh bien…)1.

——————————

1. Et ensuite je détaillerai un peu plus le mode d’emploi (3e billet, donc).

IA et opac : mettre en place un moteur de recommandation dans un opac – 4/4 : En quoi c’est du machine learning et de l’intelligence artificielle ?

02/12/2019

Enfin, commençons plutôt par expliquer pourquoi cette expérimentation n’en est pas vraiment.

Remarque importante sur l’entraînement et la validation d’un modèle de Machine Learning (pour les puristes)

Pour respecter les règles de l’art, la précision des prédictions issues d’un modèle basé sur des algorithmes doit être évaluée (et le modèle si besoin re-paramétré) avant de passer en production. Pour cela, le workflow consiste à diviser dès le départ le jeu de données en deux sets distincts : un set d’entraînement (en général 80% des données) sur lequel on choisit, paramètre et entraîne l’algorithme, et un set de test (les 20% restants) qui sert à l’évaluation du modèle, notamment au repérage d’un éventuel sur-entraînement, c’est-à dire la bonne capacité du modèle à prévoir les données d’entraînement mais sa moins bonne performance sur les données de test. Concernant un modèle de recommandations, plusieurs techniques et métriques d’évaluation existent qui analysent par exemple son efficacité (sa capacité à recommander des items qui sont ensuite « consommés » – ici empruntés – par les utilisateurs) ou son taux de couverture (sa capacité à couvrir toutes les références d’un catalogue). Ici nous avons d’emblée utilisé l’intégralité des données, tout simplement car il ne s’agissait pas d’utiliser le modèle tel quel en production – on est même très loin du compte – mais seulement d’établir une sorte de POC – et de s’amuser un peu – ;).

D’autre part, pour évaluer le modèle dans le contexte choisi pour cette expérimentation (celui de Cold Start où l’utilisateur n’est pas loggé), on ne peut pas s’appuyer sur les données de prêt pour évaluer dans quelle mesure la consultation d’une recommandation aurait été suivie d’un emprunt. Une solution dans le cadre d’une mise en production serait par contre l’étude des logs du catalogue pour analyser les vues sur les notices recommandées à partir des vues d’un item, ce qui est une autre paire de manches !

Enfin, le terme important dans Machine Learning ou apprentissage automatique est le mot apprentissage : l’algorithme est auto-apprenant, les données produites en temps réel ré-alimentent automatiquement la masse de données disponibles ainsi que les calculs de similarité, et la qualité des recommandations s’améliorent en flux continu. Ceci suppose donc une architecture dédiée et une puissance de calcul qui ne s’improvise pas pour un billet de blog.

Par contre, sur la démarche on s’en approche

En effet on aurait pu envisager une autre démarche faite de spécifications extrêmement raffinées, de règles écrites par des experts en métadonnées ou en médiation pour définir le mode de pondération qui détermine la proximité entre deux ressources.

….

Mais justement l’approche IA telle qu’abordée dans cette expérimentation est tout autre : il ne s’agit plus de définir et appliquer des règles métiers aussi élaborées soient-elles, mais de partir de la donnée (ou de la métadonnée, ou du plein texte, ou de l’image…) et de mettre en place des processus d’apprentissage de ces données, sans à priori métiers autres que le choix des bonnes variables, afin d’en extraire de la connaissance opérationnelle sur la manière dont les données s’articulent entre elles. Autrement dit d’appliquer une approche déterministe empirique dite “data-driven”, basée sur le postulat fort que les données contiennent intrinsèquement des motifs, des schémas  qui leur confèrent du sens en elles-mêmes. Ici, le bibliothécaire ne détermine pas à priori de critères de ressemblance entre notices mais laisse la main à l’algorithme qui calcule les proximités, quitte à la reprendre pour l’évaluation des résultats.

Il faut tout de même signaler qu’en dehors du champ d’étude très spécifique et plus récent du Deep Learning et des réseaux neuronaux, les algorithmes utilisés en Machine Learning ne sont pas nouveaux, ils reposent sur des méthodes statistiques de régression et de classification éprouvées et conçues pour la plupart au XIXème siècle. Les démarches scientifiques quantitatives traditionnelles, toutes les ‘Data analytics” et autres Business Intelligence (BI) reposent déjà sur ces méthodes statistiques pour transformer la donnée en information.

La nouveauté réside dans l’usage qui en est fait, boosté par la disponibilité de nouvelles masses de données structurées ou pas et croissant de manière exponentielle (y compris pour nous bibliothèques), elle-même rendue possible par le développement des architectures informatiques de stockage et de traitement : pour des humains dont les capacités cognitives sont dépassées par de tels volumes de données, il s’agit de déplacer les processus d’apprentissage et d’automatiser leur ajustement incrémental vers des processeurs et des ordinateurs, afin de :

  1. faire réaliser par une machine des tâches cognitives déjà ou possiblement effectuées par l’humain (indexation, catalogage etc….) mais appliquées à de gros volumes de données ;
  2. en développant des modélisations et en mettant à jour des corrélations dans un but moins explicatif que prédictif (moteur de recommandation qui n’est autre qu’une prédiction de document pouvant intéresser un utilisateur, FRBRisation, probabilité pour un document d’être un jour emprunté ou pas, …)

Ainsi, dans notre environnement de bibliothèque, les algorithmes d’IA nous interrogent dans au moins deux dimensions de nos métiers, sachant que nous bénéficions d’un avantage considérable pour entraîner des algorithmes : la disponibilité de collections de métadonnées riches et structurées issues de notre héritage de catalogage.

notre rôle de producteur de métadonnées par la constitution de collections : quid de l’indexation manuelle quand un algorithme peut être entraîné sur toutes les métadonnées et plus (4ème de couverture) d’une collection pour ensuite pouvoir prédire le bon descripteur à choisir dans un référentiel pour un nouveau document ? Ou encore, comment ajuster sa politique documentaire quand un algorithme pourra prévoir la probabilité pour un document d’être emprunté ou pas en fonction de telle ou telle autre cote que le bibliothécaire décide de lui affecter ?

notre rôle de médiateur de métadonnées : quel futur pour les catalogues de bibliothèques, au-delà des possibilités de moteur de recherche profonde ? L’objectif d’efficacité passera-t-il par la conception d’interfaces personnalisées à chaque utilisateur en fonction de ses caractéristiques, avec des recommandations fortement contextualisées basées sur l’exploitation de ses données d’usage, quitte à formater son environnement de recherche à la mode Google ?

 

Références

Pour une première approche pédagogique et synthétique des différents algorithmes de Machine Learning (et aussi Deep Learning)

Lemberger, Batty, Morel, Raffaëlli, Géron, and Géron Aurélien. Big Data Et Machine Learning Les Concepts Et Les Outils De La Data Science. 2e édition. ed. Malakoff: Dunod, 2016. Print. InfoPro Management Des Systèmes D’information.

Là c’est beaucoup plus chaud

Tufféry, Saporta, and Saporta Gilbert. Data Mining Et Statistique Décisionnelle La Science Des Données. 5ème édition Actualisée Et Augmentée. ed. Paris: Éditions Technip, 2017. Print.

Pour un état de l’art sur les calculs de similarités appliqués aux données textuelles

Elsa Negre. Comparaison de textes: quelques approches…. 2013. ffhal-00874280

Pour manipuler les données et implémenter les algorithmes en Python

VanderPlas, Jake. Python Data Science Handbook Essential Tools for Working with Data. Sebastopol, Calif: O’Reilly, 2017. Print.

Et enfin pour la modélisation de système de recommandations, toute une série de tutos et billets de blog sur le net, notamment sur cette plateforme de blogs

Propositions éparses pour un opac LRM

25/11/2019

La 4e journée du groupe Systèmes & Données de la Transition bibliographique, qui s’est tenue à la BnF le 15 novembre, fut riche d’interventions toutes très intéressantes. Je ne compte pas faire une synthèse complète de cette journée, d’autant que les supports et les vidéos seront prochainement en ligne, mais revenir sur l’une d’entre elles, qui m’a semblé très stimulante : les résultats d’une étude menée par une équipe de l’Abes, et présentée par deux collègues.

Dans le programme, il s’agit de la présentation désignée sous la forme suivante :

  • Etat des lieux international et perspectives sur la visualisation des données (Maïté Roux et Raphaëlle Poveda, membres de l’étude Labo sur la visualisation des données selon LRM, ABES)

Ces deux collègues ont passé en revue un certain nombre d’interfaces de consultations de bases de données FRBR (ou non-FRBR mais utiles pour la réflexion), y compris expérimentales, pour présenter ensuite plusieurs schémas et proposer certaines modalités de navigation dans ce qui serait un catalogue LRMisé.

J’ai trouvé cette présentation particulièrement stimulante parce qu’elle m’a permis de prendre conscience que j’avais une certaine vision des choses. Ou plutôt prendre conscience que, loin d’avoir une vision globale, cohérente d’une telle interface, j’avais certains principes inconscients, qui allaient à l’encontre ou en appui de ce qui était présenté.

Je souhaite donc faire état de ces principes, qui puissent alimenter la réflexion, voire la discussion, pour ceux que cela intéresseraient.

Doit-on tout réinventer ?

Le coût incontestable (humain, financier, psychologique, technique, etc.) de la Transition bibliographique risque de nous donner envie de tout bouleverser côté interface : c’est vrai, après tout, vu les efforts qu’on fait, ce serait dommage qu’à la fin l’interface ressemble beaucoup à ce qu’il y avait avant !

Sauf que c’est oublier deux choses :

  1. il y a un horizon d’attente des lecteurs. Plus exactement, il existe des pratiques extrêmement fortes en terme de recherche d’informations. De ces pratiques découlent des attentes. Ces attentes ressemblent beaucoup à une liste de résultats Google (qui n’est pas seulement une liste à plat de liens vers des documents web)
  2. il faut repartir sereinement des besoins qu’on souhaite combler, des services que l’on souhaite rendre.
    L’objectif d’un catalogue de bibliothèque est de rendre un certain service, pas de donner à voir les efforts accomplis pour concevoir ledit catalogue.

Bref, une interface de recherche (et de résultats) qui ressemblerait à rien de connu serait vite déserté.

En réalité, il faut absolument que :

  • les interfaces à venir soient rapidement réappropriables par les internautes
  • donc qu’elles conservent une continuité ergonomique avec les catalogues existants (enfin, avec ceux qui ne perturbent pas les lecteurs)
  • qu’elles bénéficient de fonctionnalités discrètes mais formidables, qui seraient impossibles avec les données des catalogues actuels

Autrement dit : repartons de ce que nous n’arrivons pas à faire aujourd’hui, qui rendrait tellement service aux lecteurs en recherche d’informations et de documentation, et qui justifient toute la Transition bibliographique.

Pas plus, pas moins.

Un des risques est d’arriver à se faire plaisir avec des résultats très expérimentaux, hyper interactifs, mais complètement déconcertants.

Et n’oublions pas que, même si cette conversion des catalogues demande beaucoup d’efforts, de temps, etc., elle n’est qu’une des dimensions de la Transition bibliographique : l’autre, c’est la diffusion des données sur le web (de données), et je pense qu’il faudra que j’y revienne à l’occasion. Par ailleurs, nous ne transformons jamais que nos catalogues de bibliothèques. Donc une large partie de nos usagers ne se rendra jamais compte que nous avons passé toutes ces années à revoir de fond en comble un outil dont ils ignorent même qu’il existe : ils vont toujours directement voir dans les rayons.

Une recherche dans un catalogue doit rester une recherche documentaire

Pour avoir assuré un certain nombre de formations sur le thème « Web sémantique et bibliothèques », j’ai bien en tête l’enjeu suivant :

Ce qui intéresse les lecteurs, ce sont des oeuvres / auteurs / thèmes ; ce qu’affiche un catalogue, ce sont des documents. Un internaute qui cherchera « Harry Potter » se retrouvera avec 8 pages de résultats, sans manière simple (en 2 ou 3 clics) de préciser le numéro de tome (et éventuellement la langue et le support) de prendre un des exemplaires papier du volume 6, quelle que soit son édition et sa page de couverture.

Bref, in fine c’est quand même bien un document qu’il espère avoir dans ses mains à la fin. Même si son point d’entrée était un auteur (« on m’a dit de lire du Dennis Lehane, il paraît que c’est bien »), il s’attend à trouver des ressources documentaires (livres, DVD, jeux vidéos, peu importe).

Donc si on lui refourgue des entités sous prétexte que c’est ce que contient le catalogue (celui de demain), il va vite être perdu. Autant que celui d’aujourd’hui auquel on ne peut proposer que des notices bibliographiques, c’est-à-dire des produits éditoriaux.

En ce sensdata.bnf.fr n’est pas un bon modèle d’interface de catalogue (j’y reviendrai) : on y trouve sur le même plan des thèmes, des lieux, des périodiques, des oeuvres, des auteurs, des dates.

La liste des résultats doit exploiter ces entités pour faciliter la vie de l’utilisateur (cf. les 5 actions du modèle FRBR : trouver, identifier, sélectionner, explorer, obtenir), mais pas nécessairement afficher ces entités sous prétexte que c’est ce que la base de données connaît. Si ces entités ne facilitent pas les actions ci-dessus, il est contre-productif de les mettre en avant.

Qu’est censé apporter le modèle FRBR à la navigation dans les catalogues ?

Prioritairement, le regroupement par oeuvres des x éditions d’un même roman, d’une même symphonie. Tant que l’interface ne rend pas ce service là, il est inutile d’aller plus loin.

Les regroupements de commune, les intercommunalités se multiplient, elles se dotent d’équipements culturels communs : les réseaux de bibliothèques fusionnent leurs catalogues. On sait tous que la majorité des oeuvres intellectuelles produites par l’esprit humain n’est éditée qu’une fois (thèse, livre d’actualité, roman jamais réédité). Mais les emprunts portent beaucoup sur les gros succès : en lecture publique les romans réédités plusieurs fois en édition de poche ; en bibliothèque universitaire les manuels réactualisés chaque année.

Or dans un catalogue de bibliothèque, et à plus forte raison s’il s’agit d’un réseau de bibliothèques, chaque établissement est susceptible d’avoir une édition différente des oeuvres qui ne cessent d’être empruntées, usées, rachetées, etc.

C’est pour éviter les 8 pages de résultats de Harry Potter qu’on met en place le modèle LRM

Certes, le modèle LRM prévoit plein d’autres choses aussi (les adaptations en film ou pour la jeunesse, etc) mais si cette simple possibilité de mettre sous une notice chapeau toutes les éditions d’une oeuvre n’est pas correctement prévue, le reste me semble bien vain.

Et la tendresse disponibilité, bordel ?

Une fois que toutes les éditions de Madame Bovary sont sous un même en-tête, qu’est-ce qui va m’intéresser le plus souvent ?

  • La bibliothèque de retrait (si le réseau propose un service interne de transport des documents, c’est cool, ce critère là devient indifférent)
  • La disponibilité1 du document
    Une fois que j’ai identifié l’oeuvre qui me convient, je veux pouvoir disposer d’une édition disponible (sans emprunt en cours)

Or, facétieusement, l’Abes et la BnF ne devraient surtout pas servir de modèle pour réfléchir sur une interface LRM, dans la mesure où ni pour l’une ni pour l’autre la notion de disponibilité n’est pertinente : l’Abes ne gère pas les collections qu’elle signale ; la BnF ne prête pas les siennes.

La place des expressions ?

Les expressions nous embarrassent un peu. D’abord, elles n’ont pas d’équivalent auquel se raccrocher dans nos catalogues. Ensuite, conceptuellement elles flottent entre l’acte créateur de l’artiste et l’acte d’accueil du lecteur.

Leur existence dans le modèle LRM, justifiée, est due au fait qu’elles mutualisent la même information pour une série de manifestation. C’est bien la même traduction de Moby Dick par Jean Giono dans ces 4 éditions successives.

Donc il est utile de les gérer dans nos catalogues. Cela ne veut pas dire les afficher en tant que telles : plutôt se demander comment limiter au maximum l’arborescence pour le lecteur qui descend progressivement dans l’arbre FRBR, de l’oeuvre (qu’il a bien identifiée) à l’exemplaire disponible, sans lui imposer la prise de conscience qu’il y a un niveau expression pour parvenir de l’un à l’autre.

Concrètement, pour moi dans la plupart des cas seuls les niveaux Oeuvre et Manifestations seront visibles. Les expressions seront là pour manipuler la liste des manifestations au sein d’une oeuvre.

Si je repars de l’affichage actuel de data.bnf.fr, qui est une bonne interface de navigation quand même, les expressions n’existent pas pour le moment : elles font semblant d’exister dans les données RDF (je peux détailler si ça intéresse quelqu’un), et sont inexploitées dans l’interface web.

Mais si les expressions étaient correctement renseignées, on pourrait envisager une page d’oeuvre sous la forme suivante :

Page actuelle de Moby Dick

Page possible de Moby Dick (du point de vue des expressions, sans parler des adaptations cinématographiques) :

L’ajout des filtres, au dessus de la liste des manifestations, vient directement des expressions, et pourrait être revue pour s’affiner selon les besoins (précision sur le traducteur français, une fois qu’on aurait choisi la langue française), etc.

Je ne suis pas ergonome, donc je ne vais pas trop préciser comment ça pourrait fonctionner sans embrouiller le lecteur. Mais il me semble assurer qu’ajouter une imbrication sera juste fatigant.

Une navigation à plusieurs niveaux

Cela nous amène à une liste de résultats à 2 niveaux :

  • une première recherche qui renvoie une liste d’oeuvres (au sens LRM)
  • quand on clique sur une oeuvre, on arrive sur une page façon data.bnf.fr, avec une liste de manifestations surmontée de filtres, et un ensemble de filtres conçus en fonction des besoins identifiés des lecteurs (suggestion simplifiée : la date de publication sera plus importante en bibliothèque universitaire ; la disponibilité le sera davantage pour la lecture publique)

Moteur de recherche et indexation

Le problème de cette liste d’oeuvre comme premier niveau de réponses, c’est qu’un internaute peut tout à fait chercher un ISBN, ou une combinaison Titre-Auteur-Date. Ainsi un collégien qui doit lire Tristan et Iseut dans la collection Folio Junior (consigne du prof) va fournir des informations relevant à la fois de l’oeuvre et de la manifestation.

Comment cela peut-il fonctionner ?

En terme d’affichage de premier niveau (liste des oeuvres), j’ai une hésitation sur la pertinence à faire apparaître, sous les métadonnées de l’oeuvre (Tristan, Béroul, XIIe siècle) un extrait de la manifestation qui explique l’apparition de l’oeuvre suite à la requête (façon Google) :

En revanche il faut que la manifestation soit bien identifiée comme pertinente suite à la requête parce qu’elle répond à tous les critères (titre de l’oeuvre + nom de la collection). Et que lors de l’affichage de la page Oeuvre, cette manifestation ressorte rapidement (en tête ? en couleur ? les deux ? ).

Comment, pour la première liste de résultats, indexer une telle combinaison Oeuvre + Expression + Manifestation ? Pour l’instant, il me semble que ça nécessite, pour l’indexation, que l’entité réellement manipulée par le moteur de recherche soit (encore) la manifestation : une manifestation enrichie des informations d’expression(s) et d’oeuvre(s).

Sur une requête donnée, le moteur identifie plusieurs manifestations contenant toutes les infos recherchées (que ces infos soient directement dans la manifestation, comme la collection ou le nom de l’éditeur, ou dans le segment expression/langue, ou dans la partie oeuvre/auteur). Ensuite, pour l’affichage, il affiche ces manifestations en les regroupant par oeuvre et en n’affichant que les métadonnées de niveau Oeuvre.

Conclusion

Aucune. Ce sont, je le redis, des idées éparses et sans légitimité particulière du point de vue des compétences. J’espère qu’elles sont cohérentes entre elles mais ce n’est même pas garanti.

Je terminerai tout de même sur une recommandation : aller consulter, dès que ce sera en ligne, la présentation à l’origine de ce billet. Elle contient un tour d’horizon de plusieurs plates-formes de diverses sortes et périmètres, ainsi que bon nombre de propositions très intéressantes.

——————————

↑ 1. Je sais que, notamment dans le monde universitaire, l’année et la mention d’édition importeront aussi. Mais dans les cas où on a affaire à la même expression, l’année et la mention d’édition perdront tout de même une certaine valeur. Et puis comme je travaille depuis 3 ans à la BnF, laissez-moi me préoccuper davantage de la lecture publique

 

IA et opac : mettre en place un moteur de recommandation dans un opac – 3/4 : Expérimentation sur les données du SCD de l’Université de Nice

21/11/2019

Source des données

Nous utilisons au SCD de Nice le SIGB Aleph 500 (v23) de la société Ex Libris, qui est livré avec un module statistique (baptisé « Arc ») à partir duquel on extrait :

  • l’ensemble des notices bibliographiques de monographies d’une des bibliothèques du SCD, précisément la BU Saint-Jean d’Angely qui contient des collections d’économie-gestion, sociologie et médecine, soit environ 33 000 notices  (après les traitements réalisés sur les données décrits ci-dessous) ;
  • tous les évènements de prêts sur des exemplaires de cette même bibliothèque depuis 2015, soit un peu plus de 26 000 lignes de prêts (également après nettoyage), comportant des éléments sur la date du prêt et sur les données bibliographiques (titre, ppn, identifiant interne Aleph), d’exemplaires (indices de cote) et de lecteurs (identifiant anonymisé, catégorie lecteur L1, L2 etc…).

En production un système de recommandations porterait évidemment sur l’ensemble des collections  (un peu plus de 300 000 notices de monographies dans notre cas) et des données d’usage (environ 400 000 prêts depuis 2011), qui alimenteraient qui plus est le modèle en flux continu.

A noter également que l’étape préliminaire d’anonymisation des lecteurs a remplacé les identifiants système par une chaîne non signifiante person_1, person_2… On aurait pu aussi utiliser un mécanisme de hashage qui remplace l’identifiant d’un lecteur par un identifiant complètement opaque : il est impossible, à partir de l’identifiant hashé, de remonter à l’identifiant initial. Mais si ultérieurement on actualise les données en reprenant une nouvelle extraction de la même base de prêt, le même identifiant lecteur donnera le même hash.

Content-based filtering (“Vous pourriez être aussi être intéressé par…”)

Comme expliqué plus haut, ce modèle est basé sur la notion de contexte (la place de chaque document par rapport aux autres dans la collection) et fortement dépendant de la quantité et la qualité des variables prédictives utilisées (ici les champs des notices bibliographiques, indexation en premier lieu).

Manuellement, il faudrait regarder chaque notice et la comparer à chaque autre, pour évaluer la distance pour chaque paire de notice : un auteur commun les rapproche, de même qu’un sujet commun, etc.

Traduction mathématique : il faut calculer un coefficient de similarité pour chaque paire de documents à partir de leurs métadonnées bibliographiques. Pour cela, l’ensemble des notices structurées sont chargées dans un dataframe (un tableau) pour y être préparées (nettoyées et reformatées), puis transformées en représentations vectorielles de comptage d’apparition de termes, vecteurs depuis lesquels on calcule des mesures de distance cosinus (“cosine similarity”).

Tout est là : https://github.com/gegedenice/primo-recommender-system/blob/master/SimilarityModel/contentBased-data.ipynb

On ne souligne ici que quelques brèves remarques, notamment à propos du fait que s’emparer des données avec des outils dédiés à l’analyse statistique de données massives est l’occasion de porter un regard synthétique sur les données agrégées, de repérer immédiatement les anomalies ou les données manquantes dans les notices, ou encore de sortir des consolidations insolites, tout cela en quelques lignes de code aisément reproductibles

Répartition des notices par date de publication PPN manquants Titres homogènes

Concernant la vectorisation des données en fin de processus, on précise qu’il s’agit de convertir des données textuelles en données numériques pour pouvoir ensuite leur appliquer des algorithmes de calculs mathématiques. Pour cela, les champs titre-auteur-indexation déjà nettoyés sont encore reformatés grâce au package Python de text mining NLKT (pour en éliminer les mots vides notamment), puis concaténés en une liste de termes servant à étiqueter chaque document. On peut alors enfin utiliser les fonction CountVectorizer  et cosine_similarity de la librairie Scikit-learn pour :

  • en extrait un dictionnaire de mots ;
  • convertir l’ensemble des listes représentant les notices en une matrice numérique de comptage des occurrences par rapport au dictionnaire, c’est-à dire au final chaque document par une représentation vectorielle du type [1,0,1,1,1,0,1,0,0,0,1,0,0,0,0,…] ;
  • appliquer à cette matrice l’algorithme de similarité par calcul de la distance cosinus entre chaque paire de vecteurs (calcul de l’angle géométrique formé par les vecteurs pris 2 à 2)

Et pour finir construire la fonction Python de recommandations, qui prendra en entrée une variable correspondant au numéro système Aleph et fournira en sortie les numéros des 10 notices les plus « proches ». Implémentée dans un endpoint grâce à la libraire Flask, la fonction est alors appelée dynamiquement par des appels Ajax dans l’interface et produit par exemple ceci :

Collaborative-filtering (“Les lecteurs qui ont emprunté ce document ont aussi emprunté…”)

Ici ce n’est plus la notion de contexte qui importe, mais les comportements passés des utilisateurs. Les similarités entre utilisateurs et entre contenus sont uniquement déduites des usages croisés entre ces 2 ensembles, complètement indépendamment des caractéristiques intrinsèques des contenus en eux-mêmes.

Comme pour l’étape précédente, toute la phase préparatoire est déclinée ici : https://github.com/gegedenice/primo-recommender-system/blob/master/SimilarityModel/collaboraticeFiltering-data.ipynb

Et comme précédemment, c’est aussi l’occasion de manipuler, interroger et visualiser en quelques commandes simples ce que nous disent les données

Répartition des prêts par année Répartition des prêts par type de lecteurs Répartition des prêts par indice de cotes
Répartition des prêts par date de publication  Répartition des prêts par jour de la semaine Répartition des prêts par jour et type de lecteurs

A rapprocher du graphique de répartition des notices (de l’offre) par date de publication : est-ce que l’offre crée la demande ?

A priori pas de corrélation (hors week-end), à affiner sur chaque année probablement

Comme annoncé, on poursuit ensuite avec une nouvelle structuration des données dans une base de données Neo4j, sous la forme d’un graphe constitué d’entités annotées avec des attributs, et connectées entre elle par des relations elles-mêmes taggées.

L’un des gros avantages d’une modélisation de type labeled-property graph est sa nature dite schemaless qui autorise la création de n’importe quel type d’entités et de liens.

Le schéma utilisé et arbitrairement choisi  est donc le suivant :

Une fois les données chargées dans l’instance Neo4j à partir du fichier csv hebergé sur Github avec le reste du code de l’application, voici à quoi ressemble (en partie) le graphe

    • En vert : les noeuds représentant les lecteurs
    • En orange : les noeuds représentant les catégories de lecteur
    • En bleu : les noeuds représentant les documents
    • En rose : les noeuds représentant les indices de cote des documents

La requête pour retrouver, à partir de l’attribut numéro interne Aleph d’un noeud représentant un document, les autres noeuds documents ayant également un lien avec les mêmes noeuds de type lecteur que le document de départ est alors très facile à construire, et la fonction de recommandations par filtrage collaboratif sur la base des usages communs de documents pondérés par le nombre de prêts de chacun donne ceci dans l’interface

L’exploration du graphe, l’étude des métriques de graphe autant que la computation par algorithmes de graphes permet d’aller beaucoup plus loin dans l’analyse des données et la mise à jour de motifs sous-jacents dans la structure des usages d’une collection. Quelques pistes sont proposées dans le Notebook et on conclura ici avec les possibilités offertes par la méthode de projection de graphe et inférence de nouvelles relations : en effet en l’état le graphe est dit k-partite car il contient des sets de noeuds représentant des types d’entités différents (documents, lecteurs, indices de cote, catégories de lecteurs). La notion de projection de graphe permet de créer un nouveau graphe monopartite à partir du graphe initial en créant (inférant) une nouvelle relation virtuelle qui n’existe pas dans les données entre noeuds de même type (en fait, pour rebondir sur les méthodes de factorisation de matrice évoquées plus haut, c’est une autre manière de décomposer une matrice item/user en produit de matrices user/user et item/item, mais dans le cadre d’une représentation en graphe). Dans le cas qui nous occupe, on peut par exemple déduire un graphe projeté ne contenant que des noeuds de type documents reliés entre eux par des liens illustrant un usage commun les mêmes lecteurs, et sur ce graphe appliquer des algorithmes qui révèlent :

  • les ouvrages très connectés (souvent empruntés en même temps) ou à l’inverse peu ou pas connectés (peu ou jamais empruntés par les mêmes lecteurs) : algorithme de centralité degré
  • les communautés de documents (les clusters de documents qui ont un usage commun), qui permettent de dresser une cartographie disciplinaire des usages à comparer avec la cartographie disciplinaire des collections : algorithmes de détection de communauté (algorithme Louvain par exemple)
  • les documents dont l’usage créent des ponts entre les communautés détectées (qui sont des noeuds pivot qui, si on les supprimait du graphe, le rendrait moins globalement connecté) : algorithme de centralité betweeness
  • les similarités (et oui!) entre noeuds : algorithmes de similarité (algorithme cosine similarity ou algorithme Jaccard par exemple)

Tout ceci sera exploré dans un prochain billet à venir.

Ouf !

Le prototype d’interface incluant le système de recommandation est disponible ici : https://ggeoffroy.com/apps/primo-recommender-system (patience ! Le fichier du modèle étant assez lourd, la page peut mettre quelques secondes à se charger).

Le code de l’application et les notebooks sont accessibles sur Github ici : https://github.com/gegedenice/primo-recommender-system

IA et opac : mettre en place un moteur de recommandation dans un opac – 2/4 : Mise en oeuvre technique

13/11/2019

Comment mettre en œuvre un système de recommandations avec des données de collections ?

Une boîte à outils avant de se lancer…

Si l’on s’essaye au développement d’un prototype de système de recommandation intégré au catalogue de la BU articulé sur les deux modèles précédents, voici les éléments nécessaires :

  • une API de recherche donnant accès et restituant les données indexées dans l’Opac :
    elle est fournie par le prestataire du SIGB/Opac ;
  • une interface web adossée à l’API, spécifiquement et sommairement développée pour visualiser le rendu du moteur de recommandation : Il va falloir la développer en interne, même sans trop d’ambition graphique pour commencer ;
  • Pour les recommandations basées sur le contenu des ressources: un jeu de données bibliographiques servant de base aux calculs de similarité de type content-based (pour produire contextuellement au niveau de chaque notice affichée des recommandations de type “Vous pourriez aussi être intéressé.e par …”)
  • Pour les recommandations basées sur les usages: un autre set de données relatives aux évènements de circulation sur ce même corpus de métadonnées, afin cette fois-ci de pouvoir générer des recommandations en mode collaborative filtering de type “Les utilisateurs qui ont emprunté ce document ont aussi emprunté …”

Le langage de programmation Python est aujourd’hui le plus répandu dans l’univers des analyses statistiques et méthodes de Data Science. Plus précisément on pourra utiliser :

  • Pour le retraitement / nettoyage / visualisation des données : les librairies1 Numpy, Pandas, Matplotlib, re pour les expressions rationnelles….)
  • Pour l’apprentissage automatique : la librairie Scikit-learn
  • Pour sérialiser/désérialiser le modèle de recommandation (c’est-à dire le convertir de sa forme d’objet hiérarchisé – Json par exemple – en octets, et inversement) la librairie pickle, et la librairie Flask pour l’exposer sous forme d’API interrogeable depuis l’interface ;
  • Pour écrire et documenter le code : l’application web Jupyter afin de détailler l’ensemble des opérations effectuées sur chacun des datasets.

Une modélisation en graphe

Pour le collaborative filtering (recommandations à partir des usages de prêt/consultation), il est préférable de s’appuyer sur une mise en réseau des données de circulation des exemplaires via une modélisation en graphe. L’approche orientée graphe représente en effet une alternative intéressante aux méthodes classiques d’analyse statistique car :

  • elle permet de produire dynamiquement des recommandations à partir de requêtes simples sur le graphe ;
  • on retrouve avec les algorithmes de graphes les possibilités de traitements et workflows de Machine Learning ;
  • les algorithmes et métriques de graphe sont des approches calculatoires centrées sur les relations entre entités (qu’elles soient explicites dans les données ou inférées dans des projections de graphes virtuels) très puissantes pour révéler des patterns dans les données et extraire de l’information, donc une nouvelle compréhension, à partir de données connectées. A titre d’exemple, on peut calculer pour chaque noeud d’un graphe son degré de connectivité (le nombre de liens entrants et/ou sortant), sa position dans le graphe calculée à partir de sa distance avec tous les autres noeuds, son intermédiarité ou sa propension à jouer le rôle d’intermédiaire entre deux clusters de noeuds etc.. On peut également déterminer des regroupements de communautés de noeuds très fortement connectés, évaluer les plus courts chemins d’un noeud à un autre…

Précision méthodologique utile : on se place également dans un contexte dit de “cold start” (démarrage à froid), c’est-à dire sans connaissance préalable de données propres à chaque utilisateur (leurs historiques de prêts par exemple) permettant de dresser des profils prédictifs et d’individualiser les recommandations, le corollaire étant que les documents recommandés seront les mêmes pour tous. Autrement dit, et concrètement, l’affichage des documents recommandés ne nécessite pas d’authentification préalable de l’utilisateur et les données qui permettraient de profiler les lecteurs ne sont pas utilisées.

La représentation vectorielle

Cette méthode mathématique, très largement répandue en analyse de données textuelles et en Text Mining, est utilisée pour produire les recommandations de type content-based filtering. En effet les similarités entre documents sont issues d’un calcul algébrique de proximité. Or qui dit calcul dit données numériques, alors que nous collectons un ensemble de documents dont les descripteurs sont de type textuel. Pour faciliter leur manipulation, on établit donc une représentation vectorielle de chaque document en lui associant un vecteur mathématique constitué d’indices numériques représentant le poids de chaque mot2 de l’échantillon par rapport à un dictionnaire de référence (en général l’ensemble de tous les mots du set de données).

Chaque document ainsi représenté par un vecteur à N dimensions peut alors être projeté dans un espace vectoriel de dimension N, et des métriques géométriques visant à calculer les ressemblances entre deux vecteurs peuvent être calculées par des calculs de distance.

Dans notre exemple la similarité de type distance cosinus entre deux documents est obtenue en calculant le cosinus de l’angle entre les deux vecteurs qui les représentent, mais il existe d’autres mesures de proximité : coefficient de corrélation Pearson (cosinus de l’angle entre deux vecteurs centrés-réduits), distance euclidienne (distance entre deux vecteurs ramenée à un seul point), coefficient de Jaccard (si chaque vecteur est considéré comme un ensemble : taille de l’intersection de deux ensembles rapportée à la taille de l’union des deux ensembles), etc…

—————————–

↑ 1. En programmation, une librairie (library, qu’on devrait traduire par « bibliothèque ») est un ensemble de fonctions fournies clé en main par d’autres développeur, et dont on peut se servir sans avoir à se demander comment elles fonctionnent.

Par exemple, on peut trouver une librairie Python qui convertira un ISBN 10 en ISBN 13, ou l’inverse, sans avoir besoin de lire la documentation pour savoir comment il recalcule la clé de contrôle.

↑ 2. Plus précisément racine de mot (après stemmatisation)

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 🙂