Nakala, entrepôt de données développé par l’infrastructure de recherche Huma-Num, a été l’objet d’une refonte rendue accessible fin 2020. La nouvelle version bénéficie notamment d’une interface graphique de présentation de la donnée qui permet plus facilement de modifier ses métadonnées (via des champs de formulaire). Les données déposées, et donc dotées d’un identifiant pérenne sous forme de DOI, peuvent être regroupées dans des collections. Toutefois, la structure du versement du corpus TEI, sa documentation et son import en masse posent des questions documentaires et techniques qui ont abouti à la constitution d’un groupe de travail, dont le dépôt GitLab dédié donne accès aux réflexions.
Déposer le corpus dans Nakala : enjeux méthodologiques
Le dépôt du corpus dans un entrepôt comme Nakala implique de penser en amont la manière de verser les différents fichiers : qu’est-ce qui constitue une donnée au sein du corpus ? Dans le cas d’un corpus de correspondance comme celui d’Europoleni, il a été décidé qu’une donnée regroupe :
- le fichier au format xml contenant l’élément <teiCorpus> (cette balise permet de regrouper en un seul fichier plusieurs textes, chacun encodé au sein d’une balise <TEI> : dans notre cas la correspondance du projet constitue le <teiCorpus> et chaque lettre est encodée au sein d’une balise <TEI>), mais pour qu’il soit valide, il ne doit contenir que le <xi:include> du texte versé dans la même donnée (cette balise permet d’inclure des renvois vers des fichiers externes afin de ne pas alourdir le fichier principal, mais l’éditeur XML le lira comme une inclusion d’un encodage au sein de l’encodage du fichier) ;
- le fichier de la lettre TEI au format xml ;
- le schéma d’encodage au format rng ;
- la transcription brute au format texte ;
- les images numérisées de la lettre manuscrite ;
- le lien vers la documentation de type ODD (One Document Does it all : il s’agit d’un fichier xml qui a pour intérêt de regrouper une documentation rédigée du schéma et le schéma lui-même).
Les métadonnées choisies pour décrire ces données peuvent donc reprendre des valeurs présentes dans le <teiHeader> des lettres encodées en TEI.
Toutefois, cette manière de concevoir la donnée, si elle correspond à ce que vont intuitivement rechercher les potentiels réutilisateurs de corpus patrimoniaux numérisés, peut poser question selon les pratiques propres à la documentation, l’archivistique ou la bibliothéconomie. Ces problématiques sont abordées par le groupe de travail TEI-Nakala qui propose une manière de concevoir les données issues des éditions numériques sous deux angles complémentaires et indissociables :
- la donnée nativement numérique dont les auteurs sont ceux qui ont participé à l’encodage
- la donnée issue d’une numérisation renvoyant au support physique, et dont les auteurs sont ceux de l’œuvre originelle.
La notion de lettre issue d’une édition numérique est alors constituée de deux versants qui requièrent deux blocs de métadonnées différents (sur les réflexions concernant la modélisation du dépôt de corpus TEI et leurs éléments de description dans les métadonnées, voir le dossier du dépôt GitLab correspondant).
Déposer le corpus dans Nakala : enjeux techniques
Si la nouvelle interface permet une prise en main rapide pour le dépôt et la documentation des données, le dépôt de corpus constitué de plusieurs centaines de lettres ne peut être envisagé sous la forme d’un dépôt manuel. L’API de Nakala (Application Programming Interface, interface logicielle qui permet de connecter un logiciel ou un service à un autre logiciel ou service pour échanger des données et des fonctionnalités) permet de faciliter l’import par lot (plusieurs exemples de prise en main de l’API sont accessibles : les programmes documentés (scripts python) de Michaël Nauge TeiHeaderCahierToSpreadSheet pour passer des métadonnées en TEI à un tableur, et NakalaPyConnect pour générer automatiquement des scripts JSON pour l’API de Nakala ; le retour d’expérience de Floriane Chiffoleau sur l’utilisation de Nakala pour déposer son corpus de correspondance en XML-TEI. On peut ainsi, à l’aide de scripts Python, cibler les métadonnées pertinentes du <teiHeader> pour les basculer sous forme de tableur, puis récupérer les valeurs du tableur pour faire une requête au format JSON. La procédure est bien décrite par Floriane Chiffoleau dans l’article suivant et un exemple de mise en application pour le projet Europoleni est disponible sur GitLab.
Le groupe de travail TEI-Nakala réfléchit également à la conception d’une plateforme qui permettrait de déposer plus facilement son corpus constitué de plusieurs fichiers (par un glisser-déposer via une interface graphique), en effectuant un contrôle sur les métadonnées renseignées selon le schéma défini pour harmoniser la documentation des corpus TEI (le workflow imaginé par les membres du groupe de travail est disponible sur le dépôt GitLab).
OpenEdition vous propose de citer ce billet de la manière suivante :
Gwenaëlle Patat (13 juillet 2022). Pérenniser les données issues du projet. La correspondance européenne de Giovanni Poleni. Consulté le 30 avril 2025 à l’adresse https://europoleni.hypotheses.org/329