UNIVERSITÉ LILLE III - CHARLES DE GAULLE UFR Mathématiques, Sciences Économiques et Sociales CENTRE D ETUDES TECHNIQUES DE L EQUIPEMENT Point national d appui documentaire Rapport de Stage Master Informatique du Document Développement d un portail de Recherche Fédérée basé sur Apache Solr Grégoire Neuville Responsables pédagogiques Rémi Gilleron Fabien Torre Responsable professionnel André Davignon
J adresse mes remerciements à l équipe du Pandoc pour son accueil, plus précisément à André Davignon pour ses précieux conseils, à l équipe enseignante du Master Informatique et Document
Table des matières 1 Introduction 5 2 Contexte de Stage - Présentation de la mission 6 2.1 Contexte................................. 6 2.1.1 Le CETE - Pandoc....................... 6 2.1.2 Système d information documentaire du Pandoc...... 6 2.2 Mission................................. 7 2.2.1 Besoins et existant....................... 8 2.2.1.1 Portail......................... 8 2.2.1.2 Besoins........................ 8 2.2.1.3 Existant........................ 9 2.2.2 Outil et Concept........................ 10 2.2.2.1 Solr.......................... 10 2.2.2.2 Recherche fédérée................. 12 3 Recherche Fédérée 14 3.1 Définitions théoriques......................... 14 3.1.1 Acception principale...................... 14 3.1.2 Variété lexicale......................... 14 3.2 Dimension technique.......................... 16 3.3 Retour sur le contexte de la mission................. 20 4 Configurations de Solr et tests 22 4.1 Configurations............................. 23 4.1.1 Mono-index........................... 24 4.1.1.1 Schéma........................ 24 4.1.1.2 Description...................... 24 4.1.2 Multi-index multi-instances.................. 25 4.1.2.1 Schéma........................ 25 4.1.2.2 Description...................... 25 4.1.3 Multi-index multi-cores..................... 26 4.1.3.1 Schéma........................ 26 4.1.3.2 Description...................... 26 4.2 Tests................................... 26 4.2.1 Environnement......................... 28 4.2.1.1 Données....................... 28 4.2.1.2 Logiciel........................ 32 4.2.1.3 Matériel........................ 32 4.2.2 Résultats............................ 32 4.2.2.1 Tests d Indexation.................. 33 4.2.2.2 Tests de Requêtes.................. 34 4.3 Synthèse................................ 37 3
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 0.0 4.3.1 Tests d indexation....................... 37 4.3.2 Tests de requêtes....................... 37 4.3.3 Conclusions........................... 38 5 Conclusion 41 A Schémas d indexation 45 A.1 Schéma RDFS de la base Urbamet................. 45 A.2 Schéma d indexation Solr....................... 47 B Feuilles XSL 54 B.1 Feuille de transformation des notices Notix en notices Solr..... 54 B.2 Feuille de transformation des schémas RDFS Notix en schéma solr 58 4
1 Introduction Ce rapport présente le stage que j ai effectué au Centre d Etudes Techniques de l Equipement Nord-Picardie, au sein du département nommé Pandoc (Point national d appui documentaire), situé à Lille, pour une période de six mois du 18 février 2008 au 14 août 2008. Il constituait la dernière étape du Master Informatique et Document dispensé à l université de Lille III. Dans le cadre de cette formation, un projet avait été réalisé dont l objectif était de reproduire une application web de consultation de notices catalographiques, initialement développée par le Pandoc, à partir de la plateforme de publication Apache Cocoon et du moteur de recherche Apache Solr. C est dans la continuité de ce projet que m a été proposée la mission dont je rends compte dans ces pages et qui visait, à partir des mêmes technologies, à développer un portail de recherche fédérée. La mission s est déroulée en deux temps : une première phase a consisté à étudier les possibilités qu offre Solr en matière de recherche fédérée, puis à concevoir et mettre en oeuvre des tests des solutions retenues la deuxième phase a été consacrée au développement de l application de consultation, c est-à dire du portail en lui-même. Je dois préciser ici que le développement du portail n est pas achevé. Par conséquent, j ai choisi de ne consacrer ce rapport qu à la première phase. Son plan est articulé en trois partie : la première est consacrée à la présentation du contexte de stage ; la seconde à l axe théorique qui le sous-tendait et en constituait l objectif, à savoir la recherche fédérée ; la rencontre de cet objectif et de l outil que j avais à utiliser - Solr - n a pas été sans poser un certain nombre de problèmes : ce sont les solutions que j ai pu proposer et leur validation par une série de tests dont la troisième partie rend compte. 5
2 Contexte de Stage - Présentation de la mission 2.1 Contexte 2.1.1 Le CETE - Pandoc Le Centre d Études Techniques de l Équipement est un bureau d ingénierie publique au service des collectivités territoriales, des organismes publics, parapublics ou privés ou des services de l Etat. LE CETE Nord-Picardie est membre du Réseau Scientifique et Technique du Ministère de l Écologie, de l Énergie du développment durable et de l aménagement du territoire (MEDAD). Coordonné par la Direction de la Recherche et des Affaires Scientifiques et Techniques (DRAST), il rassemble les 7 CETE du territoire national et la Direction Régionale de l Équipement d Ile-de-France (DREIF). Il abrite le point national d appui documentaire (Pandoc) qui assure la partie technique de la politique documentaire du MEDAD et de ses 130 centres de documentation. Plus précisément, le Pandoc héberge, donne accès et administre les banques de données documentaires du ministère assure la maîtrise d oeuvre des applications nationales informatiques du domaine assiste la maîtrise d ouvrage centrale pour la conduite et le pilotage d études effectue des prestations de conseil, d assistance ou de maîtrise d oeuvre assure la formation des utilisateurs effectue une veille technologique dans le domaine 2.1.2 Système d information documentaire du Pandoc Pour mener à bien ces missions, le Pandoc s appuie sur un système d information documentaire sophistiqué, dont les fonctions majeures sont : la gestion et la publication de notices bibliographiques la gestion de centres de documentation la production de documents structurés 6
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 2.2 Les applications que l on voit sur ce schéma s appuient sur des technologies diverses et dont le nombre va croissant : toutefois, et c est ce qui explique les possibilités de missions pour les étudiants du Master ID, l interopérabilité entre elles est assurée par l usage du métalangage XML. De fait, ce dernier joue, dans le cadre de ce système documentaire, pleinement son rôle de structuration de données - les notices, unité documentaire principalement manipulée au Pandoc, étant au format XML - et de support à la communication entre application. Plus précisément, ce qui intéresse la mission dont je rends ici compte est l application SDX qui propulse les applications de consultation de bases de notices bibliographiques (dont l actuel portail). Sa position à une extrémité du schéma témoigne de son rôle d interface entre le système documentaire et l extérieur ; d autre part, on remarque que la plupart des liens qui l unissent à ce système s établissent avec l application Notix, ce qui est logique puisque celle-ci est en charge de la saisie et la gestion des notices que les applications SDX permettent de rechercher et consulter. 2.2 Mission L intitulé de la mission ( Développement d un portail de recherche fédéré basé sur Solr ) fait s articuler autour d un concept théorique (recherche fédérée) un 7
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 2.2 produit documentaire (portail) et une technologie de recherche. Dans les sections qui suivent, j interroge chacun de ces éléments : ce que constitue un portail et la nécessité de son développement (2.2.1) d abord, puis l environnement technique et théorique de ce développement (2.2.2). 2.2.1 Besoins et existant 2.2.1.1 Portail Dans le cadre d un système d information documentaire, un portail peut être défini comme un point d accès unique à des ressources multiples. Il conjugue généralement les spécificités suivantes : outil de recherche pouvant interroger plusieurs sources distantes personnalisation des services (par authentification, session, cookies, etc...) réservation, panier, historique, toutes fonctionnalités héritées des OPAC (online public access catalog) enregistrement des requêtes, exports des données de réponses en différents formats interface d administration Ainsi défini, il apparaît de suite qu un portail constitue un produit documentaire hautement élaboré, et que, par conséquent, son déploiement en vitrine d un système d information documentaire doit être motivé. Cette motivation s enracine généralement dans une étude de besoins qu il m aurait incombé de réaliser si, à mon arrivée au Pandoc, un portail n eût déjà existé, légitimé par une étude de besoins menée en 2004. En effet, à cette époque s est fait jour le constat de la nécessité de valoriser les ressources documentaires mises en ligne par le Pandoc, les bases de données restant peu ou mal connues, d accès malaisé et en conséquence les statistiques de consultation en baisse. Des attentes fortes ont également été identifiées en rapport au contenu des bases documentaires ainsi qu aux résultats de recherche (BETTOCHI (2008)). Les besoins existaient donc, et pour y répondre, la décision de développer un portail documentaire a été prise. Ses objectifs étaient de proposer une sélection de ressources pertinentes et des services complémentaires ainsi que de permettre un accès unifié aux principales ressources documentaires du ministère, en améliorant par là la visibilité (BETTOCHI (2008)). 2.2.1.2 Besoins La légitimité du portail documentaire n était donc pas en cause. Par conséquent, les besoins relatifs à ma mission se situaient ailleurs ; un nouvel examen du libellé 8
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 2.2 de cette dernière donne la clé : Solr. Les besoins du Pandoc s exprimait là non plus à un niveau documentaire mais technique. Pour mieux discerner la nature de ces besoins, il m a fallut étudier l existant technique à la base du portail. 2.2.1.3 Existant Comme on l a dit plus haut, les applications web de consultation des bases de notices du Pandoc sont propulsées par un logiciel nommé SDX (Système Documentaire en XML). SDX, sur le site officiel du projet 1, est défini ainsi : SDX est un logiciel libre qui vous permet de construire des applications Web documentaires où la recherche joue un rôle important. Basé sur l infrastructure Cocoon 2 de la fondation Apache, il permet de construire des sites Web complexes adaptés à vos besoins. Les deux aspects majeurs d SDX sont ici présents : la construction d applications web de publication de documents et la recherche au sein de ces documents. Pour la publication, SDX s appuie sur le framework Cocoon ; pour la recherche sur la library Lucene. Parmi les avantages d SDX, on peut citer : les grandes facilités qu il offre au développeur en lui fournissant une librairie de tags ( taglib ) qui permet de mobiliser très simplement des fonctions complexes à partir de cette taglib, SDX fournit nativement des fonctionnalités qui peuvent être complexes ou laborieuses à développer intégralement. Ainsi, des fonctionnalités de recherche, de gestion d historique ou de panier, de gestion des droits utilisateurs sont intégrés à la plateforme et n ont pas à être re-développées pour être mises en oeuvre. SDX n utilise que des composants sous licence libre, comme il l est luimême, et donc bénéficie de tous les avantages propre à ce type de licence : évolutivité, interopérabilité, pérénnité, respect des standarts, etc... À l inverse, SDX présente des faiblesses non négligeables : ses capacités d indexation restent limitées et n offrent que peu de souplesse (par exemple au niveau des traitements sur les données avant stockage dans l index (normalisation, tokenization ), des types de données configurables, etc...) ses perfomances, notamment à l indexation, ne sont guère satisfaisantes (comme en témoignent les résultats de tests présentés dans la documentation 2 ) 1 http ://adnx.org/sdx/fr/index.html 2 http ://www.nongnu.org/sdx/docs/html/doc-sdx2/fr/charge/mesures/ajlsm- 200301/indexation.html 9
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 2.2 les communautés d utilisateurs et de développeurs demeurent restreintes après 7 ou 8 années d existence du projet, ce qui, au niveau d un logiciel libre, constitue un handicap certain. enfin, les principaux avantages d SDX, liés à la taglib, repose sur une technologie Cocoon nommée XSP (extended server pages) qui, si elle ne peut être considérée comme obsolète, n en est pas moins de plus en plus souvent déconseillée par les développeurs Cocoon : elle est d ailleurs abandonnée dans la dernière version de ce framework (2.2). La mission que j ai eu à remplir au Pandoc trouve son origine dans le constat de ces faiblesses et dans le premier test de substition de Solr à SDX que fut le projet de Master mentionné en introduction. Ce projet montre d ailleurs que l attention porté à Solr par le Pandoc n est pas nouvelle. Dans la section qui suit, j essaie, en présentant les principales fonctionnalités et qualités de Solr, de mettre à jour quelques unes des raisons de cette attention. 2.2.2 Outil et Concept 2.2.2.1 Solr Pour cette présentation, j utilise les données du woki Solr 3. Solr est un moteur de recherche basé sur la librarie de recherche plein-texte Apache Lucene. Avec Lucene, un document est considéré comme un ensemble de champs. À l indexation, ces derniers sont typés dynamiquement et leur contenu peut faire l objet de traitements tels que la tokenization, des fltrages, etc... Elle utilise la méthode TF/IDF pour calculer les scores de documents au regard d une requête. Solr reprend certaines des fonctionnalités liées à Lucene, mais étend cette dernière pour constituer un moteur de recherche à part entière. En fait, le but fondamental de Solr est d accéder à Lucene par le biais d un service web. Ceci implique : l utilisation d un protocol de communication : HTTP (GET pour obtenir des documents, POST pour en envoyer) une URL vaut une commande (/select pour interroger l index, /update pour le mettre à jour, etc...) la possibilité de déclencher des actions sur l index à distances, via un format d échange de données : XML ( commit / pour déclencher l écriture dans l index, delete query :docid /delete pour effacer un document, optimize / pour lancer l optimisation de l index,...) le retour des réponses dans un format structuré (XML, JSON, PHP, Python,...) 3 SolrResources 10
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 2.2 Les requêtes d interrogation (à l adresse /select) prennent un certains nombres de paramètres dont sont présentés ci-après les principaux : q : la requête (en syntaxe Lucene) start : rang à partir duquel les résultats sont ramenés rows : nombre de résultats à retourner fq : tri sur un champ donné (paramètre caché indépendamment de q) fl : noms des champs à ramener facet.field : champ à partir duquel construire des catégories (facettes) facet.date : champ de type date à partir duquel construire des facettes hl : autorise le highlighting (surlignement) de termes dans la réponse hl.fl : liste de champs sur lesquels effectuer le surlignement hl.fragsize : taille en caractères du fragment à surligner Les éléments que l on vient de décrire révèle les qualités d accessibilité de Solr, de précision de ses requêtes, les options de recherche précieuses qu il implémente (facettes) ; mais sa réputation s est bâtie sur les perfomances dont il fait preuve, notamment à grande échelle (pour des volumes de données importants). Ces perfomances proviennent de plusiseurs éléments de la structure et du fonctionnement de Solr dont on cite ici les principaux : le système de cache : il s appuie sur plusieurs types de cache ; on en donne ici trois le filtercache : il stocke des listes non ordonnées d identifiants de documents et est utilisé notamment par le paramètre fq le queryresultcache : il stocke des listes ordonnées d identifiants de documents - les résultats d une requête (paramètre q) ordonnés selon un critère donné. le documentcache : il stocke des champs de documents récupérés sur le disque dur (tous les champs ne sont pas forcément stockés à l indexation) le Warming : la recherche sur un index est réalisée au moyen d un IndexSearcher (un cliché de l index à un moment donné) ; à chaque nouveau Searcher créé (lorsque l index est modifié par exemple) ce nouveau Searcher est progressivement rempli avec les données de l ancien, lequel pendant ce temps continue à répondre aux requêtes. Un mécanisme similaire préchauffe les caches créés avec l IndexSearcher (tout cache est associé à un IndexSearcher) l indexation : elle repose sur un schéma d indexation 4 et conditionne en fait deux types de perfomances : la pertinence des résultats : elle tient aux analyseurs que l on peut associer à la déclaration d un type de donnée (élément fieldtype, définissant un type chaîne de caractère, texte, etc...) dans le schéma : ces analyseurs sont nombreux et peuvent soit exercer une tokenization des champs de ce type, ou l apparier à un anti-dictionnaire, un thésaurus de synonymes, etc... Le traitement est effectué à l indexation sur les données indexées selon ce type, et au moment de la requête sur les termes de 4 un exemple en est présenté en annexe A.2 11
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 2.2 celle-ci si elle porte sur un champ du type en question. les temps d indexation et de réponses aux requêtes, la consommation des ressources système : les facteurs importants ici sont les attributs indexed et stored que portent les déclaration de champs dans l index (élément field). En effet, plus le nombre de champs indexés est grand, plus la RAM sera sollicitée pendant l indexation, plus les temps d optimisation de l index seront longs et plus la taille de l index sera importante. Concernant les champs stockés, le problème n est pas tatn leur nombre que la quantité de donnée qu on stocke dans un seul champ : interroger un champ qui contient un grand volume de données se traduira par un allongement du temps de réponse. Nombre de ces éléments sont hautement configurables (à l aide d un fichier prévu à cet effet) et, ensemble, font de Solr une application dont la renommée se fonde avant tout sur ses perfomances. Si la page que le wiki Solr consacre à ce propos 5 ne présente que peu d exemples, on en trouve davantages sur la liste solr-user et qui confirment la vocation de Solr aux larges volumes de données (à l échelle souvent minimale du million de documents). Par ailleurs, la version 1.3 de Solr (dont j ai usé durant le stage), fourni de nouvelles fonctionnalités dont : le MultiCore (renomée depuis CoreAdmin) qui autorise la gestion de plusieurs index au sein d une seule servlet (ou webapp) Solr. Son principe de fonctionnement repose sur l instanciation multiple d une classe nommée Solr- Core : chaque instance porte un nom, réunit un schéma d indexation, un jeu de configuration et un index et est interrogeable par URL. la recherche distribuée (Distributed Search) qui permet la recherche sur plusieurs index simultanément. 2.2.2.2 Recherche fédérée Une fois l outil de recherche mieux connu, il s est agit de savoir comment il pouvait répondre à la problématique de recherche fédérée. Afin, donc de montrer en quoi cette problématique a contraint les modèles de configuration de solr que j ai pu élaborer et, à l inverse, comment la contingence technique que constitue Solr a affecté ladite problématique, il faut évidemment d abord définir ce concept de recherche fédérée. C est ce à quoi s attache la partie qui suit, qui procède en trois temps : des définitions théoriques en sont d abord données puis vient une description technique 5 http ://wiki.apache.org/solr/solrperformancedata 12
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 2.2 enfin, le concept ainsi défini est replacé et réinterprété dans le contexte de la mission 13
3 Recherche Fédérée 3.1 Définitions théoriques 3.1.1 Acception principale Le concept de recherche fédérée admet des définitions plus ou moins détaillées, mais qui toutes comportent les mêmes lignes de force. J en cite ici trois, par ordre croissant de précision : Un moteur de recherche fédérée (metasearch en anglais) est un outil de recherche proposant à l utilisateur un formulaire de recherche unique, et qui transmet ensuite la requête à différentes bases de données distantes, récupère la liste de leurs résultats et l affiche sur une page unique pour l utilisateur. La recherche fédérée est avec la gestion de contenu, l un des deux piliers des portails documentaires. (BIBLIOPEDIA (2008)) La recherche fédérée diffuse une unique requête vers de multiples sources d information et en aggrège les résultats, habituellement présentés dans un format courant, au niveau d un seul point d accès. (MARSHALL et al. (2006)) La recherche fédérée est la récupération unificatrice de résultats en réponse à une requête envoyée à plusieurs bases de données hébergées par différents systèmes d information en ligne. Mettre en oeuvre une recherche fédérée consiste à transformer une requête et à la diffuser à un ensemble de bases de données disparates dans une syntaxe appropriée, à fusionner les résultats collectés à partir des bases, à les présenter dans un format succint et unifié avec un minimum de doublons et à permettre le classement des résultats rassemblés selon différents critères. (JACSO (2004)) De ces définitions, il ressort que le processus de recherche fédérée peut être décomposé en cinq phases majeures : traduction de la requête dans les diverses syntaxes des systèmes de recherche visés transmission de cette requête aux dits systèmes récupération des résultats issus des différents systèmes fusion des résultats présentation des résultats dans un format unique 3.1.2 Variété lexicale Une difficulté concernant le concept de recherche fédérée est la grande variété de termes qui le désigne, notamment en anglais. On rencontre ainsi les appellations de : 14
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 3.1 federated search metasearch distributed search cross-databases search broadcast search distributed information retrieval (cette liste provient d un googling effectué par l auteur d un blog consacré à la recherche fédérée (LEDERMAN (2008a))) Cette difficulté se voit redoublée par le fait que ces termes recouvrent souvent des réalités techniques diverses, offrant des solutions à des problèmes eux mêmes différents dans des contextes variés. Pour autant, toutes ces notions et techniques partagent tout de même un objectif : celui d interroger à l aide d une seule requête des sources de données géographiquement distantes(crawford (2004)), ce qui correspond aux deuxième et troisième (quoique la fusion des résultats ne soient pas systématiques) phases précitées. Il m a semblé important de faire ces précisions car dans la suite de ce rapport, j utilise les termes de recherche fédérée et de recherche distribuée. Considérant la variété de vocabulaire dont je viens de parler, il est donc nécessaire d arréter des définitions précises de ces termes afin d éviter toute confusion. Ainsi, par recherche fédérée je désignerai le processus qui met en oeuvre les cinq phases citées plus haut, et par recherche distribuée une restriction de ce processus basée sur une semi-homogénéïté des sources de données qui rend inutile la première des cinq phases 1. 1 cette dernière définition est issue du Wiki Solr (SOLRWIKI (2007)) ; elle est approfondie au point 3.3 15
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 3.2 3.2 Dimension technique Une infrastructure de recherche fédérée peut-être schématisée de la manière suivante : En suivant pas-à-pas ce schéma de droite à gauche et retour, il est possible d expliciter les différentes phases du processus de recherche fédérée et d identifier les composants techniques qu elles mobilisent. Ainsi 2 : le processus débute par une requête formulée par un utilisateur au niveau d une interface de recherche (par exemple un portail web et/ou documentaire) ; c est également au niveau de cette interface que l utilisateur choisit les ressources qu il veut interroger (les systèmes de recherche sur le schéma) 3. Enfin, c est là encore qu en fontion des ressources sélectionnées, les connecteurs qui leur correspondent sont mobilisés pour traiter la requête. les connecteurs sont les éléments centraux d un système de recherche fédérée. En effet, c est à leur niveau que sont centralisées les trois premières des cinq phases mentionneés au point 3.1.1. Ainsi, ces connecteurs sont en charge de : 2 Les éléments de description donnés ici sont issus de LEDERMAN (2008b), MATTSSON (2004), CHERNOV et al. (2006) et LU et al. (2005) 3 Toutefois certains systèmes se contentent de la requête et déterminent à partir de celleci les ressources les plus pertinentes ; dans ce cas, un composant supplémentaire s intercale entre l interface de recherche et les connecteurs. Ce composant analyse la requête (en extrait les termes et les opérateurs booléens) et, en fonction de statistiques tenues sur les différentes ressources, déploie un algorithme de sélection de ces dernières. 16
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 3.2 la traduction de la requête dans la syntaxe attendue par le système de recherche auquel le connecteur est associé. Deux aspects sont ici importants : 1. la syntaxe de la requête : utilisation des opérateurs booléens, des troncatures, des guillemets, parenthèses, etc... 2. la correspondance entre les champs d interrogation proposés par l interface de recherche et les champs des index ou les entrées (noms de tables, de rangs) des bases de données ciblées par les connecteurs 4 La reformulation de la requête consiste donc en la création d une nouvelle requête utilisant les symboles et visant les champs, tables ou rangs reconnus par le système de recherche distant géré par le connecteur. la transmission de la requête qui s effectue selon le protocole par lequel le système de recherche visé est interrogeable. Ce peut être : le protocole Z39.50 : plutôt propre au monde des bibliothèques, il décrit à la fois un protocole de communication client/serveur et une syntaxe de requête ; il autorisait, bien avant l émergence des protocoles liés au world wide web, des interrogations multi-bases (alors appelées cross-databases searches ). Si cette antériorité par rapport aux technologies aujourd hui en vogue ne l ont pas rendu obsolète, il fait toutefois l objet de plusieurs tentatives de modernisation (protocoles SRU (Search/Retrieve Web Service) et SRW (Search/Retrieve URL Service)) qui visent à substituer le protocol de communication Z39.50 par HTTP tout en conservant la syntaxe de requête. le protocole HTTP : 2 cas principaux peuvent se présenter : 1. le système de recherche n est pas un service web : la transmission de la requête revient alors à la validation distante d un formulaire initalement destiné à être validé par un utilisateur humain. Celà peut se révéler une opération difficile suivant la complexité du formulaire lui-même, mais aussi selon la connaissance qu a le développeur du connecteur des paramètres nécessaires à la validation. 2. le système de recherche est un service web : (a) de type REST (Representational State Transfer) : la recherche distante est alors lançée par simple jeu d URI, laquelle pourrait se limiter à l adresse de l applications suivie de la commande à éxécuter (rechercher) et de la requête construite par le connecteur. 4 Par delà la variété des technologies de recherche (indexations plein texte, bases de données relationnelles), cet élément est un critère majeur d appréciation de l hétérogénéïté des ressources. C est une dimension que j ai eu a prendre en compte dans le contexte du Pandoc ; aussi ces aspects sont-ils réabordés au point 3.3 17
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 3.2 (b) basé sur SOAP : dans ce cas, le protocole HTTP ne sert plus que d enveloppe à des messages répondant à un autre protocole : RPC (Remote Procedure Call). Selon ce dernier, le rôle du connecteur sera alors d appeler une procédure - par exemple une méthode de classe - du système de recherche distant en lui passant en paramètre la requête précédemment construite. C est cette procédure qui lançera la recherche. le protocole STARTS (Stanford Protocol Proposal for Internet Retrieval and Search) : élaboré par un groupe de travail de l université de Stanford, il peut être comparé à Z39.50 (en ce qu il décrit à la fois une syntaxe de requête et un protocole de communication) mais au contraire de ce dernier, les communications avec les ressources n exigent pas l ouverture de sessions, et ces ressources sont sans états (autrement dit, comme dans le cas d un service web de type REST, une seul requête est nécessaire à l interrogation). De plus, il prévoit l interrogation automatique et régulière des ressources pour entretenir un jeu de statistiques et de métadonnées utiles au futur interclassement des résultats (voir plus bas). Les problématiques d authentification, de transmission de cookies et de données de session sont gérées à ce niveau également. la récupération des résultats issus du système de recherche associé au connecteur. Ces résultats peuvent être retournés dans des formats divers (HTML, XML, JSON, etc...). Le connecteur a ici pour tâche de de parcourir la iste des résultats, d en extraire les données et métadonnées pertinentes au regard de ce qu attend l interface de recherche (noms des champs, valeurs associées à ces champs, informations de tri,...) et d envoyer ces informations à l interface de recherche au format que cette dernière attend. Cet à ce niveau que sont également traités les problèmes de lenteur ou dysfonctionnement du système de recherche distant. les systèmes de recherche. Ils peuvent être : des moteurs de recherche web des moteurs de recherche fédérée des catalogues de bibliothèques en ligne des services webs etc... L important ici réside dans l exhaustivité et la précision des informations nécessaires à son interrogation et à l exploitation de ses résultats que ce système peut délivrer. Celles-ci conditionnent en effet la simplicité de développment et l efficacité du connecteur dédié au système de recherche. L initative Open Search est un exemple de format de description de système de recherche visant à faciliter l interrogation distante de tels systèmes. les source de données. Elles peuvent être : des index (tels que produits par des moteurs d indexation plein-texte) des bases de données (relationnelles, XML,...) 18
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 3.2 des systèmes de fichiers des annuaires (LDAP) Leur interrogation est la responsabilité des systèmes de recherche cités ci-dessus. Elles ne sont donc pas directement visibles pour l interface de recherche fédérée, mais c est précisemment là que réside l avantage de ce type d interface par rapport à des systèmes basés sur le parcours de liens hypertextes ( crawling ). Un système de recherche fédérée peut ainsi agrégér des données issues du web visible et du web invisible ( deep web constitué notamment de toutes les pages générées dynamiquement à partir de données stockées dans des bases de données, index, etc...). les segments du parcours de retour (de la gauche vers la droite du schéma) qui concerne la problématique de recherche fédérée se situent de par et d autre des connecteurs. Le premier a été évoqué plus haut : c est la récupération et la transformation des résultats issus d un système de recherche distant ; le second comprend la fusion ou interclassement et le dédoublonnage des résultats fournis par l ensemble des connecteurs au niveau de l interface de recherche. C est là une des problématiques les plus complexes que comporte la recherche fédérée et de nombreuses méthodes existent pour y répondre : je n en cite ici que quelques unes. une première approche consiste, une fois obtenus les multiples jeux de résultats, à affecter à chaque documents qu ils comportent un score en appliquant par exemple une méthode statistique (telle TF/IDF, qui calculerait ce score à partir de la fréquence des termes de la requête dans les documents) ou une méthode de similarité basée sur un modèle vectoriel (qui mesurait la distance à la requête des différents documents). L avantage de cette aproche est qu elle ne nécessite pas de connaître les scores attribués aux documents par les divers moteurs de recherche interrogés ; son inconvénient majeur réside dans le fait qu elle applique les méthodes précitées à l ensemble des documents ramenés, ce qui, quand ils sont nombreux, peut se révéler trés lourd en termes de performance. Afin de remédier à ce problème, certaines approches utilisent soit les informations associées aux résultats pour en accomplir l interclassement( d autres difficultés se présentent alors, liées à l hétérogénéïté des systèmes de recherche interrogés : certains retourneront un score pour chaque documents, d autres non ; ou, deux moteurs ayant une partie de leurs résultats semblables, leurs auront affectés des scores différents, n ayant pas déployé les mêmes algorithmes de calcul) ; soit une partie seulement des multiples jeux de résultats. On peut citer la méthode Borda Count, qui ignore les scores attribués par les moteurs, et ne s appuie que sur l ordre dans lequel chacun d eux renvoie ses résultats. Elle fonctionne comme suit : l ensemble des résultats retournés sont considérés comme candidats et chaque moteur comme votant. Pour chaque votant, le candidat le mieux classé se voit assigné n points (s il y a n candidats), le second n-1 points, et ainsi de suite... Pour les candidats n ayant pas reçu de vote par un moteur (parce qu il n ont pas été ramenés par ce moteur), les points 19
PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 3.3 restants du votant (chaque votant dispose d un certain nombre de points) sont répartis également entre eux. Les candidats sont alors classés en ordre décroissant des points qu ils ont obtenus. D autres méthodes existent qui effectuent la même conversion des rangs en scores, mais par des calculs différents (D-WISE). Une autre difficulté éventuelle est la présence de doublons parmi les jeux de résultats. Dans ce cas, les scores qui leurs ont été attribués au niveau de l interface de recherche fédérée doivent être combinés. Un certain nombre de méthodes ont été proposées à cet effet, parmi lesquelles les méthodes min, max, sum, average ou encore CombMNZ. Enfin, certaines méthodes s appuient sur des algorithmes d apprentissage automatique. Un exemple d approche de ce type peut être décrit ainsi : à partir d échantillons de requêtes-tests, une description du contenu de chaque système de recherche est élaborée et stockée dasn une base de données (la base d exemples). Celles-ci peut donner de bonnes approximations des scores que les documents auraient obtenus s ils avaient été récupérés à partir d un seul système global. La requête saisie par l utilisateur est alors transmise non seulement aux ressources sélectionnées, mais également à la base d exemples. Les scores indépendants de tout système de recherche issus de la bases d exemples ainsi que les scores dépendants du sytème de recherche pour chaque système sélectionné alimentent un algorithme d apprentissage qui apprend à transformer les scores dépendants des systèmes en scores indépendants. C est sur la base de ces nouveaux scores que sont finalement classés les résultats. la publication des résultats : elle peut, si l on est sûr qu il ne faille produire qu un affichage se limiter à un format prévu à cet effet (HTML, par exemple) ; néanmoins, il paraît plus pertinent de diffuser un format structuré (XML, JSON ou autre) afin que la plateforme de recherche fédérée publiant ces résultats puissent elle-même être aisément interrogée par un système du même type. 3.3 Retour sur le contexte de la mission Il s agit, après les définitions et descriptions du processus de recherche fédérée de voir comment il s est intégré dans le contexte de la mission. Ce dernier supposait l utilisation d une part d une application web qui, sur le modèle de l existant, devait permettre la saisie d une requête dans un formulaire ainsi que la sélection des ressources à interroger ; et d autre part une technologie de recherche unique : Solr. 20