Tous les billets avec l'étiquette archives

Promenade d'automne - Montagnette. © Photo Myriam Pauillac

Web des données et archives – quel intérêt ?

Une ontologie pour les archives pour quoi faire ?

L’idée de produire une ontologie pour la description archivistique est née d’un besoin. Donner d’abord à nos outils logiciels une orientation pertinente et à même d’anticiper des évolutions technologiques, qui, pour l’instant, semblent tarder à recevoir toute l’attention qu’elles méritent. Et, dans la même veine, participer activement à l’adoption des technologies du web des données dans les archives.
Tout comme, pour l’EAD en son temps, Anaphore avait su intégrer ce format dès 2001 puis lors de sa révision en 2002, participant ainsi activement à son adoption dans les services d’archives en France. Plus de dix ans plus tard, et à l’aune d’une évolution majeure de l’EAD, annoncée mais sans cesse repoussée, le pari tenu du web des données nous semble offrir un moment structurel clé pour l’évolution de nos pratiques.
Sans remettre en cause les fondements de notre métier, la prise en compte des technologies du web sémantique inscrira sans aucun doute la pratique archivistique dans le changement du paradigme numérique de ce début de 21e siècle.
Et ce n’est sans doute pas par hasard que des thématiques récurrentes du Conseil International des Archives et du Service interministériel des Archives de France (SIAF) annoncent depuis quelques années la nécessité de penser un modèle conceptuel pour les archives, mais aussi des travaux en cours allant dans cette direction [1]. Prenant ainsi acte du train déjà en marche pour les autres métiers cousins du patrimoine : bibliothèque, documentation, musées. Chez les premiers, par exemple, la mise en pratique des modèles FRBR et FRAD sonne l’heure d’un nouveau saut normatif.

Le web des données

Encore relativement méconnues, les technologies du web des données ou données liées (linked data), présentent l’immense perspective de la mise en commun, du partage et de la valorisation des métadonnées descriptives dans l’ADN même du Web.
Dit simplement, les données liées renvoient au fait d’utiliser le Web pour créer des relations entre des données de sources différentes, qu’il s’agisse de leur provenance, leur localisation géographique, ou, tout simplement, de systèmes hétérogènes qui, au sein d’une même institution, ne sont pas facilement interopérables.
D’un point de vue technique, il s’agit de données publiées dans le Web, lisibles par des machines, leur sens étant explicitement défini, liées à des sources externes, qui peuvent, à leur tour, être découvertes et atteintes par encore d’autres sources.
La force et l’intérêt des données liées est la capacité de cette technologie d’identifier et de typer les relations entre les entités en utilisant les standards du Web, favorables à la lecture par les machines et permettant de révéler ainsi des interconnections qu’il serait impossible de produire par la seule intervention humaine [2] .
Les standards du Web sont donc à la source même de cette technologie et, en conséquence, indissociables de sa mise en œuvre.

Des standards du Web

Le concept des données liées repose sur deux technologies fondamentales du Web : les URIs, (Universal Resource Identifier ou identifiant uniforme de ressource), et le protocole HTTP (HyperText Transfert Protocol). Les URLs (Uniform Resource Locators), que nous connaissons bien, sont des adresses de documents et autres entités que l’on peut trouver sur le Web. A contrario, les URIs sont un moyen générique d’identifier n’importe quelle entité existant dans le monde.
Les URIs et le protocole HTTP sont complétés par une autre technologie critique au Web des données, le RDF (Resource Description Framework).
Dans le Web des documents, le HTML (HyperText Markup Language), qui nous est plus familier, construit la structure et les relations entre les documents par des liens hypertextes non typés. Le RDF, pour sa part, fournit un modèle de données générique qui se présente sous forme de graphe, permettant ainsi de structurer et de typer les relations entre des ressources décrivant des choses existant dans le monde.

Le RDF est un modèle de données basé sur des triplets. Un triplet exprime un fait et est constitué de trois parties distinctes : sujet, prédicat, objet.
Le sujet d’un triplet est l’URI identifiant la ressource décrite. L’objet peut être une simple valeur littérale, chaîne de caractères, nombre, date ou, alors, l’URI d’une autre ressource, elle-même en relation avec le sujet. Le prédicat, situé entre les deux, indique le type de relation existant entre le sujet et l’objet. Le prédicat est lui aussi représenté par une URI. Les URIs des prédicats sont issues de vocabulaires, c’est-à-dire, des collections d’URIs utilisées pour représenter l’information d’un domaine.

 

L’intérêt le plus immédiat d’utiliser le modèle RDF dans le contexte des technologies du web des données est qu’en ayant recours à des URIs comme identifiants uniques pour nommer toute chose et se référer à tout vocabulaire, ce modèle propose de façon intrinsèque une utilisation à l’échelle globale du Web et permet à toute personne de se référer à toute chose.

 

Le RDF étant un modèle de données et non un format, publier un graphe RDF sur le Web nécessite l’utilisation d’une syntaxe dite de sérialisation RDF. Il existe plusieurs formats de sérialisation standardisés par le W3C comme RDF/XML, Turtle, N-Triples, RDF/JSON, RDFa.

Une ontologie pour modèle conceptuel

Pour reprendre la définition de Thomas R. Guber qui fait autorité : « Une ontologie est la spécification d’une conceptualisation. [...] Une conceptualisation est une vue abstraite et simplifiée du monde que l’on veut représenter. » [3]

Si les vocabulaires représentent l’information d’un domaine, une ontologie est une manière de représenter un domaine par la description formelle des entités ou objets du domaine et des relations entre ces entités. Le résultat de cette formalisation descriptive entité/relation, s’appelle un modèle conceptuel.

Quel intérêt pour les archives ?

Les technologies des données liées offrent la possibilité d’intégrer les métadonnées descriptives des archives dans la fabrique même du Web.
Faire de nos métadonnées descriptives des données liées, c’est rendre visible, lisible et exploitable le contenu de nos archives par les machines et par les humains à l’échelle du Web. Réciproquement, les données liées offrent aux archivistes des moyens sans commune mesure d’enrichir leurs contenus par l’apport de données externes publiées par d’autres fournisseurs du Web.

Pour reformuler la question initialement posée, pourquoi une ontologie par Anaphore pour la description archivistique ? Pour ouvrir aux métadonnées descriptives des archives le chemin des technologies des données liées, métadonnées que nous contribuons à produire par nos outils et par notre connaissance du domaine. Il ne s’agit pas, loin s’en faut, de produire l’ontologie définitive pour les archives (car ne perdons pas de vue qu’une ontologie n’est rien d’autre qu’une vue particulière du monde que l’on cherche à formaliser), mais bien d’offrir une réponse pragmatique à une problématique technique que nous considérons comme essentielle pour l’avenir de nos métiers et par extension du nôtre.

À suivre…

  1. Claire Sibille de Grimoüart, « Les normes de description et les formats apparentés » Journées d’études sur les formats EAD et EAC-CPF. Archives nationales d’outre-mer, 2 juin 2010.
    Nils Brübach, Robert Nahuet et Claire Sibille de Grimoüart, « Une évolution dans les pratiques descriptives – vers un modèle conceptuel archivistique ? » dans Arbido, Norme und Standards. 14 juin 2012, pp. 4-9.
    Conseil international des archives, sous-comité des normes de description, « Rapport d’étape pour la révision et l’harmonisation des normes de description de l’ICA », 4 juillet 2012.
  2. C’est en 2006 que Tim Berners-Lee, principal inventeur du Web, énonça les quatre règles pour publier des donnés sur le Web, règles universellement connues comme les principes des données liées (Linked data principles). http://www.w3.org/DesignIssues/LinkedData.html
  3. http://fr.wikipedia.org/wiki/Ontologie_(informatique) ; http://www-ksl.stanford.edu/kst/what-is-an-ontology.html
Famille de figues sur une table rouillée par une nuit d’été © Photo Myriam Pauillac

Présentation du moteur de recherche Bach

Dans un billet précédent, nous avions présenté les travaux de bibliothécaires et chercheurs qui ont abouti à une nouvelle génération de moteurs de recherche.
Il était, bien entendu, tentant de s’inspirer de ces travaux et d’utiliser les outils disponibles pour élaborer un moteur de type nouveau pour les archives.
Un certain nombre de questions se posait, compte tenu des spécificités de la description archivistique – description à plusieurs niveaux principalement – et des options étaient à prendre pour obtenir, dans un contexte plus complexe que celui des bibliothèques, des résultats satisfaisants et nettement plus pertinents que ceux des différents moteurs existants.
Après plus de deux années de définition du projet, de développements, de tests et d’ajustements, il est temps de présenter Bach, moteur de recherche de nouvelle génération développé au sein de la société Anaphore.

