5/7. Est-ce que RiC reste pure théorie aujourd’hui, ou bien y a-t-il déjà des réalisations concrètes, utilisant RiC-O et RDF ?

RiC-CM est un modèle conceptuel abstrait, donc oui en ce sens c’est de la théorie, mais élaborée par un groupe de praticiens experts du domaine[1], pour les besoins du métier et avec les communautés concernées de professionnels.

Rappelons qu’il s’agit aussi d’un brouillon (draft), dans lequel les réponses à l’appel à commentaires et les premières implémentations et leur suite permettront de dégager les composants les plus utiles. Nous avons aussi expliqué précédemment qu’il s’agit d’un modèle global. Cela signifie que dans le cadre d’une mise en œuvre locale, il n’est absolument pas obligatoire d’utiliser RiC dans sa totalité. Bien au contraire, on peut prévoir que la plupart des projets utiliseront un sous-ensemble de RiC. Par ailleurs, il est possible d’étendre RiC.

Donc RiC-CM, c’est par essence de la théorie. Mais il en existe d’ores et déjà des utilisations concrètes significatives. Et celles-ci se font souvent en utilisant RiC-O, la seule formalisation technique officielle existante de RiC-CM. Nous renvoyons pour commencer à la page sur les projets de mise en œuvre de RiC-O, que nous mettons à jour régulièrement[2].

Cette ontologie comme cela a été dit, sert à définir le vocabulaire et les règles pour produire, conformément à RiC-CM, des graphes de connaissances en RDF destinés à être publiés dans le web de données, ou web sémantique. Le domaine ou le périmètre naturels de RiC-O, c’est le web, les interfaces et services web d’accès pour les utilisateurs finaux des métadonnées.

Si l’on peut (s’il faut !) dès maintenant imaginer des trajectoires d’évolution de nos infrastructures souvent vieillissantes de stockage et de gestion des métadonnées archivistiques vers des solutions plus ouvertes orientées données, les graphes d’entités liées n’y seront probablement pas, le plus souvent, directement stockés et gérés via des bases RDF (triplestores). D’autres solutions sont souvent employées pour ce faire, de la base de données relationnelle aux bases NoSQL, qui sont connues pour leur robustesse et leur performance. RiC-O ne constitue pas du tout une injonction à utiliser RDF pour le cœur des SIA. Répétons-le, RiC-O est simplement et avant tout le modèle qui manquait aux professionnels des archives pour restructurer puis pousser dans le web de données, donc rendre accessibles aux humains et exposer aux machines dans différents formats (XML, Turtle, JSON-LD), des jeux de données de qualité, les lier entre eux, ou avec d’autres jeux de données.

Une telle démarche n’est d’ailleurs pas du tout exclusive d’autres démarches. Ce qui peut être exposé sous forme de simples fichiers tabulés ou CSV doit continuer à l’être. Disposer, dans son système d’information local, d’un entrepôt OAI-PMH exposant des métadonnées archivistiques en XML/EAD ou en Dublin Core qualifié issu du XML/EAD, par ex., permet d’ores et déjà à des agrégateurs comme FranceArchives de moissonner l’ensemble de ces métadonnées (ou des sous-ensembles prédéfinis). Rien n’empêche par ailleurs de publier directement ses fichiers EAD ou EAC(CPF), ou son registre des entrées, en open data. On publiera alors des fichiers conformes à plusieurs modèles différents.

Pour les institutions et projets qui souhaiteraient utiliser RiC-O, on voit plutôt se dessiner des évolutions consistant, non pas à remplacer ce qui existe par des entrepôts RDF, mais à ajouter aux SIA actuels les briques nécessaires pour générer et exposer de tels jeux de métadonnées.

