Voilà maintenant près d’un an et demi que FranceArchives, le Portail national des Archives de France, a annoncé le déploiement de l’outil « Supernatural » (comprendre Sparnatural) via ses réseaux, dans l’optique de proposer à ses usagers « un accès nouveau aux métadonnées archivistiques, complémentaire de la recherche classique par le moteur du portail ».

Porté par le Service interministériel des Archives de France, le portail FranceArchives offre une recherche fédérée dans près de 26 millions de métadonnées archivistiques produites par près de 170 institutions et entièrement sémantisées en RDF par le biais de l’ontologie RiC-O version 0.2 publiée en février 2021.

C’est une des premières utilisations de RiC-O à grande échelle (même s’il faudra à l’avenir qu’il se mette à jour sur la version 1.0 de RiC-O publiée depuis !), et c’est également l’un des premiers entrepôts de données archivistiques de cette taille sur le Linked Open Data.

… Un graphe de données qui a tout pour être « Supernaturalisé »

Des données de qualité à une recherche augmentée

… Enfin, il va surtout s’agir de ses « données de qualité », autrement dit les :

• inventaires avec leurs composants,
• notices descriptives de producteurs d’archives,
• fiches signalétiques des services d’archives,

 … tous objets liés à une autorité « personnes et institutions », « lieux » et « thèmes » de qualité (soit moins de 5% des métadonnées du portail avant conversion… et plus de 70% de l’ensemble du réservoir en RDF !), autorités de qualité elles-mêmes harmonisées et alignées vers des référentiels nationaux et internationaux.

Modèle particulièrement adapté à la description des archives en RDF, c’est l’ontologie RiC-O (v0.2) qui a été utilisée pour la sémantisation des données XML EAD – XML EAC-CPF vers RDF, complétée de schema.org pour les fiches signalétiques des services de l’annuaire au format XML EAG.

Les informations relatives aux archives et à leurs producteurs étant décrites dans des fichiers différents, la recherche avancée via SPARQL rend désormais possible une interrogation fédérée plus fine d’un vaste corpus de notices en « traversant » le graphe structuré selon le modèle RiC-O. En effet, l’intérêt de l’interrogation via SPARQL est de casser les silos entre types de métadonnées : il permet de faire une recherche transversale entre données provenant de fichiers EAD et de fichier EAC-CPF.

Les notices affichées en résultats de recherche montrent les alignements existants vers les notices de producteurs externes, Wikidata, data.bnf, GeoNames ou encore le Thesaurus pour l’indexation matières des archives locales. C’est ainsi dans l’onglet Personnes/indexations liées que sont exploités les résultats de la conversion en RDF, par le biais de suggestions de recherches complémentaires sur le portail classique.

Une façon de faire bénéficier le grand public du RDF de manière complètement transparente pour lui !

Quelques exemples de requêtes…

On accède à l’outil via le menu « Recherche SPARQL » en haut à droite du site du portail :

Plusieurs exemples de requêtes sont à disposition pour explorer les données :

De la requête la plus simple :

Personne est membre de Institution

À des requêtes de plus en plus élaborées et complexes, comme ici :

Lieux qui sont le sujet des archives reliées au fonds « Fabrique de berlingot Eysséric »

Où l’on voit que l’on peut retracer le cheminement de la requête à travers le graphe de l’ontologie RiC-O en cliquant sur « Afficher/masquer l’éditeur SPARQL ».

Des archives à la page…

À noter que le projet, qui avait fait l’objet d’une présentation à l’occasion de SWIB (Semantic Web in Libraries) et de SemWebPro 2023 a été entièrement déployé (et configuré !) à partir de la documentation disponible sur le site web de Sparnatural.

N’hésitez pas à aller la consulter !

Hello Sparnatural

How-to configure in SHACL

Reference documentation of Sparnatural widgets

Pour aller plus loin sur la sémantisation des archives…

Le déploiement de Sparnatural sur FranceArchives fait suite à une autre réalisation de l’année précédente, le démonstrateur Sparnatural des Archives nationales. Celui-ci avait permis de faire évoluer Sparnatural et de le déployer sur un graphe sémantique en RiC-O de 20 millions de triplets (hors inférence), alimenté avec le contenu de 1577 instruments de recherche décrivant les archives de 40 des 122 études notariales de Paris conservées aux Archives nationales, de 1120 notices décrivant ces études et les notaires qui y ont exercé, et d’autres référentiels des Archives nationales notamment sur les lieux de Paris. La réalisation de ce démonstrateur a été entièrement documentée en français et en anglais. Ce démonstrateur et ses interfaces évolueront d’ailleurs bientôt.