Rappel sur les principales caractéristiques des moteurs de recherche de troisième génération

On se rapportera, bien entendu, au post déjà cité et, mieux encore, à l’ouvrage qu’il s’est contenté de résumer très partiellement [1].
Nous rappelons rapidement les principales caractéristiques de ces moteurs.

A. Un principe de base

Le modèle booléen – qui a été utilisé jusqu’à présent, et est encore utilisé – présente un certain nombre de limites en recherchant une correspondance exacte entre les termes d’une requête et les termes présents dans les descriptions disponibles.
Un nouveau modèle, dit vectoriel, utilise un mécanisme de recherche de correspondance optimale (et non pas exacte) entre ces deux catégories de termes.
De plus, des algorithmes élaborés de calcul de pertinence permettent de classer les réponses.
Grâce à ces deux mécanismes, ces moteurs permettent d’avoir des réponses – pertinentes – qu’un moteur de précédente génération n’aurait pas retournées. Et les réponses les plus intéressantes sont présentées en tête de liste.
La requête commence donc généralement par la saisie d’un ou plusieurs termes. Ce mode de recherche correspond aux habitudes prises par les internautes avec les moteurs grand public. Et il n’est plus nécessaire de maîtriser un langage de requête ni l’utilisation des opérateurs booléens.

B. Des suggestions de termes

En cours de saisie des termes d’interrogation et après validation de la recherche, le moteur suggère des termes possibles pour la requête.

C. Des outils linguistiques

Ces moteurs intègrent généralement des outils qui permettent de remédier aux fautes de saisie (tolérance orthographique), de prendre en compte les différentes flexions d’un mot (masculin-féminin, singulier-pluriel, conjugaison des verbes), les dérivés (noms-adjectifs), de gérer la synonymie…

D. Un affinage des réponses intuitif et par étapes

Dans le cas où les réponses retournées par la requête initiale sont nombreuses, il est possible de les affiner progressivement et intuitivement, grâce à des « facettes » (ou filtres). Celles-ci peuvent être textuelles ou graphiques.

Les spécificités archivistiques

Elles sont de plusieurs ordres et complexifient notre problématique.

A. La description à plusieurs niveaux

Le principe de description à plusieurs niveaux, qui aboutit à la production d’instruments de recherche hiérarchisés, a plusieurs conséquences, principalement sur la recherche par le moteur et sur la façon de restituer les résultats.

1. Sur le fonctionnement du moteur

Les bibliothécaires mettent principalement à disposition de leurs publics des notices catalographiques. Certes, ils peuvent également produire, par exemple, des catalogues thématiques regroupant de nombreuses notices organisées par rubriques. Mais, dans tous les cas, chaque notice contient l’ensemble des éléments nécessaires à la description d’un ouvrage ou de tout autre document.
Dans la pratique archivistique, la description à plusieurs niveaux est de nature différente : chaque niveau ne dit généralement pas tout de la ressource décrite. En effet, sauf au niveau de description le plus haut, une partie des informations descriptives qui permettent d’appréhender cette ressource est consignée dans une ou plus d’une ressource parente. Une description, au niveau le plus bas, peut, par exemple, se limiter à une année. Cela pose, on le comprend, un problème a priori pour la recherche. Pour que le moteur fonctionne, il va falloir gérer l’héritage des informations descriptives pertinentes d’un niveau parent à ses enfants. Mais, il faut que cet héritage soit géré le plus intelligemment possible. Sans héritage, on génère énormément de silence. Avec trop d’héritage on obtiendra beaucoup de bruit. Dans tous les cas, cet héritage ne pourra fonctionner correctement que si la conception, en amont, des instruments de recherche, a été faite de manière intelligente.

2. Sur la présentation des résultats

Les moteurs de recherche des bibliothèques présentent les résultats d’une requête sous forme de liste simple.
Faut-il faire de même pour les archives ou présenter les résultats dans leur contexte organique ? Question importante et la réponse que l’on pourrait donner dépend de qui la donne. On ne caricature pas trop si l’on dit que souvent l’archiviste souhaitera la réponse dans son contexte alors que le public en général, même averti, sera perdu si on ne lui présente pas une simple liste des documents qu’il attend [2].
Les éditeurs de moteurs pour les archives ont généralement privilégié la présentation des résultats dans le contexte. Nous avons pu constater, en interrogeant de nombreux utilisateurs, que cette présentation est considérée comme hermétique.[3] Il faut revenir quelques instants sur la distinction que nous avions soulignée, dans un autre billet, entre données et document pour les descriptions archivistiques. Les moteurs de recherche fonctionnent en mode données et les instruments de recherche sont des documents et ne sont pas optimisés pour leur fonctionnement.

B. La diversité des ressources, de leur description, de leur indexation

Les moteurs pour les bibliothèques fournissent un accès à différents types de ressources : ouvrages, photographies, documents audiovisuels… Mais, ces différents documents sont décrits suivant des règles bien définies.
Pour les archives, les corpus – ensembles de ressources – comprennent les différents types de documents ci-dessus mais, potentiellement, pour toutes époques, toute origines (publiques, privées) concernant tous les domaines de l’activité humaine. Dans ce contexte, les règles de description des documents d’archives sont nettement moins formalisées que pour les bibliothèques, les modes d’indexation peuvent être adaptés aux différentes catégories de documents, tant pour leur forme que pour leur contenu.
Cette diversité des organisations des descriptions et des descripteurs qui servent de facettes complexifie la mise en œuvre des moteurs.

C. L’immensité de la tâche

Les services généralistes sont confrontés à des masses considérables de documents à traiter, avec des ressources humaines insuffisantes. Les descriptions ont été faites à des époques différentes, suivant des méthodes distinctes (la généralisation des normes de description ne date guère de plus d’une décennie), avec des outils souvent mal adaptés. Il s’ensuit une grande hétérogénéité des inventaires qui handicape leur mise en ligne.

Les choix effectués pour Bach

A. Les fonctions des moteurs de troisième génération

Malgré les difficultés prévisibles liées à la spécificité des descriptions d’archives, le pari d’Anaphore a été de mettre les caractéristiques des moteurs de troisième génération, rappelées ci-dessus, au service des descriptions d’archives.
Le moteur est d’abord à destination des publics, qui ont besoin de simplicité, d’intuitivité, d’outils graphiques et qui sont habitués aux moteurs de recherche grand public et commerciaux.
Pour autant, les spécialistes, en particulier les archivistes, ne devaient pas être oubliés et donc disposer de fonctions puissantes.

B. Recherche et navigation

Cette question est, on l’a vu, liée à la spécificité des descriptions d’archives.
Dans la pratique, on peut avoir besoin d’obtenir une réponse précise à une requête précise mais on peut également souhaiter partir à la découverte des ressources disponibles dans un fonds d’archives, voire un ensemble de fonds.
Bach veut offrir à la fois des possibilités de recherche simple et efficace qui conduisent à une liste de résultats et des possibilités de navigation grâce à une présentation structurée des instruments de recherche.
Si l’expérience passée nous a montré que vouloir imposer aux publics une fusion de la recherche et de la navigation aboutissait à des échecs, on doit pouvoir alterner et même associer simplement recherche et navigation.

Principales fonctions de Bach

A. La recherche

1. Une recherche textuelle intuitive et assistée

Ci-dessous quelques exemples de tolérance orthographique + flexions ou suggestions.

tolerence orthographique

 
clic sur le terme suggéré

Un clic sur le terme suggéré relance la recherche.

tolerence orthographique

 

2. Un affinement de la requête par les facettes

Une requête est lancée sur deux termes filature et soie.

requete lancée sur filature et soie

On peut, par exemple, filtrer sur la facette Catégorie avec archives d’entreprises.

filtrage sur la facette Categorie

Le filtre sélectionné s’affiche comme filtre actif et il est possible de le désélectionner si les résultats ne nous conviennent pas.
 

3. Des facettes visuelles

En complément des facettes textuelles, on peut disposer de facettes graphiques : cartographiques et chronologiques.
Par exemple, une carte permet à la fois de localiser les réponses et de filtrer.

la carte localisation et filtrage

