Outre l’accroissement des corpus numériques, l’équipe d’ingénieurs du programme BVH s’est étoffée pour le dernier semestre 2021 grâce à un financement supplémentaire de l’Equipex Biblissima, pour appuyer la refonte globale de l’architecture informatique de notre bibliothèque numérique. Cela passe notamment par l’établissement d’un modèle de données aussi complexe qu’exigeant au vu de la diversité des sources patrimoniales décrites, représentées et diffusées dans un contexte toujours attentif à la science ouverte et au partage des communs. Ces principes, qui président au programme BVH depuis sa création en 2003, se traduiront bientôt par la mise en place de nouveaux protocoles d’échanges, tels que IIIF (Image Interoperability Framework) pour l’interopérabilité des images.

Sommaire
Introduction & contexte
Déploiement du protocole IIIF (Théo Roulet, Marlène Arruga)
Migration des données & modélisation (Sarra Ferjani, Anne-Laure Allain)
Veille fonctionnelle & technique (SIGB, SGBD relationnels et XML) (Salomé Paquet)
Modélisation en XML-TEI (Flora Poupinot)

Depuis 2003, quatre bases de données Microsoft Access sont utilisées pour la saisie et le stockage des descriptions de documents anciens (fonds, notices en ligne, sommaires et images extraites), tandis que les éditions TEI de la base Epistemon sont indexées via la plateforme XTF.

Ainsi, le programme BVH doit à terme rassembler dans une nouvelle base unique les données des fac-similés actuellement réparties dans plusieurs bases Access et celles de la base textuelle Epistemon, dans un souci de rationalisation de la chaîne de production. En parallèle de la réflexion sur le modèle global des données, un fichier TEI est actuellement en cours d’élaboration (cf. infra : “Application du modèle en XML-TEI pour le stockage et l’archivage”) et contribuera à une telle rationalisation en vue du stockage, de l’archivage, et à servir  de “pivot” pour l’indexation des données relatives à un même et unique document.

L’équipe du programme de recherche BVH a ainsi engagé, en mai 2021, les recrutements de deux profils distincts et complémentaires sur un reliquat de financement Biblissima (cf. convention de reversement signée en avril 2021) pour la mise en œuvre du protocole IIIF, visant à l’interopérabilité des données produites avec le portail Biblissima, ainsi qu’avec l’ensemble des bibliothèques et établissements partenaires dont le site BVH agrège et diffuse les sources numérisées :

• Profil #1 : un.e ingénieur.e pour assurer le traitement, l’enrichissement et le contrôle des données (CDD pour un IGE de 4 à 6 mois). Voir le profil : https://bvh.hypotheses.org/6714
• Profil #2 : un.e ingénieur.e pour assurer le déploiement, l’implémentation et le paramétrage des outils (CDD pour un IGE de 4 à 6 mois). Voir le profil : https://bvh.hypotheses.org/6702

En raison des difficultés à recruter des personnels compétents et expérimentés avec très peu de délai, dans un secteur professionnel très concurrentiel et sur des contrats de durées courtes (date limite d’utilisation des crédits avec la clôture de l’Equipex en déc. 2021), de plus soumis à la grille de salaire de la fonction publique, le processus de recrutement a abouti à 5 contrats aux missions complémentaires. Cela a permis de faire avancer le chantier sur des opérations parallèles de mise en interopérabilité des données du programme BVH, impliquant de nouvelles technologies, de nouvelles procédures de travail et une nouvelle infrastructure pour la pérennisation de l’ensemble :