Depuis, Sparna s’est impliqué dans le domaine de la sémantisation des archives puisque nous développons également, pour les comptes des Archives Nationales, l’outil Ric-O converter.

Celui-ci permet la conversion de notices EAD et EAC vers du RDF exprimé en RiC-O. Nous finalisons actuellement une nouvelle version du convertisseur pour le rendre compatible RiC-O 1.0 (et même 1.1 dont la sortie est imminente).

Un nouvel article à paraître ici sur RiC-O ? … Stay tuned !

Cet article Retour sur … Le déploiement de Sparnatural pour FranceArchives est apparu en premier sur Sparna Blog.

Les sources de l’ontologie RiC-O sont dans Github à https://github.com/ICA-EGAD/RiC-O.

4 entités au coeur de RiC-CM

RiC-CM défini 4 entités « noyaux » du modèle conceptuel : la Record Resource, ses Instantiations, des Agents et des Activités. La RecordResource est une description intellectuelle qui peut avoir plusieurs matérialités (typiquement document original vs. numérisation), ses Instantiations. Une « Record Resource » peut se préciser soit en Record Set (ensemble de notices), en Record (notice seule) ou en Record Part (partie de notice), la frontière entre ces 3 notions n’étant pas toujours facile.

Sous la notion générique d’Agent, RiC-CM déclare les 3 types d’agents archivistiques classiques Person, Family et Corporate Body, mais introduit également comme des Agents les « Positions » (Fonctions dans un organigramme) et les « Mechanisms » (typiquement les logiciels), qui peuvent donc être utilisés dans une relation de Provenance.

Ces 4 entités « noyaux » sont complétées par la notion de Rule (règle, loi, normes, « contexts that establish the conditions for the performance of the activities ») et les entités classiques de Date et Place.

Le modèle conceptuel RiC-CM défini un ensemble de 78 relations majoritairement entre les 4 entités noyaux du modèle, et c’est là que la notion de Contextes (au pluriel) prends tout son sens :

1. Relations Partitives tout/partie : Record has consituent Record Part, Event has subevent Event, Group has subdivision Group, etc…
2. Relations Séquentielles avant/après : Record is original of Record, Instantiation has derived instantiation Instantiation, Agent is antecedent of Agent, etc..
3. Relations de Sujet : Record Resource has subject Thing ou Record Resource describes Thing, etc.
4. Relations inter-Record Resource : Record Resource has copy Record Resource, Record Set includes Record, etc.
5. Relations de Record Resource à Instantiation : Record Resource has instantiation Instantiation, etc.
6. Relations de Provenance (Record Resource à Agent) : Record Resource created by Agent, etc.
7. Relations inter-Instantiations, typiquement Instantiation has derived instantiation Instantiation (cas de la copie numérique d’un orginal), etc.
8. Relations de Management : Group or Person or Position is owner of Thing, Agent controls Agent, etc.
9. Relations inter-Agent : Person is leader of Group, Person has child Person, Person occupies Position, Person knows Person, etc.
10. Relations des Events/Activities, typiquement Activity performed by Agent
11. Relations des Rules : Rule regulates Thing, Mandate authorizes Agent, etc.
12. Relations de Datation
13. Relations Spatiales

Ce diagramme (tiré de cette présentation de RiC-CM aux Archives Nationales et du code source de RiC-O dans Github) donne l’aperçu haut-niveau de RiC-CM et des relations qui articulent les entités de haut-niveau du modèle :

Diagramme haut-niveau du Modèle Conceptuel Records in Contexts 0.2

RiC dans la famille des modèles conceptuels

RiC s’inscrit dans la famille des modèles conceptuels développés depuis 3 décennies dans le domaine de l’infodoc : FRBR en 1992-1995 pour les notices bibliographiques des bibliothèques, puis le CIDOC-CRM à partir de 1996 pour la description des objets muséaux et patrimoniaux en général, puis l’intégration de FRBR dans le CIDOC-CRM, à partir de 2003, qui donnera naissance à FRBRoo en 2008. Et plus récemment, en 2017, IFLA-LRM qui consolide les modèles de la famille FRBR.

