Vers une ontologie pour RDA-FR

Début juillet a eu lieu, comme cela se produit 2 fois par an, une journée de réunion pour les membres de tous les groupes (Normalisation, Formation, Systèmes & Données) de la Transition bibliographique. A cette occasion a été annoncée un ensemble d’actions dont certaines gravitent autour du projet de Fichier national d’entités (FNE), et qui pourraient infléchir la dynamique de la Transition bibliographique dans les douze prochains mois :

• La conception d’un « pilote pour le FNE », c’est-à-dire d’une application fonctionnelle permettant de tester le version, la fusion, la gestion de données communes à l’Abes et la BnF, en commençant par les entités Personnes physiques
• La conversion en site web des chapitres déjà publiés (en PDF) de RDA-FR : il y a actuellement 6 PDF, représentant environ 1200 pages, et la totalité du code pourrait bien représenter dans les 2000 pages à terme. Bref, il faut en faire un ensemble de contenus (navigable sous forme de site web), un jeu de règles, un dictionnaire de données (terme utilisé pour évoquer RDA, lors de la dernière conférence annuelle de l’ALA), bref, quelque chose de plus adapté aux usages du web.
  A l’issue de la conversion de l’existant, l’idée est bien ensuite de maintenir un site web qui accueillera directement les textes ultérieurs, sous forme de nouvelles pages et nouvelles rubriques.
• La constitution d’une ontologie pour RDA-FR, en commençant, là aussi, par les agents Personnes physiques

Cette dernière annonce a suscité quelques questions qui laissent entendre des risques d’incompréhension sur :

• ce que va être cette ontologie RDA-FR, concrètement
• à quoi ça va servir ?
• comment elle va co-exister avec les PDF disponibles sur le site transition-bibliographique.fr, et avec le futur site web : l’ontologie va-t-elle remplacer les PDF, etc. ?

Avant de développer ces questions, je vous propose d’aller faire un tour du côté de nos collègues et amis archivistes, pour voir comment coexistent, pour le modèle de données RiC, une documentation en ligne et une ontologie comparable à ce qu’on vise pour RDA-FR.

Qu’est-ce que RiC ?

RiC (Records in Contexts) ne se situe pas sur le même plan que RDA-FR, mais est plutôt un équivalent de IFLA LRM. Il décrit les types d’objets qu’on trouve dans les collections d’archives, leurs propriétés, les relations diverses qui les lient aux acteurs qui les produisent, y sont mentionnées, etc.

Ce modèle est décrit en langage naturel (en texte, quoi) et se présente sous la forme d’un PDF sur le site de l’ICA (International Council of Archives).

Ce même modèle est également exprimé sous la forme d’une ontologie, baptisée RiC-O, dont vous pouvez trouver :

• une présentation ici (texte en français d’environ 1 page)
• une documentation plus complète (texte en anglais d’environ 50 pages)
• le fichier même de règles, sous forme de triplets RDF
  Ce fichier reprend les éléments d’information essentielles du PDF pour les exprimer en triplets, afin que des programmes puissent les manipuler

Cette ontologie dispose également d’un espace de nom (je reviendrai sur cette notion) : https://www.ica.org/standards/RiC/ontology#

L’ontologie vient donc compléter, selon une modalité plus technique, le PDF qui, tant qu’on en reste à ce stade de la définition d’un modèle, n’est encore qu’une vue de l’esprit, c’est à dire non implémentable directement au sein de programmes informatiques.

On y trouve par exemple le code RDF/XML suivant :

Qui est une manière (XML) d’écrire un ensemble de triplets pour définir et caractériser la classe « RecordResource » (définition fournie : ressource, ensemble de ressource ou partie de ressource produite ou acquise par un agent durant son activité) dont la version « graphique » donne :