Une frise chronologique permet à la fois d’avoir une idée des périodes les mieux représentées et de filtrer sur une période choisie.

frise chronologique

Le fait de draguer une zone sur l’histogramme chronologique a pour effet de préciser la requête. Le nombre de réponses passe de 29 à 15.
Il faut noter que les facettes s’ajustent automatiquement. On voit, par exemple, que la facette Producteur passe de 16 à 10 éléments (il n’y a plus « Afficher plus »).

preciser la requete
 

4. La présentation des résultats de recherche

Bach présente les résultats de la manière la plus simple possible, sous forme d’une liste.
Plusieurs présentations sont possibles. Par défaut, il s’agit d’une liste comportant :

  • Le contexte éventuel (niveaux parents) de la ressource. Ces différents niveaux sont cliquables.
  • Les principaux éléments de description, en particulier l’intitulé ou titre de la ressource.
  • Les descripteurs éventuels, cliquables.
  • Un lien vers une fenêtre affichant le détail de la description (il suffit de cliquer sur le titre de la description).
  • Un lien (Situer dans l’arborescence) donnant accès à l’instrument de recherche
  • Un lien vers un ou plus d’un document numérique, s’il en existe.

mode de presentation des resultats

Ce mode de présentation des résultats par liste permet d’avoir les informations essentielles de manière synthétique. Et, de plus, les détails, les documents numérisés, l’inventaire… tout est accessible par un seul clic.

D’autres modes de présentation des résultats sont possibles, comme les listes sans vignettes ou les mosaïques d’images.

autre mode de presentation
 

5. Le tri des résultats

Par défaut, les réponses sont toujours triées par pertinence. Cette notion de pertinence correspond ici à une réalité, compte tenu du fonctionnement même du moteur. Par exemple, une interrogation halle aubais renverra toutes les descriptions comportant soit halle (ou halles) soit Aubais, soit les deux, mais les descriptions contenant les deux seront affichées en premier.

tri des resultats

D’autres modes de tri sont proposés : alphabétique, chronologique et suivant la logique de l’inventaire (nous allons revenir sur ce dernier point).

6. Le mode booléen n’est pas interdit

Notons, par parenthèses, que l’emploi des opérateurs booléens reste possible pour les habitués. Le modèle booléen reste donc accessible, tout en conservant l’avantage de la tolérance orthographique, comme le montre l’exemple suivant.

mode booleen accessible

 

B. La navigation dans les inventaires

Bach offre un accès au cadre de classement, s’il existe, et aux instruments de recherche. Ces derniers sont accessibles par le cadre de classement et par les réponses (liste ou détail).
Il est ainsi possible de naviguer, à partir du cadre de classement ; de situer une réponse à une requête dans son contexte et de poursuivre, ainsi, une recherche par une navigation. Il est également possible, lorsque l’on est sur un inventaire, de lancer une requête. Celle-ci est alors lancée dans l’instrument de recherche correspondant. On revient alors sur la fenêtre de recherche et il est possible de lancer de nouvelles requêtes.
Ci-dessous un exemple de boucle de ce type.
On lance une requête précise, à l’aide d’une expression.

lancement d'une requête précise

On obtient une réponse unique.
On clique sur « Situer dans l’arborescence ». L’instrument de recherche hiérarchique s’ouvre ; la description correspondante se trouvant en haut de l’affichage et surlignée.

résultat clic situer dans l'arborescence

Un clic sur la ligne surlignée (ou sur toute autre) affiche le détail de la description.
Ce qui nous intéresse ici, c’est la zone de recherche.
Saisissons une requête.

saisie de la requete

En validant, nous nous retrouvons sur la fenêtre de recherche. Nous pouvons faire plusieurs remarques.

  • Les réponses se situent toutes dans l’instrument de recherche d’origine, ce que confirme le filtre actif.
  • Le nombre de réponses est important (369) puisque les descriptions contenant porte(s) ou château sont prises en compte.
  • Les réponses contenant à la fois château et porte viennent en premier.
  • Parmi celles-ci, celles qui concernent la commune de Portes viennent avant, par exemple, celle concernant la porte du château d’Aubais, du fait d’un calcul de pertinence efficace.

fenetre de recherche

Un moteur pour les archives et les archivistes

On a compris que d’importants efforts ont été faits en direction des publics finals qui doivent être les principaux utilisateurs du moteur.
Toutefois, Bach est un moteur de recherche pour les descriptions d’archives qui prend en compte les spécificités du domaine archivistique. Nous avons déjà évoqué les principales caractéristiques archivistiques de ce moteur. Nous allons les récapituler et les compléter.

Les listes de réponses situent chaque occurrence dans son contexte hiérarchique, présenté en haut de la réponse.

liste de réponses

Les réponses détaillées présentent également les niveaux parents et les niveaux enfants (quand ils existent) d’un niveau donné.

réponse détaillée

L’accès à l’instrument de recherche complet se fait aussi bien à partir de la liste que du détail des réponses.

Les facettes peuvent, bien entendu, être « archivistiques », comme dans l’exemple ci-dessous.

facettes archivistiques

Le classement des réponses suivant l’ordre de l’inventaire. Les réponses à une requête sont alors classées suivant l’ordre dans lequel les descriptions se trouvent dans l’instrument de recherche.

La notion de niveau. Le terme sera peut-être à reprendre. Un instrument de recherche est généralement constitué d’une description de niveau haut (par exemple fonds), de descriptions de niveaux intermédiaires (par exemple groupes de documents) et de descriptions de niveau bas (par exemple dossiers ou pièces). Dans une liste de réponses, on peut avoir des descriptions correspondant à ces différents niveaux.
Dans l’exemple ci-dessous, la première description correspond à l’ensemble de l’instrument de recherche, la deuxième au premier titre de niveau 1, la troisième au premier titre de niveau 2, la quatrième au premier article.
On voit aussi que la facette niveau indique qu’il existe une description pour l’ensemble, 381 pour des groupes de documents et 2.817 pour les documents (ici, des pièces).

facette niveau

En filtrant sur « document », on n’a que les descriptions des pièces.

filtre document

Les recherches nominatives

Bach a été conçu non seulement pour exploiter les instruments de recherche archivistiques conçus suivant la norme ISAD(G) et la DTD EAD, mais aussi pour les recherches dans des bases de données nominatives.
Un onglet permet de chercher dans les registres matricules militaires.

A. Principe de recherche

Le même principe de recherche simple par texte a été retenu, avec une zone unique de saisie. Si l’on saisit, par exemple, « jean bernard » qui sont tous les deux à la fois des prénoms et des noms très courants, on obtient de nombreuses réponses (5.082), mais celles qui contiennent à la fois Jean et Bernard comme nom et prénom viennent en premier.
Des facettes Nom, Prénom, Classe et Lieu de naissance permettent, si nécessaire, d’affiner les requêtes.

registre matricule

On peut, ici aussi, fonctionner en mode booléen en saisissant, par exemple « jean AND bernard ». Le nombre de réponses est effectivement plus réduit (25).

Notons que l’on peut aussi utiliser Bach pour faire des statistiques sur les occurrences de noms. En cherchant toutes les réponses, on obtient, dans cette base, 60.798 réponses. Grâce aux facettes, on voit d’emblée les 10 noms les plus fréquents.

facette nom

En cliquant sur « Afficher plus », on obtient l’ensemble des noms, par défaut dans l’ordre alphabétique et que l’on peut classez par occurrences.

ensemble des noms par nombre d'occurrence

Une zone de recherche permet de filtrer sur un ou plus d’un nom

zone de recherche
 

B. Affichage des résultats

Les résultats des recherches sont ici affichés sous la forme d’un simple tableau à colonnes.
La première colonne affiche une icône page qui permet d’ouvrir la description complète correspondant à la ligne.
La deuxième colonne, avec une icône appareil photo donne accès à la visionneuse d’images.
Ici encore, notre objectif a été de limiter le plus possible les clics nécessaires pour arriver à l’information recherchée.

Et maintenant ?

Après plus de deux années de travail, nous disposons maintenant d’une version bien élaborée de Bach. Plusieurs mises en ligne auraient déjà dû avoir lieu, Anaphore étant prête, mais les services commanditaires ont pris un peu de retard pour diverses raisons.
Bach et la visionneuse d’image qui l’accompagne sont des outils open source. Anaphore a prévu de mettre ces sources à disposition très bientôt.
Bien entendu, Bach continuera à évoluer grâce aux développements réalisés chez Anaphore et, peut-être, par d’autres.
Toutes vos remarques, critiques et suggestions seront les bienvenues.