1. Établissement du nouveau modèle général de données BVH, établissement du modèle de Manifest JSON pour IIIF et supervision des formats de données exportés (XML-TEI, etc. pour le stockage, la diffusion et l’archivage) : pourvu par Anne-Laure ALLAIN, IGE, 7 mois, de juin à décembre 2021. Cf. Profil #1
2. Établissement des scripts de migration et de conversion des données depuis les bases Access vers JSON (Manifests IIIF) et XML-TEI (pour le stockage et l’archivage) : Marlène ARRUGA, IGE, 4 mois, de septembre à décembre 2021. Cf. Profil #2
3. Déploiement du serveur image et des API pour IIIF, tests et paramétrages du serveur (VM Huma-Num) : Théo ROULET, IGE, 3 mois, d’octobre à décembre 2021. Cf. Profil #2
4. Application du modèle de données en XML-TEI en vue du stockage et de l’archivage : Flora Poupinot, IGE, 3 mois, d’octobre à décembre 2021. Cf. Profil #1
5. Veille fonctionnelle & technique pour accompagner dans le choix des outils pour la mise en place de la nouvelle infrastructure de données : Salomé PAQUET, IGE, 3 mois, d’octobre à décembre 2021. Profil polyvalent impliquant la compréhension entre les problématiques des profils #1 et #2.

La définition des profils/missions puis les recrutements ont bénéficié du soutien et de l’expertise de l’équipe Biblissima (Régis Robineau notamment) et ont été supervisés sur la durée par les personnels titulaires du CESR susceptibles de poursuivre la mise en œuvre et la maintenance des outils et des données : Sarra Ferjani (IGE CNRS, CESR, Modélisation et administration de bases de données) et Sandrine Breuil (IGE Université de Tours, CESR-BVH, suivi et gestion de projet BVH).

 

Déploiement du protocole IIIF

Le protocole IIIF (International Image Interoperability Framework) est un ensemble de standards favorisant la diffusion des images numériques sur le web. Son but est de rendre les images interopérables  ce qui veut dire, selon les critères de Biblissima, les rendre “consultables, manipulables et annotables”, en ligne, “par n’importe quelle application conforme à IIIF”.

Il s’agit donc pour le programme BVH de mettre en place les API définies par IIIF : c’est-à-dire des interfaces entre les systèmes qui reposent sur un langage d’interrogation et un modèle de données communs pour échanger des images et leurs métadonnées (cf. infra “Refonte du modèle de données BVH”). Il existe 5 APIs, mais au cours de ces trois derniers mois, Théo Roulet (IGE Biblissima) s’est consacré à la mise en place des deux fondamentales : l’API Image et l’API Présentation, en parallèle du paramétrage du serveur ouvert et hébergé par la TGIR Huma-Num afin d’effectuer les tests.

• L’API Présentation : couvre l’échange des métadonnées d’une collection d’images
• L’API Image : permet au client d’échanger avec le serveur qui fournit les Images, pour les récupérer dans l’ordre et les conditions qui ont été définis dans le Manifest.

Ces deux API, et le fait qu’elles soient séparées, permettent de décrire des ensembles d’images qui s’appuient sur des numérisations ou des extraits de numérisations publiées par plusieurs bibliothèques numériques. C’est grâce à elles que Biblissima moissonnera les BVH.

Première étape : la production des fichiers de métadonnées décrivant les collections d’images, essentielle pour l’API Présentation.

La génération des ces Manifests a nécessité l’écriture d’un script de transformation des données en Python (Marlène Arruga) présentes dans les différentes bases et en particulier la base Catalogue et la base Sommaire. Ce script exporte les données dans un format JSON sur le modèle préparé en amont (par Anne-Laure Allain) et construit spécifiquement pour la mise en place du protocole IIIF, en concertation avec l’expertise de Régis Robineau (Biblissima, Condorcet). Ce script permet aussi un export en format XML-TEI, pour l’archivage des données, selon le modèle en cours d’élaboration (Anne-Laure Allain, Flora Poupinot) et qui fera l’objet de mises à jour ultérieures. Le travail a impliqué un réel ré-encodage des données produites par les BVH pour les rendre compatibles avec les normes IIIF et le modèle TEI développé par l’équipe.

En outre, un certain nombre de métadonnées requises ont dû être produites et intégrées dans les bases Access en amont de l’export : financeurs, projets financés, tailles et formats des images… (Anne-Laure Allain, Sarra Ferjani).

