La lecture d’un article du dernier numéro de Code4Lib m’a remis dans les affres de l’indexation automatique, que j’avais commencé à expérimenter juste avant le Covid, à travers l’outil Annif.
Rappel : aviez-vous oublié Annif ?
Moi, non, même si je n’avais rien écrit depuis avant le Covid. Donc pour rappel, ce billet de décembre 2019 explique de quoi il s’agit.
Et je m’étais retrouvé confronté à un certain nombre de questions, et même de problèmes, insolubles à ce moment-là — j’avais donc un peu tout laissé en plan (en testant quelques trucs en plus, sur les corpus, les modèles, etc.). En outre, j’avais rencontré un blocage technique (une librairie C++ que je n’arrivais pas à installer pour ajouter des options et logiquement de la pertinence à mes résultats)
Parmi les problèmes / questions rencontrées :
- quelles métadonnées utiliser pour entraîner une IA ?
(sachant que dans mes corpus disponibles je considère pour le moment les résumés et textes intégraux comme inaccessibles, jusqu’à ce qu’il soit démontré que s’en passer est impossible)
L’éditeur, le nom de la collection, les codes fonctions, sont-ils des informations utiles ? - comment gérer la dispersion statistique des indexations Rameau ?
l’indexation Rameau est construite, et non sous forme de mots-clés –> chaque chaîne d’indexation est, sinon unique, du moins très peu représentée dans les notices récupérées - comment gérer l’hétérogénéité des notices : dans leur traitement catalographique comme dans leur contenu intellectuel ?
Les notices du XIXe siècle ne ressemblent pas à celles du Dépôt Légal récent ; et leurs sujets ne sont pas non plus les mêmes. En outre, Rameau ayant été créé dans les années 1980, les notices indexées sont surtout postérieures à cette date. Est-il raisonnable d’indexer des notices de 1880 à partir d’une IA entraînée sur des notices d’ouvrages de 2010 ? - quel algorithme de classification/indexation utiliser (Annif en propose plusieurs) ? Et quelles règles de lemmatisation (quand on ramène les différentes variantes d’un mot, en genre et en nombre notamment, à la racine commune) ?
- ne faudrait-il pas plutôt définir des IA thématiques (une pour le droit, une pour les sciences, etc.) qui du coup seraient plus ciblées et potentiellement plus pertinentes ? Mais si oui, d’où viendrait l’information sur la thématique d’une ressource donnée, qui permettrait de sélectionner l’IA compétente ?
Surtout, j’essayais en un seul coup de :
- m’approprier Annif comme logiciel (ou comme solution technique) en devant développer les scripts appropriés pour le manipuler
- comprendre les algorithmes impliqués et sélectionner les « meilleurs »
- traiter un lot de notices et de collections complètement hétéroclites
- obtenir un résultat « définitif », c’est-à-dire des chaînes d’indexation qu’on pourrait injecter directement dans le catalogue
- alors même qu’on est en plein dans la réforme Rameau
C’était déraisonnable.
Simplifions le problème
Du coup, j’ai revu mes ambitions pour avoir des problèmes plus simples à traiter.
Plutôt que d’essayer d’emblée de produire des chaînes d’indexation (objectif qui correspondait à mes missions à la BnF : travailler à l’amélioration des données existantes dans le catalogue), j’en reviens à une démarche plus expérimentale :
- s’approprier Annif comme logiciel de traitement
- essayer de générer simplement des mots-clés pertinents (donc associer des documents à un ou plusieurs concepts Rameau), sans se préoccuper de construire d’emblée des chaînes d’indexation :
cela permet notamment de ne pas devoir respecter une certaine syntaxe ; et d’atténuer les problèmes de dispersion statistique (trop faible représentativité dans les données d’entraînement, donc les document eux-mêmes, de chaînes d’indexation trop peu utilisées en combinaisons) - au lieu de partir d’une extraction de notices bibliographiques, partir des notices Rameau pour récupérer des cas d’utilisation en nombre suffisant pour chacune des notices :
c’est là une révélation toute bête de la lecture de l’article de Code4lib mentionné plus haut. Plutôt que d’extraire un lot de XXX.000 notices et d’y trouver plein de concepts trop peu représentés, je pars de la liste des concepts, et je cherche à récupérer 5 à 10 notices bibliographiques qui leur soient liées.
Donc je recentre sur :
- mieux comprendre l’outil
- voir à quelles conditions on peut l’utiliser pour obtenir une indexation simple (sous forme de mots-clés)
Sérions le problème
Comme je l’évoquais, j’imagine (hypothèse de travail) que l’indexation sera plus pertinente si on indique déjà à l’IA la thématique concernée.
Pour le dire autrement, j’envisage de concevoir et d’entraîner une IA par discipline (ou par département thématique de la BnF, j’hésite encore) : chacune de ces n IA aura donc un nombre moindre de mots-clés à prendre en compte (on va considérer que la théorie quantique est peu présente au département des Lettres, même s’il y évidemment des contre-exemples.
Cela veut dire que pour chaque document, j’aurai par exemple le choix de l’indexer avec les propositions de chacune des n IA thématiques, chacune spécialisée dans son domaine :
Par exemple si le titre contient le mot fatigue, on a affaire à deux grandes sémantiques : la fatigue des métaux (leur endommagement sous certaines contraintes), et la fatigue pour les êtres vivants. Et en fonction des termes du référentiel rencontré dans les données d’entraînement, Annif va me proposer plusieurs termes d’indexation, avec des statistiques de probabilité.
Mais le fait de savoir que le livre relève des Sciences, techniques et médecine, ou du département Droit, économie, politique, orientera le choix de l’IA « Sciences & techniques » (entraînée à partir des collections de ce département) ou de l’IA « Droit, éco, politique » (entraînée de même). Et pour chacune de ces IA, la probabilité de choisir la plante ou le logiciel n’est pas la même.
On peut supposer une situation de ce type :
- Sur une IA générique, un titre comme Théorie de la fatigue se verra attribuer par Annif :
- Matériaux — fatigue : 85%
- Epuisement professionnel : 62%
- Fatigue (épuisement) : 77%
- Mais si on a déterminé au préalable l’information sur le département :
- sur une IA Sciences, techniques & médecine :
- Matériaux — fatigue : 92%
- Epuisement professionnel : 22%
- Fatigue (épuisement) : 88%
- sur une IA « Droit, éco, politique » :
- Matériaux — fatigue : 5%
- Epuisement professionnel : 95%
- Fatigue (épuisement) : 58%
- sur une IA Sciences, techniques & médecine :
Mais pour cela, il faut d’abord savoir si la ressource relève de tel ou tel département. Or au moment du catalogage cette information n’existe pas encore (dans le cas du Dépôt légal, par exemple) : en revanche elle peut elle même faire l’objet d’un calcul de classification avec une autre IA préalable (entraînée grâce à Annif aussi) :
On aurait donc une première étape d’attribution à un certain département, avec un calcul de probabilités : 55% Sciences, techniques et Médecine ; 90% Droit, économie, politique. Et selon la branche choisie, l’indexation retenue. Cette indexation finale se fait donc sous condition de la première classification.
C’est précisément (bon, pour ce que j’en ai compris) le principe du bayésianisme en calcul des probabilités : calculer la probabilité de X sachant Y1.
Il s’agit ici, dans un contexte de catalogage, d’enchaîner les choix successifs de classification et de s’appuyer dessus pour prendre les décisions suivantes.
- Si on ne sait rien de plus que son titre, il est assez probable (85%) que cet ouvrage Théorie de la fatigue porte sur la fatigue des matériaux.
- Si on sait que l’ouvrage relève des sciences, techniques et médecine, il peut autant porter sur les matériaux que sur la physiologie (ou les psychopathologies)
- Si on sait que c’est un ouvrage de droit, économie, politique (parce que l’éditeur est plutôt spécialisé en droit du travail), alors il y a de fortes chance que ce soit un ouvrage portant sur l’épuisement professionnel
On pourrait donc envisager une indexation automatisée comme une succession de décisions, que le catalogueur valide et ou l’étape suivante est recalculée en fonction des choix réalisés.
Mais ça vaudrait aussi le coup de considérer la probabilité de chacun des termes finaux au regard de la probabilité des choix précédents : il y a une formule pour prendre en compte l’inférence bayésienne qu’on étudiera (peut-être ?) une autre fois.
Pourquoi ça peut ne pas marcher
L’idée me semble très séduisante, suffisamment stimulante pour m’inciter à remettre le nez dans toute cette question. Néanmoins il y a plusieurs facteurs d’échecs possibles (et je suis incapable dans évaluer les probabilités…) :
- manque de temps pour concrétiser ce beau rêve (mais si vous vous sentez de le faire, ne vous en privez pas !)
- incompréhension complète de ma part du modèle bayesien et des manières correctes de s’en servir.
Ou en plus vicieux : l’hypothèse initiale pourrait être pertinente (concevoir l’indexation matière comme une succession de choix à décomposer) mais en identifiant mal les étapes ou le bon ordre de leur enchaînement fait foirer les résultats obtenus (et décourage le chaland). - métadonnées disponibles insuffisantes ou mal utilisées (je reste tributaire de notices, alors que souvent les algorithmes d’indexation travaillent sur du texte intégral, ou au moins des résumés et/ou tables des matières
Bon, si ça s’avère infructueux, au moins entre temps j’aurai remis les main dedans, réfléchi de nouveau à la question préalable de la lemmatisation (qui est le sujet de l’article cité plus haut, et qui rend compte d’un travail comparatif très intéressant sur différents algos existants), etc.
Pourquoi ça peut marcher
- Parce que la démarche me semble avoir une certaine cohérence quand même
- Parce que je me suis donné une ambition moindre (des données simplifiées, on n’essaie pas de produire du Rameau pour l’instant !)
- Parce que je vais me doter d’outils mieux conçus pour suivre mes expérimentations
Il y a deux ans, j’accumulais les fichiers de données, les fichiers de prise de notes (sous Evernote, ou avec des documents de type readme.md, etc.) et des scripts Python enrichis de plus ou moins de commentaires pour expliquer la démarche.
Comme je pars d’emblée sur une hypothèse d’architecture plus complexe, avec plusieurs IA qui ne sont pas en concurrence, ou ne sont pas des versions successives les unes des autres mais doivent fonctionner en parallèle au sein d’un même dispositif, je vais d’emblée élaborer :- une table de correspondance qui, pour chaque IA, fournit le code et un descriptif de son contenu (pour pouvoir s’y retrouver)
- un notebook qui documente les étapes
Ah oui, il faudra que je vous parle des notebooks [update : c’est fait], ces petits (ou grands) documents merveilleux pour architecturer un peu plus efficacement ce genre de projet, en mélant plus harmonieusement code, données et paratexte.
Et puis un petit billet sur ce sujet des notebooks me permettra de procrastiner le billet suivant concernant l’indexation automatique !
1. Pour avoir un aperçu du bayesianisme, vous pouvez par exemple regarder cette vidéo de Monsieur Phi (2016) : La loi de Bayes (1/2), voire la seconde : La loi de Bayes (2/2) (qui est très éloignée des questions d’indexation, mais est sympa quand même).
Je sais que j’ai laissé passé quelques années, mais pour cette fois-ci j’ai refait une carte des postes proposés au mouvement sur Poppee depuis 2 jours :
Au passage, vous y trouverez un super poste, vers lequel évidemment je ne peux pas pointer sur Poppee.
Mais il se trouve ici, et bien mieux détaillé : le Département des Métadonnées de la BnF vous tend les bras !
making-of : j’ai dû déplacer quelques adresses pour éviter les chevauchements de bulles, que Google ne gère pas très bien. Je n’ai pas non plus vérifié une à une si les adresses des SCD correspondaient aux adresses des BU d’affectation. Mais je trouve que ça donne quand même une petite idée :
Vers une ontologie pour RDA-FR
Début juillet a eu lieu, comme cela se produit 2 fois par an, une journée de réunion pour les membres de tous les groupes (Normalisation, Formation, Systèmes & Données) de la Transition bibliographique. A cette occasion a été annoncée un ensemble d’actions dont certaines gravitent autour du projet de Fichier national d’entités (FNE), et qui pourraient infléchir la dynamique de la Transition bibliographique dans les douze prochains mois :
- La conception d’un « pilote pour le FNE », c’est-à-dire d’une application fonctionnelle permettant de tester le version, la fusion, la gestion de données communes à l’Abes et la BnF, en commençant par les entités Personnes physiques
- La conversion en site web des chapitres déjà publiés (en PDF) de RDA-FR : il y a actuellement 6 PDF, représentant environ 1200 pages, et la totalité du code pourrait bien représenter dans les 2000 pages à terme. Bref, il faut en faire un ensemble de contenus (navigable sous forme de site web), un jeu de règles, un dictionnaire de données (terme utilisé pour évoquer RDA, lors de la dernière conférence annuelle de l’ALA), bref, quelque chose de plus adapté aux usages du web.
A l’issue de la conversion de l’existant, l’idée est bien ensuite de maintenir un site web qui accueillera directement les textes ultérieurs, sous forme de nouvelles pages et nouvelles rubriques. - La constitution d’une ontologie pour RDA-FR, en commençant, là aussi, par les agents Personnes physiques
Cette dernière annonce a suscité quelques questions qui laissent entendre des risques d’incompréhension sur :
- ce que va être cette ontologie RDA-FR, concrètement
- à quoi ça va servir ?
- comment elle va co-exister avec les PDF disponibles sur le site transition-bibliographique.fr, et avec le futur site web : l’ontologie va-t-elle remplacer les PDF, etc. ?
Avant de développer ces questions, je vous propose d’aller faire un tour du côté de nos collègues et amis archivistes, pour voir comment coexistent, pour le modèle de données RiC, une documentation en ligne et une ontologie comparable à ce qu’on vise pour RDA-FR.
Qu’est-ce que RiC ?
RiC (Records in Contexts) ne se situe pas sur le même plan que RDA-FR, mais est plutôt un équivalent de IFLA LRM. Il décrit les types d’objets qu’on trouve dans les collections d’archives, leurs propriétés, les relations diverses qui les lient aux acteurs qui les produisent, y sont mentionnées, etc.
Ce modèle est décrit en langage naturel (en texte, quoi) et se présente sous la forme d’un PDF sur le site de l’ICA (International Council of Archives).
Ce même modèle est également exprimé sous la forme d’une ontologie, baptisée RiC-O, dont vous pouvez trouver :
- une présentation ici (texte en français d’environ 1 page)
- une documentation plus complète (texte en anglais d’environ 50 pages)
- le fichier même de règles, sous forme de triplets RDF
Ce fichier reprend les éléments d’information essentielles du PDF pour les exprimer en triplets, afin que des programmes puissent les manipuler
Cette ontologie dispose également d’un espace de nom (je reviendrai sur cette notion) : https://www.ica.org/standards/RiC/ontology#
L’ontologie vient donc compléter, selon une modalité plus technique, le PDF qui, tant qu’on en reste à ce stade de la définition d’un modèle, n’est encore qu’une vue de l’esprit, c’est à dire non implémentable directement au sein de programmes informatiques.
On y trouve par exemple le code RDF/XML suivant :
Qui est une manière (XML) d’écrire un ensemble de triplets pour définir et caractériser la classe « RecordResource » (définition fournie : ressource, ensemble de ressource ou partie de ressource produite ou acquise par un agent durant son activité) dont la version « graphique » donne :
Parmi les triplets, il est dit aussi que cette classe d’objet est décrite dans le PDF du modèle sous l’appellation « Record Resource », identifiée par le numéro RiC-E02 dans le tableau listant les entités définies par ce modèle) et qui est décrite au paragraphe 2.2.2, page 25 du même PDF.
Qu’est-ce qu’une ontologie ?
Une ontologie, dans le sens du projet évoqué, est un fichier ou un ensemble de fichiers ou de fiches (gérées par base de données)
- utilisant un langage informatique structuré (ici, OWL, donc une liste de triplets RDF), donc selon un mode qu’un programme informatique peut manipuler
- décrivant une liste de types d’objets, des attributs, des propriétés qui lient entre eux ces types d’objets.
Exemple de liste de types d’objets : mobilier, bibelot, livre, œuvre d’art, électroménager, appareil électronique
La liste ci-dessus (qu’il faudrait encore rallonger, évidemment) permet de décrire le contenu d’un appartement, en rattachant chaque objet trouvé à un de ces types.
Dès lors qu’un objet trouvé se voit rattaché à un type, cela induit que certaines informations sont attendues pour le décrire, soit obligatoires, soit facultatives.
On peut envisager des liens entre ces types d’objets (ça s’y prête assez mal ici), ou des liens vers des types d’entités tierces : par exemple, dans le cadre d’une succession, on associera chaque objet à un des héritiers. Donc on peut identifier là deux propriétés qui seront communes à tous les objets :
- (objet) a appartenu à (personne)
- (objet) est destiné à (personne)
Entre parenthèse, le type (ou « classe ») qu’on s’attend à trouver de part et d’autre de ces propriétés. Comme ces propriétés (ainsi que d’autres) peuvent s’appliquer à tous les objets, on va définir une classe particulière englobante, appelée « Objet », dont on va dire qu’elle permet d’exprimer toutes les propriétés communes, qui sont applicables aux meubles, livres, objets d’art, etc.
Toutes les informations qui précèdent sont lisibles par vous (en tout cas j’espère !) mais pas par une machine. Par exemple, une fois récupéré le tableau qui me fournira la liste des objets et leur destinataire, je ne pourrai pas contrôler les aberrations éventuelles (deux personnes héritant du même objet, par exemple).
L’ontologie est donc là pour définir les règles qui vont structurer l’information. Le descriptif ci-dessus est utile pour les êtres humains, l’ontologie sera utilisée par un programme, qu’il va confronter aux données pour vérifier qu’elles s’y conforment.
En amont des contrôles, on peut aussi imaginer un programme qui va s’appuyer sur ce fichier contenant les classes d’objets, leurs propriétés et les différentes règles, pour élaborer une application utilisateur afin d’alimenter les données en évitant les aberrations.
Et donc, une ontologie RDA-FR ?
Comme je l’ai évoqué plus haut, l’Abes et la BnF doivent faire développer dans les prochains mois un « pilote FNE », c’est-à-dire une application (une base de données avec des programmes qui tournent dessus, dont une interface qui doit permettre de manipuler ces données1) qui va implémenter le code de catalogage RDA-FR, du moins la partie Personnes & identités publiques pour commencer.
Pour que ce soit possible, il faut que les règles décrites dans le PDF du chapitre 9 (« Identification des personnes ») soient interprétables et utilisables par un programme.
Chaque application a sa manière de gérer les règles à appliquer aux données qu’elle gère. Mais il y a des standards pour exprimer ces règles, de manière à pouvoir aisément les convertir dans des formats plus spécifiques pour les implémenter dans chacune des applications qui va vouloir les utiliser.
Parmi ces modalités standards de décrire des règles sur les données, l’ontologie exprimée en RDF/OWL fait plus ou moins partie des incontournables.
Donc concrètement, le travail va consister à ouvrir le chapitre sur les personnes, et repérer les informations qui trouveraient leur place dans une ontologie.
- la liste des éléments d’information permettant de décrire une personne, et leur caractère obligatoire, non obligatoire, exclusif, réciproque, etc. sont des choses qui seront à intégrer dans le fichier RDF
- les exemples, j’imagine, n’en font pas partie (et ils sont nombreux dans les chapitres RDA-FR)
- des questions se poseront certainement sur d’autres types d’information :
par exemple les déclarations d’équivalence entre un élément RDA-FR et celui qu’on trouve dans RDA
Comme toute cette transposition d’information ces règles se fera sous forme de triplet RDF, cela veut dire que dans la composition des sujet-verbe-complément, les sujets et les verbes seront des triplets.
Par exemple, au lieu de dire : « Pour les agents de type Personne, on peut préciser la langue (ou les langues) d’expression qu’elle utilise pour produire les ressources qui lui sont associées », l’ontologie va dire :
(ces triplets sont des exemples non contractuels !)
<url.fr/personne> rdfs:subClassOf <url.fr/agent># Dans la classe Agent, on trouve des sous-classes Personne<url.fr/langueDeLaPersonne> rdf:type rdf:Property# langueDeLaPersonne est une propriété<url.fr/langueDeLaPersonne>rdfs:label "Langue de la personne"# un libellé pour cette propriété<url.fr/# Le sujet d’une « langue de la personne » sera une personnelangueDeLaPersonne<url.fr/# l’objet d’un tel triplet sera une chaîne de caractères (si la valeur attendue est « français ». Si on veut une valeur comme http://id.loc.gov/vocabulary/iso639-2/fre, il faudra le préciser autement)langueDeLaPersonne<url.fr/# on peut trouver 0 fois cette propriété pour une personne (donc cette information est optionnelle)langueDeLaPersonne
Les écritures owl:, rdf:, et rdfs: sont des raccourcis pour ne pas écrire l’intégralité de l’URI qui identifie chacune de ces propriété.
De même le « url.fr » sera remplacé par la vraie URL racine qui sera utilisée pour définir les différents objets décrits dans l’ontologie RDA-FR, afin de construire des URI qui permettront de les identifier de manière univoque sur le web (de données). C’est la notion d’espace de nom.
Autre aspect : que l’URI contienne un libellé « nettoyé » de la propriété, ou un identifiant interne alphanumérique (« F12 », « C25 ») permettant d’anticiper les cas où les propriétés ou autres types d’objets seraient amenés à changer de nom : avoir une URI <bibliotheque.fr/langueDeLaPersonne> et un libellé « Autre nom » peut être un peu dérangeant.
Conclusion
La constitution d’une ontologie vient donc compléter logiquement la rédaction du code de catalogage RDA-FR, pour pouvoir l’utiliser pleinement dans les (futures) applications. Faute d’une telle ontologie, ça impose par exemple aux éditeurs de SIGB de faire, chacun, l’extraction et la transposition des différentes informations qui sont présentes dans les chapitres publiés, mais en mode humain, trop humain.
Cela n’enlèvera probablement pas la transposition nécessaire de ces règles, dans le système de formalisation de règles propre à chaque SIGB, mais en ayant une conversion à faire à partir de règles déjà formalisées.
Remarque : de même que la seule traduction d’IFLA LRM en français avait été l’occasion d’y relever des incohérences qui ont occasionné ensuite une mise à jour du modèle initial, de même, il n’est théoriquement pas exclu que la transposition d’informations en ontologie OWL mette à jour des besoins de mise en cohérence, d’harmonisations, etc. dans les chapitres RDA-FR publiés.
—————————————
1. « une interface qui doit permettre de manipuler ces données » n’est pas nécessairement un site web fonctionnel. Cela ne dit rien de la partie Administration, gestion, ou éventuellement publique d’une telle application. Mais il faut bien pouvoir accéder à ces données autrement qu’en utilisant le langage SQL
Si on leur pose la question (« A quoi sert la Transition bibliographique ? »), je crois que de nombreux collègues répondront :
- ça sert à rendre visible les catalogues
- voire : ça sert à les mettre sur le web de données
Cette réponse est à la fois correcte, insuffisante et frustrante.
Et j’ai l’impression qu’il y a un grand malentendu sur la raison pour laquelle on a engagé cet énorme chantier de la Transition bibliographique, et ce que ses porteurs voyaient derrière cette supposée « visibilité des catalogues ».
(Je reprécise par ailleurs que je rends compte de ma seule compréhension des choses, et que chaque article publié ne me semble que le brouillon de ce qu’il devrait être…)
Mon idée ici n’est pas de tant de questionner le modèle IFLA LRM (son contour, ses possibilités, etc.), mais d’expliquer ce qu’on peut entendre (ou pas) par « mettre les catalogues dans le web de données ».
Publier ses données sur le web, c’est facile
Il y a 15 ou 20 ans, on a constaté que les moteurs de recherche savaient naviguer d’un lien à l’autre pour découvrir des contenus, mais ne savaient pas interroger une base de données (qui existe sous la forme d’un formulaire de recherche) trouvée sur un site web, pour en récupérer les contenus (sous forme de pages de listes de résultats).
Le contenu de nos catalogues étaient donc ignorés de Google !
La bonne nouvelle, c’est que le problème ne concernait pas que les bibliothèques et leurs catalogues, mais toutes les bases de données accessibles uniquement par formulaire de recherche : donc des technologies se sont mises en place pour résoudre le problème. Une des plus simples est la sitemap : si pour chaque notice vous pouvez donner un lien pérenne (calculé généralement à partir du numéro de notice : http://catalogue.bibliotheque.fr/numero_de_notice — en plus ou moins compliqué), alors vous pouvez extraire la liste des numéros de notices, les convertir en liste d’URL, et publier cette liste dans un fichier à un endroit que les moteurs de recherche sauront trouver.
Donc pas besoin de « transition bibliographique » pour donner à Google la liste de vos documents.
Est-ce pour autant satisfaisant ? Si un internaute cherche sur Google Premier sang (le dernier roman d’Amélie Nothomb, pour le moment), est-ce un service à lui rendre que de peupler les 10 premières pages de résultats de notices de catalogues alimentés par des bibliothèques où il n’ira jamais ?
Publier ses données sur le web de données, c’est faisable
De même qu’on peut rendre un catalogue de bibliothèque indexable à moindres frais (mais pour quels services ?), on peut exposer ses métadonnées selon les technologies du web de données (aka en RDF) sans s’embarrasser d’une quelconque Transition bibliographique.
La preuve ? Le Sudoc le fait déjà :
- Prenez une notice au hasard (par exemple Premier sang)
- Récupérez son permalien : https://www.sudoc.fr/257041745
- Ajouter .rdf à la fin : https://www.sudoc.fr/257041745.rdf
- vous obtenez l’équivalent de la notice bibliographique, exprimé en RDF : donc pour une ressource décrite comme un Document (au sens de l’ontologie bibo) avec la plupart de ses métadonnées/attributs/propriétés : titre, auteur(s), date, éditeur, etc.
(toutes les métadonnées de la notice Unimarc n’y sont pas, mais on peut considérer que pour le web, c’est suffisant)
Cela demande un travail de conversion, donc de modélisation (comment exprimer chaque zone ou sous-zone selon ce procédé par triplets ?) mais la « Transition bibliographique » (telle que définie à ce stade) n’a rien de nécessaire.
Mais on sait que la Transition bibliographique, c’est plus que « mettre ses données sur le web » (même de données) : c’est l’implémentation du modèle IFLA LRM et d’un nouveau code de catalogage, RDA-FR, par la même occasion. Mais sont-ce là des moyens ou des objectifs ?
Publier ses données comme catalogue sur le web
Quand on parle de mettre ses données sur le web, un des malentendus implicites risque d’être le rêve du service suivant : une bibliothèque, localisée dans une ville, « expose ses données » afin d’être indexée par Google.
Un internaute cherche le titre du livre
et se voit proposé l’emprunt dans la bibliothèque près de chez lui
D’abord, cela signifie que l’internaute est d’accord — et apprécie — d’être géolocalisé (d’accord, il l’est déjà de toute façon, mais dans notre profession on est traditionnellement sensible à la protection des données personnelles, et potentiellement contre les mécanismes de bulle de filtre).
Ensuite, il faut pour cela :
- que Google géolocalise votre catalogue et considère qu’il est proche du lieu de l’internaute
- qu’il indexe la notice « Premier sang » dans votre catalogue
- qu’il soit capable d’associer la notice « Premier sang / Amélie Nothomb » avec l’oeuvre textuelle (au sens LRM) qui est présente par ailleurs dans son graphe (cf. la copie d’écran d’autocomplétion ci-dessus)
Or l’identification d’une oeuvre livre identifiable par son titre (Premier sang) et son auteur (Amélie Nothomb) est quelque chose que Google sait manifestement déjà faire, et sans avoir eu besoin d’implémenter LRM : cette oeuvre est dans son knowledge graph.
A la place, très vraisemblablement, il se contente de schema.org et du type de ressource « Book« .
Pour rejoindre ce graphe et y associer vos données, il faut donc qualifier typer vos notices de livres de https://schema.org/Book, en y associant nom, titre, et ISBN (selon cette même ontologie).
Et bien sûr, de se mettre d’accord avec Google pour qu’il les exploite comme vous pensez qu’il va vouloir le faire : car rien n’est moins sûr, votre service n’est pas pour lui une source de revenus.
Bref, pour obtenir que Google soit utilisable comme catalogue de votre bibliothèque, il serait peut-être plus efficace que le Ministère de la Culture ou la BnF travaillent avec Google pour voir ce qui est faisable, plutôt que d’implémenter la Transition bibliographique. D’ailleurs, OCLC et Google ont déjà travaillé dans ce sens, avec les données des catalogues existants.
Mais est-ce vraiment ce qu’on recherche, et tout ce qu’on recherche ? A-t-on besoin de la « Transition bibliographique » pour cela ? (oui, cette question m’obsède)
Ou alors on cherche à obtenir autre chose : en ce cas, autant l’expliciter.
Publier ses données sur le web, et oublier son catalogue
Quel est le service rendu à l’internaute que de lui mettre en avant, au sein des résultats d’un moteur de recherche, des informations issues des catalogues de bibliothèque (il faut aussi considérer que « le web » ne se limite pas aux moteurs de recherche, même si la perspective de se mettre sur le chemin des internautes fait bien partie des enjeux). On peut supposer qu’à la toute fin, il peut être utile pour lui d’accéder à un document précis, mais l’approche « données » d’un catalogue de bibliothèque consiste avant tout à considérer les métadonnées comme une information utile en soi.
En réalité, quand on prétend mettre ses données sur le web (de données), cela implique que le niveau d’information mis en ligne, c’est bien la donnée elle-même, l’élément d’information — que vous soyez le seul à le connaître (« Ma bibliothèque possède cet exemplaire ») ou des milliers (« Dostoïevski a écrit Les frères Karamazov« ).
Quel est le bénéfice attendu ? Qui en est bénéficiaire ?
Qu’est-ce que ça signifie de considérer le web comme une énorme base de données (au sens ou un SIGB est une petite base de données) dans laquelle on puisse (comme dans un SIGB) manipuler l’information ?
Cas d’usage : pour une œuvre donnée, les catalogues sont une source parmi d’autres permettant de connaître la liste des traducteurs qui l’ont successivement traduite. Mais pour ça il faut évidemment identifier que les 3974 notices éparpillées dans nos différents catalogues relèvent bien de la même œuvre, et que toutes ces notices contiennent des zones 700 dont le $4 a comme valeur 730. Il faut aussi dédoublonner la liste des traducteurs, dont les noms peuvent être parfois saisis de manière différente tout en désignant les mêmes personnes.
Cela implique que, dans tous les SIGB qui possèdent cette même oeuvre (à travers ses ISBN successifs), les notices soient identifiées comme relevant de la même oeuvre, que l’on puisse identifier les 2952 mentions de traducteurs comme 25 personnes distinctes, et que l’auteur est bien le même.
Dans les différents processus qu’englobe la Transition bibliographique, on est parfois tenté de se focaliser beaucoup sur la construction des arbres Oeuvre-Expression-Manifestation-Item, alors que l’adoption des mêmes identifiants (ARK, IdRef, ISNI, ID Wikidata, etc.) a au moins autant d’importance. Surtout la construction d’arbres OEMI impeccables serait inutile si on n’utilise pas dans le même temps des identifiants communs : car nos catalogues ne seraient alors pas plus qu’avant reliés entre eux et au web…
Le bénéfice pour les bibliothèques de lecture publique ?
Eh bien… au regard de leurs missions traditionnelles, le fait de mettre ses données dans le web n’a pas d’intérêt évident ni immédiat.
Le « bénéfice » essentiel est de contribuer à un projet commun de la profession, pour lequel la participation de tous est indispensable (sinon, ça semble très vain), de participer à l’émergence d’une nouvelle offre pour de nouveaux publics. Ces publics ne sont logiquement pas leurs publics traditionnels, leur communauté dont l’existence justifie le budget qu’ils obtiennent annuellement.
Mais cette participation à une entreprise collective n’est pas forcément un frein : de manière générale, l’apparition du web a brouillé les frontières dans les publics desservis par les professionnels des bibliothèques. Toutes les actions de médiation en ligne, à commencer par les services de questions-réponses en ligne, ne sont généralement pas limitées à la population desservie par les espaces de lecture.
Néanmoins le bénéfice immédiat, tel qu’on puisse en rendre compte à une tutelle, est complexe. C’est pourquoi un des enjeux de réussite de cette Transition est de parvenir à en minimiser autant que possible le coût pour la plus grande partie des établissements, afin de la rendre plus acceptable :
- processus de migration des données le plus simple possible
- accompagnement des éditeurs de SIGB pour qu’ils adaptent leurs offres
- description du futur travail de catalogage (formation, documentation, circuit de traitement)
Ce qui correspond assez bien aux travaux du groupe Systèmes & données, finalement (ça tombe bien !)
Plot twist : en revanche, les données des autres bibliothèques…
Quel intérêt pour une bibliothèque de dépenser de l’énergie (et pas seulement) à mettre en ligne ses données ? A bénéficier des données des autres.
Comme on parle d’exposer les données sur le web, cela signifie penser et manipuler le catalogue à l’aune du web. Mais le lecteur de la bibliothèque est aussi un internaute qui a accès à autre chose : autres bibliothèques, autres ressources en ligne.
Vous pouvez très bien posséder le roman Le château de Hurle de Diana Wynne Jones, sans avoir pour autant Le Château ambulant de Miyasaki ? Logiquement (si tout est bien fait), dans le graphe des données, l’information liant ces deux oeuvres existera. Et il vous est possible de la récupérer, à condition d’être lié à ce graphe. Il peut être utile de l’afficher, quand bien même vous n’avez que l’une des deux (ce qui marche aussi dans l’autre sens : un lecteur vous ayant emprunté le dessin animé sera content d’en apprendre plus sur sa source, voire vous demander de l’acheter. Mais vous pouvez aussi considérer qu’il cherchera sur Wikipedia, ce qui n’est pas déshonorant : mails tout n’est pas et n’a pas vocation à être dans Wikipedia ; et Wikipedia a aussi besoin de sources).
Penser l’accès aux œuvres de l’esprit au-delà des collections de la bibliothèque est un vrai enjeu en terme de services, mais c’est bien aussi une promesse du web de données pour les bibliothèques : faciliter la porosité entre la bibliothèque et le monde extérieur.
Au-delà de la « diffusion des données sur le web » ?
« — A quoi sert la Transition bibliographique ? — A mettre son catalogue sur le web (de données). »
En réalité cette réponse est correcte. Elle est même plus rigoureuse et plus satisfaisante que « elle consiste à basculer son catalogue dans le modèle IFLA LRM tout en adoptant le nouveau code de catalogage RDA-FR ». Cette seconde réponse est plus technique, mais ne fournit que le moyen, et non la finalité.
Ce qu’on n’a pas du tout expliqué jusque là, c’est l’articulation entre les deux :
- Si on veut simplement mettre ses données sur le web, pourquoi IFLA LRM ?
- Si on veut convertir son catalogue en LRM, en quoi est-ce associé au web de données ?
(je rappelle que IFLA LRM est héritier direct de FRBR, écrit dans les années 1990, alors que la première promesse du web sémantique date de 2001)
En outre, plus on instruit et réalise la Transition bibliographique, ou des expérimentations autour de ce modèle, et plus on a envie d’exploiter soi-même, pour le bénéfice de sa bibliothèque et de ses lecteurs immédiats (et pas juste en espérant que des internautes ou des moteurs de recherche le fassent) des données LRMisées.
Implémenter un catalogue utilisant le modèle IFLA LRM a beaucoup d’autres implications, dont certaines sont soupçonnées, et d’autres pas même encore imaginées. Cela brouille peut-être d’ailleurs la lisibilité de la Transition bibliographique :
- au départ, l’enjeu majeur était de rendre visibles, exploitables les données des bibliothèques aux acteurs du web (cf. les premières pages du rapport du Comité stratégique bibliographique de novembre 2012) ;
- pour cela, le modèle FRBR (devenu IFLA LRM) a été identifié comme la solution la plus adaptée (c’est un point sur lequel il faudra que je revienne, mais une autre fois) ;
- mais à présent que la cible est LRM, on a envie de pouvoir faire plein d’autres choses impossibles précédemment.
Ce qui nous fait une seconde cible apparue entre temps.
Un des autres axes du travail du groupe Systèmes & Données est justement d’identifier les initiatives, et de réfléchir aux potentialités, de l’implémentation du modèle IFLA LRM dans un catalogue en termes de services.
On trouvera encore dans les prochaines années, d’autres bénéfices à disposer d’une structuration des données beaucoup plus modulaire et granulaire que ne le sont les catalogues actuels. Mais ce n’était pas le sujet du présent billet (qui ne portait pas sur l’intérêt du modèle IFLA LRM, mais bien sur la question de l’exposition des données).
En outre, la mise en balance entre ces nouveaux services (donc beaucoup sont supposés existants, mais restent très indéterminés) et le coût pour les atteindre, n’a à ma connaissance pas vraiment été faite.
Ce qui nous laisse beaucoup de questions ouvertes pour l’avenir (et pour de nouveaux billets ?)
J’ai en projet un ou deux billets sur les fondements de la Transition bibliographique (puisqu’au département des Métadonnées — et ailleurs — on est beaucoup dans le comment, à tel point qu’on risque parfois d’en oublier le pourquoi).
Mais avant d’entrer dans ce vif du sujet, j’avais envie d’interroger le terme même de « transition ».
Qu’est-ce qu’une transition ?
Si on laisse de côté son sens grammatical (le premier fourni par le Littré, notamment) dans la construction des discours, le terme de « transition » se rattache à la théorie des systèmes et désigne le passage graduel d’un état stable et dynamique à un autre état stable et dynamique.
Oui, un état peut être à la fois dynamique et stable : stable ne veut pas dire immobile. Et dynamique signifie qu’il contient des transformations internes qui n’en modifient pas les caractéristiques.
- « un système est stable si et seulement si , écarté de sa position d’équilibre, il tend à y revenir »(Un culbuto est un système stable)
- un système dynamique est un système qui évolue de façon à la fois causale (son avenir ne dépend que de phénomènes du passé ou du présent) et déterministe (à une condition initiale donnée à un instant t va correspondre un seul état possible à l’instant t+1)
Un système stable et dynamique contient donc en interne les conditions de sa propre évolution.
Le site de l’académie de Nantes signale que cette notion de transition est au cœur du programme d’histoire-géographie en classe de seconde, selon l’académie de Nantes. et voici comment cette notion est définie : la notion de transition est mobilisée pour rendre compte de ces grandes mutations. Elle est déclinée à la fois à travers l’étude des évolutions environnementales, démographiques, économiques, technologiques et à travers l’étude des mobilités qui subissent les influences de ces évolutions. Cette notion de transition désigne une phase de changements majeurs, plutôt que le passage d’un état stable à un autre état stable. Elle se caractérise par des gradients, des seuils, et n’a rien de linéaire : elle peut déboucher sur une grande diversité d’évolutions selon les contextes.
Cette définition ajuste un peu ce que je disais précédemment : la notion de transition est là pour caractériser le processus de transformation, plutôt que ce qui le précède et ce qui le suit.
Conséquences / caractéristiques
Que retenir à ce stade ?
D’abord, que la progressivité est intrinsèque à la transition. Cela signifie qu’à tout moment on peut être amené
- si on y est vraiment
- si on y est encore
- si ça ne devrait pas aller plus vite, ou plus lentement
- si ça va durer encore longtemps
Ensuite, il y a un changement de nature entre l’état initial et l’état final : logiquement, ce n’est pas le même état qui aurait un peu évolué. De même qu’on doit espérer que la « transition écologique » aboutisse à une société différente de celle d’avant, la « transition bibliographique » n’est pas censée être un ajustement des catalogues précédents, mais bien transformer profondément leur nature. Le choix de le faire par une transition (plutôt que par une révolution, un bouleversement brutal) dit quelque chose de la méthode choisie, pas de la distance entre les deux états.
Par ailleurs, la gradualité n’est pas forcément anticipable, ni régulière (de nature et de vitesse identique), durant tout le processus.
Enfin, une transition est par nature temporaire (ou alors c’est autre chose) : il faut souhaiter en sortir.
Le fait de viser un futur état stable et dynamique a comme conséquence que la période de transition inclut la préparation du futur équilibre : quelle sera la dynamique (et la stabilité) du futur état ? Pour dire les choses plus concrètement pour la transition bibliographique : en plus de s’occuper de réécrire les règles de catalogage et de migrer les données, la période de transition est aussi celle qui prépare le pilotage des règles de catalogage (et de la manière de faire évoluer les règles et les données) pour la suite.
De quoi parle-t-on à l’étranger ?
J’ai l’impression que la plupart des pays se sont simplement mis à adopter RDA comme code de catalogage, mais sans chercher à implémenter LRM comme modèle structurant la base de données de leur catalogue. L’enjeu est donc assez différent : même s’ils se lancent dans la reprise des données antérieures pour rendre les zones conformes aux consignes RDA, pour autant que ce soit possible (remplacer les abréviations par les termes non abrégés, alimenter un référentiel Type de média – type de contenu – type de médiation à partir des informations présentes dans les notices, etc.), ça n’est pas un défi de même nature que le projet de transition bibliographique tel qu’il est porté en France.
La réponse est : oui
Puisque le titre du billet était une question, il me semble que la réponse est positive : le terme de « transition bibliographique », choisi il y a plusieurs années à présent — et alors même qu’on en écrit largement le chemin au fur et à mesure — relève bien de la notion de transition , si on la prend au sérieux :
- elle vise à s’arrêter un jour
- on doit arriver à un nouvel état stable et dynamique.Ce nouvel état sera très différent du précédent
- la gradualité des évolutions, durant cette phase de transition, est irrégulière : il y a des étapes plus importantes, plus compliquées, que d’autres
J’en retiens surtout qu’on travaille aujourd’hui, que notre énergie et notre temps de cerveau disponibles, sont consacrés aujourd’hui à la réalisation de cette transition elle-même : cela veut dire qu’on n’en est pas encore vraiment à organiser l’après.
Bien sûr, cette réflexion viendra en temps utile. Mais cette phase de transition devra absolument, à un moment donné, instruire une description de ce que sera ce monde d’après, ne serait-ce que pour gagner en lisibilité pour tous les établissements qui y sont engagés (et peut-être plus encore pour ceux qui n’y sont pas) : circuit du document, organisation du travail, etc. Bref, ce que sera le paysage bibliographique, hors données elles-mêmes, au lendemain de la Transition bibliographique.
Au fait, si on arrive à produire un nouveau système « stable et dynamique », avec une mise en place progressive et différenciée par établissement, comment saura-t-on qu’on est sorti de la Transition bibliographique ?
Cette question me fait penser à une autre, posée un jour sur un blog : comment sait-on quand on est « jeune » (ou qu’on ne l’est plus). La réponse proposée était : on sait qu’on est jeune quand on ne se pose pas la question de savoir si on l’est. Bref, seuls les vieux savent qu’ils ne sont plus jeunes. L’information n’est donc accessible qu’a posteriori.
La fin de la Transition bibliographique n’est certes pas imminente, mais elle n’a jamais été aussi proche !
Je me souviens qu’en 2016 ou 2017, lors d’une journée du groupe Systèmes & Données, il a fallu assurer explicitement — à ceux qui se demandaient quand cette Transition bibliographique aurait lieu — qu’on était en plein dedans. Je me demande si ceux qui se posent cette même question (alors, cette Transition, c’est pour quand ?) sont encore nombreux.
Quoi qu’il en soit, le prochain billet sera grosso modo pour reprendre une question un peu différente : au fait, cette Transition, c’est pour quoi ?
Vendredi 17 juin après-midi avait lieu aux Archives nationales une demi-journée de présentation du résultat de la collaboration entre la BnF, les AN et le Ministère de la Culture. Cette collaboration de plusieurs mois avait visé (et obtenu) des développements complémentaires d’un outil d’interrogation d’une base de triplets RDF, développée par la société Sparna, pour l’adapter aux besoins de la BnF et des AN.
L’outil en question s’appelle Sparnatural.
Les interfaces de requêtes développées pour la BnF et les AN sont aux adresses suivantes :
- pour interroger data.bnf.fr : https://data.bnf.fr/sparnatural
Cette interface est une alternative au Sparql Endpoint https://data.bnf.fr/sparql - pour interroger les fonds notariés des AN inventoriés :
Principes de l’interface
Je ne vais pas rentrer dans une présentation de l’interface, simplement en évoquer les principes, et en venir ensuite directement à une leçon que je trouve particulièrement intéressante, surtout sur le long terme.
Les Sparql Endpoint sont des interfaces de recherche permettant d’interroger un graphe RDF à partir de n’importe quel point du graphe, condition, etc. Le langage Sparql permet de définir les critères recherchés, ainsi que les métadonnées récupérées dans la réponse — alors qu’un web service normal prévoit les critères de recherche et les modalités d’affichage des résultats : ainsi le SRU de la BnF (web service équivalent à son catalogue) propose une liste de critères et des options d’affichage, mais ne vous permet pas d’inventer autre chose que ce qui est déjà prévu.
Les Sparql Endpoint imposent donc un double écueil à leurs utilisateurs :
- il faut connaître le langage de requête Sparql
- il faut connaître le modèle utilisé dans le graphe interrogé, pour pouvoir construire une requête qui le parcoure.
En conséquence les Sparql Endpoint sont très peu utilisés, alors qu’ils pourraient répondre à de nombreux besoins d’extractions de données.
L’interface Sparnatural s’efforce d’évacuer ces deux écueils, en suggérant à chaque étape le noeud suivant, la condition, le type d’entité à récupérer, etc.
Certes, on va tomber nécessairement sur d’autres écueils : les fonctionnalités elles-mêmes, le principe même de construction (intellectuelle) d’une requête en vue d’une extraction, etc. Néanmoins, les deux gros soucis de technicité évoqués plus haut sont en grande partie évacués.
Un modèle de données « usager »
Une des caractéristiques de Sparnatural est qu’il est nécessaire (mais c’est une excellente chose) de configurer un modèle de données pour la recherche, distinct du modèle des données interrogées.
Certes, on peut décrire un modèle rigoureusement identique au modèle sous-jacent, reprendre l’ensemble des entités et des propriétés pour les rendre visibles dans le parcours des blocs manipulables.
Cela permet de regrouper des entités, ou des propriétés, des valeurs de référentiels. Par exemple regrouper des codes fonction sous une appellation « auteur » ou « créateur », si on considère que dans ce contexte d’interrogation la distinction entre collaborateur, contributeur, auteur du texte et adaptateur n’est pas utile ; ou gommer le niveau Expression en reportant sur la manifestation ou sur l’oeuvre certaines de ses propriétés ; etc.
Je trouve cette étape extrêmement intéressante, car elle permet de se détacher du modèle des données telles qu’elles sont stockées, pour les repenser dans leur contexte d’utilisation publique.
Fondamentalement, le modèle de données est pensé comme granulaire pour permettre de tout faire. Mais « tout faire » ne correspond à aucun besoin. Il faut assumer de faire des choix, en considérant qu’on connaît la plupart des besoins des usagers (ou en faisant des enquêtes pour s’informer).
On peut donc s’appuyer sur le modèle de données pour les penser en parcours, en services, en besoins, et s’efforcer d’y répondre au mieux.
Avec l’élaboration d’un modèle de données usager, distinct du modèle de données interne à data.bnf.fr, j’ai le sentiment qu’on sera en mesure de mûrir une réflexion sur ce qu’implique disposer d’une base de données RDF et la convertir en interface de recherche, par exemple dans le futur contexte d’un catalogue nativement LRM.
C’est une expérience qu’il sera utile de mobiliser dans les années à venir.
Qu’est-ce qu’une bonne interface catalogue LRM ?
(ceci est une petite digression, mais aussi un corollaire des paragraphes précédents)
Google dispose de son fameux knowledge graph, base de connaissance qu’il utilise dans certains contextes, et notamment pour proposer des résultats enrichis dans les pages de résultats Google (encart Wikipedia avec photo, liste des acteurs quand on cherche un titre de film, etc.)
A aucun moment Google ne donne à voir le graphe lui-même, celui-ci n’apparaît pas (avec des noeuds et des liens) au sein d’une page de résultats : il le mobilise de manière contextuelle, de manière à conserver un affichage tel que l’utilisateur sache interpréter ce qu’il a sous les yeux. Le graphe vient enrichir cet affichage, et ces enrichissement seraient impossibles sans ce graphe.
Il est probable que lorsqu’on disposera d’un catalogue constitué d’oeuvres, d’expression, de manifestations et d’agents (et de quelques autres trucs comme des concepts, des lieux et des périodes), la tentation soit de donner à voir toutes ces entités, la richesse merveilleuse des liens entre elles, dont nous serons si fiers.
Alors qu’il faut partir de ce que l’internaute est capable de manipuler (et donc de ce qui lui est familier), pour voir ce qu’on s’autorise à ajouter, et qu’il sera possible de faire grâce à cette nouvelle base d’entités et de relations et qui ne l’est pas pour le moment.
Imposer à l’usager la navigation dans les entités elles-mêmes, c’est le forcer à apprendre les concepts d’expressions, manifestations et oeuvres, qui ne lui sont familiers par aucune autre expérience.
A la place, penser un modèle de données Utilisateur, ne contenant que des concepts qu’il peut d’emblée comprendre et manipuler (à travers des pages de résultats suite à une recherche), me semble être une meilleure démarche.
Dans cette perspective, Sparnatural s’avère une étape, une expérience qui pourra se révéler extrêmement utile.
Bloguer : les règles du jeu
La biblioblogosphère a à peu près disparu, le règne des flux RSS est passé, les réseaux sociaux l’ont emporté (et, pour la communauté des bibliothécaires, Twitter me semble un des plus actifs) — et à la veille de publier quelques billets de blogs il me vient certaine pudeur, ou prudence.
Il en est peut-être, parmi les lecteurs de ces futurs billets, qui n’ont pas connu la veille professionnelle dans les années 2010. Les autres ont peut-être un peu oublié cette période-là.
Par conséquent, avant de mettre en ligne quelque texte que ce fût, je préfère rappeler deux principes (pour me garder, autant que possible, de toute mésinterprétation) :
- ce blog, ce biblioblog, est écrit à titre personnel. Bien sûr, il est nourri de mon activité professionnelle quotidienne, celle-ci oriente mes préoccupations et mes réflexions. Néanmoins je ne parle pas sur ce blog depuis mon appartenance au département des Métadonnées de la BnF.
- un billet de blog, c’est de la pensée en mouvement, de la pensée en train de se faire.
C’est très différent d’un article dans une revue professionnelle, qui est davantage censé rendre compte du fruit d’une pensée ou d’une recherche.
Écrire un billet de blog, c’est être en train de réfléchir, le publier participe au processus de réflexion, à travers les réactions des autres notamment.
Ce dernier point implique deux choses :
- je m’autorise à publier des billets qui ont un côté un peu brouillon, mal ficelé, avec des digressions, etc.
- les réflexions et propositions que j’y mets n’ont pas de caractère définitif : elles sont une étape de maturation dans ma réflexion, ce qui me permet de les expliciter pour mieux pouvoir les regarder de loin, et pouvoir plus facilement les faire évoluer avec un regard critique.
Elles sont donc très imparfaites, à compléter.
C’est une méthode qui me permet de progresser, notamment par les critiques lues ensuite.
Si j’attendais de peaufiner chaque article pour qu’il soit plus définitif, je risquerais de n’avoir jamais le temps de publier (en plus ce blog est resté très longtemps inactif, je suis un peu rouillé dans le processus d’écriture même, donc le résultat est même pire qu’avant !).
Et si je ne publie pas, je ne peux pas profiter de retours éventuels de la part de lecteurs-collègues, qui me permettent de me corriger.
Bref, merci d’avance de votre compréhension, et merci également de vos critiques et désaccords à venir !
Indexer : pourquoi ? comment ?
-
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)
Gratification et gratitude
Promotion
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 :
- fournir des données déjà indexées pour s’appelle l’entraînement (training) de l’IA
- vérifier, sur un autre jeu de données déjà indexées, si l’IA produit le même résultat (évaluation)
- 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 :
-
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
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)
- les notices déjà indexées, à séparer là encore en 2 :
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 :
- injecter le lot1 comme données d’entraînement
- 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
- [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).
Bibliothèques [reloaded] 