Un petit site de présentation de Bach est disponible. Cette présentation donne accès à une application de démonstration avec seulement un instrument de recherche et une base de données « registres matricules ». Nous tenons à remercier les archives départementales du Gard et de Vaucluse pour nous avoir autorisés à monter certaines de leurs données qui ne sont pas encore officiellement diffusées.

Bach est le résultat de l’expérience et des réalisations accumulées par Anaphore au cours de plus de 20 ans au service des archives et des archivistes.
Bach, tel qu’il est aujourd’hui, a nécessité de nombreuses heures de conception, de développement, de tests, d’ajustements.
Le développement a été commencé par cinq élèves-ingénieurs de l’école Nancy Télécom (ex ESIAL) pendant l’année universitaire 2012-2013.
Johan Cwiklinski a repris le projet à partir d’avril 2013 et a réalisé une très grande partie des développements.
Vincent Fleurette et Sébastien Chaptal, jeunes développeurs, travaillent désormais également sur Bach.

Et, l’histoire continue…


  1. Catalogue 2.0 : The future of the library catalogue. Edited by Sally Chambers. Facet Publishing, 2013. ISBN 978-1-85604-716-6
  2. On pourra revenir, à ce sujet, sur le billet La description archivistique à l’ère du numérique – Part 1 et au commentaire : « Il faut avoir fait l’école des Chartes pour utiliser ça ! »
  3. Dans le même billet, nous avions aussi cité Eric Lease Morgan pour lequel l’instrument de recherche impose un point de vue propre à l’archiviste.
Rocher dans les Alpilles ©Myriam Pauillac et Louis Colombani

Penser, modéliser (pour le web de données) – Part 2/2

Je donnais précédemment quelques retours d’expérience sur la création d’une ontologie OWL de description des fonds d’archives, initiée par la société Anaphore. Je voulais ici mettre en avant quelques points précis de ce modèle, quelques-uns des choix de modélisation qui ont été faits pour répondre à certaines questions que nous nous sommes posées, et qui peuvent se retrouver dans d’autres cas. Pour ceux qui s’intéresseraient plus largement aux motifs de conception en OWL (« ontology design patterns »), je renvoie au site ontologydesignpatterns.org (dont je dois admettre que je ne me sers pas moi-même).

Réutiliser d’autres vocabulaires/modèles

Le web de données permet de partager et relier des données sur le web, et il permet également de partager et relier des modèles de données. Réutiliser un modèle déjà existant pour exprimer ses données permet :

  1. de bénéficier de la réflexion et des bonnes pratiques de modélisation qui ont sédimenté dans ce modèle
  2. et de rendre les données ainsi exprimées plus facilement compréhensibles et compatibles avec d’autres applications.

Il est donc tout à fait possible pour modéliser son domaine de « faire son marché » parmi les modèles déjà publiés, par exemple en parcourant l’annuaire du LOV (Linked Open Vocabularies). Trois modèles notamment sont réutilisables presque à tous les coups : FOAF pour décrire des personnes, des organisations et des documents, DCTerms pour des métadonnées qui s’appliquent largement (« creator », « subject », « publisher », etc.), et SKOS (dont je re-mentionne au passage la traduction française) pour tout ce qui est liste contrôlée. Ces 3 vocabulaires sont d’ailleurs les plus réutilisés dans l’écosystème des modèles du web de données.

Outre ces 3 vocabulaires, nous avons également pour le modèle de description des fonds d’archives réutilisé OWL Time pour la représentation des dates et des intervalles temporels, wgs84_pos pour l’expression des latitudes/longitudes, et une seule propriété de PROV-O, le modèle de description de la provenance récemment recommandé par le W3C (voir plus bas).

Qualifier les propriétés

Si vous lisez ceci je ne vous apprendrai rien en disant que RDF est un modèle de triplets, sujet-prédicat-objet (dans le cas contraire, voir cette introduction). Donc en RDF on dit : « L’entreprise Lafarge (sujet) possède un siège social (prédicat) en France (objet) ». Le problème, dans les descriptions archivistiques, c’est que les entités sont décrites, par définition, au passé. Et que, dans le passé, il s’en est passé des choses, justement, et que les informations relatives à une entité ont évolué. Il faut donc être capable, pour toutes les informations composant la description d’une entité (nom, siège social, liens avec d’autres entités…), de les qualifier avec des dates de validité (et pourquoi pas également des lieux de validité). C’est-à-dire qu’au lieu de dire « Lafarge possède un siège social en France », on dit « Lafarge entretient une relation de siège social avec la France, relation qui était valable jusqu’en avril 2014 » (le cimentier Français ayant décidé de déplacer son siège social en Suisse après sa fusion avec Holcim).

On dit qu’on réifie la relation, on la transforme en ressource à part entière pour pouvoir exprimer des choses dessus. Autant dire que cela complexifie nettement le modèle. Mais c’est le prix à payer pour structurer ces informations complexes. Dans la syntaxe RDF Turtle, on passe, sans qualification de dates, de :

ex:Lafarge mdfa:pays ex:France .

 
à ceci, avec une date de validité exprimée à la fois comme date structurée (« 2014-04-11 ») et à la fois comme chaine de caractères (« jusqu’en avril 2014 ») :

ex:Lafarge mdfa:pays _:b .
 _:b rdf:type mdfa:RelationLieu .
 _:b mdfa:lieu ex:France .
 _:b mdfa:dateValidite _:c .
 _:c time:hasEnd _:d .
 _:c rdfs:label "jusqu'en avril 2014" .
 _:d time:inXSDDateTime "2014-04-11"^^xsd:date .

 
Ou, en notation Turtle abbréviée :

ex:Lafarge mdfa:pays [
 rdf:type mdfa:RelationLieu ;
 mdfa:lieu ex:France ;
 mdfa:dateValidite [
 time:hasEnd [
 time:inXSDDateTime "2014-04-11"^^xsd:date ;
 ] ;
 ] ;
 rdfs:label "jusqu'en avril 2014";
 ]

Prendre en compte les valeurs textuelles

J’espère qu’aucun archiviste qui lit ceci ne sera vexé si je dis que les descriptions d’archives actuelles ne sont pas très structurées. J’entends par là que, de ce que j’ai pu en voir, le contenu des descriptions est essentiellement textuel, et que peu de listes contrôlées ou de thesaurus sont utilisés pour structurer les valeurs que l’on renseigne dans les différents champs de la description. D’autre part, par la force des choses, certains éléments d’information sont manquants, ou imprécis, et il peut être difficile ou impossible de leur donner une valeur contrôlée. Quelques exemples :

  • Pour indiquer la plage de date couverte par un fonds d’archives : « 1923-1932, 1936-1945 (manque 1933 à 1935) » (tiré de la norme ISAD(G)) ;
  • Pour indiquer la modalité d’entrée d’un fonds aux services d’archives : « Don de la Société ardoisière de l’Anjou (exploitation de Renazé) aux Archives départementales de la Mayenne, 1969 » (tiré de la norme ISAD(G)) ;
  • Pour indiquer une source complémentaire à un fonds (un autre fonds d’archives, géré dans un autre service, pouvant donner des informations supplémentaires sur les mêmes institutions/personnes/lieux) : « Archives départementales de la Savoie $ SA 243-244 : collèges d’Avignon (dont celui d’Annecy) ».

La création d’un modèle de description des fonds d’archives ayant pour objectif de structurer de telles descriptions se doit à la fois de les amener à plus de structuration pour améliorer l’accès et la gestion de l’information, et en même temps se doit de rester compatible avec les données telles qu’elles sont aujourd’hui; c’est-à-dire qu’il faut tout à la fois conserver la valeur de date « 1923-1932, 1936-1945 (manque 1933 à 1935) » sans perte, et en même temps permettre de structurer cette valeur si possible, pour donner la possibilité de rechercher les fonds en utilisant une plage de dates que l’on sélectionne dans des calendriers, ce qui n’est pas possible si les informations de dates sont laissées textuellement.

