[koha-Infos] [IMPORTANT] avenir de Koha

Mar 14 Juin 10:59:37 CEST 2005

Bonjour,

Joshua (le Release Manager de la prochaine version) a posté hier soir un message TRES important sur la liste des développeurs. Je vous en fait la traduction. Commentaires et questions de moi ensuite

================== TRADUCTION
Salut tout le monde,

Si vous n'avez pas suivi les discussions sur le chat, nous avons beaucoup parlé de Zebra, un moteur d'indexation et de recherche peut-être intéressant pour nous.
Le site d'indexdata nous dit que :
Zebra est un moteur d'indexation de texte structuré, de recherche et de restitution à haute performances. Il lit des données structurées dans plusieurs formats (par exemple mails, XML, MARC...) et permet des recherches booléenne, par expression, par pertinence...
Zebra gère les bases importantes (plus de 10Go de données, 10 millions d'enregistrements. Il supporte les mises à jour incrémentales et en temps réel sur des systèmes en production. Vous pouvez accéder aux données stockées dans Zebra avec de nombreux outils d'indexdata (Yaz par exemple), ou avec des clients et boites à outil z3950 commerciaux ou freewares.

http://indexdata.dk/zebra

J'ai (NDT : Joshua) mis en place un site zebra de test. Il tourne sur le serveur LibLime. Il y a pour l'instant accès aux 150 000 notices de Nelsonville, à 5 millions d'enregistrements MARC fournis par sanspach, et à 13 000 notices fournies par Paul Poulain (NDT :la base de l'EMN). Paul travaille encore sur certains problèmes d'indexation UNIMARC.

http://liblime.com/zap/advanced.html

Notez que la recherche et la restitution est faite par z3950, avec le serveur fourni dans zebra. Le moteur d'indexation comme le serveur peuvent être paramétrés pour coller au type de recherche que vous souhaitez faire (le site ci-dessus est juste une "proof of concept", une maquette) -- Il y a tout ce qu'il faut pour faire un système de recherche de haut niveau.

Si nous décidons de travailler avec Zebra, nous devrons décider ce que nous ferons des éléments non MARC. Devons nous développer un utilitaire d'export pour que zebra indexe les notices (en XML par exemple ?) Devons-nous utiliser les tables Koha pour créer une notice MARC qui sera intégrée dans Zebra. Devons nous laisser les outils de recherche de Koha 1.x et utiliser Zebra pour les notices MARC ? Que devons nous faire des tables marc_*_table existantes ?

Il est donc grand temps de programmer une réunion virtuelle du "Groupe (traitant) de (la) Recherche Koha 2.4". Je propose jeudi 23 à 21H GMT (NDT : soit 23H en France)

Faites moi savoir sur la liste si date et heure vous conviennent.
====================== FIN DE LA TRADUCTION

============== COMMENTAIRES
Tout d'abord, le 23 ce n'est pas possible pour moi, je suis à Paris chez un client, donc je vous reparlerai de la date. Si certains veulent participer, joshua nous lit (et je ferai suivre), postez vos disponibilités.

Ensuite, j'aimerai que vous mesuriez les conséquences de ce choix pour que la voix de la France :o) soit entendue.
Mettre en place un tel outil a 2 conséquences principales :
* Faire passer Koha dans la "cour des grands". Zebra peut indexer du full text, des masses hallucinantes de notices... Joshua a aussi des idées pour interfacer Koha avec un CMS pour permettre de développer un portail de bibliothèque. Bref, beaucoup de bonnes choses, de très haut niveau. Mais cela a des conséquences sur la simplicité d'installation et le "marché" auquel l'application s'adresse. En particulier, les petites médiathèques avec 1500 documents risquent de définitivement adopter PMB comme seul choix accessible de SIGB sous licence libre. Même si nous fournissons des outils pour paramétrer Zebra en fonction de la bibliothèque, il faudra "mettre les mains dans le cambouis" plus qu'aujourd'hui. Ajoutons aussi que la migration de 2.2 à la nouvelle version ne pourra être automatique (mais comme d'habitude, personne n'est obligé de migrer ;-) )
* Par contre, les "grosses" structures seront enchantées d'apprendre tout ce que sait faire Koha. On atteint avec les outils actuels une limite en terme de performance. Par exemple, la bib de sociologie, du haut de ses 60 000 documents, a parfois des temps de réponse médiocre (il suffit de chercher 2 mots très utilisés)

Si vous me demandez mon avis personnel, il est que zebra est un outil très excitant, et, comme tous les informaticiens, j'aime la nouveauté. De plus, taper dans le "haut de gamme" est un objectif que nous avons dans Koha depuis un bon moment. D'un autre coté, je ne voudrais pas me "mettre à dos" les petites structures, aussi mes clients ;-)

En fait, je pense que la décision ira dans le sens de zebra. Joshua travaille pour Nelsonville, et Nelsonville fait partie des bibs qui souffrent des limites actuelles. Donc il faut peut être reformuler la question autrement : l'équipe de développement doit-elle maintenir un "double Koha", c'est à dire avoir un paramètre qui permette de définir "koha + zebra" ou "koha seul". Sachant que "koha seul" ne fonctionne bien que jusqu'à x0 000 notices, et qu'au delà "koha+zebra" est impératif. Ou bien acceptons nous d'avoir un Koha plus compliqué à installer mais plus simple à maintenir pour les développeurs ?

Bon, j'ai conscience que je ne suis pas tout à fait convaincu de voir quelle est la meilleure solution. Donc j'aimerai que vous fassiez part de vos commentaires et de vos remarques ici même. Je me chargerai de les transmettre "en haut lieu" ;-) Et si certains veulent être présent lors du chat, qu'ils n'hésitent pas.

-- 
Paul POULAIN
Consultant indépendant en logiciels libres
responsable francophone de koha (SIGB libre http://www.koha-fr.org)