On notera la temporalité longue pour l’élaboration de ces standards internationaux : réunions internationales, disponibilité des participants, nécessaires discussions longues sur l’identification des concepts fondamentaux du métier. On notera aussi le retard de la communauté des archives, avec le début du groupe EGAD en 2012 et la version 0.1 de RiC-CM publiée en 2016, sur cette réflexion au niveau conceptuel, par rapport aux bibliothèques et aux musées. Cela peut s’expliquer par la présence d’un standard technique unique et utilisé mondialement, l’EAD, et par des moyens plus réduits dans la communauté archivistique.

La communauté du CIDOC-CRM s’est empressé de dénoncer la « secte des archivistes » qui réinventent leur propre modèle conceptuel plutôt que de s’appuyer sur les fondations théoriques du CIDOC-CRM. Mais cette phase de réflexion où sont réexaminés l’existence, le périmètre, la pertinence et l’articulation de de chaque concept métier est bien nécessaire à une communauté de pratique avant que celle-ci ne puisse proposer un éventuel accostage avec le point de vue – certes générique et théoriquement fondé, mais issu d’une autre communauté de pratiques – du CIDOC-CRM. Le document « Toward an International Conceptual Model for Archival Description… » mentionné plus haut mentionne déjà cela :

« Avant de collaborer, la communauté archivistique doit développer un modèle conceptuel qui réponde d’abord et avant tout aux principes et aux besoins des archivistes. Une fois ce modèle élaboré, la communauté sera bien placée pour se joindre aux communautés professionnelles apparentées dans une quête commune pour fournir un accès intégré à l’expression humaine sous toutes ses formes. »

Quelques années de patience, donc, avant une intégration RiC-CM / CIDOC-CRM  (RiCoo ? )

Ricoconverter : Un convertisseur EAD et EAC vers RiC-O, par les Archives Nationales

Florence Clavaud, responsable de la mission Référentiels aux Archives Nationales, a largement développé l’ontologie RiC-O au sein du groupe EGAD. Sous son impulsion avait déjà été développé en 2017-2018 le prototype PIAFF (Pilote d’interopérabilité pour les Autorités Archivistiques françaises), incluant 276 notices d’autorités des AN, de la BNF et du SIAFF, converties dans la première version de RiC-CM et RiC-O qui datait de 2016.

Les Archives Nationales ont souhaité un passage à l’échelle après le succès de PIAFF, pour la conversion de l’intégralité des 28000 instruments de recherche et 15000 notices d’autorité des Archives Nationales, dans la version la plus récente de RiC-O. Le travail a été confié à votre serviteur. Le résultat est ricoconverter, un logiciel opensource, permettant de lancer simplement en ligne de commande une conversion d’un ensemble de fichiers EAD ou EAC vers du RDF/XML structuré en RiC-O. Ricoconverter est essentiellement basé sur 2 feuilles de style XSLT qui font l’essentiel du travail, enrobées dans un script Java. La feuille de style convertissant l’EAC est assez générique et transposable dans d’autres contextes probablement assez directement, la feuille de style EAD répond à l’implémentation spécifique de l’EAD aux AN et demandera plus d’adaptions; mais l’objectif de Ricoconverter est bel et bien de pouvoir être adapté et utilisé pas d’autres services d’archives pour produire des graphes de données RiC-O.

Les sources de ricoconverter sont disponibles dans Github à https://github.com/ArchivesNationalesFR/rico-converter.

Cerise sur le gâteau, quand on a un joli graphe RiC-O, on peut avoir un joli Sparnatural (voir ce billet de blog) qui permet de naviguer dans le graphe et de chercher par exemple « toutes les archives numérisées des organisations ayant succédé à la Direction des Beaux Arts (1848-1852) » (cliquer sur l’image pour voir le screencast) :

Présentations de RiC-CM et RiC-O aux Archives Nationales le 28/01/2020

Pour aller plus loin on peut consulter les présentations sur RiC-CM, RiC-O, ricoconverter et plus encore faites lors de la journée d’étude du 28 janvier 2020 aux Archives Nationales.

Illustration : Institut, [salle des] archives : [photographie de presse] / [Agence Rol] Agence Rol. Agence photographique depuis Gallica.

Cet article RiC-CM, RiC-O : les Archives se dotent de leur modèle conceptuel (Records in Contexts) est apparu en premier sur Sparna Blog.

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 et 2/ 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 noeuds blancs, ou noeuds 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) ») ou 2/ 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.

Cet article Penser, modéliser (pour le web de données) – 2/2 est apparu en premier sur Sparna Blog.

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. Eternelle 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. Eternelle 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.

Evidemment, 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.

Cet article Penser, modéliser (pour le web de données) (1/2) est apparu en premier sur Sparna Blog.