Cela a eu des conséquences à plusieurs endroits dans le modèle :

  • Première conséquence, lorsqu’il est nécessaire d’indiquer une référence à un autre fonds d’archives, géré par un autre service d’archives, il faut pouvoir y faire référence même si ce fonds ne possède pas (encore) d’URI sur le web de données. RDF propose pour cela un mécanisme de nœuds blancs, ou nœuds anonymes, permettant d’associer des informations à une ressource dont on ne connait pas l’identifiant, ou qu’on ne souhaite pas identifier avec une URI. Cependant ce n’est pas vraiment ce que l’on veut faire ici. Lorsque l’on indique comme source complémentaire « Archives départementales de la Savoie $ SA 243-244 : collèges d’Avignon (dont celui d’Annecy) », il ne s’agit pas nécessairement du titre exact ou de la cote exacte d’un autre fonds, mais simplement d’une référence textuelle à quelque chose (peut-être à plusieurs choses d’ailleurs) dont le titre par exemple, est différent de ce que l’on indique en y faisant référence. Le modèle contient donc un mécanisme de référence textuelle pour faire référence à un fonds ou à une entité, qui permet :
  1. de rester compatible avec les valeurs textuelles existantes dans les données actuelles ;
  2. de pouvoir faire référence à un fonds ou à une entité dont on ne connait pas précisément le titre, l’intitulé ou l’URI ;
  3. de pouvoir travailler dans un mode « on exprime la relation d’abord, et on essaie de résoudre la valeur contrôlée ensuite » ;
  4. de pouvoir travailler à un niveau de granularité et de finesse que l’on choisit (trouver/sélectionner la bonne valeur contrôlée prend du temps, en rester à une référence pas/peu contrôlée est plus simple).

 Prenons l’exemple d’un fonds d’archives qui serait la copie d’un autre, et dont on veut indiquer l’original :

On peut indiquer cette référence sous forme de texte ainsi :

ex:fondsArchives_1 mdfa:aPourOriginal [
 mdfa:referenceTextuelle "collège Saint-Nicolas d'Annecy (1642-1785)." ;
 ]

 

Ou bien résoudre la référence, trouver la bonne URI contrôlée, et l’indiquer :

ex:fondsArchives_1 mdfa:aPourOriginal [
 mdfa:referenceTextuelle "collège Saint-Nicolas d'Annecy (1642-1785)." ;
 mdfa:ressource ex:uriUnAutreFondArchives ;
 ]

 

  • Deuxième conséquence sur la description des dates : les dates mentionnées dans les descriptions de fonds sont soit :
  1. compliquées à décrire (« 1923-1932, 1936-1945 (manque 1933 à 1935) »)
  2. ou imprécises (« milieu du XIXème siècle »).

On ne peut donc pas se contenter de 2 propriétés de dates (début et fin), il faut également pouvoir associer à l’information de date une description textuelle, et donner la possibilité, lorsque cela est possible/souhaitable, de structurer l’information. Pour cela nous avons réutilisé l’ontologie OWL Time qui permet de décrire des intervalles de dates, et d’associer à l’intervalle lui-même, ou bien à une date de début ou de fin d’intervalle, une description textuelle aussi bien qu’une information de date contrôlée.

Premier exemple, pour décrire les dates de contenu d’un fonds :

:fondsArchives_1 mdfa:datesContenu [
 rdfs:label "Du 1er janvier 1920 jusqu'aux environs de 1951"
 time:hasBeginning [ time:inXSDDateTime "1920-01-01"^^xsd:dateTime ] ;
 time:hasEnd [ time:inXSDDateTime "1951-01-01"^^xsd:dateTime ] ;
 ]

 

Deuxième exemple, pour décrire les dates de naissance et de décès d’une personne :

:personne_1 mdfa:datesExistence [
 rdfs:label "Date de naissance inconnue, mort le 23/10/1873"
 time:hasEnd [ time:inXSDDateTime "1873-10-23"^^xsd:dateTime ] ;
 ]

 

  • Troisième conséquence sur des propriétés tantôt littérales, tantôt contrôlées ; RDF et OWL permettent, on a un peu tendance à l’oublier, de déclarer des propriétés sans préciser si leur valeur sera une valeur contrôlée ou une valeur littérale. C’est ce que fait SKOS par exemple, pour les propriétés de notes descriptives : une note SKOS peut être une valeur littérale, ou une référence à une entité représentant la note (voir le SKOS PRIMER). De telles propriétés sont des Annotation Properties. C’est ce mécanisme que nous avons utilisé pour déclarer par exemple les propriétés correspondant au statut juridique, à la modalité d’entrée ou au support d’une ressource archivistique. Cela veut donc dire par exemple que, dans le cadre de cette ontologie, on laisse le choix de décrire les statuts juridiques comme une liste de valeurs contrôlées par un thesaurus en SKOS, ou bien comme une valeur textuelle libre.

On pourra donc dire tout aussi bien, pour indiquer la langue en utilisant une valeur contrôlée :

ex:notice_de_fonds_archives_1 dcterms:language <http://lexvo.org/id/iso639-3/lat> .

(on utilise dans cet exemple l’identifiant de langue latine issu de Lexvo, mais tout autre thesaurus contrôlé des langues peut faire l’affaire).

Ou bien ceci, en utilisant une description textuelle :