Ce nouveau processus a l’avantage de partir directement des données présentes dans les bases, de réduire le nombre de conversions et le risque de perte de données. Cela permet aussi, s’il y a un changement en base de données, de ne pas avoir à modifier plusieurs scripts. Le script actuel permet de générer les fichiers JSON et TEI, à l’unité, par lot ou en totalité, à partir de l’identifiant présent dans la base Catalogue. Les fichiers JSON sont ensuite exploités par le serveur image.

2ème étape : publier les Manifests et les images

Les Manifests JSON, produits par les scripts, et les images converties au format JP2000 sans perte (traitement d’un premier lot d’images en 2020 sur co-financement CPER BIOPATIC, MSH Val de Loire), sont actuellement stockées dans la même arborescence de dossiers.

Théo Roulet a ainsi mis en place :

• un serveur web (sous Nginx, avec règles de redirection vers les images et Manifests),
• le serveur image choisi et déployé à l’issue d’une veille technique : Cantaloupe, développé par la communauté IIIF (Bibliothèque de l’Université de l’Illinois).

Ces deux serveurs sont installés sur une même machine virtuelle (VM) hébergée par la TGIR Huma-Num. La majeure partie du travail de Théo Roulet s’est concentrée sur la mise en place de l’environnement informatique nécessaire au fonctionnement de ce système un peu complexe, en particulier en ce qui concerne Cantaloupe. Il a fallu concevoir un certain nombre de scripts et paramétrer la Machine Virtuelle pour transformer une application en un service autonome, stable et sécurisé. Mais aussi parce qu’il s’agit d’un logiciel de transformation d’images à la volée, qui doit être capable de répondre à une certaine charge de requêtes dans un temps suffisamment court, un certain nombre de tests de paramétrage et de performances ont été menés. Pour mettre en place cet environnement, au-delà de notre veille technique, nous avons pu nous appuyer sur les conseils de Cyril Masset (pôle numérique, IRHT), Régis Robineau (Biblissima, Condorcet) et de Jean-Louis Bouteiller (DSI, Université de Tours, CESR).

Deux points importants doivent encore néanmoins être résolus en priorité :

• les performances de la VM sont à l’heure actuelle insatisfaisantes en cas de fréquentation assidue par de futurs multiples utilisateurs. Les deux variables à améliorer et sur lesquelles il va falloir trancher sont :
  • obtenir un accord d’Huma-Num pour augmenter le nombre de processeurs et la RAM de la VM (demande en cours, au 02/02/2022) ;
  • privilégier les librairies de Kakadu – plus performantes, actuellement installées en version d’essai (jusqu’à fin mars 2022) – à OpenJPG (libre et gratuit), pour les traitements d’images à la volée par Cantaloupe. Le prix de la licence annuelle de Kakadu est prohibitif et ne peut pas être assuré par le CESR-BVH alors même qu’Huma-Num a confirmé ne pas disposer de cette licence dans sa grille de service.
  • En parallèle, l’équipe BVH prospecte et cherche des retours d’expérience d’administrateurs serveurs (profil faisant défaut en interne au CESR) ayant à installer et maintenir de tels dispositifs avec des volumes de données équivalents ou supérieurs.
• l’accès à la Huma-Num Box, sur laquelle seront stockées les images, est limité et pose des difficultés d’accès en écriture (demande effective depuis le printemps 2021, pour 10 To : via la MSH Val de Loire dans un premier temps, puis auprès d’Huma-Num faute de solution pour résoudre les problèmes d’accès CIF). Au vu des volumes d’images à faire migrer (7,5 To) et en raison de l’accès rendu difficile, les transferts devront se faire progressivement avec une copie locale intermédiaire sur PC augmentant de fait considérablement le temps de travail, de copie et possiblement les corruptions de fichiers.