Parmi les triplets, il est dit aussi que cette classe d’objet est décrite dans le PDF du modèle sous l’appellation « Record Resource », identifiée par le numéro RiC-E02 dans le tableau listant les entités définies par ce modèle) et qui est décrite au paragraphe 2.2.2, page 25 du même PDF.

Qu’est-ce qu’une ontologie ?

Une ontologie, dans le sens du projet évoqué, est un fichier ou un ensemble de fichiers ou de fiches (gérées par base de données)

• utilisant un langage informatique structuré (ici, OWL, donc une liste de triplets RDF), donc selon un mode qu’un programme informatique peut manipuler
• décrivant une liste de types d’objets, des attributs, des propriétés qui lient entre eux ces types d’objets.

Exemple de liste de types d’objets : mobilier, bibelot, livre, œuvre d’art, électroménager, appareil électronique

La liste ci-dessus (qu’il faudrait encore rallonger, évidemment) permet de décrire le contenu d’un appartement, en rattachant chaque objet trouvé à un de ces types.

Dès lors qu’un objet trouvé se voit rattaché à un type, cela induit que certaines informations sont attendues pour le décrire, soit obligatoires, soit facultatives.

On peut envisager des liens entre ces types d’objets (ça s’y prête assez mal ici), ou des liens vers des types d’entités tierces : par exemple, dans le cadre d’une succession, on associera chaque objet à un des héritiers. Donc on peut identifier là deux propriétés qui seront communes à tous les objets :

• (objet) a appartenu à (personne)
• (objet) est destiné à (personne)

Entre parenthèse, le type (ou « classe ») qu’on s’attend à trouver de part et d’autre de ces propriétés. Comme ces propriétés (ainsi que d’autres) peuvent s’appliquer à tous les objets, on va définir une classe particulière englobante, appelée « Objet », dont on va dire qu’elle permet d’exprimer toutes les propriétés communes, qui sont applicables aux meubles, livres, objets d’art, etc.

Toutes les informations qui précèdent sont lisibles par vous (en tout cas j’espère !) mais pas par une machine. Par exemple, une fois récupéré le tableau qui me fournira la liste des objets et leur destinataire, je ne pourrai pas contrôler les aberrations éventuelles (deux personnes héritant du même objet, par exemple).

L’ontologie est donc là pour définir les règles qui vont structurer l’information. Le descriptif ci-dessus est utile pour les êtres humains, l’ontologie sera utilisée par un programme, qu’il va confronter aux données pour vérifier qu’elles s’y conforment.

En amont des contrôles, on peut aussi imaginer un programme qui va s’appuyer sur ce fichier contenant les classes d’objets, leurs propriétés et les différentes règles, pour élaborer une application utilisateur afin d’alimenter les données en évitant les aberrations.

Et donc, une ontologie RDA-FR ?

Comme je l’ai évoqué plus haut, l’Abes et la BnF doivent faire développer dans les prochains mois un « pilote FNE », c’est-à-dire une application (une base de données avec des programmes qui tournent dessus, dont une interface qui doit permettre de manipuler ces données¹) qui va implémenter le code de catalogage RDA-FR, du moins la partie Personnes & identités publiques pour commencer.

Pour que ce soit possible, il faut que les règles décrites dans le PDF du chapitre 9 (« Identification des personnes ») soient interprétables et utilisables par un programme.

Chaque application a sa manière de gérer les règles à appliquer aux données qu’elle gère. Mais il y a des standards pour exprimer ces règles, de manière à pouvoir aisément les convertir dans des formats plus spécifiques pour les implémenter dans chacune des applications qui va vouloir les utiliser.

Parmi ces modalités standards de décrire des règles sur les données, l’ontologie exprimée en RDF/OWL fait plus ou moins partie des incontournables.

Donc concrètement, le travail va consister à ouvrir le chapitre sur les personnes, et repérer les informations qui trouveraient leur place dans une ontologie.

