Documentation professionnelle

2. La mise en œuvre de l’OAI-PMH à la Bibliothèque nationale de France

Les principales règles de fonctionnement

Les établissements culturels disposent d’un moyen technique qui leur permet d’échanger de l’information descriptive et de regrouper virtuellement des corpus de documents numériques dont les originaux sont conservés dans des lieux différents. Ce procédé est le protocole OAI-PMH (open archive initiative – protocol for metadata harvesting(1)), dont nous proposons ici de décrire les principales règles de fonctionnement, avant de présenter de quelle façon il est utilisé à la Bibliothèque nationale de France.

Le protocole OAI-PMH est une réalisation née dans le sillage de l’initiative pour les archives ouvertes, lancée en 1999. L’objectif était de répondre à une question simple dans son énoncé, mais potentiellement complexe dans sa réponse : comment améliorer le signalement des e-prints, des publications scientifiques et comment favoriser l’interopérabilité des bases d’archives ouvertes ? Les articles, les rapports, les thèses, qui constituent une masse abondante de savoir à haute valeur ajoutée sont insuffisamment visibles sur Internet, et signalés dans des bases de données dispersées. Cette situation est pénalisante pour les chercheurs. Pour répondre à cet enjeu, le protocole technique OAI-PMH a été conçu en 2001, pour permettre la diffusion et la collecte de métadonnées. La version courante est la version 2 (2002).

Si l’OAI-PMH trouve son origine dans le domaine de la production documentaire scientifique, il présente également un grand intérêt dans le domaine culturel, comme l’a montré Muriel Foulonneau dans son rapport Collaborer pour de nouveaux services culturels en ligne : le protocole OAI [...] (2004). Le ministère de la Culture et de la communication en recommande l’utilisation. Ajoutons à cela que la diffusion de données « brutes » sur Internet, en XML, pour en favoriser la réutilisation sous différentes formes, correspond à une tendance actuelle du web. Il s’agit d’un procédé comparable à la syndication de contenus RSS utilisée pour les blogs, proche des web services.

Au fondement du protocole OAI, nous trouvons la distinction entre les fournisseurs de données (data providers) et les fournisseurs de services (service providers). La communication s’établit de client à serveur : le client envoie des requêtes en http (une requête comporte un « verbe » et éventuellement un ou plusieurs « paramètres ») ; le serveur répond par un flux de données encodées en XML. A la différence du protocole d’interrogation des bases de données Z39-50, bien connu des bibliothèques, l’OAI-PMH est asynchrone, c’est-à-dire qu’il n’interroge pas les données sources en temps réel. Le mécanisme est le suivant : un fournisseur de données expose sur un serveur OAI (dit « entrepôt »), les données qu’il a extraites de ses propres bases (il peut déjà exister à ce stade un décalage dans le temps entre les mises à jour de la base source et celle de l’entrepôt) ; un fournisseur de service vient collecter les métadonnées sur le serveur OAI pour les intégrer dans son propre index. Le degré de « fraîcheur » des informations recueillies par le fournisseur de services et proposées à l’utilisateur final dépendra donc de la fréquence de ses collectes d’une part, mais aussi de la fréquence des mises à jour de l’entrepôt côté fournisseur de données. Ce qui peut être considéré comme un handicap est aussi un atout : pour l’utilisateur final, le temps de réponse est optimal dans la mesure où il n’interroge que l’index local du fournisseur de services.

Revenons un peu sur les deux types d’acteurs. Les fournisseurs de données « exposent » leurs métadonnées sur un serveur OAI. Les métadonnées sont disponibles au minimum au format Dublin Core non qualifié (15 éléments) mais d’autres formats sont possibles et peuvent être fournis parallèlement au Dublin Core. Il suffit de mettre en place une application informatique compatible OAI-PMH, une base de données accessible via un serveur web, une application capable de répondre aux 6 requêtes(2) OAI-PMH (verbs) et de renvoyer des documents XML valides. Les fournisseurs de services, quant à eux, localisent les fournisseurs de données enregistrés, et collectent leurs métadonnées avec un programme « moissonneur » (harvester), de manière automatique et incrémentale. Ils traitent ensuite les métadonnées en ajoutant des informations de <provenance> et peuvent ajouter de la valeur sous la forme de services (recherche bibliographique, rapprochement, comptage de citations et de références, personnalisation, alerte…). Un même établissement peut être tout à la fois fournisseur de ses propres données, et fournisseur de services en intégrant à sa bibliothèque numérique des notices exposées par d’autres partenaires. C’est notamment le cas de la BnF.