Au terme de l’Equipex, en décembre 2021, un démonstrateur a pu être mis en place : par exemple la version d’essai du visualiseur compatible avec IIIF Universal Viewer (requête en temps réel sur notre serveur, et possibilité de demander des modifications) ou encore avec le visualiseur Mirador (tests avec une version d’essai en ligne).

La mise en place du protocole IIIF au sein du projet BVH est donc fonctionnelle.

Elle doit dorénavant être poursuivie en 2022 (financement Biblissima+) par une personnalisation des développements et un paramétrage plus spécifiques aux BVH :

• Une personnalisation du serveur image, grâce à un script délégué qui permet d’adapter son comportement. Les fonctions sur lesquelles nous devons nous concentrer en priorité sont : la récupération des métadonnées encapsulées dans les images, et la limitation de l’accès à certaines images en fonction des droits mentionnés dans la base de données. Ce delegate script qui a nécessité au préalable un apprentissage du code RUBY est actuellement en cours d’écriture par Marlène Arruga.
• Le deuxième objectif est d’implémenter un visualiseur sur notre serveur pour pouvoir le paramétrer et le personnaliser afin de permettre une consultation efficace et adaptée aux besoins des chercheurs et utilisateurs des BVH.
• En parallèle, le contrôle des Manifests générés (plus de 1 200) est effectué par Anne-Laure Allain et les correctifs appliqués au script d’export python par Marlène Arruga (cas particuliers à gérer, bugs, informations manquantes ou tronquées…)

Marlène Arruga et Anne-Laure Allain ont en outre bénéficié d’un renouvellement de contrat sur financement Equipex Biblissima+ à compter de janvier 2022 afin de poursuivre les travaux engagés jusqu’en décembre 2022.

Refonte du modèle de données BVH

Le processus global de refonte des BVH induit par la mise en place de nouveaux protocoles tels que IIIF et par l’obsolescence de l’infrastructure en place depuis 2003, nécessite à la fois une réflexion technique, et avant tout, une réflexion scientifique sur les données que l’on souhaite pouvoir collecter, interroger, partager. L’objectif premier a été de définir les unités documentaires opératoires (entre autres une œuvre, une édition, un ouvrage, un recueil, une collection, etc.) par une approche itérative, avec des aller-retours constants entre le schéma en cours de construction et la structure actuelle. Pour appuyer cette réflexion, plusieurs configurations plus ou moins complexes ont été étudiées pour déterminer et définir les niveaux opératoires de description indispensables au catalogage du livre ancien pour notre bibliothèque numérique. Nous nous sommes notamment appuyés sur des exemples qui ne sont pas gérés de façon satisfaisante par le modèle encore en place. L’enjeu est également de conserver un équilibre entre une description fine des fac-similés tout en préservant une interopérabilité avec les bibliothèques (cf. modèle MARC encore utilisé par les bibliothèques partenaires, tout en s’adossant au changement de perspective induit par la Transition bibliographique).

À l’heure actuelle, nous nous sommes arrêtés sur quatre niveaux opératoires de description qui sont : l’objet physique, l’unité bibliographique, la manifestation et l’œuvre (à noter que la terminologie n’est pas fixée et fait encore l’objet de discussions en interne). Pour chacun de ces niveaux (du point de vue du catalogueur), nous pouvons considérer les deux premiers comme “niveaux concrets” puisqu’ils correspondent à ce que l’on peut voir et feuilleter. Les deux suivants sont considérés comme des “niveaux abstraits” correspondant à une deuxième phase d’analyse et d’identification. L’ensemble de ces niveaux a pour but de faciliter la recherche de l’utilisateur et par conséquent l’accès à l’objet numérique.

