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 :
- de bénéficier de la réflexion et des bonnes pratiques de modélisation qui ont sédimenté dans ce modèle
- 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 :
- de rester compatible avec les valeurs textuelles existantes dans les données actuelles ;
- 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 ;
- de pouvoir travailler dans un mode « on exprime la relation d’abord, et on essaie de résoudre la valeur contrôlée ensuite » ;
- 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 :
- compliquées à décrire (« 1923-1932, 1936-1945 (manque 1933 à 1935) »)
- 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
- une URI pour désigner « Apple » en tant qu’entité générique
- 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.
Bonjour,
Merci pour cet article qui illustre bien les réponses que peut apporter le web de données aux préoccupations archivistiques.
Je travaille actuellement sur un projet de système d’archivage électronique et nous avons identifié les descripteurs candidats appartenant aussi bien au domaine de la description archivistique que de la description technique ou administrative des objets d’archives.
Certains modèles de données existent maintenant sous la forme d’une ontologie comme par exemple PREMIS mais malheureusement cela ne semble pas être la direction prise pour la révision de la DTD EAD et ni actuellement pour le schéma EAC. Dans votre article, vous ne faites référence ni à l’un ni à l’autre. Est-ce que cela signifie que vous avez préféré identifier au sein d’ontologies existantes les significations des descripteurs que ces schémas contiennent ?
Par exemple, vous décrivez l’utilisation de PROV-O pour « spécialiser » les propriétés d’une entité productrice d’archives. C’est la fonction centrale du modèle EAC, censé pouvoir retranscrire les évolutions des compétences ou fonctions d’un producteur. J’imagine que ce choix est guidé par les possibilités d’interopérabilité des données alignées sur cette ontologie avec d’autres domaines de connaissance mais je serais intéressé de savoir si vous avez envisagé de « traduire » les schémas archivistiques existants en OWL ou si vous avez choisi dès le départ de partir de concepts généralistes ?
Pour finir, existe-t-il une version consultable de cette ontologie en construction ?
Bonne continuation et merci pour ce partage d’information
Pascal Romain
Bonjour Pascal,
Tout d’abord, nous sommes désolés d’avoir pris tout ce temps pour réagir à ton commentaire très intéressant et à tes questions nombreuses. Nous avons, chez Sparna comme chez Anaphore, été bien occupés en cette période de pré-congés.
Nous en avions discuté, avec Thomas, et, disposant maintenant d’un peu de temps, je prends le clavier.
Merci pour ton intervention qui enrichit le débat. Nous espérons que ton exemple fera école et qu’un dialogue pourra s’instaurer sur ces questions importantes.
Nous nous sommes aussi posé une question sur ce que tu entends exactement par « descripteur ». Thomas et nous ne sommes pas sûrs de comprendre exactement la même chose, le terme descripteur pouvant avoir des sens différents suivant les contextes. S’agit-il des termes d’indexation, comme pourraient l’entendre les archivistes ou, plus largement, de champs de métadonnées correspondant à des propriétés ?
Nous partageons ton analyse suivant laquelle le schéma EAC et la version 3 de l’EAD ne vont pas assez loin en direction de la sémantisation, même si l’on sent bien qu’une petite partie du chemin a été parcourue. Nous aurons certainement l’occasion de revenir sur ces questions de format. Effectivement, dans ce contexte, il ne nous a pas semblé opportun de partir de ces schémas, contrairement à ce qu’ont fait d’autres archivistes, par exemple pour le projet LOCAH que tu connais bien. Ces schémas correspondant avant tout à une syntaxe, avec ses limites et les contraintes qu’elle impose, il est nécessaire de repartir de plus haut, d’un modèle. Le Conseil international des archives l’a bien compris qui s’est engagé dans l’élaboration d’un modèle conceptuel. Et, comme tu le soulignes, il est effectivement intéressant d’aligner son vocabulaire sur ceux existants. C’est ainsi que nous réutilisons d’autres modèles comme foaf, dc, skos, prov, wgs84-pos… Néanmoins, nous avons évidemment bien regardé le schéma EAC et la version disponible de l’EAD 3 où, en particulier, les données de contrôle semblent aller dans la bonne direction, même si la question de la licence n’est pas envisagée. Ces données de contrôle, que nous avons assez largement ignorées dans la pratique archivistique, vont prendre de l’importance pour fournir des indications sur le degré de fiabilité des données diffusées sur le web.
Alors, non, nous n’avons pas envisagé « de « traduire » les schémas archivistiques existants en OWL ». Ce n’est pas un rôle qui revient à une entreprise comme la nôtre et cela ne nous motive pas vraiment.
Il faut insister sur le fait que notre démarche qui consiste à réfléchir à un modèle conceptuel et à définir un vocabulaire, malgré le grand intérêt intellectuel que nous y trouvons, est aussi une démarche pragmatique. Nous restons, malgré tout, éditeurs d’outils pour les archivistes. Nous sommes persuadés que des évolutions importantes se profilent et que les stratégies qui se sont appuyées sur les seuls formats métier vont se refermer comme un piège en isolant les descriptions ainsi réalisées dans les murailles érigées par ces syntaxes métier car la conversion d’une syntaxe vers une autre ne permettra pas une ouverture suffisante. Il s’agit donc, pour nous, de préparer nos outils et les méthodes d’utilisation qui les accompagnent, afin d’éviter, à ceux qui nous ont fait confiance, des réveils douloureux.
Pour l’instant, nous avons manqué de temps pour finaliser, en particulier, la documentation des classes et propriétés. Mais, notre objectif est, bien entendu, d’ouvrir, de bénéficier ainsi des critiques et collaborations d’autres personnes intéressées par le sujet et de participer à des échanges.
Merci encore pour tes remarques.
Louis Colombani