• la liste des éléments d’information permettant de décrire une personne, et leur caractère obligatoire, non obligatoire, exclusif, réciproque, etc. sont des choses qui seront à intégrer dans le fichier RDF
• les exemples, j’imagine, n’en font pas partie (et ils sont nombreux dans les chapitres RDA-FR)
• des questions se poseront certainement sur d’autres types d’information :
  par exemple les déclarations d’équivalence entre un élément RDA-FR et celui qu’on trouve dans RDA

Comme toute cette transposition d’information ces règles se fera sous forme de triplet RDF, cela veut dire que dans la composition des sujet-verbe-complément, les sujets et les verbes seront des triplets.

Par exemple, au lieu de dire : « Pour les agents de type Personne, on peut préciser la langue (ou les langues) d’expression qu’elle utilise pour produire les ressources qui lui sont associées », l’ontologie va dire :

(ces triplets sont des exemples non contractuels !)

• <url.fr/personne> rdfs:subClassOf <url.fr/agent> # Dans la classe Agent, on trouve des sous-classes Personne
• <url.fr/langueDeLaPersonne> rdf:type rdf:Property # langueDeLaPersonne est une propriété
• <url.fr/langueDeLaPersonne> rdfs:label "Langue de la personne" # un libellé pour cette propriété
• <url.fr/langueDeLaPersonne> rdfs:domain <url.fr/personne> # Le sujet d’une « langue de la personne » sera une personne
• <url.fr/langueDeLaPersonne> rdfs:range xsd:string # l’objet d’un tel triplet sera une chaîne de caractères (si la valeur attendue est « français ». Si on veut une valeur comme http://id.loc.gov/vocabulary/iso639-2/fre, il faudra le préciser autement)
• <url.fr/langueDeLaPersonne> owl:minCardinality "0"^^xsd:integer # on peut trouver 0 fois cette propriété pour une personne (donc cette information est optionnelle)

Les écritures owl:, rdf:, et rdfs: sont des raccourcis pour ne pas écrire l’intégralité de l’URI qui identifie chacune de ces propriété.

De même le « url.fr » sera remplacé par la vraie URL racine qui sera utilisée pour définir les différents objets décrits dans l’ontologie RDA-FR, afin de construire des URI qui permettront de les identifier de manière univoque sur le web (de données). C’est la notion d’espace de nom.

Autre aspect : que l’URI contienne un libellé « nettoyé » de la propriété, ou un identifiant interne alphanumérique (« F12 », « C25 ») permettant d’anticiper les cas où les propriétés ou autres types d’objets seraient amenés à changer de nom : avoir une URI <bibliotheque.fr/langueDeLaPersonne> et un libellé « Autre nom » peut être un peu dérangeant.

Conclusion

La constitution d’une ontologie vient donc compléter logiquement la rédaction du code de catalogage RDA-FR, pour pouvoir l’utiliser pleinement dans les (futures) applications. Faute d’une telle ontologie, ça impose par exemple aux éditeurs de SIGB de faire, chacun, l’extraction et la transposition des différentes informations qui sont présentes dans les chapitres publiés, mais en mode humain, trop humain.

Cela n’enlèvera probablement pas la transposition nécessaire de ces règles, dans le système de formalisation de règles propre à chaque SIGB, mais en ayant une conversion à faire à partir de règles déjà formalisées.

Remarque : de même que la seule traduction d’IFLA LRM en français avait été l’occasion d’y relever des incohérences qui ont occasionné ensuite une mise à jour du modèle initial, de même, il n’est théoriquement pas exclu que la transposition d’informations en ontologie OWL mette à jour des besoins de mise en cohérence, d’harmonisations, etc. dans les chapitres RDA-FR publiés.

—————————————

1. « une interface qui doit permettre de manipuler ces données » n’est pas nécessairement un site web fonctionnel. Cela ne dit rien de la partie Administration, gestion, ou éventuellement publique d’une telle application. Mais il faut bien pouvoir accéder à ces données autrement qu’en utilisant le langage SQL