On peut s’inspirer de l’exemple de la BnF. La BnF développe depuis dix ans data.bnf.fr . Cette application est construite avec le logiciel CubicWeb (cf. https://fr.wikipedia.org/wiki/CubicWeb), qui emploie entre autres une base de données relationnelle pour stocker les données. Les données de data.bnf.fr sont le résultat du regroupement et du retraitement de métadonnées de structures et formats divers produites par la BnF, pour les rendre conformes à un modèle unique fondé sur IFLA LRM. Data.bnf.fr génère dynamiquement, en réponse aux requêtes des utilisateurs finaux, des vues de ces données qu’il embarque dans les pages HTML retournées au navigateur web des utilisateurs. Les triplets RDF correspondant à chaque page web peuvent être téléchargés depuis la page dans les différents formats de sérialisation de RDF. En outre la source HTML de ces pages web de data.bnf.fr embarque des données RDFa conformes aux modèles génériques Schema.org et Opengraph Protocol, ce qui permet aux moteurs de recherche du web d’indexer finement ces pages web. Enfin data.bnf.fr est dotée d’un triplestore et d’un SPARQL endpoint, par lequel elle rend la version RDF de l’ensemble de ces données interrogeable directement par les utilisateurs finaux, ou à distance pour les machines (SPARQL étant en même temps un langage de requête pour les données RDF et un protocole de recherche)[3]. La BnF propose ainsi une API d’accès à une version RDF de ses données, parmi d’autres APIs[4]. Signalons au passage que la BnF a inscrit dans la feuille de route data.bnf.fr pour 2020-2024 l’intégration de RiC-O pour un meilleur traitement des données issues de la Base Archives et Manuscrits (BAM)[5].

De plus, la BnF et l’ABES élaborent en ce moment le Fichier National d’Entités (FNE), une plateforme de production mutualisée de descriptions d’entités structurées conformément à IFLA-LRM[6].Pour le cœur de cette plateforme, le choix logiciel s’est porté sur la plateforme Wikibase, utilisée désormais par un nombre significatif d’institutions et de projets, dont l’architecture inclut un triplestore RDF (Blazegraph) adossé à une base de données relationnelle (cf. https://addshore.com/2018/12/wikidata-architecture-overview-diagrams/).

On voit bien, dans ces exemples concernant le web de données, que les bases de données (triplestores) RDF s’inscrivent dans des écosystèmes vastes, dans lequel elles jouent un rôle précis, et qu’elles n’y servent pas de moyen de stockage et d’administration des métadonnées.

Quels que soient les choix d’architecture techniques à faire et à implémenter dans les systèmes d’information locaux si l’on souhaite « passer à RiC » et publier les résultats dans le web de données, il s’agit d’un important travail (comme pour toute implémentation industrielle), qui devrait à notre sens aux AN commencer par les référentiels, en tant que clés de liage internes et externes des métadonnées, et compte tenu des problèmes de modèle, de gestion et de positionnement qu’ils cumulent.

Mais en attendant, rien n’empêche, même si on ne dispose pas d’application comme data.bnf.fr, pleinement intégrée au SI institutionnel, de commencer à produire des métadonnées conformes à RiC, puisqu’on dispose de cette ontologie RiC-O, projet de standard lui-même fondé sur un modèle conceptuel international et des langages informatiques publics dotés de spécifications.

Aux AN nous avons donc produit, et mettons à jour régulièrement, des jeux de données RDF conformes à RiC-O à partir :

– de l’ensemble des instruments de recherche en EAD (soit actuellement environ 29000 fichiers) ;

– de l’ensemble des notices d’autorité de producteurs en EAC-CPF (soit actuellement environ 15210 fichiers) ;

– de l’ensemble des vocabulaires servant actuellement à l’indexation des inventaires et notices de producteurs (soit une vingtaine de vocabulaires).

Cela constitue en soi un pas en avant très concret et important, par rapport à l’étape précédente pendant laquelle nous avions élaboré, en collaboration avec la BnF, le SIAF et la société Logilab, la preuve de concept qualitative PIAAF (https://piaaf.demo.logilab.fr, publiée en février 2018). En effet nous sommes ainsi passés à une échelle industrielle et systématique.

Nous faisons cela automatiquement, en utilisant, d’une part, pour les deux premiers ensembles, le logiciel open source RiC-O Converter[7] développé par la société Sparna et publié en avril 2020 ; d’autre part, une série de scripts XSLT que nous avons écrits et maintenons (la structure des référentiels d’indexation des AN étant appelée à évoluer fortement, nous avons dans l’immédiat préféré cette solution). Nous souhaitons maintenant commencer à travailler à la conversion en RDF/RiC-O des fichiers SEDA du SAE des AN, ce qui nous conduira très certainement à envisager d’associer des données RIC-O et des données conformes à l’ontologie PREMIS.

Dans le cadre du projet RiC-O Converter, nous avons d’ailleurs produit et publié, dans la documentation du logiciel, des mappings (tableaux de correspondance) entre éléments EAD et composants de RiC-O, éléments EAC-CPF et composants (classes et propriétés) de RiC-O[8]. Même s’ils ne prennent pas en compte la totalité des éléments ou attributs des formats source mais seulement ceux utilisés par les AN, ces mappings, les seuls qui existent à notre connaissance pour l’instant, peuvent servir de base de travail à n’importe quel autre projet et institution souhaitant convertir en RDF/RiC-O des fichiers EAD ou EAC-CPF, qu’elle utilise RiC-O Converter ou non. Nous allons par ailleurs réaliser avec Sparna une version 2.0 de RiC-O Converter et de sa documentation cette année, pour les rendre conformes à RiC-O 0.2 publiée en février 2021.

Voilà qui prouve au moins de façon très claire qu’on peut bel et bien produire du RDF conforme à RiC-O à partir d’un corpus de fichiers EAD (d’instruments de recherche archivistiques classiques) et de notices EAC-CPF tels que produits par un SI institutionnel.

Si c’est un pas en avant important, c’est aussi parce que cela oblige à s’interroger sur ce dont on dispose véritablement, sur la cible qu’on souhaite atteindre, sur la distance à parcourir pour atteindre la cible et sur les méthodes à mettre en œuvre pour atteindre cette cible. Toutes réflexions qui sont très importantes pour la suite, et doivent nécessairement être menées avant de toucher au SI. Une série de questions doit donc être traitée :

– En ce qui concerne l’existant : de quoi est-il constitué exactement ? Si, pour les notices de producteurs et les vocabulaires les AN ont une vision assez claire de ce qu’elles ont produit, pour les 29000 instruments de recherche, c’est plus difficile à dire, étant donné le caractère plastique d’EAD, la grande diversité de nature des inventaires et des documents décrits, et la quantité de métadonnées. À l’occasion du projet RiC-O Converter, en préparant les tests unitaires, nous avons ainsi, par exemple, fouillé assez systématiquement les fichiers EAD et nous percevons mieux les différents choix d’encodage qui ont été faits pour un élément EAD ou un autre, le caractère parfois très faiblement structuré ou plus rarement les écarts constatés entre certains usages et les règles énoncées par la documentation EAD.

Le diagnostic n’est pas achevé aux AN, et le projet RiC-O Converter n’est évidemment pas le seul à pouvoir apporter des éclairages sur ce sujet. Mais, en tenant compte de l’objectif de construction d’un graphe d’entités liées, il est déjà certain qu’une marge de progression qualitative existe, qui demande, pour être réduite, d’élaborer un plan collectif d’action, associé à des modifications techniques et fonctionnelles  du SI : une plus grande attention à la rédaction des IR, des extensions au profil d’application EAD des AN trop restrictif, parfois des contraintes plus fortes, un effort d’indexation (humaine ou semi-automatique), des évolutions importantes du contenu et de la structure des référentiels.

– En ce qui concerne la cible : à partir de l’existant, quelles catégories d’entités (instances de classes RiC-O) veut-on, et peut-on dans l’immédiat, envisager d’isoler et de décrire ? Avec quels attributs/propriétés ? Quelles relations distinguer entre les entités ? Cela pose la question de la granularité des données à produire, et cela renvoie à la notion de ce qui est utile, ou suffisant (« good enough ») pour répondre aux besoins utilisateurs mentionnés précédemment. Une autre question, tout aussi importante, est celle de l’assignation d’identifiants uniques et pérennes aux entités qu’on va décrire en RDF/RiC-O ; nous ne ferons que la mentionner ici.

Il faut donc faire des choix, l’idée étant de tirer le meilleur parti de l’état actuel des métadonnées et de prendre en compte toutes les modalités d’utilisation des éléments ou attributs XML, donc divers scénarios de conversion, de la plus simple à la plus élaborée possible.

Dans l’entrepôt GitHub de RiC-O, on trouvera quelques exemples de fichiers EAD et de notices EAC-CPF des AN, avec les fichiers RDF/RiC-O v0.2 issus de la conversion[9]. On trouvera aussi d’autres exemples préparés à partir de métadonnées produites hors de France, tels qu’un ensemble de fichiers EAD et EAC-CPF exportés depuis une application web fondée sur le logiciel ICA ATOM, et un exemple très simple, mais éclairant, de triplets RDF utilisant RiC-O et l’ontologie PREMIS pour décrire un document nativement numérique.

 

[1] La grande majorité d’entre eux sont des praticiens exerçant des missions à haut niveau de responsabilité (directeurs de services d’archives ou de gros projets numériques comme SNAC, gérant de SSII spécialisée) ; quelques-uns sont enseignants chercheurs.

[2] https://ica-egad.github.io/RiC-O/projects-and-tools.html. Il faut noter que l’équipe du portail FranceArchives a choisi, pour sa future version, d’utiliser RiC-O.

[3] Nous résumons ici ce qui est expliqué aux pages suivantes : https://data.bnf.fr/fr/about et https://data.bnf.fr/semanticweb.

[4] Voir https://api.bnf.fr/fr/, et au sujet du service SPARQL d’accès, la page https://api.bnf.fr/fr/sparql-endpoint-de-databnffr. Par ailleurs bien sûr les jeux de données ouvertes RDF de la BnF sont directement téléchargeables (https://api.bnf.fr/fr/dumps-de-databnffr).

[5] Voir https://data.bnf.fr/roadmap.

[6] https://www.transition-bibliographique.fr/fne/fichier-national-entites/.

[7] https://github.com/ArchivesNationalesFR/rico-converter. Au sujet de RiC-O Converter, voir aussi la présentation qui en a été faite par Thomas Francart et Pauline Charbonnier le 28 janvier 2020 (https://labarchiv.hypotheses.org/files/2020/02/20200128_4_RiCOConverter.pdf) et les enregistrements vidéo du webinaire organisé en juin 2020 avec l’aide de l’AAF (https://www.dailymotion.com/playlist/x6x1d0).

[8] Ce sont les deux fichiers Excel disponibles dans le dossier https://github.com/ArchivesNationalesFR/rico-converter/tree/master/ricoconverter/ricoconverter-doc/src/main/resources.

[9] Voir https://github.com/ICA-EGAD/RiC-O/tree/master/examples/examples_v0-2/NationalArchivesOfFrance.

Article suivant: 6/7 Mais finalement à quoi RDF/RiC-O peut-il très concrètement être utile pour un service d’archives ?

---

---