CENTRE D ETUDES TECHNIQUES DE L EQUIPEMENT Point national d appui documentaire. Rapport de Stage. Master Informatique du Document.

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

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 3.3 Cette unicité de la technologie de recherche levait un premier niveau d hétérogénéïté propre à la recherche fédérée et liée justement à la diversité des systèmes de recherche interrogés. En effet, toutes les instances de cette technologie - c est-à dire dans notre cas toutes les servlets ou les cores Solr - acceptaient la même syntaxe de requête. Par ailleurs, Solr disposant d un composant de recherche dite distribuée proposait une solution pour diffuser la requête aux instances ou cores Solr, récupérer leurs résultats, les interclasser et finalement retourner les résultats fusionnés au format XML Solr habituel. Toutefois, ce composant ne pouvait pas fonctionner dans cette configuration, c est à dire tant que les champs interrogés au niveau du portail n était pas présents dans tous les index. La solution la plus simple et la plus évidente à mettre en oeuvre a consisté à inclure les champs du portail dans les schémas d indexation Solr au moment de leur production 5. C est à ce moment donc que l on s est déplacé d un contexte de recherche fédérée (hétérogénéïté des sources) à un contexte de recherche distribuée (homogénéïté des sources). Le maintien du contexte de recherche fédérée, en interdisant l utilisation du composant de recherche distribuée aurait nécessité la création de connecteurs pour chaque instances ou core de Solr, ce qui représentait un coût de développement nettement supérieur. 5 le procédé de production est décrit au 4.2.1 21