La mise en place de cette nouvelle chaîne de production et de description constitue un enjeu à part entière. Cela implique de trancher sur les formats (de production, d’archivage),  les stratégies de mise en ligne et de consultation et, au-delà, d’assurer la cohérence de l’ensemble de l’infrastructure. L’articulation entre la structuration logique et physique des documents est centrale. S’il reste impératif de faire en sorte que la réflexion scientifique ne soit ni entravée ni guidée par le choix technique, ces derniers induisent des contraintes fortes sur les possibilités de mise en œuvre, les capacités de maintenance ou encore l’interopérabilité avec nos partenaires.

L’objectif final visé est donc à terme de permettre des requêtes plus fines, une meilleure visualisation, de limiter la redondance d’informations, d’inclure dans le même modèle une articulation avec l’ensemble des projets BVH qui possèdent leurs bases de données spécifiques.

Ainsi, le travail de modélisation des données, commencé en 2021 avec la mise en place d’ateliers de travail hebdomadaires impliquant l’ensemble des membres de l’équipe BVH, a permis à Anne-Laure Allain (IGE Biblissima) et Sarra Ferjani (IGE CESR) d’établir les premiers modèles cohérents. Il doit mener à l’établissement de cahier des charges courant 2022 (Biblissima+  et FEDER) pour le développement des outils, des interfaces de saisie et à terme des interfaces de consultation et de requête en ligne.

 

Veille fonctionnelle & technique

Cadre et objectif de la veille fonctionnelle réalisée

Dans le cadre de la refonte de l’architecture informatique des BVH, une veille technologique a été réalisée sur les systèmes de gestion de données. Cette partie du travail, confiée à Salomé Paquet (IGE Biblissima), visait à faire le point sur les différents outils et technologies à notre disposition, en fonction des contraintes précédemment évoquées sur les plans scientifiques et techniques. Deux types de logiciels ont été étudiés :

• les systèmes intégrés de gestion des bibliothèques (SIGB),
• les bases de données XML natives et relationnelles compatibles avec XML.

Alors que l’option du SIGB répond à l’objectif de partage de données avec les bibliothèques, celle d’une base XML dépend de l’établissement d’un fichier XML-TEI (ou comme envisagé à terme d’une combinaison possible entre fichiers TEI, METS, ALTO, etc.). Le recours au langage XML a une incidence sur le choix du système de gestion de données. Le logiciel sélectionné devra prendre en charge le format XML ou, du moins, un format « intermédiaire » dont la conversion n’occasionnera pas de perte de données, de même que pour les formats d’export et les protocoles mis en oeuvre pour l’interopérabilité avec les bibliothèques patrimoniales et les partenaires de recherche.

L’analyse des systèmes effectuée fin 2021 a pris en compte les contraintes techniques principales suivantes : la gestion du schéma de données structuré en XML-TEI, l’implémentation de protocoles de communication de données, la compatibilité des outils de requête avec le format XML et l’intégration de systèmes de gestion, d’interrogation et de visualisation de données. Ensemble, elles constituent un socle solide pour accroître l’interopérabilité, la pérennité et le partage des ressources produites par les BVH.

L’étude comparative d’un panel de SIGB a fait ressortir deux logiciels en particulier, sur lesquels a été réalisée une analyse plus poussée : PMB et Koha. L’étude conjointe de ces deux systèmes nous a menés à la conclusion que le SIGB ne constitue actuellement pas le système le plus adapté à la gestion des métadonnées produites par les BVH. Nous estimons le coût du paramétrage puis de la maintenance trop important pour répondre aux besoins des BVH (scripts d’imports et d’exports, paramétrage de la grille de catalogage, ajouts de nombreux champs supplémentaires spécifiques…). Néanmoins, le regroupement de modules de catalogage, de partage et de visualisation des données en un seul logiciel fait du SIGB un système pertinent pour la rationalisation de la chaîne de production. C’est pourquoi nous avons été particulièrement attentifs à ce critère dans le cadre de la veille réalisée sur les bases de données XML.

L’étude de deux familles de base de données :

• les bases XML natives : systèmes NoSQL fondés sur le modèle XML et ses technologies
• les bases relationnelles compatibles avec XML : systèmes SQL supportant le mapping xml-relationnel et les données de type XML

