Développements SolR pour Koha

Toutes ces informations ont déjà été postées sur la liste de diffusion koha-devel. Afin de partager avec une plus large audience notre travail et nos attentes au sujet d’un nouveau moteur d’indexation (SolR) pour Koha, nous pensions qu’il serait bien de rassembler nos idées et réflexions ici. Nous remercions les bibliothèques qui apportent leur soutien à notre démarche.Pourquoi zebra ne nous convient plus?

• Il n’y a pas de communauté autour de cette solution, c’est un logiciel open-source distribué et développé par Indexdata.
• Indexation
  • pas d’indexation en temps réel: l’utilisation de l’outil crontab (automatisation du lancement des tâches) est limitée, lorsqu’une autorité est ajoutée alors qu’une notice est créée, il faut attendre quelques minutes pour que la notice soit indexée (devrait être résolu… depuis que zebra a quelques possibilités pour indexer les notices via des services z3950… c’est complexe et cela a besoin d’être testé)
  • aucune possibilité d’accéder / transformer / supprimer facilement des données. Si un jour il faut réindexer la totalité des données et s’il y a des problèmes (d’encodage par exemple) avec les données, rien ne sera indexé. Pendant l’indexation d’un fichier, s’il y a une erreur, zebraix échouera en silence. Le process n’est pas sécurisé et il n’y a pas de moyen de savoir quelle notice a fait échouer le programme.
  • nous utilisons un moyen qui n’est plus supporté pour définir les index pour les notices (grs1), et l’outil développé par Indexdata pour utiliser DOM a quelques défauts. Son utilisation nécessiterait des modifications dans la méthode d’indexation pour fonctionner. Si quelqu’un a réalisé quelque chose qui fonctionne, il est le bienvenu.
  • Le standard Iso2709 défini une limite de taille pour l’enregistrement. Le process d’indexation de Zebra utilise Iso2709 pour sérialiser une notice avant de l’indexer. Le XML peut être utilisé, mais cela génère des problèmes d’encodage. Ainsi, si un item doit être sérialisé avec beaucoup de données, il ne sera pas indexé entièrement par Zebra.
  • ccl, cql et pqf ne sont pas intuitifs.
• Recherche:
  • Les facettes n’existent pas, elles sont calculées par Koha, mais sont fausses (calcul réalisé sur la page courante). Un patch a été envoyé qui réalise le calcul sur 500 enregistrements, mais qui ne réalise toujours pas de vraies facettes. Si nous voulions utiliser les facettes de zebra, nous aurions des problèmes avec les accents et ce n’est pas résolu à ce jour.
  • Lorsque Zebra est utilisé avec ICU (beaucoup en France), nous perdons 2 fonctionnalités importantes: la troncature gauche et la recherche floue.
  • De manière générale, beaucoup de fonctionnalités manquent à ce jour: la recherche floue (avec ICU activé), la recherche par facettes, recherche par racine (stemming search), recherche par synonymes, recherche phonétique, SolR peut répondre à ces besoins…
• Autres problèmes:
  • Les fichiers de configuration de Zebra sont un cauchemar. La configuration ne peut être pilotée facilement: les index ne sont pas indexables via http ou la configuration. Ils sont tous codés en dur sur le disque, il n’est donc pas possible de les lister, les modifier, de choisir si un index doit être visible pour l’opac ou l’intranet simplement (cela pourrait être fait en analysant les fichiers ccl.properties, record.abs, ib1.att… mais quelle complexité). Il n’est donc pas possible de personnaliser la configuration en définissant les index que l’ont veut facilement.
  • Nous rencontrons aujourd’hui une anomalie de gestion de la mémoire avec Zoom et Zebra sur des connexions persistantes.

Qu’est-ce que SolR apporte?

• La solution et son contexte:
  • Grande communauté, open-source, libre, basé sur lucene, largement utilisé, c’est un projet apache
  • Bien documenté et supporté par la communauté