ex:notice_de_fonds_archives_1 dcterms:language "Latin. Ecriture insulaire
(noter en particulier l'abréviation utilisée pour per)" .

Spécialiser les entités

La vision du monde RDF et OWL comporte un présupposé majeur : il existerait dans le monde réel des « choses » que l’on peut identifier de manière certaine, que l’on peut isoler des autres, et auxquelles on peut donner une URI. C’est une vision où le monde se « discretise » pour mieux se manipuler. Une manipulation du monde sans le langage. Mais il n’est pas du tout sûr que des « entités » que l’on puisse identifier et isoler existent ailleurs que dans notre tête (je crois que Chomsky et Gondry parlent de ça, si j’ai bien compris, mais il faudrait que je revoie le film). Et une vision du monde qui ne prend pas en compte l’aspect temporel. Alors que tout change. Qu’on ne se baigne jamais deux fois dans la même eau. Que seul le changement est permanent. etc.

Mais revenons à nos archives pour replacer ce problème en contexte : l’archiviste décrit toujours une entité (comme une société par exemple) en regardant dans le rétroviseur, au passé. On ne décrit donc pas « une société », on décrit « la vie de la société ». Est-on en droit de dire que l’on parle de la même société lors de son immatriculation et 30 ans plus tard quand elle est devenue une multinationale ? Est-ce que la société Apple au début des années 1980 et la société Apple en 2014 sont la même chose ? peut-être pas. Ou pas complètement. Tout ce qui se rapporte à « Apple au début des années 1980 » ne se rapporte pas forcément à « Apple en 2014 ».

On ne peut pas se contenter d’assigner une seule URI unique pour identifier une entité dont on souhaite rendre compte de l’évolution. Il nous en faut plusieurs. Et autant le point de départ de ce paragraphe nous a emmené dans des questions philosophiques théoriques, autant la solution pragmatique à ces questions est simple. Le modèle d’ontologie proposé par le W3C pour décrire la « provenance » (on dirait plutôt l’ « origine » ou l’ « historique », en français), PROV-O, propose 2 notions intéressantes : la notion d’ « Entité » (qui peut être ce qu’on veut : « An entity is a physical, digital, conceptual, or other kind of thing with some fixed aspects ; entities may be real or imaginary. ») , et la notion de « spécialisation d’entité ». Et c’est cette dernière notion qui va particulièrement nous intéresser : la « spécialisation » d’une entité « en possède toutes les caractéristiques et présente en plus certains aspects spécifiques de cette entité. En particulier la plage de validité (lifespan) de l’entité qui est spécialisée contient les plages de validité de ses spécialisations. Des exemples de spécialisation peuvent être une période de temps ou un certain contexte. »

On pourra donc par exemple avoir

  1. une URI pour désigner « Apple » en tant qu’entité générique
  2. une URI pour chaque grande période de la vie de société, comme par exemple les 6 grandes périodes décrites dans l’historique de la page Wikipedia :
ex:Apple_entre_1976_et_1980 prov:specializationOf ex:Apple_en_general .
 ex:Apple_entre_1981_et_1989 prov:specializationOf ex:Apple_en_general .
 ex:Apple_entre_1990_et_1999 prov:specializationOf ex:Apple_en_general .
 etc...

 
La finesse du découpage de la vie de l’entité en périodes historiques est laissée à l’appréciation de chacun. Les ressources archivistiques peuvent alors se rapporter soit à l’entité « générique », soit à l’une de ses « spécialisations ». Chacune des spécialisations portera ses caractéristiques propres (nombre d’employés, siège social, organigramme, etc.). On gagne en finesse de description de l’entité, et en finesse d’indexation des ressources.

Rocher dans les Alpilles ©Myriam Pauillac et Louis Colombani

Penser, modéliser (pour le web de données) – Part 1/2

J’ai récemment eu le plaisir de collaborer avec la société Anaphore à la mise au point d’un modèle d’ontologie pour décrire des fonds d’archives. S’il ne m’appartient pas de dévoiler le contenu de ce modèle qui sera je l’espère rendu public dans quelques semaines, je voulais donner quelques retours d’expérience sur le processus de modélisation lui-même, ainsi que sur quelques motifs de conception que nous avons mis en œuvre (dans un second article).

Pour quoi modélise-t-on ?

La question n’est pas aussi simple qu’il n’y parait, et il y a tout à gagner à mettre à plat dès le début du travail de modélisation la distinction entre :

  • un modèle/format de travail ;
  • un modèle/format d’échange ;
  • et un modèle conceptuel.

Est-ce que l’on cherche à définir un modèle de travail qui sera utilisé à l’intérieur d’un système logiciel (le schéma des tables de sa base de données, pour faire simple) ? ou bien est-ce qu’on cherche à définir un modèle d’échange qui sera fait pour publier les données à l’extérieur du système logiciel, sur le web de données ? La distinction est empruntée à Bruno Bachimont (dans Ingénierie des connaissances et des contenus : le numérique entre ontologies et documents (Lavoisier, 2007)) :

« Les formats d’échange permettent de rendre lisibles par différentes applications les mêmes données. Les formats de travail permettent à une application d’effectuer tous les traitements nécessaires et de créer les structures à cet effet. »

Ou bien encore, et c’est un peu différent, est-ce que l’on cherche à esquisser un modèle conceptuel du domaine, c’est-à-dire se mettre d’accord sur les principales entités de ce domaine et les relations qu’elles entretiennent entre elles, sans rentrer dans les détails d’implémentation ? FRBR par exemple est un modèle conceptuel, et RDA est une implémentation de FRBR en tant que modèle d’échange; et rien n’implique qu’un logiciel compatible avec ce format d’échange l’utilise effectivement en tant que format de travail; il y a même toutes les chances que non.

La distinction entre ces 3 objectifs est importante car chacun va apporter ses contraintes : par exemple, faire le modèle de travail d’une application implique de prendre en compte des contraintes de facilité de saisie ou de navigation dans les données pour l’utilisateur, ou de traçabilité des informations (quel utilisateur a créé quoi). Faire un modèle de publication pour le web de données amène des contraintes de facilité de compréhension, et de réutilisation du modèle. Faire un modèle de domaine ne demande pas de rentrer dans le détail de chaque propriété et de chaque relation, mais d’être tout à fait clair sur la définition de chaque entité.

Retour d’expérience numéro 1 : déterminer précisément l’objectif du modèle : modèle interne à une application, modèle de publication, ou modèle conceptuel.

« Be real »

Les modèles, les ontologies et tous ces bazars conceptuels ont ce côté rassurant des arrières-mondes que l’on fabrique pour s’échapper du douloureux réel. Tant que l’on reste dans le modèle, tout va bien, mais quand on commence à regarder les données, les vraies données qui existent réellement pour de vrai, ça fait toujours un peu mal : on a oublié de prendre en compte telle colonne dans le fichier de données, telle autre contient du texte alors qu’on avait prévu une référence contrôlée, etc. Pour paraphraser la boutade philosophico-geek « le réel, c’est ce qui fait mal quand on éteint l’ordinateur », on pourrait dire « les données, c’est ce qui fait mal quand on a fini le modèle ». « Reality is broken », par essence.

Non content de faire un modèle avec des boîtes et des flèches, il faut travailler le plus tôt possible dans le processus de modélisation sur les vraies données. Les exemples de données existantes exprimées suivant le modèle conçu doivent faire partie des livrables, autant que le modèle lui-même.

Retour d’expérience numéro 2 : travailler sur des exemples de vraies données, en les exprimant dans le modèle cible.

Modéliser c’est communiquer

Tous les modèles sont imparfaits, on a beau le savoir il faut se le redire sans cesse pour ne pas oublier la réalité que ce modèle tente de capturer. Ce n’est pas la réalité qui est cassée (« reality is broken »), ce sont nos modèles. Ou plutôt, la réalité est cassée parce qu’on en fait des modèles.

Tous les modèles sont imparfaits, car, malgré toutes les précautions que vous aurez prises pour faire émerger une objectivité, celle-ci ne restera finalement que votre vision du monde, la vôtre personnellement, ou celle du groupe de gens qui ont participé à sa mise au point. Éternelle subjectivité. Et c’est précisément parce que votre modèle est subjectif qu’il faut être capable de l’expliciter, de l’expliquer, de le communiquer aux autres. Le modèle doit servir de moyen, de support à la communication de votre vision du domaine métier. Il doit permettre d’instaurer un dialogue. Éternelle inter-subjectivité. Dès lors, il faut s’appliquer à rendre le modèle communicable :

  • 99% des modèles OWL que l’on trouve sur le web utilisent des URIs et des libellés en anglais. Mais pourquoi ne pas faire un modèle en français, si on le voit comme un support de communication à destination d’acteurs francophones ? c’est le parti que nous avons pris avec Anaphore. Pensons local avant de penser universel, il sera toujours temps, le jour où le modèle aura un succès international, de le traduire.
  • un fichier d’ontologie OWL ne suffit pas; c’est incompréhensible. Faites des diagrammes, des schémas, dès le début du processus de modélisation, pour vous mettre d’accord et pouvoir parler du modèle. La communication autour du modèle commence dès sa conception ;
  • c’est une évidence, mais documentez les classes et les propriétés du modèle, et le modèle lui-même, en suivant les pratiques de bon sens documentées dans le LOV ;
  • utilisez les outils de génération automatique de documentation à partir du fichier OWL, comme LODE ou Parrot. Nous avons utilisé LODE pour son rendu propre et la possibilité d’intégrer les images des diagrammes dans la documentation;
  • prévoyez un moyen de recevoir du feedback une fois votre modèle publié; a minima une adresse e-mail, ou une mailing-list, un forum, un formulaire de suggestion, un hashtag, ce que vous voulez, mais permettez qu’un dialogue s’instaure.

Retour d’expérience numéro 3 : penser dès le départ le modèle comme un moyen de communication, autant qu’un moyen de structurer les informations dans un système informatique.

Un arbre plutôt que du marbre

Si vous vous placez dans la perspective de publier un modèle OWL sur le web, il faut envisager cela à la fois, bien sûr, comme l’aboutissement d’un travail de réflexion, mais aussi comme le début d’un processus d’évolution. Ne pensez pas que votre modèle va être figé une fois publié. Si, comme évoqué précédemment, vous avez tenu compte de la réalité des données, et que vous avez prévu les moyens de dialogue et de feedback, alors votre modèle évoluera en tenant compte des évolutions dans l’expression des données et des retours de la communauté. Soyez donc prêt à prendre en compte ces retours, en prévoyant pourquoi pas un mécanisme de versioning, et en établissant clairement le processus de mise à jour; sans faire l’erreur de FOAF qui a incorporé un numéro de version dans son URI, en étant maintenant incapable de la changer sans embêter tous ses utilisateurs !

« …the technical namespace ID [of FOAF] remains fixed and includes the original value of « 0.1″. It long ago became impractical to update the namespace URI without causing huge disruption to both producers and consumers of FOAF data. We are left with the digits « 0.1″ in our URI. This stands as a warning to all those who might embed metadata in their vocabulary identifiers. »

Bref, pensez à votre modèle comme quelque chose de vivant, un arbre plutôt que quelque chose de figé dans le marbre. Une certaine automatisation dans son processus de publication sur le web peut donc être bienvenue.

Évidemment, si votre modèle est un modèle de travail interne pour une solution logicielle, son évolution est moins aisée, la problématique est différente.

Retour d’expérience numéro 4 : penser à l’évolution du modèle une fois sa mise en ligne, ne pas hésiter à le faire évoluer.

 

Le second volet de ces quelques réflexions, dont le titre « Penser, modéliser » s’inspire du livre « Penser, classer » de Georges Perec, sera consacré aux motifs de conception (design pattern) utilisés pour construire ce modèle de description des fonds d’archives.

Extrait de la correspondance de Galilée, 1610 © Myriam Pauillac

A prototype ontology schema: my experience at the Historical Archives of the Pontifical Gregorian University (APUG)

Une ontologie pour les archives : l’exemple de l’APUG

C’est à l’automne dernier que nous avons eu le grand plaisir de rencontrer Damiana Luzzi et de faire la connaissance de Padre Moralès et Irene Pedretti, ces derniers respectivement responsable et archiviste des archives historiques de l’Université Pontificale Grégorienne, à Rome.

Damiana et Irene collaborent depuis 2010 au développement d’une ontologie pour la description des archives conservées par l’APUG. Dans la perspective annoncée de l’évolution vers un modèle conceptuel pour les archives [1] et de l’inhérente évolution des normes et formats standard qui devrait en découler, la démarche de nos voisins nous a semblé singulièrement intéressante.

En effet, dans le contexte d’un petit service dépositaire d’un fonds extrêmement précieux et varié (archives, manuscrits, ouvrages, objets, etc.), il s’agissait d’inscrire la production des métadonnées descriptives dans la perspective d’une utilisation des technologies les plus avancées d’Internet et du Web sémantique sans pour autant négliger les fondamentaux métier et tout en visant un niveau très fin de granularité.

Damiana nous livre ici une synthèse de la démarche adoptée et de leurs options. Nous avons fait le choix de laisser le texte de Damiana dans sa version originale.

The Historical Archives of the Pontifical Gregorian University (APUG) owns a precious heritage formed by many of the manuscripts belonging to the Roman College, founded by the Jesuits in 1551.
APUG
Facade PUG

The college was closed at the time of the Society of Jesus’ Suppression in 1773. It was later reopened in 1824, ten years after the restoration of the Society, and continued its educational function until today, as Pontifical Gregorian University.

Because of this long history APUG describes the educational practices over a large stretch of time, about five centuries. Its funds comprises more than 5000 codes attesting the lessons in the Roman College such as: rhetoric, grammar, theology, philosophy, that were hold during two centuries, in addition to the studies of Greek and Latin classics, astronomy, mathematics and physics, and Latin, Hebrew, Greek and Arabic languages. Along with this material, other important documents attest to the fervid activity of research and study that took place at the Roman College:

  • the correspondence of Athanasius Kircher, Christopher Clavius;
  • the codes used by Sforza Pallavicini to write the Story of the Council of Trent;
  • other documents show the relations that many Jesuits around the world maintained with the masters of the Roman College;
  • the first topographic maps of China made by the Jesuit D’Elia and documents on the missions in Asia.

The material includes:

  • printed texts, some of these glossed by author and with notes of the censors;
  • about 6,000 manuscripts with handmade illustrations, glosses, erasures and some of these with insertion of papers and fragments;
  • many modern archival documents;
  • ancient and modern books, both with a lot of handwritten notes;
  • graphic material, such as drawings, prints, maps and photos.

Moreover, the APUG funds attest to the extra educational activity of the teachers, especially for the XIX and XX centuries: so, for example, it also hold documentation from the Second Vatican Council, where some Jesuits professors at Pontifical Gregorian University had an important role. At the end, the troubled vicissitudes lived, especially in Rome, by the Jesuits and other religious Orders’ goods after the unification of Italy, have brought among the APUG funds a lot of “stranger” documents, sometimes totally disconnected from its history.

This variety of resources implies, apart from preservation issues, at least one kind of problems connected with theirs cataloguing: to describe different resources, the standards developed for each of them were used: ISAD(G) [2] for archival documents, FRBRoo Model [3] for bibliographic material or ISAAR [4] and FRAD [5] for authority records, and so on. Usually these standards have their own software expressly developed to simplify their use, application and search.

Trying to give a different answer to these problems, at the end of 2010 APUG contacted the Digital Renaissance Foundation, an Italian institution which was specialized in the development of advanced solutions for cultural heritage (e.g. semantic web technologies) and with whom I was working. In close collaboration with the staff of the APUG, I developed a prototype of ontology schema which could solve the cited problems without neglecting the principles of APUG work, especially in terms of standardization and conceptualization, and which would allow APUG to describe a great variety of resources at a deeper level. Here are two examples taken from the prototype ontological schema.

The Physical Object and document description

The detailed information about the physical aspect of the resources, in particular about manuscript, is structured on FRBRoo Model, an evolution and merging of CIDOC CRM and FRBR. FRBRoo Model has provided a new class inside the conceptualization, the F4 Manifestation Singleton, expressly thought for the manuscripts.
The Item class provided a detailed description of all the physical elements which compose the document, e.g. binding, material (paper, parchment etc.), damages, restorations, accompanying material: just considering all of these features it is possible to give the right value to an ancient object, which is never fully represented just by the text it carries. At the end, the scientific topics described in APUG documents have also required specific classes for other two kinds of physical objects: Astronomical, such as planets, stars etc., and Instrument, mainly considering scientific instruments.

The Actor class and its specializations

The organization of information about “actors” is inspired by FOAF [6] ontology: opting for Actor instead of Agent, more familiar term in the humanities and more generic of the term Creator present in ISAD (G). The Actor class is specialized in classes Group and Person. The subclasses of the Group are:

  • Organization (e.g. institutions, organizations, agencies, public or private companies) specialized in classes: Family, ReligiousOrder);
  • TemporaryOrganization describes bodies of a temporary nature (e.g. committee, consortium, conference).