L’étude des bases XML (natives et relationnelles compatibles) a permis à l’équipe de préciser les besoins qui en découlent en terme d’architecture informatique. La division entre système orienté document et système orienté donnée a notamment fait ressortir la diversité des données produites par le programme. L’utilisation croisée d’une base relationnelle pour la collecte et la gestion de métadonnées descriptives, et d’une base XML pour les éditions textuelles en XML-TEI, est une possibilité qu’il faudra continuer d’envisager. Maintenir cette séparation dans la chaîne de travail continurait d’avoir un impact pour la constitution du fichier XML-TEI visé qui, à terme, vise à rassembler les métadonnées des fac-similés et celles des éditions de la base Epistemon. Elle ne répond pas non plus à l’objectif de rationalisation de la chaîne de production. Par conséquent, l’utilisation d’une base unique, XML native ou relationnelle compatible, devra être étudiée davantage.

Conclusions

Ainsi, la veille a fait émerger plusieurs variables à prendre en compte pour définir la nouvelle infrastructure BVH, opposant souvent deux objectifs :

• Rationalisation de la chaîne de production versus accroissement des performances
• XML versus modèle relationnel
• un seul système (NoSQL ou SQL) versus des systèmes couplés pour gérer l’ensemble

Vraisemblablement, les BVH devront approfondir cette dernière option « hybride » par une veille et des retours d’expériences d’autres projets ayant mis en œuvre des systèmes couplés pour gérer un ensemble hétérogène de données structurées.

 

Application du modèle en XML-TEI pour le stockage et l’archivage

A la suite de travaux antérieurs, la transposition du modèle de données BVH général (en cours, cf. supra “Refonte du modèle de données”) au format XML-TEI, a été poursuivie par Flora Poupinot (IGE Biblissima). Il s’agit de rassembler les données d’un même document dans un format interopérable et permettant de répondre en premier lieu à plusieurs impératifs :

• d’archiver des données et métadonnées produites
• d’établir un lien entre la partie Fac-similés et Epistemon
• d’envisager l’ensemble des champs requis pour une description aussi fine que souple des objets physiques et numériques traités par les BVH, quelles que soient leurs spécificités

Ce fichier XML-TEI est organisé en deux parties :

1. une entête (<teiHeader>) avec les métadonnées descriptives de l’objet : partie pour laquelle l’application en TEI du modèle de données dans son état actuel est à jour et fonctionnel au terme du contrat de Flora Poupinot ;
2. un contenu (<body>) pour la structuration du sommaire, qui doit permettre de générer et afficher un sommaire du côté utilisateur : partie pour laquelle le travail a été commencé mais doit être poursuivi en 2022.

 

Cette modélisation en XML-TEI est donc encore en construction et nécessite une expertise spécifique en vue de conserver toute la finesse de description proposée par le schéma de données des BVH. Ce travail devra être poursuivi en 2022 (Biblissima+). L’articulation de ce fichier TEI “pivot” avec des formats METS, ALTO et potentiellement EAD ou d’autres fichiers XML-TEI propres à des “variantes” d’édition numérique d’un même exemplaire donné, doit être étudiée et approfondie (version modernisée, traduction, ou version pour les outils d’analyse linguistique tels que TXM ou Philologic par exemple). En outre, l’intégration d’identifiants uniques devra aussi être déployée sur l’ensemble des données, pour toutes les entités mais aussi, par exemple, avec les handles attribués aux genres de texte (typologie textuelle mise en place par le groupe de travail du Consortium Cahier sous Opentheso, TGIR Huma-Num).

 

Ce billet est basé sur les interventions d’Anne-Laure Allain, Marlène Arruga, Sarra Ferjani, Salomé Paquet et Théo Roulet, à l’occasion du bilan présenté en Assemblée générale 2021 du programme BVH (voir les supports de présentation en ligne), le mercredi 15 décembre 2021, à Tours.

---

---