Le modèle de données du protocole OAI-PMH est d’une extrême simplicité. Il repose sur quatre entités : la ressource (resource), à savoir un objet physique ou numérique pour lequel il existe une description documentaire ; l’item, un objet documentaire qui décrit et identifie de manière unique une ressource, c’est-à-dire toutes les métadonnées dont on dispose, stockées dans un entrepôt (repository) et décrites selon des schémas XML ; l’enregistrement (record), une description dans un format spécifique (le Dublin Core par exemple), et l’ensemble (set), un regroupement d’items suivant des critères que l’on définit soi-même. Un même item peut appartenir à plusieurs ensembles (un type de document, une thématique, un fonds…). Les ensembles (sets) permettent une structuration logique des entrepôts. Ils sont facultatifs. Il n’y a pas de recommandation pour l’implémentation des sets. Les sets ne sont pas nécessairement exhaustifs quant au contenu de l’entrepôt. Ils peuvent être ou non organisés de façon hiérarchique. Leur fonction est de permettre le moissonnage sélectif d’une partie de l’entrepôt OAI, sans avoir à en récupérer la totalité et à réaliser le tri côté fournisseur de services. Ils trouvent leur application dans le cadre de portails thématiques, de corpus spécialisés, de collections recréées virtuellement. On peut les établir par types de publications (thèses, articles, rapports…), par types de documents (textes, documents sonores, images, ressources audiovisuelles), par thèmes (en utilisant par exemple la classification décimale Dewey (médecine, biologie…) etc.

Avant de mettre en œuvre le protocole OAI-PMH, il est nécessaire d’être clair sur ses objectifs en se posant les bonnes questions. Du côté du fournisseur de données : quels types de données je souhaite diffuser et sur quels types de ressources ? Auprès de quels fournisseurs de services (ou types de fournisseurs de services) je désire diffuser des données ? Du côté du fournisseur de service : quel(s) service(s) fournir, et à qui ? Quels sont les entrepôts (ou les types d’entrepôts) qui m’intéressent ? Quels sont les traitements éventuels que je dois faire sur les métadonnées collectées pour fournir le service que je souhaite ? Un certain nombre de choix peuvent être discutés directement entre les différents acteurs, comme le choix des formats de métadonnées à utiliser, les types de sets, les vocabulaires contrôlés (référentiels, langages d’indexation), l’usage qui sera fait du protocole. Une fois l’entrepôt développé, il faut le faire connaître. Pour cela, on l’inscrit sur des registres en ligne, comme celui qui figure sur le site officiel de l’OAI (727 entrepôts référencés à ce jour), celui que dresse l’Université d’Illinois aux Etats-Unis (1578 entrepôts), ou encore auprès de OAISTER (université de Michigan, 903 entrepôts).

En quelques mots, l’OAI-PMH est un protocole technique simple et ouvert qui accroît la visibilité sur le web de l’offre documentaire, favorise l’interopérabilité et le signalement complémentaire des ressources, s’appuie sur un format de description générique sans interdire des formats spécifiques, échange les métadonnées, et non les objets numériques eux-mêmes.

Le traitement des données

A de très rares exceptions près, les fournisseurs de données ne créent pas directement les enregistrements dans le format Dublin Core, mais les obtiennent par conversion de bases de données existantes. Cette opération nécessite de rédiger une table de conversion (« mapping ») entre les champs de la base de données source, vers le format de données cible (Dublin Core et autres formats XML). Cette conversion s’accompagne d’une mise en XML pour les données qui ne sont pas originellement sous cette forme.

Le problème est que le format Dublin Core est générique et peu contraignant (chacun des 15 éléments est facultatif et répétable). Il en résulte une hétérogénéité des pratiques d’un fournisseur de données à l’autre qui nuit à l’interopérabilité globale et rend plus difficile l’élaboration de services à valeur ajoutée. Pour résoudre ce problème, il est nécessaire de s’entendre sur des bonnes pratiques, de veiller à la qualité de ses propres métadonnées, d’utiliser des référentiels normalisés à l’échelle internationale : les types MIME caractérisant les formats de fichier (ex. « image/jpeg »), les types DCMI pour la typologie documentaire (ex. « text » ou « still image »), les codes de langue ISO 639 (ex. « fre ») etc.

Dans son guide des bonnes pratiques en OAI, la National Science Digital Library définit plusieurs critères de qualité des métadonnées qu’il peut être bon de garder à l’esprit, dès lors que l’on souhaite améliorer l’interopérabilité de ses descriptions documentaires :

  • la complétude : le fait de choisir un format qui permette une description aussi complète que possible (en tenant compte de l’aspect économique) et d’utiliser ce format de la façon la plus complète possible. On peut par exemple se fixer un nombre minimum d’éléments Dublin Core (huit ?) requis dans une notice.
  • la pertinence : l’information doit être correcte et conforme à la syntaxe du format retenu.
  • la provenance : l’information concernant le producteur des métadonnées et son expertise.
  • la conformité aux attentes : les éléments de métadonnées, les vocabulaires contrôlés doivent répondre aux attentes de la communauté visée. Cet aspect est problématique pour les fournisseurs de données OAI, car le partage des métadonnées peut s’effectuer entre une large variété de communautés.
  • la cohérence : l’utilisation d’un élément de métadonnée doit être conforme aux définitions normalisées. Il faut s’assurer en particulier que le même type de données est toujours codé dans le même élément du format.
  • le cycle de vie : la prise en compte des éventuelles modifications de la ressource décrite ; la disponibilité de la ressource comme préalable à la disponibilité des métadonnées
  • l’accessibilité : l’association correcte entre les métadonnées et l’objet décrit et la bonne lisibilité par les communautés visées
  • le choix du bon niveau de granularité : le principe du one-to-tone en Dublin Core, une notice par objet numérique ou physique.

Ces critères concernent la qualité des métadonnées en général, et valent aussi bien dans un contexte local que dans un environnement plus large. Dès lors que l’on souhaite diffuser plus amplement l’information descriptive, d’autres points sont à prendre en considération.

  • l’indépendance par rapport au contexte : dans un environnement partagé, les notices sont séparées de leur contexte local. Chaque notice doit comporter les informations nécessaires pour connaître la ressource, sans que l’on doive recourir à une information extérieure.
  • l’auto-documentation : la notice doit être auto-suffisante et exclure l’information qui n’a d’utilité qu’au niveau local.
  • l’utilisation de vocabulaires normalisés : pour améliorer l’intégration dans une même base de notices provenant de sources différentes.
  • la « constance » : toutes les décisions prises sur l’utilisation des éléments de métadonnées, la forme des valeurs, les vocabulaires contrôlés doivent être constantes et cohérentes au sein d’un même ensemble identifié de notices.

Plusieurs fournisseurs de données informent sur leurs propres pratiques en mettant à disposition sur Internet des guides d’utilisation. La BnF en a fait de même avec son Guide d’utilisation du Dublin Core non qualifié(3), destinés aux partenaires de la BnF (pôles associés de Gallica…) ainsi qu’à tous les fournisseurs de services intéressés.

Les objectifs et les réalisations à la Bibliothèque nationale de France

La mise en œuvre de l’OAI-PMH à la BnF répond à trois objectifs principaux. Le premier consiste à faciliter les partenariats réalisés autour du signalement partagé des collections numériques, à partir de l’expérience menée avec le projet La France en Amérique. Il se traduit également par l’accès via Gallica à des collections numériques externes, comme celles des partenaires de la BnF au niveau français. Le second objectif vise à améliorer la visibilité des ressources de la BnF (documents numérisés, notices bibliographiques) sur Internet, au sein de portails documentaires (comme le Sudoc), de fournisseurs de service généralistes (OAIster…), ou de moteurs de recherche grand public (Yahoo!, MSN, Google…). Enfin, nous comptons à terme créer un moteur de recherche fédéré portant sur l’ensemble des bases de données documentaires, qui soit interrogeable sur le site internet public de la BnF, en s’appuyant sur une couche Dublin Core/ OAI, sur le modèle de ce que la bibliothèque nationale d’Australie a réalisé sur la page d’accueil de son propre site.

Concrètement, la réalisation du projet a abouti à la mise en ligne de deux entrepôts, l’un pour les collections numériques (OAI-NUM), l’autre pour les catalogues (OAI-CAT). Il nous a paru important de distinguer d’emblée deux types de services dont pourront bénéficier les utilisateurs finaux : d’une part, l’accès direct aux documents primaires (OAI-NUM), d’autre part, l’accès à l’information secondaire, aux informations décrivant l’ensemble des documents conservés à la BnF (OAI-CAT).

L’entrepôt OAI-NUM est le premier à avoir été développé. Il signale à ce jour 60 538 documents numériques provenant de la collection Gallica (près de 45 000 monographies imprimées, plus de 1000 titres de périodiques, et 14 000 ou images ou lots d’images(4)). D’autres collections numériques ont vocation à enrichir cet entrepôt : Mandragore, la base iconographique du département des Manuscrits ; la Banque d’Images du département de la Reproduction ; les images des Dossiers pédagogiques ainsi que des Expositions virtuelles. Bien entendu, le programme de numérisation de masse aura pour conséquence directe un accroissement du nombre de documents consultables dans Gallica et signalés dans l’entrepôt OAI.

Dernièrement, une étape décisive a été franchie avec la mise en ligne de l’entrepôt OAI-CAT. Le serveur contient actuellement plus de 9,8 millions de notices en Dublin Core non qualifié provenant du catalogue BN-Opale plus, ce qui en fait l’un des plus riches au monde. Il est organisé en 242 sets (par grandes classes de la Dewey, types de documents, fonds ou collections…) de manière à permettre le moissonnage sélectif de données, comme pour OAI-NUM. A terme, les descriptions du catalogue Archives et Manuscrits de la BnF viendront compléter cet ensemble, déjà important. Un long travail de spécification et de développement a été nécessaire pour obtenir ce résultat (définition des règles de conversion depuis le format Intermarc vers le Dublin Core ; dimensionnement de l’architecture technique pour gérer convenablement les flux de données et optimiser les performances du serveur). Il nous reste encore beaucoup à apprendre des utilisations qui seront faites des données de la BnF, dans la perspective d’une interopérabilité qui dépasse la communauté des bibliothèques.

Parallèlement à la mise en place de ces deux entrepôts, la BnF tire parti des opportunités qu’apporte l’OAI dans le domaine de la coopération. Après une première expérimentation avec la Library of Congress au sein du projet La France en Amérique, le signalement de collections externes au sein de la bibliothèque numérique Gallica s’amplifie progressivement : plus de 4 000 documents provenant du Conservatoire numérique des Arts et métiers, de Medic@ (Bibliothèque interuniversitaire de médecine), des Bibliothèques virtuelles humanistes du Centre d’études supérieurs de la Renaissance de Tours, du Patrimoine numérisé des Universités de Strasbourg sont à présent intégrés à l’index central de Gallica, aux côtés des fonds de la BnF. Cette liste n’est pas close et s’allongera en fonction des besoins des partenaires et de leur souhait de recourir à l’OAI pour valoriser leurs collections.

C’est également l’OAI-PMH qui a été retenu dans la réalisation du prototype Europeana, la contribution de la BnF à la Bibliothèque numérique européenne. Ce démonstrateur, lancé en mars 2007, s’appuie sur une sélection de 12 000 documents, dont 4 000 sont issus de la Bibliothèque nationale de Hongrie et 1 000 proviennent de la Bibliothèque nationale du Portugal. L’existence préalable d’entrepôts OAI pour ces deux établissements, ainsi qu’une convergence dans les critères de sélection documentaire (pluridisciplinarité, dimension européenne), ont prévalu au choix d’intégrer ces deux collections, préfigurant ce que pourrait être une offre de bibliothèque numérique à l’échelle européenne. Dernière réalisation, Gallica 2, projet évolutif qui succèdera à la version actuelle de Gallica fin 2008, bénéficie des innovations apportées par Europeana. Du point de vue technique, son indexation repose sur les données de l’entrepôt OAI, auxquelles sont ajoutées les résultats de l’OCR. C’est la raison pour laquelle les notices affichées dans Gallica 2 sont au format Dublin Core.

L’OAI-PMH tient ses promesses. Au-delà de ses aspects techniques, il permet de mener des projets ambitieux qui aillent dans le sens d’une valorisation des collections, d’une meilleure diffusion des données sur Internet, d’une multiplication des points d’accès et de visibilité des ressources patrimoniales. Il reste du chemin à parcourir pour exploiter au mieux les potentialités de cet outil, première étape vers une utilisation plus généralisée des « web services ».


  1. La documentation est disponible sur le site officiel : http://www.openarchives.org/
  2. Ces six requêtes sont : Identify, ListRecords, ListIdentifiers, ListSets, ListMetadataFormats, GetRecord
  3. Consultable en ligne, depuis août 2006 à l’URL :  http://bibnum.bnf.fr/oai/
  4. NB : un lot peut contenir jusqu’à plusieurs centaines d’images.

Frédéric Martin
Bibliothèque nationale de France, Direction des Services et des Réseaux,
Département de la Bibliothèque numérique

Imprimer Retour haut de page