• Indexation:
  • Configuration des types: l’installation standard de Solr fourni des “Analyzers” et “Tokenizers”.
    L’indexation avec les “tokenizers”: quand un document est indexé, les champs sont analysés et découpés pour transformer et normaliser les données.
    La recherche avec l’aide des “analyzers”: il pré-traite le texte à l’indexation ou à la recherche pour trouver l’information (par exemple: trouver des mots sans tenir compte de leur casse, trouver des synonymes etc.)
  • Les noms des index sont clairs et personnalisables
  • La gestion des champs dynamiques facilite la configuration par la base de données
  • Indexation des données dans un format autre que MARC possible: indexation de documents texte, pdf etc.
  • Les librairies qui permettent d’interroger SolR existent dans beaucoup de langages, l’interconnexion des applications est donc facilitée
  • Il n’y a plus de gestion par cronjob puisqu’il est possible de mettre à jour à la volée. Cela pourrait certainement être fait avec les services étendus de Zebra. Plusieurs problèmes ont été levés lors des premiers développements et tests (avec les accès concurrents) mais cela reste à résoudre
• Recherche
  • La recherche par facettes fournit une bien meilleure expérience utilisateur.
  • Recherche floue
  • L’interface web d’administration de solr permet de tester facilement la recherche
  • Le format des requêtes est intuitif et il est même possible d’écrire son propre format
  • Recherche avancée: gestion de la recherche par racine et la recherche phonétique (algorithme pour indexer et retrouver les mots par leur prononciation).
  • Utilisation des caractères génériques pour requêter sur une troncature gauche ou droite (* ou ?)
  • Recherche par proximité
  • Pondération de mots clés
  • Recherche par synonymes
  • Suggestions orthographiques
  • Recherche de documents par similarité (“articles similaires”)
  • Le tri par pertinence est meilleur
  • Les problèmes d’accents et d’utf8 sont résolus sans effort particulier
• Généralités
  • Possibilité d’utiliser une installation multi-core: une instance SolR pour plusieurs bases de données indexées

Les développements chez Biblibre sur SolR

I. État des lieux du POC (Proof of concept)

1/ remplacer l’indexation de notices et leurs recherche, aujourd’hui développé avec Zebra, avec SolR sur des types simples (string, text, date, integer), avec des “tokenizers” et “analyzers” basiques.
2/ Gérer les index et les mappings de notices et autorités sur une page d’administration (la configuration est enregistrée en base)

• 08/2010 les développements ont démarré et une première requête a été possible
• le code de recherche de Koha (Search.pm etc.) est largement simplifié (il a fondu de 70%)
• 08/2010 nouvelles pages d’administration “indexes.pl” et “indexmappings.pl”
• 08/2010 ajout du support pour les plugins fonctionnels d’indexation (indexation de la disponibilité en temps réel par exemple)
• 09/2010 WIP (Travail en cours) lors des développements nous nous efforçons de refactoriser le code de Koha lié à la recherche si possible
• 10/2010 un poc a été déployé et montré lors de la Koha Con 2010 pour avoir du feedback

II. Affiner les besoins et améliorer les développements

• 11/2010 améliorer la gestion des types (raffinement toujours en cours pour répondre à plus de types de requêtes)
• 11/2010 SolR autorise une installation multi-core qui donnerait la possibilité de gérer plusieurs sites pour une seule installation
• WIP 11/2010 recherche possible dans les différentes formes (rejetée, associée, vedette)
• WIP 11/2010 développement d’un nouveau serveur z3950 qui requête SolR utilisant le module Net::Z3950::SimpleServer fourni par Indexdata. La recherche simple est déjà possible. Le développement des réponses à des requêtes complexes est en cours de développement
• WIP 12/2010 mise à jour des scripts d’installation (bdd, configuration solr, scripts…)

Roadmap Biblibre:

Améliorations techniques:

• améliorer le temps d’indexation (c’est trop long)
• raffiner la configuration des types
• nettoyer le code mort
• développement d’une suite de tests (scénarios fonctionnels, tests unitaires, tests de non régression zebra vs solr)
• mettre à jour les fichiers xslt
• fournir une couche d’abstraction pour donner la possibilité de maintenir Zebra

A venir:

• mettre à jour le formulaire de recherche avancée
• afficher les facettes sous forme de nuage de tag

Les développements en cours sont disponibles sur notre dépot git et seront bientôt publiés sur la branche wip/solr.

Nous souhaitons réellement travailler avec vous sur ce sujet et Henri Damien Laurent devrait très bientôt organiser quelque chose. Restez connectés!