The Person class is related (isMemberOf) with to Group this relationship indicates whether one or more persons are part of a group. The classes Person and Group have other relationships and attributes respectively to enter:

  • date and place of birth and death;
  • date and place of foundation and termination of activities.

In cataloguing systems it is very important how the names are structured: a simplification could affect the generation of the relevant indices. Appellation class is used to refer to and define the “names” of: people (PersonName), groups (GroupName), places (PlaceName), objects (Name) and titles (Title). The Names are placed in the normalized form indicating, where applicable, the authority file reference (e.g. VIAF [7]) and in their possible variant forms (e.g. Clavius, Cristoforo Clavio, Christophorus Clavius, Christoph Clavius, Christoph Clau) also indicating the time and place in which the variant is in use (e.g. some Jesuits have lived in China and they have changed their name). In addition, the classes responsible for the management of the names was designed both to allow simple insertion, following the rules that the inclusion of cataloguing national or international. So, the first name, last name and the particle name are entered separately in order to decide how to build the index of names and how to display the name of the person in the search interface: first name and last name, last name followed by a comma and then the first name, etc. Instead of creating many classes to describe the relationships between actors (Actor) and objects (Object), only the Role class was created. Role, linked to ActorInRole, express, without predetermined patterns, each possible role that an actor can play in given period and place on the basis of an object or archival resource (e.g. author, creator, publisher, sender, addressee, teacher, student, archivist, administrator, official).

Conclusion

On the basis of my experience in this and in other projects, I can point out that an ontology, and its tools, has been very useful, because it facilitates the share, interoperability and reuse of information. It is easy to provide the URI to any class, property and instance present in the ontology schema, so thanks to the Linked Data Model it is possible to make available and gather information generated by other archives, library, museum, galleries, research centres, etc.

At the same time the ontology offers different views and perspectives on resources and on the concepts that they convey, and it will open new ways for further studies and analysis. Such an “enhanced” search allows you to infer, thanks to a reasoner (e.g. Apache Jena Fuseki, HermiT) and deduce new knowledge based on what is available.


  1. http://www.ica.org/13845/egad-activities-and-projects/egad-strategic-work-plan.html, la version française étant moins expressive.
  2. General International Standard Archival Description-Second edition
  3. Functional Requirements for Bibliographic Records object oriented, Version 2.0
  4. International Standard Archival Authority Record for Corporate Bodies, Persons and Families, 2nd Edition ISAAR (CPF)
  5. Functional Requirements for Authority Data
  6. Friend of a Friend expresses information about persons and groups
  7. Virtual International Authority File
Inventaire des archives de la seigneurie de Caderousse par Jean de Jarlains, 1525. Arch.dép. Vaucluse, 2E9/1

« Il faut mettre en ligne ! »
Les contenus archivistiques en ligne : le travail de l’archiviste (part II)

