L'utilisation du protocole OAI-PMH par le Portail

De Doc.

Le protocole OAI comprend six requêtes distinctes qu’un portail peut effectuer vers un entrepôt. On discutera ici de celles qui concernent particulièrement le fonctionnement du Portail.

Sommaire


Identifiant de la notice (requêtes ListIdentifiers, ListRecords, GetRecord)

Chaque notice dans un entrepôt possède un identifiant unique, qui est fourni au Portail en réponse à des requêtes ListIdentifiers et ListRecords, et qui sert au Portail à requérir une notice particulière à l’aide de la requête GetRecord.

Cet identifiant doit se conformer à la syntaxe des URI. Plus pratiquement, on utilisera le format recommandé pour OAI, plus restrictif et plus simple, et qui permet des mentions telles que :

oai:nom de domaine de l'organisme:identifiant local

pour un organisme qui n'a qu'un entrepôt (ou qui veut le faire paraître) ou :

oai:nom de domaine de l'organisme:entrepôt:identifiant local

Par exemple :

oai:ensembleinter.com:523

identifie la notice n° 523 de l'ensemble intercontemporain - sans mention d'entrepôt (donc, s'il y en a plusieurs, les identifiants doivent tous différer les uns des autres) ; autre exemple :

oai:ircam.fr:catalogue:13459

identifie la notice n° 13459 de l'entrepôt catalogue de l'Ircam (rien n'empêche une notice d'un autre entrepôt de l'Ircam de porter le même numéro, si les identifiants des deux notices distinguent les deux entrepôts).

La seconde composante de cet identifiant, nom de domaine de l'organisme est différente d'organisme à organisme, et commune à tous les entrepôts de l'organisme auquel elle se rapporte. Dans le cas où un organisme dispose de plusieurs entrepôts, il peut en distinguer les notices à l'aide d'une troisième composante.

Les identifiants ne sont pas des URLs, même si techniquement une URL est une URI. Il s'agit ici d'un identifiant de la notice indépendant du logiciel qui sert à la fournir. Cet identifiant servira à construire l'URL que le Portail fournira pour accéder à la notice qu'il fournira pour décrire cette ressource, par exemple : http://www.musiquecontemporaine.fr/record/oai:ensembleinter.com:523 (cf. la description des URLs normalisées) et qui sera donc utilisée par les moteurs de recherche lors de leur indexation du Portail. Si cet identifiant change, ceci aura pour conséquence de rendre le référencement dans les moteurs incorrect. Il est donc primordial d'assurer la permanence de ces identifiants.

Gestion des droits d'accès aux contenus (requête Identify)

La requête Identify sert au Portail à déterminer des informations de base concernant l'entrepôt interrogé. Chaque partenaire doit s'assurer qu'au moins un de ses entrepôts fournisse en réponse à cette requête un conteneur décrivant l'étendue de l'intranet du partenaire (et non de l'entrepôt, cf. accès aux contenus numériques).

<description>
<perimeter xmlns="http://www.musiquecontemporaine.fr.eu.org/schemas/perimeter/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.musiquecontemporaine.fr.eu.org/schemas/perimeter/ :: http://www.musiquecontemporaine.fr.eu.org/schemas/perimeter/">
<range>IP[/nn][, IP[/nn]...</range>
</perimeter>
</description>

Le périmètre consiste en un ou plusieurs numéros IP d'ordinateurs (par exemple : 192.168.1.24) ou de sous-réseaux d'ordinateurs spécifiés à l'aide d'une paire réseau/masque (par exemple : 192.168.3.0/24, qui dénote l'ensemble des adresses 192.168.3.0-192.168.3.255).

Notices effacées (requête Identify)

Au fil du temps, il se peut qu'une notice qui avait été présentée à la moisson soit effacée de la base d'origine (par exemple : un événement du passé dont on ne veut garder trace, une notice d'ouvrage désherbé, etc.) Rappel du protocole : les entrepôts doivent annoncer la façon dont ils gèrent cette destruction de notices. Ils ont le choix :

  1. de ne pas le gérer : dans ce cas, lorsque la notice sera effacée, elle ne sera plus présentée dans l'entrepôt. Si le Portail n'a pas réinitialisé (pour quelque raison que ce soit) le résultat de ses moissons précédentes, cette notice sera toujours visible dans le Portail.
  2. de le gérer temporairement ou pour toujours : dans ce cas, l'entrepôt continuera à présenter à la moisson cette notice mais sans aucune métadonnée attachée, et accompagnée d'une information sur sa disparition. Ceci permettra au Portail d'en effacer la copie qu'il avait obtenue d'une moisson précédente.

Gestion des lots de notices (requête ListSets)

Les entrepôts pouvent comprendre des notices qui ne concernent pas uniquement la musique contemporaine. Il est donc nécessaire que le Portail puisse effectuer une moisson sélective qui n'inclura que les notices pertinentes. À cette fin, l'administrateur de l'entrepôt peut les regrouper en des lots (sets, en anglais), dont il fournira la description qui sera renvoyée en réponse à la requête [ListSets]. Une réponse type est de la forme suivante (une par lot) - exemple tiré de l'entrepôt OAI de la BnF :

<set>
<setSpec>catalogue:fonds:muscont</setSpec>
<setName>catalogue : fonds : Musique contemporaine</setName>
<setDescription>
<oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/">
<dc:description xml:lang="fre">Cet ensemble donne accès aux notices bibliographiques des documents de musique contemporaine.</dc:description>
<dc:description xml:lang="eng">This set provides access to the bibliographic records of contemporary music.</dc:description>
</oai_dc:dc>
</setDescription>
</set>

Le conteneur <setSpec> fournit l'identifiant du lot ; si l'administrateur du Portail considère que ce lot doit être moissonné, c'est cet identifiant qu'il utilisera pour paramétrer le Portail à cette fin (il doit se conformer à la syntaxe décrite dans le protocole OAI). Selon la répartition des lots, il se peut que le Portail moissonne plusieurs lots dans le même entrepôt (par exemple : s'il y en a un qui regroupe les notices de musique contemporaine pour la période 1945-1999 et un autre pour la période commençant en 2000). Un entrepôt qui n'annonce aucun lot sera moissonné dans sa totalité. Enfin, une notice peut faire partie de plusieurs lots.

Gestion des longs échanges

Les transferts d’informations (de listes de notices ou d’identifiants de notices) entre le Portail et un entrepôt pouvant être particulièrement longs, notamment lors d’une moisson initiale ou suivant une réinitialisation, l’entrepôt fragmente les listes de réponses en paquets comprenant, par exemple, 50 ou 100 réponses ; à la requête d’origine, il ne fournira que le premier paquet. Il doit alors fournir à la fin de ce paquet un jeton de continuation (en anglais, [resumption token]) qui servira au Portail à émettre une nouvelle requête destinée à obtenir le paquet suivant, et ainsi de suite jusqu’à l’obtention de la totalité des réponses.

Comment créer son entrepôt OAI

Un entrepôt OAI consiste en un ensemble de logiciels capables d’extraire des notices à partir d’une base de données (catalogue ou autres), de les mettre en forme (par exemple : MODS), de les attribuer à des lots distincts selon le cas, et à répondre aux requêtes d’un moissonneur.

La mise en œuvre d’un entrepôt peut se faire, en principe, de deux façons différentes :

  1. utilisation d’un module interne au logiciel (ou progiciel) gérant la base de données ; c’est le cas pour les bases gérées par le logiciel de gestion de bibliothèques Aloès, utilisé chez plusieurs partenaires du Portail ;
  2. réalisation d’un logiciel externe, qui obtient les notices de la base en question de l’une de deux façons :
    1. par l’entremise de requêtes qu’il enverra selon que de besoin à la base pour en extraire les notices, ce qui lui permettra de les traiter à la volée ; ceci suppose que le logiciel gérant la base propose un volant de requêtes (appelé API en anglais – application programming interface).
    2. à la suite d’exports des notices effectués manuellement (ou de façon programmée) à l’aide d’une commande proposée par le logiciel gérant la base ; une fois ces exports finis, les notices pourront être traitées. Le prétraitement peut être plus ou moins complexe, selon que la commande d’export fournit des notices traitées ou brutes (comprenant, par exemple, des liens vers d’autres tables qu’il faut aussi exporter et traiter). C’est la solution qui a été adoptée pour créer un entrepôt à partir des notices gérées par le logiciel de gestion de bibliothèques Loris, utilisé chez un autre partenaire.

La réalisation du logiciel externe lui-même n’est pas difficile : il suffit d’utiliser un logiciel libre à l’instar de phpOAI2 (solution adoptée pour plusieurs des entrepôts participant au Portail). Un prétraitement développé spécifiquement sert à récupérer les notices de la base (soit à l’aide d’un API soit à partir d’un export), d’en extraire les contenus adéquats qui seront mis dans une base de données (MySQL, par exemple). phpOAI2 est alors paramétré pour produire, à partir de ces contenus, des notices au format souhaité (MODS, en l’occurrence). Il répondra ensuite aux requêtes de moisson lancées par le Portail.

Outils personnels