4 Configurations de Solr et tests Solr et le multi-index Ce qui précède a donc mis en évidence le fait que, n ayant à exploiter que des sources de données homogènes (du point de vue des schémas d indexation auxquelles elles répondent), l objectif de la mission n était donc pas celui de la mis en en oeuvre d une recherche fédérée mais distribuée ; toutefois, cette distinction ne levait pas l exigence d interroger, au moyen d une unique interface, plusieurs ressources c est-à dire, dans le cas de Solr, plusieurs index. Il m a donc fallut réunir autant d informations que possible concernant ce sujet ; les sources de renseignements à propos de Solr étant constituées essentiellement de la mailing list 1 et du wiki 2, c est donc vers elles que je me suis tourné. L examen de ces sources m a apporté deux types de renseignements : structurels : ils concernent les possibilités de faire cohabiter plusieurs index au sein du même serveur d application. une première solution consiste à utiliser plusieurs webapps Solr ( multiinstances ) : la gestion de ces dernières dépend alors du serveur d application utilisé (4.2.1.2). une autre solution tient cette fois non plus au conteneur de servlets mais à Solr lui-même : ce dernier présente en effet une fonctionnalité appellé Multicore qui permet, au sein d une unique webapp Solr, de gérer plusieurs index par le truchement de sous instances nommées Cores. fonctionnels : ils portent sur les moyens d interroger simultanément plusieurs index. la possibilité la plus évidente est d utiliser le composant de recherche distribuée proposé par Solr ; celui-ci est en effet destiné à cette tâche de transmettre une requête à de multiples instances (ou cores) de Solr et d en fusionner les résultats. toutefois, les commiteurs Solr (interrogés sur la recherche distribuée) soulignent fréquemment le fait que le composant de recherche distribuée ne doit en théorie répondre qu à des problématiques de taille d index ; et insistent sur la pleine validité de la pratique qui vise à ne manipuler qu un seul index. On utilise alors un paramètre de tri dans la requête pour circonscrire les différentes catégories de documents. Ces éléments seront décrits plus complètement dans la partie qui suit (4.1) ; en effet, c est en les combinant que j ai élaboré des configurations d installation de 1 SOLR USER (2008) 2 SOLRWIKI (2008e) 22

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.1 l outil de recherche qui devaient être à même de permettre l interrogation multibases : c est donc dans le cadre de ces configurations que l on explicitera le plus clairement l organisation et le rôle des dits éléments. Bien sûr, une fois ces configurations modélisées, la question s est posée du choix de l une d entre elles ; ce dernier pouvait s effectuer en fonction de diverses de leurs dimensions (complexité d installation, coût en développement ultérieur,...). Après consultation de mon responsable professionnel est clairement apparu que la dimension la plus immédiatement et aisément mesurable était celle des performances ; des test devaient être effectués, ce dont rend compte la section qui suit la présentation des configurations (4.2). À partir des descriptions des configurations et des données collectées lors des tests, j effectuerai enfin une synthèse présentant les avantages et inconvénients de chacune d entre elles. 4.1 Configurations Les configurations présentées ici correspondent aux différentes possibilités d installation de Solr dans l optique d une interrogation multi-bases. Elles ne concernent donc pas (pour l instant) l application web de consultation (même si celleci figure sur les schémas qui suivent). 23

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.1 4.1.1 Mono-index 4.1.1.1 Schéma 4.1.1.2 Description Cette configuration entérine le contournement le plus radical des difficultés posées par la problématique initiale de recherche fédérée. En effet, il s agit ici non seulement de se ramener à des sources de données homogènes (mais celà, on l a dit, est conséquent au contexte de la mission (cf.3.3)), mais de concentrer la multiplicité des sources en une. Celà suppose l élaboration d un schéma d indexation suffisamment peu contraignant (sur le graphique on parle d indexation lâche ) pour pouvoir constituer un index monolithique comprenant les données de toutes les bases à gérer. Pour ce qui est des requêtes, l accès aux données d une base se fait au moyen d un paramètre de requête qui pointe un champ de l index identifiant la base à laquelle est associée un document. (ex : NOM BASE sur le graphique) 24

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.1 4.1.2 Multi-index multi-instances 4.1.2.1 Schéma 4.1.2.2 Description Cette configuration est rendue possible par l utilisation du composante de recherche distribuée fourni par Solr. Il s agit ici d installer au sein du serveur d application plusieurs instances (webapps sur le graphique) de Solr, chacune gérant un index correspondant à une base. Celà suppose l élaboration d un schéma d indexation par instance de Solr. Ces schémas n ayant plus à être aussi générique que l index monolithique de la configuration monoindex, les seuls champs nécessaires au portail seront commmuns aux différents index. L accès aux données des bases se fait à nouveau par un paramètre de requête, mais ce dernier ne vise plus d informations contenues dans l index, mais active un composant logiciel responsable de la transmission de la requête aux différentes instances de Solr et de l interclassement des résultats produits par chacune d entre elles. 25

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 4.1.3 Multi-index multi-cores 4.1.3.1 Schéma 4.1.3.2 Description À nouveau cette configuration s appuie sur la mobilisation du composant de recherche distribuée ; toutefois on utilise plus ici qu une seule instance de Solr et autant de cores (cf. 2.2.2.1) que de bases. Il n y a pas de changements concernants les schémas d indexation par rapport à la configuration multi-instances. De même la gestion des requêtes et réponses des cores fonctionne de la même façon qu en multi-instances. 4.2 Tests Une fois les différents configurations modélisées, il convenait de les tester afin de les départager voire d en isoler une, la plus perfomante, et de n alors conserver 26

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 qu elle comme base des développements ultérieurs. Mais si j ai choisi de ne me consacrer qu à la dimension des performances lors des tests, cette dernière recouvre elle même divers aspects : de fait, on peut identifier au moins trois grandes catégories de tests de performances 3 : les tests de performances généraux : (performances testing). Ce type de tests détermine les caractérisitiques de vitesse, échelle et stabilité d un système ou d une application. La performance se traduit en niveaux de temps de réponse, de débit et d utilisation de ressources systèmes, lesquels atteignent ou non des objectifs de performance propres au projet ou produit testé. 4 les test de montée en charge : (load testing) Cette sous catégorie des tests de performance s attache à déterminer les caractérisitiques de performances (précitées) d un système ou d une application soumises à des charges (volumes de requêtes, de données...) mesurées en phases de production. 5 les test de scénarios extrêmes : (stress testing) Cette sous catégorie des tests de performance s attache à déterminer les caractérisitiques de performances (précitées) d un système ou d une application soumises à des charges (volumes de requêtes, de données...) supérieures à celles anticipées en phase de production. 6 J ai écarté les deux derniers types de tests cités puisqu il ne s agissait pas pour moi d évaluer finement les performances des différentes configuration de Solr dans un contexte réaliste de production à des fins d optimisation, mais, dans un environnement stable (c est-à dire le même pour chaque configuration), de comparer lesdites performances. Des test de performances généraux semblaient donc suffisant ; toutefois, ceuxci pouvaient être mobilisés selon divers processus, dont l un convenait particulièrement à mon cas : le test de référence ou banc d essai (benchmarking) qui peut être présenté ainsi : processus de comparaison d un système à l aune d un niveau de référence établi en interne ou d un standart industriel émis par d autres organisations. 7 Ainsi, selon ce processus, je pouvais considérer les mesures résultant des tests d une des configurations comme l étalon auquel comparer les autres. Restait alors à déterminer, parmi les multiples dimensions mesurables au cours de tests de performances généraux, lesquelles seraient les plus pertinentes. Celles-ci se déduisent des services qu est censée rendre l application : dans le cas de Solr, 3 MEIER et al. (2007) 4 ibid. 5 ibid. 6 ibid. 7 ibid. 27

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 indexer des données et interroger cet index au moyen d un web service. Par conséquent, j ai choisi de considérer les indicateurs suivants : phase d indexation : le temps d indexation (temps humain, celui qu on lit à l horloge) le pourcentage de temps CPU utilisé (indicateur de consommation de ressources systèmes) phase de requêtes : le temps de réponse moyen par groupes de requêtes (on explicite ciaprès quels sont ces groupes) La description de Solr présente au 2.2.2.1 ainsi que les sources sur lesquelles elle s appuie (SOLRWIKI (2008b), SOLRWIKI (2008d) et SOLRWIKI (2008f) ) révèle le grand nombre de paramètres de requêtes dont Solr autorise l emploie. On les a donc regroupés en catégories ; mais ces catégories elles-mêmes ne contiennent pas tous les paramètres qu elles pourraient théoriquement comprendre : j ai en effet sélectionné ceux dont la recension des fonctionnalités du portail existant désignait comme nécessaires (dans la partie qui suit consacrée à la description des données de tests (4.2.1.1) sont indiquées les fonctionnalités associée à chaque groupe de requêtes). 4.2.1 Environnement Sont décrits ici trois aspects majeurs de l environnement dans lequel furent effectués les tests : les données, le matériel et les logiciels disponibles. 4.2.1.1 Données Notices J ai pu disposer pour les test d un corpus de 318714 notices issues de quatre 8 bases différentes gérées par le Pandoc : les bases Urbamet, Temis, Archires et Ceddre. Deux dimensions sont ici importantes : le nombre de notices : il influe directement sur la taille des index. Or, pour que les différences éventuelles de performance entre les configurations puissent s exprimer de manière significative relativement au contexte du Pandoc, il fallait constituer des index de taille réaliste, sachant que les volumes qui y sont manipulés se mesurent en centaines de milliers de notices. la variété des notices : en configuration mono-index, elle conditionne le nombre de champs de l index et la variété des types de données qui y sont représentés, éléments qui eux aussi contribuent au réalisme de l environnement de test. Les notices qui me furent fournies n étant pas au format d import de Solr, il m a fallut les transformer ; j ai donc écrit une feuille XSL à cet effet, qui est présenté en annexe B.1. 8 Trois en réalité, la base Ceddre ne constituant qu une simple réplication de la base Urbamet à des fins de volume de données 28

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 La répartition du nombre de notices par bases est la suivante : Urbamet Temis Archires Ceddre Nbre de notices 90906 57694 79208 90906 TAB. 4.1 Nombre de notices par bases Schémas d indexations Là encore une feuille de transformation XSL (B.2) a permis le passage du format de description Notix des bases de notices (annexe A.1) au format de schéma d indexation Solr (annexe A.2). Cette feuille produit des schémas d indexation différentes suivant les configurations. Ainsi : en mono-index : le schéma Solr est produit à partir de plusieurs schémas rdfs, tous les champs du schéma Solr portent l attribut required à la valeur false, ce qui est logique puisque des notices répondant à des schémas originellement différents devront être indexées à partir d un unique schéma Solr, en mutli-index (multi-cores ou multi-instances) : chaque schéma Solr est produit à partir du rdfs correspondant (un par base donc), le caractère optionnel ou nom d un champ donné est repris tel que décrit dans le schéma rdfs d origine. Concernant les autres informations nécessaires à la déclaration d un champ dans les schémas Solr : le type de données et le caractère multivalué d un champ donné ont été récupérées dans le rdfs quand ils y figuraient ; sinon ils ont été positionnés à des valeurs arbitraires non susceptibles de provoquer des erreurs d indexation (c est-à dire indexés en chaine de caractère multivaluée) les attributs indexed et stored - qui spécifient si une recherche peut s effectuer sur le champ en question pour le premier et si la valeur dudit champ peut être récupérée pour le second - ont été systématiquement positionnés à la valeur true, dans l optique de permettre une interogation des index par des applications autres que le portail. Requêtes Comme je l ai dit plus haut, les paramètres de requêtes ont été regroupés en catégories ; pour constituer les requêtes, ces catégories n ont pas été croisées entre elles, mais seulement les paramètres qu elles comprenaient : en effet, construire et soumettre à Solr toutes les requêtes possibles, même en se limitant au choix de certains paramètres, n eût abouti qu au receuil d un flot de données unitaires peu exploitables ni significatives relativement à la configuration d index testée. 29

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 Il m est donc apparu plus pertinent de mesurer un temps de réponse moyen pour chaque groupe de requête 9, lesquels sont décrits ci-dessous dans la forme suivante : 1. présentation du croisement des paramètres 2. fonctionnalité du portail associée au groupe 3. exemples de requêtes Enfin, toutes les requêtes ont été construites sur une base commune : celle-ci comprenait le protocole (http), l adresse IP et le port d écoute du serveur d application, le nom de l instance de Solr et l URI d interrogation ( /Solr/select ) et enfin une requête immuable sur un champ d index (on rappelle que celà s effectue au moyen du paramètre q ), ce qui donne : http ://127.0.0.1 :8080/solr/select?q=SUJET :urbain Groupe des bases 1. on disposait de quatre bases de notices ; ainsi, on a pu former 15 requêtes résultant des combinaisons possibles des quatres noms 2. toutes les requêtes formulées par l utilisateur du portail sont soumises à des bases qu il a choisi préalablement 3. exemples : http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND NOM BASE :Urbamet), http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND (NOM BASE :Urbamet OR NOM BASE :Temis)), etc... jusqu à http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND (NOM BASE :Urbamet OR NOM BASE :Temis OR NOM BASE :Ceddre OR NOM BASE :Archires)) Groupe de pagination 1. tableau des valeurs rows (nbr résultats par page) start (numéro de page) 1 5 10 15 15 15 25 25 25 50 50 50 2. Choix de la page affichée et du nombre de résultats par page 9 Pour que ces moyennes soient expressives, j ai soumis chacun des groupes de requêtes 50 fois à Solr 30

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 3. exemples : http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND NOM BASE :Urbamet)&start=1&rows=25 http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND NOM BASE :Urbamet)&start=10&rows=15 Groupe de classement 1. tableau des valeurs sort Champ de tri TITRE NOM BASE DATE PUBLI COTE Sens de tri asc asc asc asc desc desc desc desc 2. tri des résultats selon le titre des colonnes de la page de résultats 3. exemples : http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND NOM BASE :Urbamet)&sort=TITRE,asc http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND NOM BASE :Urbamet)&sort=DATE PUBLI,desc Groupe des facettes 1. une seule valeur a été utilisée : le champs FACETS THEME (copie des descripteurs de thèmes référencée dans des champs de noms divers selon les bases (cf. annexe A.2)) 2. liste, sur la page de résultats, de catégories de documents (répondant à la requête principale) accompagnées du nombre de documents qu elles comportent 3. http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND NOM BASE :Urbamet)&facet=true&facet.field=FACETS THEME Groupe de highlighting 1. une seule valeur a été utilisée : le champs TITRE 2. mise en valeur des termes de la requête dans les titre des résultats 3. http ://127.0.0.1 :8080/solr/select?q=(SUJET :urbain AND NOM BASE :Urbamet)&hl=true&hl.fl=TITRE 31

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 4.2.1.2 Logiciel Les test ont été effectués à l aide des logiciels suivants : le serveur d application Apache Tomcat : il s agit d un conteneur de servlets (c est-à dire d applications écrites en java et dont la fonction fondamentale est de traiter des requêtes http et d y répondre), sous licence libre (licence Apache 2.0). Il était responsable pendant les test de la propulsion de Solr La version utilisée était Tomcat 6.0.16. JMeter : il s agit d un projet de la fondation Apache permettant de réaliser des tests de performances d applications et de serveurs selon différents protocoles (WIKIPÉDIA (2008)). Il était chargé de soumettre les requêtes présentées plus haut à Solr, de mesurer les temps de réponses pour chacune et d établir un certain nombre de statistiques sur ces réponses (cellesci sont présentées dans la section à suivre : cf. 4.2.2. Tomcat comme Solr sont deux application java ; par conséquent elles ne peuvent fonctionner que si une machine virtuelle java est installée sur le système. J ai utilisé sur le serveur de développement dont je disposais une JVM (Java Virtual Machine) en version 1.5, à laquelle je passais les paramètres suivants : -Xms256m (quantité de RAM disponible à minima) -Xmx512m (quantité de RAM diponible maximale) Précisons enfin que les différents caches de Solr ont été désactivé pour les tests ; en effet, chaque groupe de requêtes ayant été envoyé 50 fois, si les caches avaient été activés, seules les premières soumission des différentes requêtes auraient correspondu à des recherches réelles sur les index et nous aurions au final mélé des mesures de deux facteurs différents : l efficacité de la recherche sur l index d une part, l efficacité du système de cache d autre part. 4.2.1.3 Matériel Le serveur d application Tomcat, les différentes instances de Solr et leurs index étaient localisés sur une machine dont sont présentés ci-après les principaux composants matériels. processeur : Intel(R) Pentium(R) 4 CPU 2.80GHz mémoire vive : 4 barettes DIMM SDRAM Synchronous 400 MHz 128MB carte réseau : 82540EM Gigabit Ethernet Controller 100MB/s disque dur : ST340014A ATA Disk 37GB 4.2.2 Résultats On trouvera ci-après les résultats des test d indexation d abord, puis ceux des tests de requêtes, chaque fois répartis selon les configurations testées. Ces résultats sont présentés de manière brute, sans commentaires : en effet, ils n ont pas de sens considérés isolément (par configuration) mais comparativement les uns aux autres. Par conséquent, leur analyse sera menée dans la section suivante (cf. 4.3) où il seront synthétisés. 32

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 4.2.2.1 Tests d Indexation Monoindex texte invisible pour placer le tableau Temps d indexation Consommation moyenne CPU Taille de l index généré 01h11min41sec 40% 1,2Go TAB. 4.2 Perfomances d indexation en configuration Monoindex Multi-index multi-instances Indexations simultanées texte invisible pour placer le tableau Instance de Solr Temps d indexation Consommation moyenne CPU Taille de l index généré Urbamet 01h12min10sec 15% 211Mo Temis 00h48min44sec 14% 50Mo Archires 01h04min17sec 15% 115Mo Ceddre 01h12min08sec 15% 211Mo TAB. 4.3 Perfomances d indexation en configuration Multi-index multi-instances Multi-index multi-cores Indexations simultanées texte invisible pour placer le tableau Instance de Solr Temps d indexation Consommation moyenne CPU Taille de l index généré Urbamet 01h00min30sec 14% 210Mo Temis 00h40min15sec 14% 51Mo Archires 00h52min36sec 14% 115Mo Ceddre 01h00min34sec 14% 211Mo TAB. 4.4 Perfomances d indexations simultanées en configuration Multi-index multi-cores texte invisible pour placer le tableau Indexations séquentielles texte invisible pour placer le tableau Instance de Solr Temps d indexation Consommation moyenne CPU Taille de l index généré Urbamet 00h19min26sec 45% 210Mo Temis 00h08min56sec 61% 51Mo Archires 00h13min26sec 57% 115Mo Ceddre 00h21min17sec 43% 211Mo TAB. 4.5 Perfomances d indexations séquentielles en configuration Multi-index multi-cores 33

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 4.2.2.2 Tests de Requêtes Monoindex Données Diagramme 34

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.2 Multi-index multi-instances Données Diagramme 35

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.3 Multi-index multi-cores Données Diagramme 36

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.3 4.3 Synthèse 4.3.1 Tests d indexation Taille des index Une première information apparait à l examen des tests d indexation : la configuration monoindex aboutit à une occupation d espace-disque double par rapport aux configurations multi-index (1,2Go contre 587Mo). Temps d indexation Deux ensignements peuvent-être tirés des résultats selon que l on compare la configuration monoindex aux configurations multi-index : en indexations simultanées 10 : on obtient dans ce cas des temps d indexation tous situés dans un ordre de grandeur unique (une heure, la configuration multi-cores n obtenant le meilleur score qu à une dizaine de minutes près) en indexations séquentielles 11 : comme on pouvait s y attendre, les temps d indexation de chaque core pris individuellement se révèlent largement inférieur à celui de la configuration monoindex (huit minutes pour la base Temis, vingt pour les bases Urbamet et Ceddre). Cependant, si l on cumule ces temps individuels, on retrouve l ordre de grandeur précité d une heure environ. 4.3.2 Tests de requêtes De l examen des tests de requêtes on peut dégager les observations suivantes : les performances réalisées par les deux configurations multi-index se situent dans le même ordre de grandeur relativement à celles réalisées par la configuration monoindex. (l écart moyen entre deux groupes de paramètres des configurations multi-index est de 4,8 millisecondes ; le même écart pour les configurations multi-instances et mononindex est de 19,8ms et les configurations multi-cores et monoindex de 15ms). si la configuration monoindex se montre légèrement plus lente pour le groupe de paramètres relatif au choix des bases à interroger (d un facteur d environ 1,2 par rapport au multi-instances et 1,3 par rapport au multi-cores), les configurations multi-index se révèlent quant à elles nettement moins performantes concernant les autres groupes de paramètres (elles sont environ 3 fois plus lente pour les groupes de pagination et facettes et 2 fois plus lente pour les groupes de classement et highlighting). 10 les processus d indexation ont alors été lançés en même temps ; le temps d indexation global correspondant à celuidu core ou de l instance responsable du temps le plus long 11 chaque processus d indexation a alors été lançé après que le précédent se soit terminé. Je n ai pas eu le temps d effectuer ce test pour la configuration multi-instances ; il semble toutefois raisonnable de penser que les résultats se seraient situés dans un ordre de grandeur proche de celui de la configuration multi-cores 37

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.3 4.3.3 Conclusions Des observations qui viennent d être rapportées, j ai pu tirer les concusions suivantes : les performances d indexation ne constituent pas un critère pertinent pour choisir une configuration parmi les trois testées : en effet, aucune d entre elles ne s illustre par des temps d indexation significativement plus court que les autres ; de plus, les différences observées au niveau des tailles d index doivent être rapportées aux performances actuelles atteintes par les disquesdurs : ainsi, à l échelle de centaines de milliers de notices (qui est celle du Pandoc), la configuration la moins économe en espace-disque (monoindex) n aboutirait qu à la constitution d un index de taille vraisemblablement inférieure à 10Go 12, ce qui reste bien en deçà des capacités des matériels de stockage utilisés aujourd hui. des tests de requêtes, une information importante peut-être dégagée : l utilisation du composant de recherche distribuée a un coût certain dès lors qu on utilise des paramètres induisant des manipulations sur l ensemble des résultats. Cependant, il me semble à nouveau devoir relativiser le poid de cette information au regard de deux facteurs : de semblables tests effectués en activant les caches de solr dans les différentes configurations pourraient révéler des écarts de performances moindres (en multi-index, le travail de distribution des requêtes et d interclassement des résultats s effectuerait toujours certes, mais le parcours des multiples index serait moins fréquent : le poid du composant de recherche distribuée serait alors plus précisément mesuré) ; En fait, les contre-performances manifestées par les configurations multiindex s expliquent par la faiblesse du volume de données manipulées lors des tests (en comparaison des témoignages rapportés sur la liste solr-user) : en effet, le wiki Solr (SOLRWIKI (2008c)) précise que la motivation principale pour utiliser le composant de recherche distribué est la surdimension d un index se traduisant par une dégradation des performances de requête. Ce que montre finalement les résultats des tests, c est que ce seuil au delà duquel les performances de Solr s infléchissent (en configuration monoindex) n est pas susceptible d être franchi dans le 12 Les retours d expériences et analyses présents sur la liste solr-user (SOLR USER (2008)) indiquent que c est davantage le nombre de termes uniques dans les documents indexés que le nombre de ces documents eux-mêmes qui influe sur la taillle des index : même si je n ai pas effectué cette mesure, l échantillon de notices que j ai utilisé donne une représentation suffisamment fidèle de l environnement documentaire du Pandoc (en termes de variété des informations) pour appuyer cette hypothèse ; laquelles se retrouve renforcée par ces mêmes témoignages quand ils font états d index de plusieurs dizaines voire centaines de Go certes, mais pour des documents de taille importante (des livres ou des sites web entiers) et nombreux par dizaines ou centaines de millions 38

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.3 contexte documentaire du Pandoc. Enfin, il est nécessaire de rappeler que Solr doit au final, dans le cadre du projet de portail, être interrogé via une application web. Or, le temps de réponse limite généralement reconnu comme celui au delà duquel un utilisateur humain perd la sensation d une réaction instantanée de l application est de 100 millisecondes ; celui au delà duquel l utilisateur voit son flux de pensées ( flow of thoughts ) interrompu de 1 seconde ; enfin celui au delà duquel l utilisateur décidera d entamer une nouvelle tâche en attendant que la réponse lui soit fourni de 10 secondes (NIELSEN (1993)). Ainsi, les écarts observés pendant les tests (l écart temporel maximal enregistré (groupe de pagination, écart entre les configurations multi-instances et mononindex) est de 40ms) ne semblent susceptibles que, additionnés aux facteurs temporels liés à l application web de consultation elle-même, de favoriser le franchissement du premier seuil. Autrement dit, en considérant le nombre et la complexité des traitements à effectuer sur la réponse brute de Solr par l application de consultation (ce dont l examen du portail existant donne une idée), le choix d une configuration apparaît comme un facteur secondaire dans la détermination de l expérience d utilisation de l application. Finalement, il me semble que choix d une configuration devra probablement se faire sur des critères additionnels à ceux des performances. On pourra ainsi considérer : le handicap fondamental de la configuration monoindex : elle centralise les données de toutes les bases. Ceci présente les inconvénients suivants : tout le traffic réseau est dirigé vers le serveur hébergeant l index unique ce qui pourrait mettre à mal les capacités de ce dernier et/ou induire des surconsommations de bande passante en cas de corruption d index ou de panne du serveur hébergeant ce dernier, toutes les bases sont rendues inaccessibles la réponse à ces problèmes que constitue l utilisation du composant de recherche distribuée, le choix devant alors se faire entre multi-cores et multiinstances. Un point de vue organisationnel pourra alors être adopté : le multi-instances induirait une répartition maximale (une base par machine), ce qui simplifierait la gestion individuelle des bases mais pourrait par trop complexifier l infrastructure du réseau ; le multi-core autoriserait alors le regroupement de certaines bases et la diminution cet éclatement. une autre réponse possible qu est la réplication d index (SOLRWIKI (2008a)) : dans cette configuration, une instance maîtresse de Solr héberge une version de l index monolithique qu elle met à jour, mais elle ne répond à aucune requêtes ; plusieurs instances esclaves de Solr hébergent une version du même index, répondent aux requêtes et interrogent périodiquement l instance maîtresse pour mettre à jour leur index. Les travaux d indexation 39

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 4.3 seraient alors simplifiés (comme en configuration monoindex, un seul index est à alimenter) mais la complexité se déplacerait vers le maintien à jour des index esclaves (notamment au niveau de la planification et des fréquences de mises à jour). Je précise qu il ne s agit d une nouvelle configuration mais de l extension de la configuration monoindex qui semble pouvoir permettre la conjugaison des performances propres au monoindex avec la robustesse des configurations multi-index. 40

5 Conclusion Pour rendre compte de mon stage au CETE /Pandoc, ce rapport a procédé comme suit : j ai d abord présenté le contexte que représentait le Pandoc, mais également l envirnnement théorique et technique qu impliquait l objectif de la mission Puis, j ai défini théoriquement, puis techniquement, le concept qui constituait la problématique principale du stage ; je le replaçai ensuite dans le contexte de stage pour voir en quoi ce dernier l affectait Enfin, j ai exposé les modèles de configuration de Solr que j ai pu éléborer pour répondre à la problématique initiale, puis les test menés pour motiver un choix éventuel d une de ces configurations En fait, dans cette dernière partie, j ai présenté les éléments qui sont susceptibles d orienter un choix donc, mais sans émettre moi-même de préconisations. En effet, la suite du stage consistait à développer l application web de consultation des bases de notices (le portail) et il est apparu que rendre cette dernière compatible avec les trois configurations de Solr évoquées ne constituait pas un surcoût de développement significatif. C est donc ce que j ai prioritairement réalisé au niveau du développemt du portail afin de permettre au Pandoc d effectuer un choix ultérieurement, en menant sans doute des test supplémentaires qui devront mobiliser des moyens logistiques et des volumes de donnés supérieurs à ceux dont j ai pu bénéficier de ne pas bloquer mon travail de développement et de rendre l application web suffisamment robuste et addaptative pour rester opérationnelle après un changement de configuration de Solr. 41

Bibliographie B Catherine BETTOCHI. Système d information documentaire du medad. Lille, 2008. CETE - Nord Picardie / Pandoc. BIBLIOPEDIA. Recherche fédérée - bibliopedia. http ://www.bibliopedia.fr/index.php/recherche f%c3%a9d%c3%a9r%c3%a9e, 2008. C Sergey CHERNOV, Bernd FEHLING, Christian KOHLSCHÜTTER, Wolfgang NEJDL, Dirk PIEPER Friedrich SUMMANN. Enabling federated search with heterogeneous search engines. 2006. Walt CRAWFORD. Meta, federated, distributed : Search solutions. http ://www.ala.org/ala/alonline/thecrawfordfiles/crawford2004/crawfordaug04.cfm, 2004. J Peter JACSO. Peter jacso : Thoughts about federated searching. http ://www2.hawaii.edu/ jacso/extra/federated/federated.htm, 2004. L Sol LEDERMAN. Googling for federated search - federated search blog. http ://federatedsearchblog.com/2008/08/18/googling-for-federatedsearch/#more-149, 2008a. Sol LEDERMAN. What is a connector? - federated search blog. http ://federatedsearchblog.com/2007/12/13/what-is-a-connector/, 2008b. Yiyao LU, Weiyi MENG, Liangcai SHU, Clement YU King LUP LIU. Evaluation of result merging strategies for metasearch engines. 13, 53 66, 2005. 42

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - 5.0 M Peg MARSHALL, Shawn HERMAN Sri RAJAN. In search of more meaningful search. Serials Review, 32(3):172 180, 2006. Peter MATTSSON. Federated search searching information across the astrazeneca organisation. http ://www.handels.gu.se/epc/archive/00003948/, 2004. J.D MEIER, Carlos FARRE, Carlos BANSODE, Scott BARBER Dennis REA. patterns & practices : Performance Testing Guidance for Web Applications. 2007. N Jakob NIELSEN. Usability Engineering. AP Professional, 1993. ISBN 0-12- 518406-9. S SOLR USER. org.apache.lucene.solr-user - markmail. http ://markmail.org/browse/org.apache.lucene.solr-user, 2008. SOLRWIKI. Federatedsearch - solr wiki. http ://wiki.apache.org/solr/federatedsearch, 2007. SOLRWIKI. Collectiondistribution - solr wiki. http ://wiki.apache.org/solr/collectiondistribution, 2008a. SOLRWIKI. Commonqueryparameters - solr wiki. http ://wiki.apache.org/solr/commonqueryparameters, 2008b. SOLRWIKI. Distributedsearch - solr wiki. http ://wiki.apache.org/solr/distributedsearch, 2008c. SOLRWIKI. Highlightingparameters - solr wiki. http ://wiki.apache.org/solr/highlightingparameters, 2008d. SOLRWIKI. Multipleindexes - solr wiki. http ://wiki.apache.org/solr/multipleindexes, 2008e. SOLRWIKI. Simplefacetparameters - solr wiki. http ://wiki.apache.org/solr/simplefacetparameters, 2008f. W WIKIPÉDIA. Jmeter - wikipédia. http ://fr.wikipedia.org/wiki/jmeter, 2008. 43

Annexes 44

A Schémas d indexation A.1 Schéma RDFS de la base Urbamet <! Notix, schema de l a base b i b l i o g r a p h i q u e Urbamet T i t r e : Notix, schema de l a base b i b l i o g r a p h i q u e Urbamet copie a p a r t i r du modele de Ceddre Copyright : 2005 "Ministere de l Equipement", "AJLSM" <h t t p : / / ajlsm. com>. Creation : 2005 10 11 Licence : "GPL" <h t t p : / /www. gnu. org / c o p y l e f t / gpl. html> Createur : [FG] F r e d e r i c Glorieux <f r e d e r i c. glorieux@ajlsm. com> CVS : $ I d : \ Ceddre. rdfs, v 1.33 2006/06/22 19 :11:36 f g l o r i e u x Exp $ D e s c r i p t i o n : Ce f i c h i e r permet de d e c r i r e l a s t r u c t u r e d une base bibliographique. Il est destine a etre generable par un formulaire. <license > Notix : notices bibliographiques et d a u t o r i t e s, dans une base XML. Copyright (C) 2005 M i n i s t e r e de l Equipement, AJLSM. Ministere de l Equipement, des Transports, de l Amenagement du Territoire, du Tourisme et de la Mer (FRANCE), Centre d Etudes Technique de l Equipement Nord - Picardie (CETE Nord - Picardie), Point d appui n a t i o n a l documentaire ( Pandoc ), 2 rue de B r u x e l l e s BP 275, 59019 LILLE Cedex, France. AJLSM, 17 rue V i t a l Carles, 33000 Bordeaux, France This program i s f r e e software ; you can r e d i s t r i b u t e i t and / or modify i t under the terms of the GNU General P ubli c License as published by the Free Software Foundation ; e i t h e r version 2 of the License, or ( at your option ) any l a t e r version. This program i s d i s t r i b u t e d i n the hope t h a t i t w i l l be useful, but WITHOUT ANY WARRANTY; w i t h o u t even the i m p l i e d warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General P u b l i c License f o r more d e t a i l s. You should have received a copy of the GNU General Pub lic License along w ith t h i s program ; i f not, w r i t e to the Free Software Foundation, Inc. 59 Temple Place Suite 330, Boston, MA 02111 1307, USA or connect t o : h t t p : / /www. f s f. org / c o p y l e f t / gpl. html </ l i c e n s e> XML genere et Relax NG = = = = = = = = = = = A f i n d obtenir le secours d une documentation externe et d une modelisation, Notix utilise la syntaxe Relax -NG afin de specifier * le XML correspondant a une propriete * les contraintes qui lui sont attachees Cependant, il s a g i t d un usage restreint et specialise, avec quelques amenagements pour rendre la syntaxe plus compacte. Pour l i n s t a n t Notix se concentre pour generer et m a i n t e n i r des elements comme ceci ( avec un l i e n o p t i o n n e l vers une autre n o t i c e ) 45

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.1 <Nom de la p r o p r i e t e x l i n k : h r e f ="/collection/notice" >Valeur t e x t e pouvant e t r e c o n t r o l e e</nom de la p r o p r i e t e> ><rdf:rdf x m l n s : r d f ="http://www.w3.org/1999/02/22-rdf-syntax -ns#"><! D e s c r i p t i o n de l a c o l l e c t i o n $C\ CEDDRE screen\ name=base Ceddre ; La c o l l e c t i o n d o i t e t r e i d e n t i f i e par une URI dans r d f : a b o u t Cette URI est resolue r e l a t i v e m e n t a l attribut xml:base en racine de document. Par defaut la base en question est la racine d un serveur Notix. I l f a u t pouvoir i c i d e f i n i r l audience et les droits --><rdf:description rdf:about=" Urbamet/" xml:id=" Urbamet"> <rdfs:label xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">catalogue Urbamet </rdfs:label > <dc:title xmlns:dc="http://purl.org/dc/elements/1.1/" >Urbamet : etudes, recherches et publications sur l urbanisme.</ d c : t i t l e> <dc:language xmlns:dc="http://purl.org/dc/elements/1.1/">f r</ dc:language> <! champ d affichage par defaut --><notix:display xmlns:notix="http:// portail. documentation.equipement.gouv.fr/ns/notix">titre </ notix:display > <!-- Vue breve, liste ordonnee de champs separes de virgules servant a une vue breve --><notix:brief xmlns:notix="http:// portail.documentation.equipement. gouv.fr/ns/notix">titre,auteur,date\_publi </ notix:brief > <!-- Champs constituant une cle de doublon, sera analyse pour supprimer les faux doublons sur la casse --><notix:unicity xmlns:notix="http:// portail. documentation.equipement.gouv.fr/ns/notix">titre,auteur,date\_publi </ notix:unicity > <dc:description xmlns:dc="http://purl.org/dc/elements/1.1/" >Quoi? Elle rassemble plus de 200000 references. Sur intranet et internet </dc:description > <!-- TODO, un moyen d h i s t o r i s e r l e s m o d i f i c a t i o n s au modele? ><dcq:created xmlns:dcq="http://purl.org/dc/terms/" by="">2005 10 01</ dcq: created> <dcq: modified xmlns:dcq="http://purl.org/dc/terms/" by="">2005 11 21</ dcq: modified> <! Pour exetension, nom de l element conteneur des proprietes --><rng:start xmlns:rng="http:// relaxng.org/ns/structure/1.0"> <rng:element name=" record"/> </rng:start > <notix:suggest xmlns:notix="http:// portail.documentation.equipement.gouv.fr/ns/notix">nom\ _BASE </ notix:suggest > </rdf:description > <!-- --><rdf:property xml:id="cle"> <rdfs:label xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">cle </rdfs:label > <rng:element xmlns:rng="http:// relaxng.org/ns/structure/1.0" name="cle"> <rng:data type="name"/> </rng:element > <xf:hint xmlns:xf="http://www.w3.org/2002/ xforms">ancienne cle doris </xf:hint > </rdf:property > <rdf:property xml:id="nom\_base"> <!-- Cet intule court est utilise comme tete de colonne ou etiquette de formulaire --><rdfs:label xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#">base </ rdfs:label > <rdfs:comment xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"> * NOM\_BASE * len\_maxi=50; * screen\_name=nom de la base; * def\_value=ceddre; * oblig; * no\_input; Index : cle </rdfs:comment > 46

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.2 <!-- --><dc:title xmlns:dc="http://purl.org/dc/elements/1.1/" >Nom de la base de cette notice.</dc:title > <xf:hint xmlns:xf="http://www.w3.org/2002/ xforms">urbamet </xf:hint > <xf:help xmlns:xf="http://www.w3.org/2002/ xforms">valeur fixee automatiquement.</xf:help > <rng:element xmlns:rng="http:// relaxng.org/ns/structure/1.0" name="nom\_base"> <rng:value >URBAMET </rng:value > </rng:element > </rdf:property > <!-- champ NUM\_BASE de l o r i g i n a l ><r d f : P r o p e r t y x m l : i d ="NUM\_BASE"> <r d f s : l a b e l x m l n s : r d f s ="http://www.w3.org/2000/01/rdf-schema#">n dans l a base</ r d f s : l a b e l> <rng: element xmlns: rng="http:// relaxng.org/ns/structure/1.0" name="num\_base"> <r n g : data x m l n s : n o t i x ="http://portail.documentation.equipement.gouv.fr/ns/notix" n o t i x : s u g g e s t ="true" /> </ rng: element> </ r d f : P r o p e r t y> <r d f : P r o p e r t y x m l : i d ="UTIL\_CREAT"> <r d f s : l a b e l x m l n s : r d f s ="http://www.w3.org/2000/01/rdf-schema#">s a isie par</ r d f s : l a b e l> <r n g : o p t i o n a l xmlns:rng="http://relaxng.org/ns/structure/1.0"> <rng: element name="util\_creat"> <r n g : d a t a x m l n s : n o t i x ="http://portail.documentation.equipement.gouv.fr/ns/notix" n o t i x : t y p e ="createur" type="name" /> </ rng: element> </ r n g : o p t i o n a l> </ r d f : P r o p e r t y> <! <DATE\ CREAT>1998 01 05</ DATE\ CREAT> ><r d f : P r o p e r t y x m l : i d ="DATE\_CREAT"> <r d f s : l a b e l x m l n s : r d f s ="http://www.w3.org/2000/01/rdf-schema#">date de c r e a t i o n</ r d f s : l a b e l> < d c : t i t l e xmlns:dc="http://purl.org/dc/elements/1.1/">date automatique de c r e a t i o n de c e t t e n o t i c e.</ d c : t i t l e> <r n g : o p t i o n a l xmlns:rng="http://relaxng.org/ns/structure/1.0"> <rng: element name="date\_creat"> <r n g : d a t a x m l n s : n o t i x ="http://portail.documentation.equipement.gouv.fr/ns/notix" n o t i x : t y p e ="creation" type="date" /> </ rng: element> </ r n g : o p t i o n a l> </ r d f : P r o p e r t y> <r d f : P r o p e r t y x m l : i d ="UTIL\_MAJ"> <r d f s : l a b e l x m l n s : r d f s ="http://www.w3.org/2000/01/rdf-schema#">modifiee par</ r d f s : l a b e l> <r n g : o p t i o n a l xmlns:rng="http://relaxng.org/ns/structure/1.0"> <rng: element name="util\_maj"> <r ng:data x m l n s : n o t i x ="http://portail.documentation.equipement.gouv.fr/ns/notix" n o t i x : t y p e ="utilisateur" type="name" /> </ rng: element> </ r n g : o p t i o n a l> </ r d f : P r o p e r t y> <! <DATE\ MAJ>2003 04 14</ DATE\ MAJ> ><r d f : P r o p e r t y x m l : i d ="DATE\_MAJ"> <r d f s : l a b e l x m l n s : r d f s ="http://www.w3.org/2000/01/rdf-schema#">mise a j o u r</ r d f s : l a b e l> < d c : t i t l e xmlns:dc="http://purl.org/dc/elements/1.1/">date automatique de mise a j o u r de c e t t e n o t i c e.</ d c : t i t l e> <r n g : o p t i o n a l xmlns:rng="http://relaxng.org/ns/structure/1.0"> <rng: element name="date\_maj"> <r ng:data x m l n s : n o t i x ="http://portail.documentation.equipement.gouv.fr/ns/notix" n o t i x : t y p e ="modification" type="date" /> </ rng: element> </ r n g : o p t i o n a l> </ r d f : P r o p e r t y> A.2 Schéma d indexation Solr <?xml version="1.0"?> 47

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.2 <schema xmlns="" name="temis -Urbamet -Archires -Ceddre" version="1.3"> <! Section des types > <types> <! Types simples > <f i e l d T y p e name="string" class="solr.strfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="boolean" class="solr.boolfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="int" class ="solr.intfield" omitnorms="true" /> <f i e l d T y p e name="long" class ="solr.longfield" omitnorms="true" /> <f i e l d T y p e name="float" class ="solr.floatfield" omitnorms="true" /> <f i e l d T y p e name="double" class ="solr.doublefield" omitnorms="true" /> <! T r i s > <f i e l d T y p e name="sint" class="solr.sortableintfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="slong" class="solr.sortablelongfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="sfloat" class="solr.sortablefloatfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="sdouble" class="solr.sortabledoublefield" s o r t M i s s i n g L a s t ="true" omitnorms=" true" /> <! Pour i g n o r e r des champs > <f i e l d t y p e name="ignored" stored="false" indexed="false" class ="solr.strfield" /> <! Dates > <f i e l d T y p e name="date" class="solr.datefield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <! Chaine ( pour l e nom de base, l e t i t r e et l auteur) --> <fieldtype name=" chaine" class="solr.textfield" positionincrementgap="100" > <analyzer > <tokenizer class="solr.standardtokenizerfactory"/> <filter class="solr.standardfilterfactory"/> <filter class="solr.lowercasefilterfactory"/> <filter class="solr.trimfilterfactory"/> </analyzer > </fieldtype > <!-- Texte (trouve dans les notices Notix : on en fait un equivalent du type test) --> <fieldtype name="texte" class="solr.textfield" positionincrementgap="100" > <analyzer > <tokenizer class="solr.standardtokenizerfactory"/> <filter class="solr.synonymfilterfactory" synonyms=" synonyms.txt" ignorecase="true" expand=" <filter class="solr.stopfilterfactory" ignorecase="true" words=" stopwords.txt"/> <filter class="solr.lowercasefilterfactory"/> <filter class="solr.patternreplacefilterfactory" pattern="([^a-z])" replacement="" replace=" all"/> </analyzer > </fieldtype > <fieldtype name="text" class="solr.textfield" positionincrementgap="100" > <analyzer > <tokenizer class="solr.standardtokenizerfactory"/> <filter class="solr.synonymfilterfactory" synonyms=" synonyms.txt" ignorecase="true" expand=" <filter class="solr.stopfilterfactory" ignorecase="true" words=" stopwords.txt"/> <filter class="solr.lowercasefilterfactory"/> <filter class="solr.patternreplacefilterfactory" pattern="([^a-z])" replacement="" replace=" all"/> </analyzer > </fieldtype > <fieldtype name="key" class="solr.strfield" sortmissinglast="true" omitnorms="true"/> <fieldtype name=" anyuri" class="solr.strfield" sortmissinglast="true" omitnorms="true"/> <fieldtype name="name" class="solr.strfield" sortmissinglast="true" omitnorms="true"/> </types > <!-- les champs --> 48

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.2 <fields > <field name="cle" type="key" indexed="true" stored="true" required="true" multivalued=" <field name=" NOM_BASE" type=" chaine" indexed="true" stored="true" required="true" multivalued=" <field name=" UTIL_CREAT" type="name" indexed="true" stored="true" required="false" multivalued=" <field name=" DATE_CREAT" type="date" indexed="true" stored="true" required="false" multivalued=" <field name=" UTIL_MAJ" type="name" indexed="true" stored="true" required="false" multivalued=" <field name=" DATE_MAJ" type="date" indexed="true" stored="true" required="false" multivalued=" <field name=" NIV_BIB" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" DIFFUSION" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" TYPE_DOC" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name="cote" type=" string" indexed="true" stored="true" required="false" multivalued="true "/> <field name=" CATALOGUE" type=" string" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" BULLETIN" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" VEDETTE" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" LANGUE" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" AUTEUR_MORAL" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" AUTEUR_PHYSIQUE" type=" chaine" indexed="true" stored="true" required="false" multivalued="true"/> <field name="titre" type=" chaine" indexed="true" stored="true" required="false" multivalued=" <field name=" TITRE_DEPOUILLEMENT" type="text" indexed="true" stored="true" required="false" multivalued=" <field name=" TITRE_PERIODIQUE" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" NO_PERIODIQUE" type=" string" indexed="true" stored="true" required="false" multivalued="true"/> <field name="lieu" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" EDITEUR" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" DATE_PUBLICATION" type="date" indexed="true" stored="true" required="false" multivalued=" <field name=" ANNEE_PUBLICATION" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" NO_EDITION" type=" string" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" PAGINATION" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" ILLUSTRATIONS" type=" string" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" PERIODICITE" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" TITRE_COLLECTION" type=" string" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" NO_COLLECTION" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" RESUME" type="text" indexed="true" stored="true" required="false" multivalued=" <field name="teg" type=" anyuri" indexed="true" stored="false" required="false" multivalued="true "/> <field name="tes" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true "/> <field name=" DESCRIPTEUR" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" MOT_LIBRE" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" ORGANISME" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> 49

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.2 <field name=" ENTREPRISE" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> <field name="geo" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true "/> <field name=" LOCALISATION" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" COMMENTAIRE" type="text" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" EVOLUTION" type=" string" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" EVOLUTIONA" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" PUBLIABLE" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" NUM_BASE" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" COTE_MIC" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" SUPPORT" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name="media" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" BLOC_TITRE" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name="revue" type=" anyuri" indexed="true" stored="true" required="false" multivalued=" <field name=" REVUE_OCC" type=" anyuri" indexed="true" stored="true" required="false" multivalued =" <field name=" TITRE_TRAD" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" BLOC_AUTEURS" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" ORG_AUT" type=" anyuri" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" ORG_FIN" type=" anyuri" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" AUTEUR" type=" chaine" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" AUTEUR_SEC" type=" string" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" BLOC_DESCRIPTION" type="text" indexed="true" stored="true" required="false" multivalued=" <field name="theme" type=" anyuri" indexed="true" stored="false" required="false" multivalued=" true"/> <field name=" DESC_P_URB" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" DESC_P_URB_ENG" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" DESC_P_URB_ESP" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" DESC_S_URB" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" DESC_S_URB_ENG" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" DESC_S_URB_ESP" type=" anyuri" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" MOT_CLE" type="text" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" DESC_GEO" type=" anyuri" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" DESC_GEOS" type="text" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" LOCALIS" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" MOU_ORG" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" MOE_ORG" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" RES_COURT" type="text" indexed="true" stored="true" required="false" multivalued=" <field name=" RES_LONG" type="text" indexed="true" stored="true" required="false" multivalued=" 50

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.2 <field name=" BLOC_SOURCE" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" SOURCE" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" EVOLUTIONE" type=" string" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" DATE_PUBLI" type="date" indexed="true" stored="true" required="false" multivalued=" <field name=" COLLECTION" type=" string" indexed="true" stored="true" required="false" multivalued ="true"/> <field name="notes" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name="issn" type=" string" indexed="true" stored="true" required="false" multivalued="true "/> <field name="isbn" type=" string" indexed="true" stored="true" required="false" multivalued="true "/> <field name=" EVOLUTIONK" type=" string" indexed="true" stored="true" required="false" multivalued ="true"/> <field name="isrn" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" LANG_DOC" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" BLOC_GESTION" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" COPROD" type=" anyuri" indexed="true" stored="true" required="false" multivalued=" <field name=" ALIMENTE" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" DATE_VERST" type="date" indexed="true" stored="true" required="false" multivalued=" <field name=" EVOLUTIONH" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" EVOLUTIONF" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" NUM_INVENT" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" PRIX_EURO" type="int" indexed="true" stored="true" required="false" multivalued=" <field name=" ORG_CHER" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" LIEU_ED" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" PAYS_ED" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" MENTION" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" VOL_FASC" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" NUM_FASC" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name=" NUM_COL" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name="pages" type=" string" indexed="true" stored="true" required="false" multivalued=" <field name="ill" type=" string" indexed="true" stored="true" required="false" multivalued="false "/> <field name=" FORMAT_ED" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" PAYS_RECH" type=" string" indexed="true" stored="true" required="false" multivalued =" <field name=" DESC_COMP" type=" anyuri" indexed="true" stored="true" required="false" multivalued ="true"/> <field name=" REALIS" type=" string" indexed="true" stored="true" required="false" multivalued=" true"/> <field name=" MOD_DIF" type=" string" indexed="true" stored="true" required="false" multivalued=" <!-- champ sujet : permet d i n t e r r o g e r sur p l u s i e u r s champs a l a f o i s : c f copyfields ( on ne l e stocke pas pour l i m i t e r l impact sur la taille de l index ) > <f i e l d name="sujet" type="text" indexed="true" stored ="false" r e qu i r e d ="false" multivalued="true " /> 51

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.2 <! champ t i t r e u n i v a l : copie du t i t r e en chaine de caracteres brute ( non tokenizee ) => permet l e t r i sur l e s t i t r e s > <f i e l d name="titre_unival" type="string" indexed="true" stored ="false" r e qu i r e d ="false" multivalued="false" /> <! champ l i e u g e o : permet d interroger tous les champs geographiques --> <field name=" LIEU_GEO" type="text" indexed="true" stored="false" required="false" multivalued=" true"/> <!-- Prise en compte des champs specifiques au portail THEME PORTAIL et TYPE DOC PORTAIL Champs ajoutes dans les notices mais absents des rdfs!! --> <field name=" THEME_PORTAIL" type=" string" indexed="true" stored="true" required="false" multivalued="true"/> <field name=" TYPE_DOC_PORTAIL" type=" string" indexed="true" stored="true" required="false" multivalued="true"/> <!-- permet des requetes tout:1 pour attraper tout l index > <f i e l d name="tout" type="string" indexed="true" stored ="false" default="1" r e qu i r ed ="true" multivalued="false" /> <! date d indexation --> <field name=" timestamp" type="date" indexed="true" stored="true" default="now" multivalued=" <!--Par defaut, une erreur est lancee lorsqu un champ est propose a l indexation alors qu i l n a pas ete matche dans la liste plus haut. Cet attrape -tout permet de tout indexer, sans reflexion. Le @type=" ignored" permet d i g n o r e r l e s champs non prevus > <dynamicfield name="*" type="ignored" indexed="false" stored ="false" multivalued="true" /> </ f i e l d s> <! Champ a u t i l i s e r comme i d e n t i f i a n t de n o t i c e. > <uniquekey>cle</ uniquekey> <! Champ par defaut pour l a recherche. > <d e f a u l t S e a r c h F i e l d>sujet</ d e f a u l t S e a r c h F i e l d> <! Operateur par defaut du SolrQueryParser : @defaultoperator="and OR" > <solrqueryparser d e f a u l t O p e r a t o r ="OR" /> <! <copyfield> permet de cop ier un champ envoye a l indexation par post dans un champ declare plus haut. C est u t i l e pour assurer p l u s i e u r s analyses d i f f e r e n t e s ( type ) pour une meme i n f o r m a t i o n. > <copyfield source="auteur_physique" dest="auteur" /> <copyfield source="titre" dest="titre_unival" /> <copyfield source="date_publication" dest="date_publi" /> <copyfield source="resume" dest="sujet" /> <copyfield source="descripteur" dest="sujet" /> <copyfield source="mot_libre" dest="sujet" /> <copyfield source="geo" dest="lieu_geo" /> <copyfield source="commentaire" dest="sujet" /> <copyfield source="bloc_description" dest="sujet" /> <copyfield source="desc_p_urb" dest="sujet" /> <copyfield source="desc_p_urb_eng" dest="sujet" /> <copyfield source="desc_p_urb_esp" dest="sujet" /> <copyfield source="desc_s_urb" dest="sujet" /> <copyfield source="desc_s_urb_eng" dest="sujet" /> <copyfield source="desc_s_urb_esp" dest="sujet" /> <copyfield source="mot_cle" dest="sujet" /> <copyfield source="desc_geo" dest="sujet" /> <copyfield source="desc_geo" dest="lieu_geo" /> <copyfield source="desc_geos" dest="sujet" /> <copyfield source="desc_geos" dest="lieu_geo" /> <copyfield source="res_court" dest="sujet" /> <copyfield source="res_long" dest="sujet" /> <copyfield source="desc_comp" dest="sujet" /> 52

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - A.2 </ schema> 53

B Feuilles XSL B.1 Feuille de transformation des notices Notix en notices Solr <?xml version="1.0" encoding="utf -8"?> <x s l : s t y l e s h e e t x m l n s : x s l ="http://www.w3.org/1999/ XSL/Transform" version="1.0" xmlns: set="http://exslt.org/sets" extension element p r e f i x e s ="set"> <x s l : o u t p u t method="xml" encoding="utf -8" indent="yes" /> <xsl: param name="nombase" /> <xsl: param name="basesxml" /> <x s l : v a r i a b l e name="sousthemesbasexml" s e l e c t ="document($basesxml)//base[@nom=$nombase]/ descendant::soustheme" /> <x s l : v a r i a b l e name="soustypesdocbasexml" s e l e c t ="document($basesxml)//base[@nom=$nombase]/ descendant::soustypedoc" /> <! <x s l : v a r i a b l e name="sousthemesnotice" s e l e c t ="(/descendant::theme) (/descendant::teg)" /> <x s l : v a r i a b l e name="soustypesdocnotice" s e l e c t ="(/descendant::type_doc)" /> > <x s l : t e m p l a t e match="record"> <add> <doc> <x s l : v a r i a b l e name="cle" s e l e c t ="@xml:id" /> <f i e l d> <x s l : a t t r i b u t e name="name"> <x s l : t e x t>cle</ x s l : t e x t> </ x s l : a t t r i b u t e> <x s l : v a l u e of s e l e c t ="$cle" /> </ f i e l d> <x s l : a p p l y templates s e l e c t ="*[(name()!= CLE ) and not(starts -with(name(), DATE )) and (name()!= THEME ) and (name()!= TEG ) and (name()!= TYPE_DOC )]" /> <x s l : a p p l y templates s e l e c t ="*[starts -with(name(), DATE )]" mode="date" /> <x s l : a p p l y templates s e l e c t ="//THEME //TEG" mode="soustheme" /> <x s l : a p p l y templates s e l e c t ="//THEME //TEG" mode="theme" /> <x s l : a p p l y templates s e l e c t ="//TYPE_DOC" mode="soustype" /> <x s l : a p p l y templates s e l e c t ="//TYPE_DOC" mode="type" /> </ doc> </ add> </ x s l : t e m p l a t e> <x s l : t e m p l a t e match="*"> <f i e l d> <x s l : a t t r i b u t e name="name"> <x s l : v a l u e of s e l e c t ="name()" /> </ x s l : a t t r i b u t e> <x s l : v a l u e of s e l e c t ="node()" /> </ f i e l d> </ x s l : t e m p l a t e> <x s l : t e m p l a t e match="*" mode="date"> <f i e l d> 54

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.1 <x s l : a t t r i b u t e name="name"> <x s l : v a l u e of s e l e c t ="name()" /> </ x s l : a t t r i b u t e> <xsl: choose> <xsl:when t e s t ="(string -length(.) > 10) and not(contains(., / ))"> <x s l : v a r i a b l e name="date" s e l e c t ="substring(.,1,10)" /> <xsl: choose> <xsl:when t e s t ="contains($date, - )"> <x s l : c a l l template name="traitedateatirets"> <x s l : w i t h param name="sousdate" s e l e c t ="translate($date, I, 1 )" /> </ x s l : c a l l template> </ xsl:when> <x s l : o t h e r w i s e> <x s l : c a l l template name="traitedatesanstirets"> <x s l : w i t h param name="sousdate" s e l e c t ="translate(substring($date,1,8), I, 1 )" /> </ x s l : c a l l template> </ x s l : o t h e r w i s e> </ xsl: choose> </ xsl:when> <xsl:when t e s t ="contains(., / )"> <x s l : v a r i a b l e name="date" s e l e c t ="substring -before(., / )" /> <xsl: choose> <xsl:when t e s t ="contains($date, - )"> <x s l : c a l l template name="traitedateatirets"> <x s l : w i t h param name="sousdate" s e l e c t ="translate($date, I, 1 )" /> </ x s l : c a l l template> </ xsl:when> <x s l : o t h e r w i s e> <x s l : c a l l template name="traitedatesanstirets"> <x s l : w i t h param name="sousdate" s e l e c t ="translate($date, I, 1 )" /> </ x s l : c a l l template> </ x s l : o t h e r w i s e> </ xsl: choose> </ xsl:when> <x s l : o t h e r w i s e> <x s l : v a r i a b l e name="date" s e l e c t ="." /> <xsl: choose> <xsl:when t e s t ="contains($date, - )"> <x s l : c a l l template name="traitedateatirets"> <x s l : w i t h param name="sousdate" s e l e c t ="translate($date, I, 1 )" /> </ x s l : c a l l template> </ xsl:when> <x s l : o t h e r w i s e> <x s l : c a l l template name="traitedatesanstirets"> <x s l : w i t h param name="sousdate" s e l e c t ="translate($date, I, 1 )" /> </ x s l : c a l l template> </ x s l : o t h e r w i s e> </ xsl: choose> </ x s l : o t h e r w i s e> </ xsl: choose> </ f i e l d> </ x s l : t e m p l a t e> <x s l : t e m p l a t e match="theme TEG" mode="soustheme"> <! [ s t a r t s with (name ( ), THEME ) or s t a r t s with (name ( ), TEG ) ] > <f i e l d> <x s l : a t t r i b u t e name="name"> <x s l : v a l u e of s e l e c t ="name()" /> </ x s l : a t t r i b u t e> <x s l : v a l u e of s e l e c t ="node()" /> </ f i e l d> </ x s l : t e m p l a t e> <! Ajout, Ã p a r t i r du f i c h i e r bases.xml de catã c gories de thã mes propres au p o r t a i l En f o n c t i o n des thã mes prã c sents dans l a notice, on y aj oute l e s catã c gories auxquelles ces thã mes appartiennent > 55

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.1 <x s l : t e m p l a t e match="theme TEG" mode="theme"> <x s l : v a r i a b l e name="sousthemesnotice" s e l e c t ="translate(text(), ABCDEFGHIJKLMNOPQRSTUVWXYZ, abcdefghijklmnopqrstuvwxyz )" /> <x s l : f o r each s e l e c t ="$sousthemesbasexml"> <x s l : v a r i a b l e name="theme" s e l e c t ="parent::theme/@nom" /> < x s l : i f t e s t ="$sousthemesnotice = translate(text(), ABCDEFGHIJKLMNOPQRSTUVWXYZ, abcdefghijklmnopqrstuvwxyz )"> <f i e l d name="theme_portail"> <x s l : v a l u e of s e l e c t ="$theme" /> </ f i e l d> </ x s l : i f> </ x s l : f o r each> </ x s l : t e m p l a t e> <x s l : t e m p l a t e name="prodsoustheme"> </ x s l : t e m p l a t e> <x s l : t e m p l a t e match="type_doc" mode="soustype"> <f i e l d> <x s l : a t t r i b u t e name="name"> <x s l : v a l u e of s e l e c t ="name()" /> </ x s l : a t t r i b u t e> <x s l : v a l u e of s e l e c t ="node()" /> </ f i e l d> </ x s l : t e m p l a t e> <! Ajout, à p a r t i r du f i c h i e r bases.xml de catã c gories de types de documents propres au p o r t a i l En f o n c t i o n des types de documents prã c sents dans l a notice, on y aj oute l e s catã c gories auxquelles ces types appartiennent > <x s l : t e m p l a t e match="type_doc" mode="type"> <x s l : v a r i a b l e name="soustypesdocnotice" s e l e c t ="translate(text(), ABCDEFGHIJKLMNOPQRSTUVWXYZ, abcdefghijklmnopqrstuvwxyz )" /> <x s l : f o r each s e l e c t ="$soustypesdocbasexml"> <x s l : v a r i a b l e name="typedoc" s e l e c t ="parent::typedoc/@nom" /> < x s l : i f t e s t ="$soustypesdocnotice = translate(text(), ABCDEFGHIJKLMNOPQRSTUVWXYZ, abcdefghijklmnopqrstuvwxyz )"> <f i e l d name="type_doc_portail"> <x s l : v a l u e of s e l e c t ="$typedoc" /> </ f i e l d> </ x s l : i f> </ x s l : f o r each> </ x s l : t e m p l a t e> <! Rà gles Nommà c es > <! Mise au format XX XX XXTDD:DD:DDZ de dates comportant des - > <x s l : t e m p l a t e name="traitedateatirets"> <xsl: param name="sousdate" /> <x s l : v a l u e of s e l e c t ="substring($sousdate,1,4)" /> <xsl: choose> <xsl:when t e s t ="string -length($sousdate) > 4"> <x s l : v a r i a b l e name="month" > <xsl: choose> <xsl:when t e s t ="string -length($sousdate) = 5"> 56

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.1 <x s l : t e x t> 01 01</ x s l : t e x t> </ xsl:when> <xsl:when t e s t ="(substring($sousdate,6,1)= - )"> <x s l : t e x t> 0</ x s l : t e x t> <x s l : v a l u e of s e l e c t ="substring($sousdate,7,1)" /> </ xsl:when> <x s l : o t h e r w i s e> <x s l : v a l u e of s e l e c t ="substring($sousdate,5,3)" /> </ x s l : o t h e r w i s e> </ xsl: choose> </ x s l : v a r i a b l e> <xsl: choose> <xsl:when t e s t ="$month= -00 "> <x s l : t e x t> 01</ x s l : t e x t> </ xsl:when> <x s l : o t h e r w i s e> <x s l : v a l u e of s e l e c t ="$month" /> </ x s l : o t h e r w i s e> </ xsl: choose> < x s l : i f t e s t ="string -length($sousdate) = 7 or string -length($sousdate) = 8"> <x s l : t e x t> 01</ x s l : t e x t> </ x s l : i f> < x s l : i f t e s t ="string -length($sousdate) > 8"> <x s l : v a r i a b l e name="day"> <xsl: choose> <xsl:when t e s t ="substring($sousdate,9,1)= - "> <xsl: choose> <xsl:when t e s t ="string -length($sousdate) = 9"> <x s l : t e x t> 01</ x s l : t e x t> </ xsl:when> <x s l : o t h e r w i s e> <x s l : t e x t> 0</ x s l : t e x t> <x s l : v a l u e of s e l e c t ="substring($sousdate,10,1)" /> </ x s l : o t h e r w i s e> </ xsl: choose> </ xsl:when> <x s l : o t h e r w i s e> <x s l : v a l u e of s e l e c t ="substring($sousdate,8,3)" /> </ x s l : o t h e r w i s e> </ xsl: choose> </ x s l : v a r i a b l e> <xsl: choose> <xsl:when t e s t ="$day= -00 "> <x s l : t e x t> 01</ x s l : t e x t> </ xsl:when> <x s l : o t h e r w i s e> <x s l : v a l u e of s e l e c t ="$day" /> </ x s l : o t h e r w i s e> </ xsl: choose> </ x s l : i f> </ xsl:when> <x s l : o t h e r w i s e> <x s l : t e x t> 01 01</ x s l : t e x t> </ x s l : o t h e r w i s e> </ xsl: choose> <x s l : t e x t>t</ x s l : t e x t> <x s l : t e x t>23 :59:59Z</ x s l : t e x t> </ x s l : t e m p l a t e> <! Mise au format XX XX XXTDD:DD:DDZ de dates ne comportant pas de - > <x s l : t e m p l a t e name="traitedatesanstirets"> <xsl: param name="sousdate" /> <x s l : v a l u e of s e l e c t ="substring($sousdate,1,4)" /> <xsl: choose> 57

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 <xsl:when t e s t ="string -length($sousdate) > 4"> <x s l : v a r i a b l e name="month" s e l e c t ="substring($sousdate,5,2)" /> <x s l : t e x t> </ x s l : t e x t> <xsl: choose> <xsl:when t e s t ="$month= 00 "> <x s l : t e x t>01</ x s l : t e x t> </ xsl:when> <x s l : o t h e r w i s e> <x s l : v a l u e of s e l e c t ="$month" /> </ x s l : o t h e r w i s e> </ xsl: choose> < x s l : i f t e s t ="string -length($sousdate) = 6"> <x s l : t e x t> 01</ x s l : t e x t> </ x s l : i f> < x s l : i f t e s t ="string -length($sousdate) = 8"> <x s l : v a r i a b l e name="day" s e l e c t ="substring($sousdate,7,2)" /> <x s l : t e x t> </ x s l : t e x t> <xsl: choose> <xsl:when t e s t ="$day= 00 "> <x s l : t e x t>01</ x s l : t e x t> </ xsl:when> <x s l : o t h e r w i s e> <x s l : v a l u e of s e l e c t ="$day" /> </ x s l : o t h e r w i s e> </ xsl: choose> </ x s l : i f> </ xsl:when> <x s l : o t h e r w i s e> <x s l : t e x t> 01 01</ x s l : t e x t> </ x s l : o t h e r w i s e> </ xsl: choose> <x s l : t e x t>t</ x s l : t e x t> <x s l : t e x t>23 :59:59Z</ x s l : t e x t> </ x s l : t e m p l a t e> </ x s l : s t y l e s h e e t> B.2 Feuille de transformation des schémas RDFS Notix en schéma solr <?xml version="1.0" encoding="utf -8"?> <! F e u i l l e de t r a n s f o r m a t i o n produisant un schema d indexation Solr a partir de schemas RDF issus de Notix exemples d u t i l i s a t i o n : m u l t i i n d e x : x s l t p r o c stringparam mode transfo m u l t i stringparam doc1 Temis. r d f s Rdfs2Solr. x s l Temis. r d f s > schema. xml monoindex : x s l t p r o c stringparam mode transfo uni stringparam doc1 Temis. r d f s stringparam doc2 Urbamet. r d f s Rdfs2Solr. x s l Temis. r d f s > schema. xml > <x s l : s t y l e s h e e t version="1.0" x m l n s : x s l ="http://www.w3.org/1999/xsl/transform" x m l n s : r d f ="http://www.w3.org/1999/02/22-rdf-syntax -ns#" xmlns: rng="http:// relaxng.org/ns/structure/1.0" exclude r e s u l t p r e f i x e s ="rdf rng"> <x s l : o u t p u t method="xml" i n d e n t ="yes" version="1.0" /> 58

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 <! l e s docs r d f s a transformer > <xsl: param name="doc1" /> <xsl: param name="doc2" /> <xsl: param name="doc3" /> <xsl: param name="doc4" /> <! Mode de Transformation uni => monoindex ( tous l e s champs sont o p t i o n n e l s ( sauf CLE et NOM BASE) ) multi => m u l t i i n d e x ( l e caractere r equis ou non des champs est l u dans l e f i c h i e r RDFS > <xsl:param name="mode_transfo" s e l e c t =" uni " /> <x s l : t e m p l a t e match="/"> <x s l : v a r i a b l e name="nbauteur" s e l e c t ="count(descendant::*[@xml:id = AUTEUR ])" /> <x s l : v a r i a b l e name="nbdatepubli" s e l e c t ="count(descendant::*[@xml:id = DATE_PUBLI ])" /> <x s l : v a r i a b l e name="propdoc1" s e l e c t ="document($doc1)/descendant::rdf:property" /> <x s l : v a r i a b l e name="propdoc2" s e l e c t ="document($doc2)/descendant::rdf:property" /> <x s l : v a r i a b l e name="propdoc3" s e l e c t ="document($doc3)/descendant::rdf:property" /> <x s l : v a r i a b l e name="propdoc4" s e l e c t ="document($doc4)/descendant::rdf:property" /> <schema xmlns=""> <x s l : a t t r i b u t e name="name"> <x s l : v a l u e of s e l e c t ="substring -before($doc1,. )" /> < x s l : i f t e s t ="$doc2!= "> <x s l : t e x t> </ x s l : t e x t> <x s l : v a l u e of s e l e c t ="substring -before($doc2,. )" /> </ x s l : i f> < x s l : i f t e s t ="$doc3!= "> <x s l : t e x t> </ x s l : t e x t> <x s l : v a l u e of s e l e c t ="substring -before($doc3,. )" /> </ x s l : i f> < x s l : i f t e s t ="$doc4!= "> <x s l : t e x t> </ x s l : t e x t> <x s l : v a l u e of s e l e c t ="substring -before($doc4,. )" /> </ x s l : i f> </ x s l : a t t r i b u t e> <x s l : a t t r i b u t e name="version"> <x s l : t e x t>1.3</ x s l : t e x t> </ x s l : a t t r i b u t e> <! l e s types > <xsl:comment> Section des types </ xsl:comment> <types> <xsl:comment> Types simples </ xsl:comment> <f i e l d T y p e name="string" class="solr.strfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="boolean" class="solr.boolfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="int" class ="solr.intfield" omitnorms="true" /> <f i e l d T y p e name="long" class ="solr.longfield" omitnorms="true" /> <f i e l d T y p e name="float" class ="solr.floatfield" omitnorms="true" /> <f i e l d T y p e name="double" class ="solr.doublefield" omitnorms="true" /> <xsl:comment> T r i s </ xsl:comment> <f i e l d T y p e name="sint" class="solr.sortableintfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="slong" class="solr.sortablelongfield" s o r t M i s s i n g L a s t ="true" omitnorms=" true" /> <f i e l d T y p e name="sfloat" class="solr.sortablefloatfield" s o r t M i s s i n g L a s t ="true" omitnorms=" true" /> 59

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 <f i e l d T y p e name="sdouble" class="solr.sortabledoublefield" s o r t M i s s i n g L a s t ="true" omitnorms= "true" /> <xsl:comment>pour i g n o r e r des champs</ xsl:comment> <f i e l d t y p e name="ignored" stored ="false" indexed="false" class ="solr.strfield" /> <xsl:comment> Dates </ xsl:comment> <f i e l d T y p e name="date" class="solr.datefield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <xsl:comment> Chaine ( pour l e nom de base, l e t i t r e et l auteur) </xsl:comment > <fieldtype name=" chaine" class="solr.textfield" positionincrementgap="100" > <analyzer > <tokenizer class="solr.standardtokenizerfactory"/> <filter class="solr.standardfilterfactory"/> <filter class="solr.lowercasefilterfactory"/> <filter class="solr.trimfilterfactory" /> </analyzer > </fieldtype > <xsl:comment > Texte (trouve dans les notices Notix : on en fait un equivalent du type test) </xsl:comment > <fieldtype name="texte" class="solr.textfield" positionincrementgap="100" > <analyzer > <tokenizer class="solr.standardtokenizerfactory"/> <filter class="solr.synonymfilterfactory" synonyms=" synonyms.txt" ignorecase="true" expand=" <filter class="solr.stopfilterfactory" ignorecase="true" words=" stopwords.txt"/> <filter class="solr.lowercasefilterfactory"/> <filter class="solr.patternreplacefilterfactory" pattern="([^a-z])" replacement="" replace="all" /> </analyzer > </fieldtype > <fieldtype name="text" class="solr.textfield" positionincrementgap="100" > <analyzer > <tokenizer class="solr.standardtokenizerfactory"/> <filter class="solr.synonymfilterfactory" synonyms=" synonyms.txt" ignorecase="true" expand=" <filter class="solr.stopfilterfactory" ignorecase="true" words=" stopwords.txt"/> <filter class="solr.lowercasefilterfactory"/> <filter class="solr.patternreplacefilterfactory" pattern="([^a-z])" replacement="" replace="all" /> </analyzer > </fieldtype > <!-- types Notix ou SDX => pour l i n s t a n t indexes en chaines de c a r a c t e r e r e s > <f i e l d T y p e name="key" class="solr.strfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="anyuri" class="solr.strfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> <f i e l d T y p e name="name" class="solr.strfield" s o r t M i s s i n g L a s t ="true" omitnorms="true" /> </ types> <! production des f i e l d s > <xsl:comment> l e s champs </ xsl:comment> <f i e l d s> <! on e v i t e d iterer sur des rdf:property semblables dans les divers fichiers RDF --> <xsl:for -each select="$propdoc1 $propdoc2[not(@xml:id = $propdoc1/@xml:id)] $propdoc3[not( @xml:id = $propdoc1/@xml:id) and not(@xml:id = $propdoc2/@xml:id)] $propdoc4[not(@xml:id = $propdoc1/@xml:id) and not(@xml:id = $propdoc2/@xml:id) and not(@xml:id = $propdoc3/ 60

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 @xml:id)]"> <xsl:call -template name=" transfoproperty" /> </xsl:for -each > <xsl:comment > champ sujet : permet d i n t e r r o g e r sur p l u s i e u r s champs a l a f o i s : c f copyfields ( on ne l e stocke pas pour l i m i t e r l impact sur la taille de l index ) </ xsl:comment> <f i e l d name="sujet" type="text" indexed="true" stored="false" r e qu i r ed ="false" multivalued=" true" /> <xsl:comment> champ t i t r e u n i v a l : copie du t i t r e en chaine de caracteres brute ( non tokenizee ) => permet l e t r i sur l e s t i t r e s </ xsl:comment> <f i e l d name="titre_unival" type="string" indexed="true" stored="false" r e qu i r ed ="false" multivalued="false" /> <xsl:comment> champ l i e u g e o : permet d interroger tous les champs geographiques </xsl:comment > <field name=" LIEU_GEO" type="text" indexed="true" stored="false" required="false" multivalued="true"/> <xsl:if test="$nbauteur=0"> <xsl:comment >Insertion d un champ auteur s i absent du Rdfs ( Temis )</ xsl:comment> <f i e l d name="auteur" type="chaine" indexed="true" stored ="true" r e qu i r e d ="false" multivalued="true" /> </ x s l : i f> < x s l : i f t e s t ="$nbdatepubli=0"> <xsl:comment>i n s e r t i o n d un champ date_publi si absent du Rdfs (Temis)</xsl:comment > <field name=" DATE_PUBLI" type="date" indexed="true" stored="true" required="false" multivalued=" </xsl:if > <xsl:comment > Prise en compte des champs specifiques au portail THEME PORTAIL et TYPE DOC PORTAIL Champs ajoutes dans les notices mais absents des rdfs!! </xsl:comment > <field name=" THEME_PORTAIL" type=" string" indexed="true" stored="true" required="false" multivalued="true" /> <field name=" TYPE_DOC_PORTAIL" type=" string" indexed="true" stored="true" required="false" multivalued="true" /> <!-- <xsl:comment > champs trouves dans les notices mais absent des rdfs!! (normalement a gerer par un attrape -tout dans un dynamicfield, mais ce dernier ecrase l i n d e x a t i o n des champs crees comme c i b l e des copyfields ( ex: TITRE UNIVAL ) ) </ xsl:comment> <f i e l d name="statut" type="ignored" indexed="false" stored="false" r e qu i r e d ="false" multivalued ="true" /> > <xsl:comment> permet des requetes t o u t : 1 pour a t t r a p e r t o u t l index </xsl:comment > <field name="tout" type=" string" indexed="true" stored="false" default="1" required="true" multivalued=" <!--date d indexation > <xsl:comment>date d indexation </ xsl:comment > <field name=" timestamp" type="date" indexed="true" stored="true" default="now" multivalued=" <!--Champs dynamiques, selectionnes sur prefixes ou suffixes. Permet de ne pas declarer tous les champs d un modele documentaire plus haut, t o u t en l e u r a t t r i b u a n t t o u t de meme un type p r e c i s. <xsl:comment> Dynamic F i e l d s 61

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 </ xsl:comment> <dynamicfield name="*_s" type="string" indexed="true" stored="true" /> > <xsl:comment>par defaut, une e r r e u r est lancee lorsqu un champ est propose a l i n d e x a t i o n a l o r s qu il n a pas ete matche dans l a l i s t e plus haut. Cet attrape t o u t permet de t o u t indexer, sans r e f l e x i o n. Le @type="ignored" permet d ignorer les champs non prevus </ xsl:comment > <dynamicfield name="*" type=" ignored" indexed="false" stored="false" multivalued="true"/> </fields > <xsl:comment > Champ a utiliser comme identifiant de notice. </xsl:comment > <uniquekey >CLE </uniquekey > <xsl:comment > Champ par defaut pour la recherche. </xsl:comment > <defaultsearchfield >SUJET </ defaultsearchfield > <xsl:comment > Operateur par defaut du SolrQueryParser : @defaultoperator="and OR" </xsl:comment > <solrqueryparser defaultoperator="or"/> <!-- les copyfields --> <xsl:comment > <copyfield> permet de copier un champ envoye a l i n d e x a t i o n par post dans un champ declare plus haut. C est utile pour assurer plusieurs analyses differentes (type) pour une meme information. </xsl:comment > <xsl:for -each select="$propdoc1 $propdoc2[not(@xml:id = $propdoc1/@xml:id)] $propdoc3[not( @xml:id = $propdoc1/@xml:id) and not(@xml:id = $propdoc2/@xml:id)] $propdoc4[not(@xml:id = $propdoc1/@xml:id) and not(@xml:id = $propdoc2/@xml:id) and not(@xml:id = $propdoc3/ @xml:id)]"> <xsl:call -template name=" copyfields" /> </xsl:for -each > </schema > </xsl:template > <!-- Les templates nommes --> <!-- Production des fields --> <xsl:template name=" transfoproperty"> <xsl:choose > <xsl:when test="@xml:id = CHAMP0 or @xml:id = CHPCTRL "> <xsl:text ></xsl:text > </xsl:when > <xsl:otherwise > <field > <!-- attribut name du field --> <xsl:attribute name="name"> <xsl:value -of select="@xml:id" /> </xsl:attribute > <xsl:call -template name="type" /> <xsl:call -template name="index" /> <xsl:call -template name="store" /> <xsl:choose > <!-- attribut required et multivalued de fields speciaux --> <xsl:when test="@xml:id = CLE "> <xsl:attribute name=" required"> <xsl:text >true </xsl:text > 62

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 </xsl:attribute > <xsl:attribute name=" multivalued"> <xsl:text >false </xsl:text > </xsl:attribute > </xsl:when > <xsl:when test="@xml:id = NOM BASE "> <xsl:attribute name=" required"> <xsl:text >true </xsl:text > </xsl:attribute > <xsl:attribute name=" multivalued"> <xsl:text >false </xsl:text > </xsl:attribute > </xsl:when > <xsl:when test="@xml:id = TITRE "> <xsl:attribute name=" required"> <xsl:text >false </xsl:text > </xsl:attribute > <xsl:attribute name=" multivalued"> <xsl:text >false </xsl:text > </xsl:attribute > </xsl:when > <xsl:when test="(@xml:id = AUTEUR ) or (@xml:id = AUTEUR PHYSIQUE )"> <xsl:attribute name=" required"> <xsl:text >false </xsl:text > </xsl:attribute > <xsl:attribute name=" multivalued"> <xsl:text >true </xsl:text > </xsl:attribute > </xsl:when > <xsl:when test="$mode_transfo= uni "> <xsl:call -template name=" require_uni" /> <xsl:call -template name=" multival_uni" /> </xsl:when > <xsl:otherwise > <xsl:call -template name=" require_multi" /> <xsl:call -template name=" multival_multi" /> </xsl:otherwise > </xsl:choose > </field > </xsl:otherwise > </xsl:choose > </xsl:template > <!-- attribut type du field --> <xsl:template name="type"> <xsl:attribute name="type"> <xsl:choose > <xsl:when test=" descendant::rng:data[@type!= date ]"> <xsl:value -of select=" descendant::rng:data[@type]/@type" /> </xsl:when > <xsl:otherwise > <xsl:choose > <xsl:when test=" contains(@xml:id, DESC ) or contains(@xml:id, GEO ) or contains( @xml:id, COMMENTAIRE ) or contains(@xml:id, MOT ) or starts -with(@xml:id, RES )"> <xsl:text >text </xsl:text > </xsl:when > <xsl:when test="starts -with(@xml:id, PRIX )"> <xsl:text >int </xsl:text > </xsl:when > <xsl:when test="(@xml:id = NOM BASE ) or (@xml:id = TITRE ) or (@xml:id = AUTEUR ) or (@xml:id = AUTEUR PHYSIQUE )"> <xsl:text >chaine </xsl:text > </xsl:when > <xsl:when test="starts -with(@xml:id, DATE )"> <xsl:text >date </xsl:text > </xsl:when > <xsl:otherwise > <xsl:text >string </xsl:text > </xsl:otherwise > </xsl:choose > 63

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 </xsl:otherwise > </xsl:choose > </xsl:attribute > </xsl:template > <!-- attribut indexed du field --> <xsl:template name="index"> <xsl:attribute name=" indexed"> <xsl:text >true </xsl:text > </xsl:attribute > </xsl:template > <!-- attribut stored du field --> <xsl:template name="store"> <xsl:attribute name=" stored"> <xsl:choose > <xsl:when test="(($mode_transfo= uni ) and ((@xml:id= THEME ) or (@xml:id= TEG )))"> <xsl:text >false </xsl:text > </xsl:when > <xsl:otherwise > <xsl:text >true </xsl:text > </xsl:otherwise > </xsl:choose > </xsl:attribute > </xsl:template > <!-- attribut required du field --> <xsl:template name=" require_uni"> <xsl:attribute name=" required"> <xsl:text >false </xsl:text > </xsl:attribute > </xsl:template > <xsl:template name=" require_multi"> <xsl:attribute name=" required"> <xsl:choose > <xsl:when test=" descendant::rng:optionnal"> <xsl:text >false </xsl:text > </xsl:when > <xsl:otherwise > <xsl:text >true </xsl:text > </xsl:otherwise > </xsl:choose > </xsl:attribute > </xsl:template > <!-- attribut multivalued du field --> <xsl:template name=" multival_uni"> <xsl:choose > <xsl:when test=" descendant::rng:zeroormore descendant::rng:oneormore"> <xsl:attribute name=" required"> <xsl:text >false </xsl:text > </xsl:attribute > <xsl:attribute name=" multivalued"> <xsl:text >true </xsl:text > </xsl:attribute > </xsl:when > <xsl:otherwise > <xsl:attribute name=" multivalued"> <xsl:text >false </xsl:text > </xsl:attribute > </xsl:otherwise > </xsl:choose > </xsl:template > <xsl:template name=" multival_multi"> <xsl:choose > <xsl:when test=" descendant::rng:zeroormore"> <xsl:attribute name=" required"> <xsl:text >false </xsl:text > </xsl:attribute > <xsl:attribute name=" multivalued"> 64

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 <xsl:text >true </xsl:text > </xsl:attribute > </xsl:when > <xsl:when test=" descendant::rng:oneormore"> <xsl:attribute name=" required"> <xsl:text >true </xsl:text > </xsl:attribute > <xsl:attribute name=" multivalued"> <xsl:text >true </xsl:text > </xsl:attribute > </xsl:when > <xsl:otherwise > <xsl:attribute name=" multivalued"> <xsl:text >false </xsl:text > </xsl:attribute > </xsl:otherwise > </xsl:choose > </xsl:template > <xsl:template name=" copyfields"> <xsl:if test="@xml:id = TITRE "> <copyfield source="titre" dest=" TITRE_UNIVAL" /> </xsl:if > <xsl:if test=" contains(@xml:id, DESC ) or starts -with(@xml:id, RES ) or contains(@xml:id, COMMENTAIRE ) or contains(@xml:id, MOT )"> <copyfield > <xsl:attribute name=" source"> <xsl:value -of select="@xml:id" /> </xsl:attribute > <xsl:attribute name="dest"> <xsl:text >SUJET </xsl:text > </xsl:attribute > </copyfield > </xsl:if > <xsl:if test=" contains(@xml:id, GEO )"> <copyfield > <xsl:attribute name=" source"> <xsl:value -of select="@xml:id" /> </xsl:attribute > <xsl:attribute name="dest"> <xsl:text >LIEU_GEO </xsl:text > </xsl:attribute > </copyfield > </xsl:if > <!-- On ne copie plus tous les titres dans TITRE car cela exige de declarer ce champ comme multivalue ; or on veut pouvoir trier les reponses sur ce champ (et le parametre sort de Solr n admet pas l e s champs m u l t i v a l u e s ; cela d i t, un t r i est t o u t de meme e f f e c t u e sur un champ multivalue, mais avec q u e l l e pertinence? En tous cas, pour l e s champs AUTEUR et AUTEUR PHYSIQUE ( Temis ), l a d e c l a r a t i o n en m u l t i v a l u e est i n e v i t a b l e ) < x s l : i f t e s t ="contains(@xml:id, TITRE ) and (@xml:id!= TITRE )"> <copyfield> <x s l : a t t r i b u t e name="source"> <x s l : v a l u e of s e l e c t ="@xml:id" /> </ x s l : a t t r i b u t e> <x s l : a t t r i b u t e name="dest"> <x s l : t e x t>titre</ x s l : t e x t> </ x s l : a t t r i b u t e> </ copyfield> </ x s l : i f> > < x s l : i f t e s t ="(@xml:id = AUTEUR_PHYSIQUE )"> <copyfield> <x s l : a t t r i b u t e name="source"> <x s l : v a l u e of s e l e c t ="@xml:id" /> </ x s l : a t t r i b u t e> 65

PORTAIL DE RECHERCHE FÉDÉRÉE BASÉ SUR SOLR - B.2 <x s l : a t t r i b u t e name="dest"> <x s l : t e x t>auteur</ x s l : t e x t> </ x s l : a t t r i b u t e> </ copyfield> </ x s l : i f> < x s l : i f t e s t ="(@xml:id = DATE_PUBLICATION )"> <copyfield> <x s l : a t t r i b u t e name="source"> <x s l : v a l u e of s e l e c t ="@xml:id" /> </ x s l : a t t r i b u t e> <x s l : a t t r i b u t e name="dest"> <x s l : t e x t>date PUBLI</ x s l : t e x t> </ x s l : a t t r i b u t e> </ copyfield> </ x s l : i f> </ x s l : t e m p l a t e> </ x s l : s t y l e s h e e t> 66