Questions préalables

  • La recherche en archives est une démarche complexe par nature, car elle aborde un matériau riche et complexe ; hors du domaine des grandes séries répétitives, il est illusoire de croire qu’on peut la simplifier à l’extrême, que l’on peut cerner par un ou deux critères un ensemble gigantesque et varié ; tout un arsenal de guides ou de modules spécialisés sont offerts aux chercheurs sur les sites des grandes institutions qui mettent les instruments de recherche au cœur de leur proposition en ligne. Un bel exemple est donné par le site des Archives nationales australiennes.
  • Quels publics l’archiviste doit-il cibler en mettant en ligne des inventaires d’archives ?
    A priori, les publics chercheurs, quels qu’ils soient, même amateurs ou débutants, mais prêts à entamer une vraie démarche, pas à trouver des réponses toutes faites, même si l’archiviste fait en parallèle des propositions du type « dossiers d’histoire », destinés à un public plus large non chercheur.
  • Comment consulte-t-on en ligne ?
    Ce n’est pas le lieu d’analyser ici ce qui fait l’objet d’études nombreuses, mais c’est bien sûr une question primordiale à se poser avant d’adopter un parti de présentation, un modèle de recherche, un type d’instruments de recherche ; il n’est toutefois pas obligatoire de se conformer aux pratiques majoritaires, mais de les connaître et de les évaluer, pour les retenir si elles sont conformes aux objectifs de mise en ligne, ou les rejeter si elles ne sont pas adaptées à la nature du matériau traité ou au niveau d’information délivré. Il faut néanmoins avoir en tête que l’internaute, impatient d’aller à ce qu’il juge l’essentiel, de poser sa question et d’avoir des réponses, lit très peu les modes d’emploi et autres didacticiels, au grand risque de ne rien trouver dans le cadre d’une recherche non formatée.
  • Met-on les mêmes outils en ligne et en salle de lecture ?
    Non. Ni dans leur nombre et diversité, ni dans leur forme.

    • En salle, le recours à l’archiviste est direct et résout nombre de difficultés, ce que l’approche solitaire de la machine ne permet que difficilement ;
    • L’informatique supporte très mal l’approximatif des instruments de recherche provisoires ou anciens, pourtant fort précieux pour le chercheur ;
    • Recherche en ligne et recherche en salle ne sont pas équivalentes, et ont besoin d’outils différents ;
    • Tout contenu d’instrument de recherche n’est pas publiable en ligne.
  • Comment gérer les « retours » de l’interactivité entre public et recherche en ligne ?
    L’internaute est beaucoup plus exigeant, plus critique et plus réactif que le lecteur traditionnel. Son utilisation des outils mis en ligne n’est en outre jamais tout à fait ce que l’archiviste avait prévu ; à l’archiviste d’évaluer les critiques formulées, soit pour les prendre en compte et adapter les outils, soit pour user de plus de pédagogie en ligne et mieux expliciter la démarche et les objectifs atteignables grâce aux outils.

La présentation des fonds et des instruments de recherche

L’organisation des sites d’archives est significative de ce que l’archiviste veut porter comme message et des priorités qu’il attribue à chacun des modules qu’il propose à l’internaute.

La structuration de la présentation des fonds

C’est une vraie démarche archivistique de présenter les fonds conservés par l’institution, dans lesquels les recherches s’effectueront, soit en ligne, soit en salle.
Sa raison d’être est d’aider l’internaute à connaître le contexte général de production des archives qu’il va pouvoir consulter et à mieux cerner ce qu’il peut y trouver, donc y chercher. Les systèmes nationaux de collecte et de conservation, les histoires archivistiques des pays, conditionnent la plupart du temps cette présentation, organisée simplement (ordre alphabétique du nom des fonds par exemple pour les archives italiennes) ou structurée, de façon chronologique (fonds coloniaux / fonds après l’indépendance au Sénégal, fonds d’Ancien Régime / fonds postérieurs à la Révolution en France), selon la nature des fonds (fonds notariaux, fonds administratifs…), selon les niveaux hiérarchiques des producteurs (organisations gouvernementales, agences locales), selon des thématiques (archives militaires, archives de l’immigration)…
En France, ce sont des cadres de classement réglementaires qui sont généralement utilisés, subdivisés en « séries », identifiées par des lettres et regroupant des fonds de même type de provenance (fonds judiciaires d’ancien régime, fonds d’institutions religieuses régulières, fonds d’origine privée…) ; extrêmement « pratique » car référentiel uniforme partout en France, le cadre de classement départemental est cependant un système faussement respectueux des fonds, qu’il va éclater entre diverses périodes, regrouper artificiellement, ou scinder en plusieurs thématiques.

L’organisation des instruments de recherche

L’organisation des instruments de recherche, indépendamment de leur nature et de leur forme, est de même un choix archivistique fondé sur les sources mais aussi sur les méthodes de recherche proposées, ou les sujets priorisés :

  • Elle peut suivre la même structuration que la présentation des fonds, par série du cadre de classement, ou au contraire par type de fonds ;

Capture d'écran État général des fonds - Archives de Vaucluse

  • Elle peut être organisée de façon plus pragmatique, indépendamment de la présentation globale des fonds, en fonction de sujets pertinents entre eux : les outils pour effectuer une recherche sur l’histoire des familles, les guides des sources de l’histoire de la première guerre mondiale ou de l’immigration…

La mise en forme des instruments de recherche

La façon dont l’internaute pourra appréhender l’instrument de recherche qui répondra à sa requête dépend aussi de choix archivistiques majeurs :

  • L’archiviste peut choisir de n’offrir qu’une référence précise, hors contexte ; la description de l’article ou des articles qui répond(ent) à une recherche simple dans des documents sériels, et qui vont mener parfois à l’image des documents eux-mêmes : le plan cadastral de la commune de R ou les baptêmes de 1754 du village de Saint-Martin.
  • Il peut choisir cette solution également dans une recherche plus complexe, dans une réponse de type documentaire.
  • Une réponse de type archivistique mettra, elle, le document identifié en relation avec son contexte, dans le cadre d’une description hiérarchisée conforme à l’ISAD(G).
  • Le parti peut également être d’offrir systématiquement au chercheur un instrument de recherche lisible de son début à sa fin, soit sous forme traditionnelle (reproduction sous format pdf d’un instrument de recherche papier) soit sous forme « navigable », où chaque niveau se déplie.

L’interrogation des instruments de recherche

    Photo

    • L’accès aux archives
      • Mettre les archives à la disposition du public, mission ultime de l’existence de l’archiviste, ne veut pas dire laisser le chercheur essayer de trouver lui-même dans les magasins de stockage un item choisi au hasard, sur son simple titre aperçu au passage. Mettre à disposition virtuellement repose sur le même principe : comme lors de l’accueil physique du lecteur, que l’archiviste écoute et oriente, la mission de l’archiviste n’est pas de laisser l’internaute se débrouiller tout seul face à des milliers d’images ou de références, mais bien d’être un médiateur entre le document d’archives et l’utilisateur, grâce à son expertise, sans céder aux fallacieux arguments qui prétendent que son travail propre peut être remplacé par un moteur de recherche performant.
      • Servir de médiateur ne veut pas dire faire le travail du chercheur, mais lui donner des outils d’accès, en fonction de sa demande, de son attente, de ses compétences également ; percevoir quel niveau d’information apporter est primordial : on ne répond pas de la même façon à un généalogiste amateur débutant et à un historien professionnel habitué à la fréquentation scientifique des documents. Il est donc nécessaire de proposer plusieurs niveaux de recherche, et des parcours différents adaptés aux intérêts des différentes catégories de publics visés. Il est également fondamental de concevoir simultanément l’instrument de recherche et son outil d’interrogation, adapté au contenu des descriptions.
    • L’archiviste ne travaille plus pour une communauté restreinte se déplaçant vers lui et partageant avec lui un mode consensuel d’échange, mais s’adresse à travers la mise en ligne à des internautes du monde entier, avec lesquels il lui faut trouver un langage commun dépassant les usages particuliers, normalisé et structuré.
    • Parallèlement, de nouveaux modes d’interrogation, de nouvelles façons de concevoir la relation des objets entre eux, de nouvelles approches des contenus sont en plein développement sur la toile. Les archives ne doivent pas rater leur entrée dans le monde du web des données, et ne pourront rester figées dans des schémas dont l’insuffisance commence à se faire sentir : le web sémantique est la porte d’accès à un vrai réseau culturel et patrimonial dont il serait inconcevable que les archives soient absentes. Il convient donc à nouveau que l’archiviste réévalue ses outils de mise en ligne, mais qu’il garde toujours la même ligne de mire : l’instrument de recherche est l’outil d’accès aux archives, il se décline seulement selon les supports.