SESSION 3. OUTILS ET SYSTÈMES POUR LES DONNÉES RIC
Des outils pour faire la transition de métadonnées archivistiques classiques vers RiC-O et pour les exploiter par Thomas Francart (consultant graphes de connaissances et ontologies, Sparna, France) et Florence Clavaud (responsable du Lab, AnF)
[English]
SESSION 3. TOOLS AND SYSTEMS FOR RIC DATA
Tools for converting classic archival metadata to RiC-O and semantically querying them by Thomas Francart (ontologies and knowledge graphs consultant, Sparna, France) and Florence Clavaud (head of the Lab, AnF)
Des outils pour faire la transition de métadonnées archivistiques classiques vers RiC-O et pour les exploiter par Thomas Francart (consultant graphes de connaissances et ontologies, Sparna, France) et Florence Clavaud (responsable du Lab, AnF)
[English]
SESSION 3. TOOLS AND SYSTEMS FOR RIC DATA
Tools for converting classic archival metadata to RiC-O and semantically querying them by Thomas Francart (ontologies and knowledge graphs consultant, Sparna, France) and Florence Clavaud (head of the Lab, AnF)
Category
📚
ÉducationTranscription
00:00 Bonjour à tous et à toutes. Nous allons vous parler des outils que nous avons développés et mis en oeuvre pour migrer et exploiter des métadonnées archivistiques dans ce contexte de la transition des formats archivistiques classiques vers RICO.
00:28 La problématique générale c'est celle de la transition à des formats archivistiques actuels vers une sémantique archivistique.
00:48 RICCM et RICO sont des étapes majeures dans la définition des concepts métiers du monde des archives. On transitionne des formats actuels vers une sémantique archivistique.
01:03 On peut faire le parallèle avec ce qui se passe dans la transition bibliographique en FRBR avec les bibliothèques. On souhaite arriver à des graphs d'entités actionnables et requêtables.
01:18 Cette transition implique un certain nombre de challenges et de points qu'il faut traiter. En particulier l'identification de ces entités qui vont former notre graphe de données.
01:33 La sémantique des informations, la différence entre les formats EAD et EAC et la cible RICORDS in contexte. La normalisation des valeurs, puisqu'on veut un graphe avec un maximum de qualité.
01:48 Ce qui implique parfois une normalisation des valeurs existantes. Et des questions de gestion simple de format de fichier ou de production de fichiers de données exprimés en RICO.
02:02 Pour adresser ces challenges, l'outil RICO Converter permet de migrer des formats EAD vers RICO ou EAC vers RICO en adressant ces challenges que l'on va passer en revue.
02:19 La première de ces problématiques est l'identification des entités métiers. On en a déjà un peu parlé dans les sessions de ce matin.
02:31 La différence entre les RICORDS Ressources et les instances RICO. Cet outil de conversion RICO Converter va faire émerger ces entités conceptuelles qui ne sont pas tout à fait explicites dans les fichiers EAD de départ.
02:49 On va créer des RICORDS Ressources, des ressources intellectuelles et des instances physiques.
03:02 Ici avec un exemple qui ne doit pas être très lisible, mais avec un exemple d'une ressource qui a initialement un DAO group en EAD et qui va donner lieu à deux instances RICO.
03:17 Les deux, donc l'une papier et l'autre numérique, les deux étant articulées avec une relation qui dit que cette instantiation numérique dérive de l'instantiation physique.
03:31 Cette propriété hasDerivedInstantiation qui est du RICO 0.2, version sur laquelle RICO Converter se base actuellement, est renommée un identifiant différent dans RICO 1.0.
03:46 Un autre exemple problématique d'identification de ces entités métiers, plutôt du côté EAC, c'est le distinguo entre l'Authority RICORD, la notice de l'agent, versus l'agent lui-même dans le monde réel.
04:05 On vient créer deux entités, identifiées chacune par un identifiant différent, l'une représentant la notice, l'autre représentant l'agent, les deux étant articulées avec le lien describes or described.
04:21 On vient aussi lors de cette conversion préciser la sémantique de certains attributs de l'EAD, par exemple l'attribut FISDESC.
04:37 C'est précisé que l'attribut FISDESC, en fonction de la façon dont il est peuplé, va donner du côté RICO tantôt un RICO Physical Characteristics, ou un RICO Instantiation Extent, ou Carrier Extent, ou As Carrier Type.
05:00 Ces propriétés RICO servant à caractériser toutes les caractéristiques physiques, puisqu'on est bien là au niveau de l'instantiation, qui sont en EAD regroupées ou qui peuvent s'exprimer dans le FISDESC.
05:18 Donc en fonction de la structure de FISDESC d'input, d'entrée, on va produire des propriétés de sortie RICO différentes.
05:26 La conversion vient aussi normaliser un certain nombre de valeurs, ça c'est typiquement le cas des Unidates en EAD.
05:38 Donc des dates plus ou moins normalisées, avec plus ou moins de cas possibles d'utilisation de cet élément, que l'on va essayer autant que possible de normaliser pour se ramener à des valeurs les plus propres et les plus structurées possibles.
05:59 On peut faire ce travail lors de la conversion, c'est toujours mieux si la qualité des données sources est la meilleure possible.
06:17 Le quatrième challenge que j'avais listé était sur le format des fichiers. On passe de fichiers EAD et EAC à la production d'un ensemble de fichiers RDF XML.
06:30 Ces fichiers RDF XML sont organisés pour la conversion EAD ou EAC de façon un peu différente.
06:37 La conversion des instruments de recherche EAD va pouvoir donner lieu à un découpage des fichiers en fonction des branches de l'instrument de recherche.
06:48 La conversion des fichiers EAC va donner lieu à une arborescence de répertoires dans lesquels vont venir se ranger respectivement les agents, les lieux et les relations de différents types dans cette arborescence.
07:01 C'est un petit détail de gestion mais qui permet d'avoir à la fin en sortie un ensemble de fichiers relativement petit et plus facilement manipulable que des gros fichiers monolithiques.
07:22 Petit point lié à la question de l'identification des entités. Ces entités, record resources, instantiation, authority record ou agents, doivent être identifiées par des identifiants uniques.
07:37 L'outil de conversion se propose de créer tous les identifiants qu'il génère dans un espace de nom fictif et que l'on peut customiser, qui est celui-ci data-archives-national.culture.gouv.fr
07:58 Derrière lequel on va mettre l'identifiant de l'entité que l'on crée. Pour créer cet identifiant on va s'appuyer autant que possible sur les identifiants qui sont déjà existants dans les données sources.
08:11 On ne va rien inventer de nouveau, sauf dans le cas où il n'y a pas l'identifiant qu'il nous faut. Dans ce cas là, cet identifiant il faut le forger, il faut le créer.
08:19 Ces identifiants sont mis après un élément structurant dans l'URI qui va être le type RICO conceptuellement au niveau de l'entité que l'on crée.
08:37 Par exemple /agent ou /record, respectivement dans le cas des agents et des RICORN Ressources. Ou /agent-hierarchical-relation.
08:48 Ici un exemple d'identifiant de relations hiérarchiques qui est construit en concaténant un certain nombre d'éléments.
08:54 Ici l'identifiant de l'agent cible, l'identifiant de l'agent source et puis les dates de début et de fin de la relation pour garantir la création d'un identifiant unique.
09:10 Le développement de RICO-converter est driveé par les tests unitaires. L'outil de conversion est fourni avec un ensemble de test-case, de cas de test à peu près 200 dans le cas de l'EAD et une centaine dans le cas de l'EAC.
09:29 Répartis dans un certain nombre de fichiers. Ce sont ces cas de test qui donnent la spécification la plus formelle du comportement du convertisseur.
09:38 La maintenance et la production de ces cas de test représentent une part significative de l'écriture, du développement initial et de la maintenance du convertisseur.
09:50 Mais ils nous donnent une certaine garantie de qualité de la conversion qui est produite.
09:56 Un petit exemple de ce que donne ces tests unitaires. On vient écrire manuellement un petit fichier d'entrée et on écrit manuellement le petit fichier de sortie attendu et on vérifie que le convertisseur produit bien ce qu'on attend qu'il le fasse.
10:14 On voit un petit exemple de la génération du traitement des anti-TID avec des identifiants de compagnie SIRET qui vont produire des RICO identifiers.
10:28 On vérifie qu'à partir de cette spécification, le convertisseur produit bien ce qui est attendu.
10:34 RICO Converter est implémenté principalement par des feuilles de stig XSLT.
10:46 Ca fait à peu près 2000 lignes de code pour la conversion EAD et 3000 lignes de code pour la conversion EAC.
10:52 Le fait de s'appuyer sur du XSLT lui donne de bonnes performances puisqu'on arrive à traiter des quantités significatives de fichiers, donc à peu près 15 000 fichiers EAC CPF en quelques minutes pour produire 700 000 triplets.
11:10 Et pour l'EAD, à peu près 31 000 fichiers, donc 4 gigas de XML là aussi en fonction des options qu'on va lui demander, un quart d'heure, 30 minutes sur des postes de développement tout à fait classiques.
11:22 On n'est pas sur des serveurs pour produire 150 millions de triplets.
11:26 XSLT est très expressif, donc on a un mapping qui travaille au niveau de la syntaxe, on n'a pas un mapping qui travaille au niveau de la sémantique.
11:34 On produit une syntaxe particulière qui est le RDFXML, ça a des avantages et des désavantages.
11:40 L'un de ses avantages c'est une expressivité très forte et les performances associées.
11:45 Le désavantage c'est qu'il faut travailler vraiment au niveau de la syntaxe et connaître exactement la syntaxe de production des fichiers de sortie.
11:52 On ne travaille pas au niveau de la sémantique de RICO propriété à propriété ou triplet à triplet.
11:58 L'outil est adaptable, chaque processus de conversion que ce soit pour le AD ou pour le AC est encapsulé ou est driveé par une XSLT maîtresse
12:10 qui est un point d'entrée qui est vide, qui ne fait qu'importer les règles génériques, qui est vide à dessein puisque c'est dans cette XSLT maîtresse
12:20 que l'on peut venir customiser le comportement du convertisseur ou changer un certain nombre de paramètres
12:26 comme par exemple le nom de domaine des identifiants qui est en archi-nationale que l'on peut venir customiser.
12:32 Tout ça est très bien documenté sur ce site en français et en anglais.
12:43 Le lancement est simple, c'est une ligne de commande, c'est portable, c'est écrit en java.
12:52 Tout ça est bien fait pour que d'autres puissent se l'approprier, ce qui est l'objectif.
12:59 Je te laisse la parole Florence.
13:03 Je poursuis la présentation pour dire que si cet outil a été développé pour répondre avant tout aux besoins des archives nationales
13:18 qui avaient donc une très grosse collection de fichiers EAD hétérogènes et une importante collection de fichiers EACCPF,
13:28 probablement la plus importante en France, et qui avait besoin de quelque chose de performant, de fiable, de configurable
13:36 et de facile à prendre en main, aujourd'hui on peut dire que Ricoconverter peut traiter la majorité des éléments XML
13:47 et des attributs de ces deux formats, même si tout n'est pas pris en compte.
13:52 Et en particulier, il ne prend pas en compte certains éléments ou attributs que nous n'utilisons pas aux archives nationales.
13:59 Je n'ai pas essayé de quantifier exactement la proportion couverte, mais je dirais qu'on couvre quasiment tout le format EACCPF dans sa version de 2015
14:15 et quelque chose comme 80-85% du format EAD 2002.
14:22 Ce qui n'est pas couvert, ce sont par exemple des éléments comme "running title" ou "front matter" en EAD,
14:32 qui n'ont pas réellement sa place dans le monde RDF, on les a donc ignorés,
14:41 ou des éléments qu'on n'utilise pas, il se trouve qu'aux archives nationales on n'utilise pas "dao" mais "dao group".
14:47 Ceci dit, encore une fois, l'outil est fait pour être adapté.
14:52 Il est publié également sous licence, une licence très permissive, comparable à la licence du MIT, donc une licence de domaine public.
15:01 On l'a déjà dit, documenté et facile à porter, grâce au fait que c'est Java à la base.
15:10 Et il est fait pour être adapté et réutilisé par d'autres institutions, même si jusqu'ici nous n'avons pas connaissance de tel cas.
15:20 Vous voyez là en bas une copie d'écran de l'invite de commande Windows.
15:29 Je précise également qu'on peut l'utiliser sur un système Unix ou Linux, en l'occurrence là c'est du Linux,
15:38 où on a lancé une commande de conversion de fichiers EAD.
15:47 En complément des tests unitaires, qui constituent comme Thomas l'a déjà dit, la spécification formelle véritable du logiciel,
16:02 nous avons également réalisé des mappings entre EAD et RDF RICO 0.2 d'une part et EACCPF RDF RICO 0.2 d'autre part,
16:14 sous la forme de fichiers Excel, qui sont des fichiers Excel faciles à ouvrir, et qui définissent plus globalement, plus sommairement, le comportement du logiciel.
16:28 Ces fichiers sont fournis dans la documentation et ils sont réutilisables tels quels,
16:34 y compris quand on n'a pas décidé de choisir RICO Converter comme outil de conversion.
16:41 Je crois d'ailleurs que pour le portail France Archive, ils ont servi au moins de point de départ pour les mappings.
16:50 Nous voulions également signaler que nous avons publié récemment un article de référence en anglais sur le logiciel,
17:01 dans la revue américaine Journal on Computing and Cultural Heritage, qui est désormais disponible en accès restreint,
17:12 comme hélas c'est souvent le cas dans ce genre de revue, mais nous pouvons donner accès à un préprint si nécessaire.
17:21 Vous y trouverez beaucoup d'autres informations sur le logiciel et sur ce que nous en avons fait,
17:27 et sur les conclusions que nous avons tirées, en particulier en termes d'analyse de la qualité des fichiers entrants.
17:40 Alors que nous savions assez bien, vraiment même très bien, ce que contenait nos fichiers EACCPF,
17:48 avec 31 000 fichiers EAD, produits à différentes époques selon différentes règles par un nombre de personnes très importants,
17:59 dans un système d'informations qui ne permet pas de les surveiller, nous savions pas très bien à quoi nous avions à faire.
18:09 Nous avons dû explorer en amont le paquet de fichiers, puis en aval le résultat,
18:16 pour mieux cerner les variations et les problèmes de qualité qui n'ont pas manqué de voir le jour.
18:24 Par ailleurs, j'ai pas eu le temps de diffuser l'information encore sur les listes françaises ou francophones,
18:32 mais nous avons publié tout récemment, en octobre dernier, une version 2 du logiciel, qui est complètement conforme à Ricoh 0.2.
18:42 Et si nécessaire, si nous en avons la demande, nous pourrions organiser un webinaire pour présenter cet outil,
18:51 comme nous l'avions fait en juin 2020, de mémoire en pleine période de Covid, d'ailleurs, pour la version 1.
18:59 Alors nous, comme je viens de le dire, nous avons pu mieux cerner certains problèmes de qualité dans les données sources.
19:12 De ce fait, des valeurs de ces données n'étaient pas bien converties. C'est le cas, par exemple, de certains URL qui n'en étaient pas.
19:22 Enfin, c'est un problème classique, mais il est réellement à ne pas négliger. Nous avons d'ailleurs dans le logiciel des messages d'erreur,
19:34 qui ont également été configurés pour, en fonction de ce que nous savons déjà des données sources, émettre des avertissements pour dire, par exemple,
19:47 « cet attribut est censé contenir cette chose-là, mais ne la contient pas ». Je pense à l'utilisation de nos référentiels.
19:56 Nous utilisons beaucoup de référentiels, de vocabulaires, comme Mathieu et Alexandre l'ont dit ce matin.
20:02 Pour aller un peu plus loin, nous avons également pu, évidemment, explorer en Sparkle les données.
20:09 Nous travaillons, par exemple, sur les métadonnées des archives notariales. Nous allons travailler l'année prochaine à améliorer leur qualité.
20:20 Mais nous souhaitons, pour l'avenir, utiliser également d'autres méthodes, et en particulier le langage Shackle,
20:31 qui est donc une spécification du W3C, qui permet de spécifier la structure d'un graphe de connaissances, et non pas son vocabulaire.
20:43 Et pour valider la conformité des données produites, conformité à des règles métiers générales, par exemple, un fonds d'archives devrait avoir au moins un producteur,
20:59 exprimé en langage Shackle ou RDF, mais aussi à des règles spécifiques des archives nationales.
21:08 Par exemple, un record resource devrait avoir un et un seul intitulé, en français,
21:17 ou bien un type de document devrait impérativement faire partie de notre vocabulaire des types de documents.
21:28 Je vous donne des exemples.
21:32 Nous avons donc pu interroger les résultats des conversions en utilisant Sparkle.
21:41 Ici, vous avez par exemple l'exemple d'une requête assez simple concernant les archives que nous conservons,
21:50 qui sont datées d'avant 1939 et qui proviennent d'une étude notariale.
21:56 Cela permet d'avoir transformé les données en un unique graphe de connaissances,
22:02 permet de relier entre elles les informations contenues dans les fichiers EAD et celles contenues dans les fichiers EAC.
22:09 C'est plus difficile à faire dans notre système d'information actuel qu'aujourd'hui avec des données RDF.
22:17 Il a déjà été mentionné plusieurs fois ce matin, mais nous avons mis en place l'année dernière un démonstrateur
22:29 qui interroge le tiers des métadonnées de nos archives notariales, les archives de notaires de Paris.
22:35 C'est un éditeur visuel de requêtes qui permet à n'importe quel utilisateur final de construire sa requête
22:45 en appuyant sur des boutons, en choisissant les entités de départ, les entités cibles et les relations qui peuvent les relier,
22:52 sans connaître SPARQL ni le modèle sous-jacent utilisé, le même outil que Jamie Lee a mentionné tout à l'heure
23:02 et que France Archive emploie également depuis quelques semaines.
23:11 Je n'ai pas le temps d'aller plus loin. Vous trouverez toutes ces informations sur le démonstrateur à cet endroit.
23:23 Il est complètement documenté et interfacé en français et en anglais.
23:28 Une de ses autres qualités, c'est qu'on peut construire des formulaires multilingues.
23:34 Je ne parle pas des données interrogées, ce n'est pas automatique, mais des interfaces, ce qui est intéressant.
23:41 L'interface est entièrement configurable de différentes manières.
23:46 Nous avons choisi de créer une ontologie pour la recherche.
23:51 C'est une des méthodes de configuration de l'outil.
23:53 Nous avons développé une ontologie avec l'aide de Sparna pour interroger nos états données notariales.
24:05 Notamment, à droite de la diapositive, les classes et les relations ajoutées à Ricoh,
24:16 puisque nous avons utilisé une extension de Ricoh mentionnée ce matin par Mathieu Zral.
24:23 Pour terminer, les évolutions que nous prévoyons l'année prochaine,
24:28 c'est la montée de la version 3 de Ricoh Converter conforme à Ricoh 1.0 et qui intègre des règles Shackle.
24:41 Nous prévoyons de faire cela au premier semestre 2024 si possible.
24:47 Puis, en 2025, nous nous attaquerons aux métadonnées de nos archives nativement numériques,
24:54 qui sont exprimées dans un autre format XML.
25:00 Nous aurons probablement besoin de l'ontologie Prémis à cette occasion.
25:07 En ce qui concerne Sparna, nous avons prévu de nouvelles évolutions du logiciel,
25:12 qui a donc évolué dans le cadre du projet dont j'ai parlé à l'instant.
25:16 Notamment, nous avons prévu de construire des formulaires qui hiérarchisent les classes,
25:23 par exemple, ressources archivistiques et en dessous documents,
25:29 ou bien lieu et en dessous voies de Paris.
25:33 Nous avons prévu d'interroger et de consulter les lieux sous la forme de cartes,
25:39 lorsqu'ils ont des coordonnées géographiques.
25:42 Voilà, j'ai terminé. Merci de votre attention.
25:46 [SILENCE]