Notre cas d’usage

Nous avons ainsi recommandé OAI-PMH à l’un de nos clients, le Laboratoire NT2 qui, avec le Consortium on Electronic Literature (CELL), souhaite fédérer les extraordinaires ressources bibliographiques des membres du CELL, qui décrivent des nouvelles formes de textes et d’œuvres hypermédiatiques, une foule d’objets que les membres du CELL sont parfois les seuls à répertorier et à étudier. Chaque partenaire gère ses données de manière indépendante, dans ses propres systèmes d’information, d’où la nécessité d’un protocole interopérable pour échanger les données.

Notre analyse devait aussi identifier un format de données adapté aux besoins du CELL, des besoins que nous connaissions très bien pour avoir accompagné le NT2 dès les premiers balbutiements du projet. Le protocole OAI supporte par défaut le format Dublin Core, un format ni assez étoffé, ni assez extensible pour représenter certains des champs de données particuliers au CELL. Heureusement, le protocole OAI peut aussi transporter les métadonnées dans n’importe quel schéma XML. Nous avons opté pour le format Metadata Object Description Schema (MODS), qui offre plusieurs avantages :

• MODS permet de représenter fidèlement et de manière parfaitement structurée les données du CELL.
• Héritant d’une grande partie des caractéristiques du format MARC utilisé par les bibliothèques et dont il incarne une sorte de modernisation, MODS est très répandu.
• L’emploi d’un format connu favorise l’interopérabilité, ouvre la porte à un rayonnement au-delà du seul cercle des membres du CELL.
• Jouissant d’un support important de la Bibliothèque du Congrès américain, le format est bien entretenu et continue à évoluer.
• Il est possible de représenter des vocabulaires contrôlés, et les autorités ne sont pas limitées à un ensemble prédéterminé. Ceci est essentiel, puisque le CELL aura ses propres autorités.

Au terme de notre analyse, les membres du CELL ont adopté l’architecture d’échange de données basée sur OAI-PMH et MODS, chacun promettant la mise en œuvre d’un dépôt OAI-PMH sur ses serveurs. En parallèle, les membres avaient déjà accompli un ambitieux travail d’harmonisation des champs et des vocabulaires contrôlés, un effort essentiel pour assurer une cohérence du répertoire fédéré, dans l’intérêt de ses utilisateurs.

La mise en œuvre dans Drupal

Notre mission se poursuivait ensuite avec l’implantation d’un dépôt OAI-PMH dans le site Drupal du Laboratoire NT2, au moyen d’une recette suffisamment générique pour être utilisable par des partenaires ayant aussi des systèmes basés sur Drupal.

Au cours de la période d’analyse, nous avions déjà créé un site Drupal prototype, un diffuseur OAI-PMH reposant sur le module Views OAI-PMH, qui fournit des extensions au module Views. Views permet de créer une vue chargée de filtrer les contenus et d’extraire les données des champs, tandis que Views OAI-PMH permet d’établir les correspondances entre chaque champ d’une vue (par exemple l’auteur d’une œuvre) et un élément XML du format de métadonnées (par exemple l’élément <dc:creator> de Dublin Core).

Notre prototype était incomplet puisqu’il utilisait le format Dublin Core (Views OAI-PMH ne supportait pas MODS), mais la démonstration était fort concluante. Un second site Drupal agissait à titre de moissonneur, à l’aide du module Feeds OAI-PMH Fetcher and Parser.

Le format MODS, toutefois, amenait de nouvelles difficultés, particulièrement en raison de son grand usage des attributs XML. En effet, pour chaque enregistrement, Views OAI-PMH ne permettait qu’une valeur unique par attribut, alors qu’avec MODS certains attributs se présentent avec différentes valeurs, sur différents éléments d’un même enregistrement. En fouillant un peu plus le module, nous avons aussi identifié d’autres problèmes, ce qui nous a conduit à une réécriture presque complète, aujourd’hui publiée sur GitHub. Les principaux changements que nous avons apportés sont :

• Une architecture simplifiée comportant seulement deux extensions pour Views au lieu de dix.
• L’élimination des variables globales, remplacées par un dispositif de chargement paresseux (lazy loading) des définitions de formats de métadonnées.
• L’ajout de nouveaux hooks, à la manière de Drupal, qui permet à des modules tiers d’implémenter de nouveaux formats de métadonnées ou d’altérer les formats déjà offerts, sans aucune modification à Views OAI-PMH.
• Un mécanisme de mise en correspondance des champs de la vue vers les éléments d’un format de métadonnées qui utilise sa propre structure de données plutôt que de détourner (de manière douteuse) les étiquettes des champs de la vue.
• La possibilité d’avoir plusieurs instances d’un même attribut, chacune avec une valeur distincte, sur différents éléments XML (dans le module original, chaque attribut n’avait qu’une valeur globale pour tout l’enregistrement).
• Une construction plus robuste des réponses XML, via la classe DOMDocument de PHP.
• La séparation complète de la logique de programmation et de la couche de présentation (theming) de Drupal.

Bien entendu, nous avons aussi incorporé le format MODS au module, qui s’ajoute aux formats qui étaient supportés par la version originale de Views OAI-PMH. Ainsi les formats supportés sont :

• Dublin Core (oai_dc).
• Metadata Object Description Schema (mods).
• Learning Objects Metadata (oai_lom).
• Learning Resource Exchange (oai_lre).
• IMS Learning Objects Exchange (oai_ilox).

Il est rare que nous procédions à la refonte aussi profonde d’un module existant. Si d’habitude l’esprit de la communauté Drupal nous amène tout naturellement à travailler de concert avec les responsables des modules existants pour graduellement améliorer les solutions, cette fois l’envergure des changements nous est apparue comme trop profonde pour être réalisable par petits pas dans l’habituel processus de soumission, justification et révision des changements. Il est possible que certains changements, comme la création d’une nouvelle classe représentant les paramètres de la requête, eussent été difficiles à défendre de manière isolée, puisqu’ils ne devaient prendre leur sens que plus tard dans le développement, avec d’autres changements venant prendre appui sur ces nouvelles fondations.

L’une des beautés du développement en logiciel libre, c’est la liberté. Pour cette fois nous avons choisi la fourche (fork), ce qui ne nous empêchera pas de travailler avec les responsable du module original en vue d’un rapprochement. D’ici là, vous avez le choix entre au moins deux solutions pour intégrer OAI-PMH dans un site Drupal.

Cette solution sera bientôt déployée en production. En attendant, nous nous attaquons déjà à la phase suivante du projet : le moissonnage des enregistrements sur un site Drupal. Si notre moissonneuse basée sur le module Feeds OAI-PMH Fetcher and Parser fonctionnait bien pour le format Dublin Core, le module Migrate OAI-PMH est apparu depuis et méritera examen. Dans un cas comme dans l’autre, nous devrons développer tout ce qui est nécessaire pour traiter le format MODS.