technique adaptée
2.2.1 Présentation des protocoles d’interrogation synchrone et asynchrone
On distingue deux grandes tendances dans les protocoles permettant la recherche fédérée sur plusieurs bases de données, toutes deux reposant sur une syntaxe d’échange XML (eXtensible Markup Language) :
Les protocoles d’interrogation asychronele protocole OAI-PMH (Open Archive Intiative Protocol for Metadata Harvesting) qui consiste en une fédération des contenus au sein d’un entrepôt OAI commun à l’ensemble des répertoires de ressources concernés : les différentes bases de données sont transformées en entrepôts OAI qui sont moissonnés par un programme appelé « moissonneur », ce
« moissonneur » ne conserve que les dernières métadonnées ajoutées depuis sa dernière moisson et les « stocke » dans un entrepôt OAI commun qui permettra d’alimenter l’index consultable en ligne. De ce fait les bases de données ne sont jamais interrogées directement. Par ailleurs les bases de données n’ont pas besoin d’être moissonnées en ligne, il est en effet également possible de faire un export XML sur l’entrepôt commun qui lui doit être interrogeable en ligne.
Le schéma suivant, réalisé par François Nawrocki1, permet de mieux comprendre le fonctionnement du protocole OAI :
1 NAWROCKI, François. Le protocole OAI et ses usages en bibliothèques [en ligne]. Mise en ligne le 28 janvier 2005, dernière mise à jour le 15 février 2005 [consulté le 9 août 2011].
Les protocoles d’interrogation synchronele protocole Z39.50 évoluant progressivement aujourd’hui grâce aux protocoles SRU/SRW (« Search/Retrieve via URL/Web »). L’interrogation se fait directement en ligne sur les diverses bases de données concernées : la requête est traduite en Z39.50 à la base de données par un serveur Z39.50 qui fournit une réponse traduite en Z39.50 par ce même serveur.
SRU/SRW ont été développés dans l’optique de retranscrire les procédures pour les rendre conformes à celles du Web : il s’agit, pour résumer, de transcrire les requêtes Z39.50 dans une seule URL (selon une technique REST pour le SRU et une encapsulation SOAP pour le SRW). Le protocole Z39.50 nécessite donc que les bases de données soient interrogeables en ligne.
Le schéma suivant, réalisé par Dominique Lahary2, permet de mieux comprendre le fonctionnement du protocole Z39.50 :
2 LAHARY, Dominique. La norme Z3950 [en ligne]. Mise en ligne octobre 1998, dernière mise à jour le 18 mars 2003 [consulté le 9 août 2011].
http://www.lahary.fr/pro/z3950/index.htm
2.2.2 Comparatif des forces et faiblesses des protocoles existants
Le tableau suivant dresse un comparatif des avantages et des inconvénients des protocoles OAI-PMH et Z39.50 dans le cadre de la mise en place d’un portail documentaire. Selon les contextes et les ambitions d’un projet de portail documentaire, l’une de ces solutions apparaît davantage adaptée.
Protocole OAI Protocole Z39.50
Le fonctionnement Les notices de chaque base sont basculées dans un entrepôt OAI, cet entrepôt est moissonné selon une fréquence prédéfinie. La moissonneuse « dépose » ses récoltes dans un index central qui sera interrogé par l’utilisateur
Chaque base de données est interrogée par un serveur propre qui traduit les requêtes et les réponses en Z39.50
Les avantages -Rapidité de la réponse car une requête est adressée à une base
« fédératrice », la fédération a donc été effectuée en amont -Aucun risque d’altération pour les bases d’origine
-Aucune surcharge sur les
-Interrogation en temps réel, ce qui permet d’avoir accès aux dernières notices créées ou modifiéesprotocole
synchrone
-Prise en compte de divers formats de notices structurés (tels que le MARC, le GRS-1etc.),
-Aucun besoin de faire basculer une base de données locale en OPAC Web, seul l’entrepôt de stockage doit être accessible en ligne
formats d’image et de son
Les inconvénients -Le résultat d’une requête reflète l’état « figé » des répertoires de ressources au dernier moment où ils ont été moissonnés, les informations les plus récentes ne sont donc pas accessiblesil s’agit d’un protocole asynchrone
-Le format Dublin Core (qui est le format préconisé par le protocole OAI-PMH, même si d’autres formats sont pris en compte) est un format relativement pauvre (15 champs de métadonnées pour un Dublin Core non qualifié) par rapport à la richesse des métadonnées liées à des collections muséales
-Fait peser une charge supplémentaire sur les serveurs des bases de données
-Temps de réponse plus long, une requête est dupliquée pour chaque base
Les contraintes de
mise en place -Si les bases de données ne sont pas en OPAC web (interrogeables en ligne), cela nécessite que les notices de tous les répertoires de ressources soient exportées dans l’entrepôt dans une syntaxe XML et de préférence dans un format Dublin Core non qualifié.
-Configurer le moissonneur
-Nécessite que chaque base soit accessible en ligne, d’où le besoin de basculer les répertoires de ressources en OPAC Web pour les rendre interrogeables par un serveur Z39.50
2.2.3 La solution ODBC
Outre les protocoles OAI et Z39.50, il existe un logiciel permettant d’interroger simultanément plusieurs bases de données en synchrone et prenant en compte tous les formats de notices sans restriction : l’ODBC (Open Database Connectivity).
L'architecture ODBC est formée de quatre composants :
Une interface de programmation d'application (API) qui appelle les fonctions ODBC pour effectuer une connexion à une source de données, envoyer et recevoir des données, puis effectuer la déconnection.
Un gestionnaire de pilotes qui fournit des informations à une application (par exemple, une liste des sources de données disponibles), charge les pilotes dynamiquement en fonction des besoins et vérifie les arguments et la transition d'état.
Un pilote qui traite les appels de fonctions ODBC et gère tous les échanges entre une application et une base de données relationnelle spécifique. Si nécessaire, le pilote peut convertir la syntaxe SQL standard dans le langage SQL natif de la source de données de destination.
Une source de données qui comprend les données et le moteur de base de données associé.
L’application utilise l'API ODBC pour se connecter à une source de données, soumettre des instructions SQL, extraire des données et se déconnecter. Un gestionnaire de pilotes, situé entre l'application et les pilotes ODBC, décide du pilote à charger et gère les communications lors des appels aux fonctions des pilotes. Enfin, les pilotes mettent en œuvre les fonctions de l'API ODBC pour la base de données concernée.
Par conséquent le logiciel ODBC permet d’accéder de façon uniformisée à des données stockées dans différents formats de bases de données. L’ODBC repose sur des connecteurs spécifiques et configurables qui permettent d’interroger simultanément différentes bases de données et d’extraire les résultats selon les formats propres à ces bases de données (contrairement au protocole OAI qui restitue l’information dans un format pauvre), ce qui pourrait s’avérer judicieux dans un contexte muséal dans la mesure où les répertoires de
ressources dans les musées contiennent des notices riches en métadonnées qui seraient, dans le cadre d’un moissonnage OAI, forcément appauvries par un affichage en Dublin Core.
2.2.4 De la fédération des contenus à la fédération des contenants : les « dataware-houses »
Au-delà du choix entre protocole d’interrogation synchrone ou asynchrone, la recherche fédérée peut techniquement s’appuyer sur une fédération non de contenus, mais de contenants. C'est-à-dire que ce ne sont pas les données qui sont mises en commun mais leurs bases de données d’origine au sein d’entrepôts de données (dataware houses).
Il s’agit d’une technologie déjà largement utilisée dans l’informatique décisionnelle en entreprise. Cela consiste à centraliser dans une base de données commune des systèmes métier aux structures très hétérogènes. Cette option permet aux acteurs d’un projet de mutualisation de garder les applicatifs métier de leurs applications, mais les contenus pertinents pour le portail sont mutualisés dans une base de données commune. La difficulté principale réside alors dans la synchronisation des données entre cette base matricielle et chaque application. L’un des avantages de cette solution est d’être souple, c'est-à-dire qu’elle permet d’accueillir tout nouvel acteur du portail grâce à une structure de données facilement paramétrable et à géométrie variable (16, BREBION, BEL). Par exemple le logiciel doit autoriser la création de nouveaux champs non prévus initialement si un nouvel acteur, un musée, possède comme champ dans son application propre de gestion de fonds un champ « fragilité ».