Intégration des revues électroniques dans le catalogue

Après avoir indexé les notices du SIGB, il nous restait à intégrer les ressources électroniques pour que notre catalogue soit tout à fait opérationnel. C’est chose faite depuis quelques jours car nous avons enfin trouvé une solution satisfaisante pour exploiter nos données issues du résolveur de liens SFX.

Exporter depuis la base SFX

Alors que j’expliquais, dans un précédent billet, comment nous avions indexé les notices UNIMARC de notre SIGB dans Solr, j’envisageais d’importer les métadonnées relatives aux ressources électroniques au format CSV. Mais assez rapidement, nous avons constaté que les données que nous exportions de SFX étaient partielles et surtout que l’indexation dans Solr puis l’affichage dans Blacklight posait des problèmes puisque le catalogue est conçu pour bien fonctionner avec des données MARC.

Nous avons donc regardé ce qui ce faisait chez les autres utilisateurs de Blacklight et nous sommes entrés en contact avec nos homologues de Stanford. Surprise ! Leur solution est on ne peut plus simple : profiter de l’outil MARCIt! inclus dans SFX pour exporter les métadonnées au format MARC et donc les indexer dans Solr aussi facilement que les notices “classiques”. Que n’y avais-je pensé ! Sauf que… MARCIt! exporte les données en MARC21, donc Ex Libris ne commercialise pas cet outil en France. Il fallait donc trouver autre chose, mais l’idée était là : obtenir les données en MARC.

Du coup, j’ai testé tous les exports disponibles dans l’Export Tool de SFX et j’ai trouvé ce qu’il nous fallait : l’export XML. L’intérêt de ce fichier est qu’il nous fournit tous les champs descriptifs utiles ainsi qu’un lien (856) vers le menu SFX, un lien contextuel donc.

Export XML dans export tool SFX
Export XML dans Export Tool SFX

Traiter le fichier MARCXML

Pour que le fichier SFX soit exploitable par Solr/Blacklight, il faut le convertir en UNIMARC. Nous procédons en deux temps, avec le logiciel MarcEdit.

D’abord, nous utilisons les MARC Tools pour transformer l’XML en MARC. Il suffit de soumettre le fichier SFX à MarcEdit qui va exécuter la conversion de MARC21XML à MARC. Evidemment, on récupère encore des données au format MARC21.

Dans un second temps, on utilise l’outil MarcEditor pour transformer les champs MARC21 en champs UNIMARC, mais aussi générer un control number, c’est-à-dire un numéro unique pour le champ 001. On en profite aussi pour faire du nettoyage dans les données (par exemple modifier le label de notice de sorte que les codes d’application mentionnent “revue électronique” plutôt que “revue imprimée”).

Outil MarcEditor dans MarcEdit
Outil MarcEditor dans MarcEdit

Importer dans Solr

Quand tous les traitements sont effectués, on compile le fichier de manière à obtenir un .mrc qui sera importé aussi facilement par Solr que le fichier .iso issu du SIGB.

Tadam ! Les revues électroniques sont disponibles dans le catalogue !

Revues électroniques intégrées au catalogue
Revues électroniques intégrées au catalogue

 

Outil de découverte libre : un schéma pour y voir plus clair

Après le poster réalisé pour les journées ABES, et plusieurs billets sur l’alambic, voici un schéma plus détaillé de notre outil de découverte. Il présente avec plus de précisions les relations techniques entre notre catalogue Absysnet et l’installation de Blacklight. Un billet très court donc, mais parfois, un dessin vaut mieux qu’une longue explication.

Schéma de l'outil de découverte libre de la BCU
Schéma de l’outil de découverte libre de la BCU

 

L’OPAC avant les RAMEAU

Que l’on me pardonne de recycler en guise de titre une boutade de potache, compréhensible des seuls bibliothécaires : elle m’a valu un jour, lors d’un de mes premiers exposés professionnels, l’innocente satisfaction d’arracher un franc éclat de rire à une collègue qui me paraissait un peu austère. Je m’étais alors promis, si un jour l’OPAC de mes rêves venait à exister, de recaser ce jeu de mots.

Or c’est chose faite, et voici l’occasion de revenir un peu sur le projet majeur de l’année 2013, sur un ton un peu léger parce qu’après tout, quand on a bien travaillé, il est juste de célébrer le labeur accompli et il n’est pas interdit de le faire de façon récréative. Je précise que c’est le travail d’autrui que je célèbre (voir les billets parus sur le sujet). En revanche je revendique la pleine et entière responsabilité de mes jeux de mots désastreux.

À présent, à l’intention des non bibliothécaires qui se demandent ce que signifie ce titre absurde entaché d’une faute d’accord, petit cours de jargon bibliothécaire à l’usage des gens normaux. Les collègues peuvent se rendre directement au paragraphe 3.

Signalétique de l'OPAC, (publié sur FlickR sous le pseudonyme d'Enokson, sous licence Creative Commons, Attribution)
Signalétique de l’OPAC, (publié sur FlickR sous le pseudonyme d’Enokson, sous licence Creative Commons, Attribution)

1. OPAC, c’est l’acronyme de Online public access catalogue. Allez savoir pourquoi ce sigle anglophone s’est imposé en français, alors que sa prononciation en français évoque l’idée diamétralement opposée au service qu’il rend, ainsi que l’a plaisamment relevé le dictionnaire du diable des bibliothèques  à la définition du mot « acronyme ».
On propose parfois d’y lire un message subliminal des bibliothécaires à l’intention de leurs lecteurs ; exégèse qui mérite quelques secondes d’autodérision à la pause café les jours de mauvaise humeur, pas plus. Ou bien, s’il faut vraiment faire du mauvais esprit, ne mégotons pas et réformons tout notre vocabulaire :  les tests utilisateurs organisés l’an dernier autour de notre site web ont révélé que même le mot “catalogue” peut dérouter nos lecteurs. « Catalogue, on pense à un livre », disait un commentaire. En effet ; c’est vraiment agaçant cette association dont on n’arrive pas à se défaire entre bibliothèque et bouquins.

Heureusement, la modernité a inventé le Discovery tool, dont la traduction Outil de découverte semble en voie de s’imposer, sans doute grâce à sa brièveté et à son intelligibilité parfaite. Va pour outil de découverte, donc, en espérant que le sigle « OD » ne va pas venir infester la documentation professionnelle, sans oublier les perles éventuelles qui pourraient jaillir de trouvailles comme « catalogue de découverte (CD) » ou encore mieux « Catalogue outil de découverte (COD) ». J’imagine déjà la conclusion désabusée d’un rapport d’activités de 2018 : à l’usage, malgré les promesses d’interopérabilité du fournisseur, notre système, dépassé, ne s’accorde pas avec le COD, alors que celui-ci était positionné avant.
Bref, l’OPAC, c’est le catalogue en ligne offert au public

 

2. RAMEAU, c’est plus compliqué. C’est le Répertoire d’Autorité Matière Encyclopédique, Alphabétique et Unifié, et l’un des symboles du savoir-faire bibliothécaire. Comme tout outil systématique, RAMEAU, en dépit de son caractère impressionnant (l’édition 2002 fait 8 volumes, d’après… l’OPAC) est précieux : tous ceux qui ont tâté de l’indexation savent qu’il faut renvoyer tous ses synonymes vers un seul terme, pour que le lecteur ait toute l’information en une fois. Exemple pertinent bien qu’un peu impertinent aussi : c’est grâce à ces renvois conçus a priori  que le lecteur qui cherche « doudou » ou « peluche » aura pour réponse des notices sur les livres de psycho ou de puériculture parlant des objets transitionnels. On peut railler le terme, n’empêche : on accède bien aux résultats. Bon, je regrette un peu de n’avoir pas trouvé, dans la liste des « formes rejetées », l’appellation « nain-nain », qui est pourtant d’usage attesté dans certaines zones linguistiques. J’enverrai une proposition de modification à ce sujet.
Comme tous les outils métiers, RAMEAU a sans doute ses déviances et ses idolâtres. Je n’en ai jamais rencontré en chair et en os et je ne suis pas sûr de leur existence réelle, mais on dit que certains bibliothécaires éprouveraient un véritable plaisir, par exemple, à saisir le plus possible de termes RAMEAU dans leurs notices de catalogage, pour le plaisir de manier les règles subtiles de cette liste, car elle est articulée logiquement de façon hiérarchique (avec des “vedettes primaires”, des “subdivisions thématiques” et des “subdivisions chronologiques”). Je conçois d’ailleurs que l’on puisse, aux époques troublées, céder à la tentation de recréer l’ordonnancement harmonieux du monde par la magie de mots ordonnés séparés par des tirets doubles. Mais je n’ai jamais rencontré personne qui ait amené cette pratique jusqu’à l’addiction.
Bref, les mots RAMEAU, c’est le vocabulaire contrôlé d’indexation employé par les bibliothécaires.

Le catalogue "en ligne", version 1974.
Le catalogue “en ligne”, version 1974 (Source FlickR, domaine public).

[les collègues peuvent reprendre ici]

3. En résumé, on peut considérer l’OPAC et RAMEAU comme les symboles respectifs du front office et du back office. Alors, “l’OPAC avant les RAMEAU”, qu’est-ce à dire ? Eh bien, comme chacun sait, les bibliothécaires d’avant ne pensait qu’à leurs bouquins, alors que ceux d’aujourd’hui sont beaucoup plus gentils et ne pensent qu’à leurs lecteurs. C’est cette victoire des gentils modernes sur les méchants ringards, illustrée par la montée en puissance des outils de découverte (on les appelait alors “OPAC de nouvelle génération”) qu’était censée impliquer ma boutade. Avec en prime une petite connotation transgressive très tendance et absolument sans risque, tout à fait adaptée pour stigmatiser la supposée crispation professionnelle des méchantes bibliothécaires à chignon. C’était vraiment mesquin de ma part, mais le plaisir du jeu de mots l’emportait sur l’intention polémique.

La réalité, c’est que l’outil de découverte permet réellement d’amener l’OPAC vers un meilleur service, à l’aide d’avancées techniques que les bibliothécaires (avec ou sans chignon) attendaient avec impatience : tri des résultats par pertinence, filtrage, etc. Mais le savoureux de l’affaire, c’est que l’OPAC-outil-de-découverte-catalogue-en-ligne utilise bel et bien les mots clés RAMEAU. Ces termes, choisis avec soin par les catalogueurs, sont tout indiqués pour créer (entre autres) les filtres des résultats obtenus. La question peut ensuite se poser (elle s’est posée à nous, de fait) de savoir s’il faut, ou non, préserver la structure hiérarchique de cette indexation, ou ne préserver que les mots eux-mêmes, en abandonnant leur lien logique ? En l’occurrence nous avons choisi de briser les liens entre les termes pour l’affichage des facettes (mots clefs de filtrage) mais de les préserver dans les notices. En conclusion, il fallait bien passer par les RAMEAU pour accomplir cette remise à neuf d’OPAC.

Quelles autres leçons tirer ? Je les livre à la va-vite, ce billet est déjà trop long.  1°) C’était le projet majeur de l’année, il est arrivé à réalisation. J’en avais rêvé pour 2012 dans un billet programmatique. Comme souvent, il a pris un peu plus de temps que prévu, mais enfin il fonctionne. 12 mois, de la première installation à la mise en test public, c’est un délai correct compte tenu d’un accident majeur sur le serveur de développement (trois bons mois de retard) 2°) la présence dans le service d’un informaticien de métier épargne la fastidieuse rédaction d’un cahier des charges suivi d’un appel d’offres et des factures annuelles subséquentes 3°) Un stage informatique a permis en prime de mettre en place une version adaptée pour téléphone mobile du catalogue en ligne et du site web. 4°) Il y a encore de nombreuses améliorations à apporter, bien sûr, on y travaille. 5°) Nous avons le même catalogue que l’université de Stanford, c’est un début encourageant ; les créateurs du google de demain sont peut-être auvergnats ?

Dernière précision enfin, à l’intention des contribuables sourcilleux qui verraient dans ce billet une imposture professionnelle : il a été principalement rédigé sur mon temps personnel. En ces temps de météo tendue, de négociations en baisse et de budgets maussades, qu’on veuille bien y voir ma modeste contribution à l’allègement de l’ambiance et de la dette publique.
Ainsi qu’un souriant hommage au travail de mes collègues.

Premier catalogue en ligne (?) à la bibliothèque universitaire de l'Ohio, source du cliché (publié sur FlickR sous licence Creative Commons Attribution, Pas d'utilisation commerciale, Partage dans les même conditions).
Premier catalogue en ligne (?) à la bibliothèque universitaire de l’Ohio, source du cliché (publié sur FlickR sous licence Creative Commons Attribution, Pas d’utilisation commerciale, Partage dans les même conditions).

Un outil de découverte libre : poster pour les JABES

Nous avons eu la joie de présenter cette semaine notre poster lors des Journées ABES. Léonard Bourlet et moi-mêmes étions présents pour parler de notre travail mais je dois rendre hommage aux principaux artisans de ce poster, Mathieu et Karine.

Présentation du poster aux JABES 2013
Présentation du poster aux JABES 2013

 

Il nous est apparu très vite que le sujet à développer serait Blacklight et sa mise en œuvre. Nous avons voulu restituer notre expérience. Mathieu Bacault a donc conçu le scénario du poster en privilégiant l’aspect chronologique et les étapes du projet, de la réflexion initiale à la mise en production. C’est cette idée de fil conducteur qui nous a menés à la Linea.

Partant de là, Karine Vazeille a réalisé le poster, du dessin à la mise en page (avec Illustrator). Elle a repris le style de la Linea, en modifiant le dessin de la tête notamment, et a conçu toutes les illustrations et les boutons. Le tout en une quinzaine de jours. L’imprimeur a d’ailleurs fourni le poster la veille du pont de l’Ascension, donc juste avant le départ pour Montpellier.

Sur place, nous avons subi une petite douche froide en constatant que les panneaux n’étaient pas adaptés à un poster horizontal ! Et nous étions les seuls à arriver avec un tel format… Bref, voici le poster :

Poster Blacklight image

Poster à télécharger en version PDF (2,60 Mo)

Mise en place de Blacklight : comment ?

Nous avons choisi Blacklight comme interface publique pour notre catalogue. Voici comment nous avons procédé pour indexer les données de notre SIGB et comment nous allons intégrer d’autres données (revues et livres électroniques).

Pour faire fonctionner Blacklight en mode OPAC de nouvelle génération d’abord, il a fallu répondre à 3 questions :

  1. comment importer toutes les notices du SIGB dans l’index Solr ?
  2. comment obtenir les données d’exemplaires (donner la disponibilité) ?
  3. comment gérer les services et l’accès au dossier lecteur ?

Paramétrage de l’index Solr et procédure d’import

Blacklight n’est à proprement parler que l’interface qui permet de gérer l’affichage des données et les services au lecteur. Celui qui fait tout le boulot de traitement des données, c’est le moteur Solr. Il s’agit donc de lui faire avaler des données au format MARC ISO2709 afin qu’il puisse les indexer et les proposer sous forme de facettes, par exemple.

Indexation

La version standard de Blacklight proposée en téléchargement fournit une configuration de base opérationnelle. Mais comme c’est un produit développé aux États-Unis, le format par défaut est le MARC21. Donc, au minimum, pour une BU française, le travail consiste à remplacer les étiquettes de champs MARC21 par des étiquettes UNIMARC. Plutôt facile de mettre 200 là où on trouve 245 ! Mais quand on aborde les notions d’auteurs secondaires ou de titres complémentaires, on se rend compte que les deux formats ont une manière de voir les choses bien différente.

Pour obtenir des facettes intéressantes, il faut réaliser des mappings comme celui-ci, qui concerne le type de document :

# format mapping
# leader 06-07
map.format.aa = Article ou communication
map.format.ai = Ressource à mises à jour
map.format.ac = Recueil
map.format.am = Livre
map.format.as = Revue
map.format.lm = Ressource électronique
# leader 06
map.format.b = Texte
map.format.b = Manuscrit
map.format.c = Partition musicale
map.format.d = Partition musicale
map.format.e = Carte ou plan
map.format.f = Carte ou plan
map.format.g = Vidéo
map.format.i = Enregistrement sonore non musical
map.format.j = Enregistrement musical
map.format.k = Image
map.format.l = Support informatique
map.format.m = Ressource multimédia
# 007[0] when it doesn't clash with above
#map.format.h = Microforme
#map.format.q = Partition musicale
# none of the above
map.format = Indéterminé

Pour la facette « Sujets », nous avons utilisé les mots-clés RAMEAU en séparant les subdivisions : tout ce qu’on trouve en $a ou $x constitue une vedette « thème » tandis que les $y et $z sont distribués « région » et « période ».

Importation automatique

Comme on veut disposer de données bibliographiques à jour, il faut mettre en place deux procédures automatiques : une pour exporter la base catalographique du SIGB, une autre pour importer les données dans l’index Solr.

Nous avons demandé à notre fournisseur de SIGB (GFI) de créer une procédure d’export de toutes les notices au format ISO2709. Donc, tous les jours, l’ensemble du catalogue est mis à jour.

Ensuite, nous avons développé un script shell qui permet, toutes les nuits, d’effacer l’index et d’importer le fichier ISO généré par AbsysNET. Après avoir longtemps buté sur la question des notices supprimées dans le SIGB, nous avons en effet choisi d’effacer tout l’index avant import. Cela permet de ne pas avoir à gérer d’import différentiel (i.e. seulement les nouvelles notices) ni d’avoir à retraiter les notices modifiées ou supprimées. En effet, il nous a semblé impossible d’extraire des indicateurs fiables pour identifier les notices à traiter : pas de données dans le label de notice UNIMARC (position 5 concernant le statut de la notice).

Connexions pour les données d’exemplaire et du lecteur

AbsysNET comprend un serveur Z3950 qui permet d’interroger la base Oracle. C’est sur ce serveur que l’on s’appuie pour interroger en temps réel la base des exemplaires et connaître leur disponibilité.

La page Blacklight qui affiche la notice détaillée d’un document intègre une requête Z3950. Le serveur Z3950 d’AbsysNET renvoie une réponse XML qu’il suffit de mettre en forme à sa guise. Nous affichons donc les données d’exemplaires en tableau et indiquons par une icône rouge ou verte si le document est disponible, c’est-à-dire non emprunté, dans telle ou telle bibliothèque du réseau.

Notice détaillée avec disponibilité
Notice détaillée avec disponibilité des exemplaires

En ce qui concerne le dossier lecteur et les services associés, nous utilisons un connecteur développé par GFI. Connu sous le nom de zabnetarch (car conçu pour fonctionner avec les portails Archimed), ce connecteur permet d’interroger les données du fichier lecteur et d’interagir avec les services permis par les politiques de prêt.

Notice détaillée avec service
Notice détaillée avec bouton de communication

On peut ainsi intégrer des boutons pour demander un prêt (et générer l’impression d’un bulletin), réserver un exemplaire, prolonger un emprunt et fédérer toutes les informations dans une page « mon compte ».

Personnalisation de l’interface

Nous n’avons pas passé de temps sur la partie graphique du catalogue. Nous nous sommes contentés pour le moment d’utiliser le thème standard de Blacklight. La mise en forme nous a semblé bonne et nous n’avons pas fait de cet aspect du projet une priorité.

Nous avons travaillé essentiellement à la traduction de l’interface et des libellés, avec le souci de sortir du jargon bibliothéconomique. Ce n’est pas toujours facile d’y parvenir… Ce même souci de lisibilité nous a conduits à simplifier autant que possible la lecture des notices. Il a fallu faire des choix quant aux champs à afficher. La tension est forte entre la clarté de la présentation et l’exhaustivité de l’information donnée. Compte tenu des remarques des uns et des autres, ce travail se poursuit, d’ailleurs.

Pour illustrer le catalogue, nous avons utilisé les API Google Books qui permettent d’afficher les vignettes de couverture des ouvrages. Après quelques déboires dus à la requête sur l’ISBN (Google digère mal les tirets), nous avons traité les notices de manière à obtenir systématiquement un EAN. Le taux d’affichage des vignettes s’en est trouvé amélioré. Mais c’est encore insuffisant. Notre catalogue est peu illustré, nous le voyons bien avec notre page d’accueil qui recense les nouveautés.

Faute d’un taux de couverture suffisant, nous avons provisoirement affiché nos titres dans un cadre représentant un livre. Nous obtiendrions certainement de meilleurs résultats si on utilisait les API d’Amazon. Mais ici comme ailleurs, le débat reste vif entre les tenants de l’efficacité (plus de vignettes grâce aux API Amazon) et les défenseurs du petit commerce (non à la publicité pour le géant d’internet). Il faudra bientôt trancher.

Configuration de Solr

Dès les premiers tests, il est apparu que les résultats donnés par Solr ne nous convenaient pas. Il a fallu bien se documenter sur son fonctionnement avant d’en saisir les mécanismes et de pouvoir agir sur le calcul de pertinence.

Le plus difficile pour un bibliothécaire est de rompre avec la rigidité des sacro-saints opérateurs booléens. Certes, ils sont utilisés par le moteur mais pas seulement. C’est tout un système de pondération qui peut être paramétré. Le moteur est tendu vers un objectif : donner des résultats. Il n’aime donc pas répondre qu’il ne trouve rien.

Tout l’équilibre réside dans le fait de trouver les termes demandés tout en suggérant d’autres pistes. Solr donne la priorité aux premiers termes saisis et à leur place dans la notice. Le premier résultat de la liste sera toujours la notice qui contient tous les mots saisis dans son titre. Si ce n’est pas le cas, alors le moteur revoit ses exigences à la baisse : des mots placés dans le corps de la notice, moins de mots retrouvés, etc. Et puis si vraiment il n’y a aucune concordance possible, Solr fait des suggestions.

Là encore, les mécanismes sont complexes et tout est différent d’une langue à l’autre. Solr doit être paramétré pour le français afin qu’il puisse analyser les structures de mots pour corriger une faute d’orthographe ou étendre ses recherches à une famille de mots.

Nous avons beaucoup de connaissances à acquérir dans ce domaine pour optimiser le comportement du moteur.

Et maintenant ?

Notre catalogue est en place, sur un mode OPAC de nouvelle génération puisqu’il n’intègre que les ressources imprimées gérées par le SIGB. Il s’agit maintenant de travailler à l’indexation de nos ressources électroniques. Certaines sont déjà présentes : les livres électroniques pour lesquels nous disposons de fichier de notices au format ISO2709 sont indexés directement par import.

Mais le gros des ressources devra faire l’objet d’autres traitements. La base de connaissance SFX pourrait être importée au format CSV et fonctionnerait avec des liens open url. D’autres ressources dont les éditeurs proposent des échanges via le protocole OAI-PMH nécessiteront le développement d’un moissonneur.

Bref, nous avons du pain sur la planche !

Mise en place de Blacklight : pourquoi ?

Du nouveau site web au futur système de gestion, la mise en place de l’outil de recherche Blacklight s’inscrit dans une démarche d’amélioration des outils publics et professionnels des BU.

Le contexte local

2010 a constitué une année charnière pour notre catalogue :

  • les bibliothèques de l’agglomération se sont regroupées au sein du réseau communautaire et ont migré vers un système Carthame (Decalog)
  • les bibliothèques universitaires ont fait évoluer leur système vers une nouvelle version, Absysnet (GFI)
  • le portail commun Archimed n’avait plus de raison d’être

En 2011, l’ouverture du site web des BU a imposé la substitution du moteur de recherche Bookline d’Archimed par l’OPAC Absysnet et le retour à une recherche par type de document. On se retrouvait donc avec

  • 2 OPAC : collections imprimées BU et IUFM
  • une liste AZ : revues électroniques
  • des pages de liens : bases de données, livres électroniques, etc.
OPAC des BU
OPAC des BU
OPAC des IUFM
OPAC des IUFM

Une fois le site web BCU mis en place, on pouvait réfléchir au changement de catalogue.

Le contexte national

Au premier abord, on a pensé qu’il fallait tout changer, le catalogue comme le SIGB. Fort de la présence de son développeur web, le service bibnum envisageait de développer tous ses outils à partir de logiciels libres. Mais les évolutions du marché et des projets nationaux nous ont amenés à affiner notre stratégie.

D’une part, ce qui paraissait le plus urgent était la refonte du catalogue public. Impossible de faire passer notre OPAC au « contrôle technique » du moindre utilisateur. Après avoir assisté à la journée sur les discovery tools libres, Mathieu et moi n’avions plus de doutes. Il fallait trouver un remplaçant à ce bon vieil OPAC.

D’autre part, la réinformatisation ne s’imposait pas immédiatement. Koha, bien que séduisant parce que libre, n’offrait pas de bénéfice fonctionnel significatif. Et puis le projet de SGB mutualisé émergeant, il était sage d’attendre.

Bref, en ce début d’année 2012, nous avons décidé de privilégier le catalogue public de manière à offrir rapidement un meilleur outil de recherche aux usagers en fédérant nos différentes ressources et en facilitant la navigation. Nous avons pensé d’abord à l’outil Vufind, mais après la présentation de Blacklight à la journée Couperin, notre choix s’est porté sur ce dernier, dont SearchWorks est la réalisation la plus connue.

La prochaine fois, je vous expliquerai comment on a fait !

Blacklight : déploiement avec Ruby On Rails

Du serveur de développement au serveur de production, intéressons-nous maintenant aux grandes étapes de la mise en ligne de Blacklight. Nous avions commencé cette série par une prise en main de ce logiciel, puis par l’ajout des données d’exemplaire et enfin l’activation des services au lecteur. Les développeurs pourront compléter ce billet avec cette procédure détaillée.
Gaivota Bird oiseau Vogel uccello aves 鳥 птица – Sur Flickr par Rodrigo Sá – Licence CC BY 2.0

Déployer Blacklight offre plusieurs avantages. Tout d’abord, son serveur web proposé par défaut n’est pas assez robuste pour une mise en ligne. Nous devons donc en installer un nouveau à même d’assurer un nombre de visites élevé. Ce sera Apache avec le module Passenger.

Apache n’est plus à présenter dans le monde du développement web. Quant à Passenger, il s’agit d’un programme adossé à Apache pour rendre accessible en ligne une application faite avec Ruby On Rails. C’est une architecture complexe.

Si l’on récapitule :

  • Ruby est un langage de programmation.
  • Ruby on Rails est un framework, construit avec Ruby.
  • Blacklight est un moteur de recherche construit avec Ruby On Rails.
  • Apache et Passenger sont un serveur web mettant en ligne un logiciel fait avec Ruby On Rails, en l’occurrence : Blacklight !

Outils pour une maintenance aisée

Ces composants sont obligatoires pour rendre disponible notre nouveau catalogue. Nous utiliserons également Capistrano et Git pour faciliter les mises à jour du serveur de départ au serveur d’arrivée.
En revanche, ces deux derniers programmes ne sont pas nécessaires. Le déploiement peut se faire en copiant simplement les fichiers sur le serveur d’arrivée. Pourtant, même en étant un adepte féru de simplicité, leur relative complexité de prise en main est largement pondérée par ce qu’ils apportent.

Git pour garder un historique

Git, que l’on configure sur le serveur de développement, est un outil désormais prisé pour la gestion de versions. Il va nous permettre d’archiver toutes les étapes des développements ultérieurs. On pourra l’utiliser également pour rétablir une version antérieure de notre catalogue en cas de problèmes de mise à jour par exemple.

Déployer avec Capistrano

Capistrano est un logiciel écrit en Ruby permettant le déploiement automatisé d’une application d’une machine à une autre. Depuis le serveur de travail, il va se charger, avec très peu d’instructions de notre part, de déployer Blacklight en ligne, de passer d’une version à l’autre, ou de le mettre à jour aisément.

Il n’est pas simple dans cette nébuleuse d’utilitaires, modules, applications, serveurs de voir qui fait quoi et à quoi ça sert. Au final, on finit par l’oublier et ses avantages permettent de se concentrer plus profondément sur l’amélioration de Blacklight.

Voilà, notre catalogue est en ligne… Ah non me dit-on ! Il reste encore quelques menus détails à régler, mais bientôt Blacklight sortira en pleine lumière à la BCU…

Blacklight, troisième partie : les services au lecteur

La série avait commencé par une présentation introductive puis par ce billet consacré aux données d’exemplaires, voyons dès à présent le problème des services aux lecteurs : renouvellement, liste des prêts en cours, demande de communication et réservation. Comment intégrer ces nouvelles possibilités à Blacklight (BL) ?

Serveur en tenue - Par telomi sur Flickr - Licence CC BY-NC-ND 2.0
Serveur en tenue – Par telomi sur Flickr – Licence CC BY-NC-ND 2.0

Appelons cela un problème, car la solution n’est pas totalement dans les mains de BL qui ne fournit pas d’outils pour se connecter à un catalogue. Pour bénéficier de toutes ces fonctionnalités utiles aux lecteurs, il faut un préalable évident : le SIGB interrogé doit proposer une interface permettant d’interroger ses services par des applications externes comme BL. Ce n’est pas toujours le cas et, pour nous, Absysnet ne dispose pas, par défaut, de telles interfaces. Heureusement, nous avons sous la main un programme répondant au doux nom de « zabnetarch », ajouté il y a quelques années à Absysnet par le prestataire pour l’intégration à notre défunt et regretté portail Archimed.

Ce programme est interrogeable via une connexion réseau simple TCP/IP. Nous lui passons des ordres rudimentaires du type : « donne moi les informations du lecteur possédant tel identifiant » ou encore « réserve cet exemplaire pour tel lecteur », et « zabnetarch » répond en XML en fournissant les données souhaitées ou un code explicite indiquant l’échec ou la réussite de la commande.

Quelques lignes de code pour finir

Une fois pris en main le fonctionnement de cette « API» minimaliste, il ne reste plus qu’à l’intégrer à BL. Avec Ruby On Rails, le principe est simple, il suffit d’ajouter un fichier avec des instructions en ruby dans le répertoire « models » de l’application. Pour chaque service (renouvellement, réservation, etc.) on ajoute une fonction dédiée dans notre fichier qui pourra être appelée par le programme qui gère l’utilisateur authentifié, offrant ainsi de nouveaux usages à l’intention du lecteur.

Désormais, nous avons intégré les données d’exemplaires, les services aux lecteurs fonctionnent, notre nouvel OPAC est presque prêt. La prochaine étape sera de déployer Blacklight sur son serveur définitif. Au menu, il sera question de capistrano, git, passenger mais nous verrons cela dans un prochain billet…

Blacklight, deuxième partie : les données d’exemplaires

Quand l'eau se fait RUBIS -Par CHRIS230*** - Licence CC BY-NC-SA 2.0 - Sur Flickr
Quand l’eau se fait RUBIS -Par CHRIS230*** – Licence CC BY-NC-SA 2.0 – Sur Flickr

Suite de notre série de billets sur Blacklight, commencée par une présentation générale.
La question qui nous intéresse désormais est de savoir comment connecter Blacklight à un SIGB. À priori, les nouvelles sont peu réjouissantes car Blacklight ne connait ni le z3950, ni OAI-PMH, ni aucun autre protocole pour interroger directement un catalogue. On peut l’alimenter d’une seule manière par défaut : en lisant des données au format Marc en XML ou ISO2709. Cependant, on peut le faire communiquer avec un catalogue, via z3950 notamment, sans devoir reprogrammer entièrement un client dédié. Si z3950 ne peut pas servir a récupérer un catalogue entier il peut être utile en revanche pour récupérer des informations en direct, comme les données d’exemplaires.

Nous allons utiliser ruby-zoom, une bibliothèque écrite en ruby et interrogeant ZOOM, une API disponible pour développer des services autour de z3950 (ce composant existe aussi pour PHP et C).
Pour l’installer sur un serveur Debian disposant d’un environnement Ruby, cette commande suffit :

[sourcecode language=”bash” gutter=”false”]$ apt-get install yaz libyaz4-dev[/sourcecode]

Ensuite, dans le fichier Gemfile de BL, ajoutons la ligne :

[sourcecode language=”ruby” gutter=”false”]gem ‘zoom’, :git => ‘https://github.com/bricestacey/ruby-zoom.git'[/sourcecode]

puis, dans le répertoire de BL, exécutons la commande suivante pour terminer l’installation de ruby-zoom (il sera compilé puis installé dans ruby on rails) :

[sourcecode language=”ruby” gutter=”false”]$ bundle install[/sourcecode]

Quelques lignes de code pour finir

À cette étape, il faut mettre la main à la pâte et programmer en Ruby. Le plus simple est de créer un nouveau modèle dans le framework Ruby on rails de BL dédié à la connexion z3950. Voici un exemple utilisant les fonctionnalités de ZOOM.

[sourcecode language=”ruby”]

class Z3950
attr_reader :ip, :base, :port, :url
attr_accessor :keyword

def initialize(ip, base, port)
@ip = ip
@base = base
@port = port
@url = @ip + ‘:’ + @port + ‘/’ + @base
end

def search
resultats = ”
begin
ZOOM::Connection.open(url) do |conn|
rset = conn.search(@keyword)
rset.each_record do |record|
resultats += record.xml
end
end
resultats.force_encoding(“ISO-8859-1”).encode(“UTF-8″)
rescue
nil
end
end

def get_localisations(resultats=”)
doc = REXML::Document.new(resultats)
resultats = []
root = doc.root

if root.respond_to?(‘elements’)
#parcours des champs 998
root.elements.each(“datafield[@tag=’998′]”) do |element|
resultab = {}
#pour chaque element fils on récupère les informations d’exemplaire (localisation, salle, cote, empruntable ou non)
element.each do |field|
if field.respond_to?(‘elements’)
resultab[:localisation] = field.elements[“[@code=’b’]”].text if !field.elements[“[@code=’b’]”].nil?
resultab[:salle] = field.elements[“[@code=’c’]”].text if !field.elements[“[@code=’c’]”].nil?
resultab[:cote] = field.elements[“[@code=’e’]”].text if !field.elements[“[@code=’e’]”].nil?
if !field.elements[“[@code=’h’]”].nil?
if field.elements[“[@code=’h’]”].text ==  ‘ ‘
resultab[:empruntable] = nil
else
resultab[:empruntable] = field.elements[“[@code=’h’]”].text
end
end
end
end
resultats << resultab
end
end
resultats
end
end

[/sourcecode]

La méthode search définie ici s’occupe de la connexion au serveur z3950 et la méthode get_localisations récupère et traite la réponse XML du serveur pour obtenir les données d’exemplaire.
Il reste à ajouter quelques lignes de code dans le fichier catalog_controller.rb ou  l’on utilise les deux méthodes précédemment créées, puis dans le fichier show.html.erb pour afficher les résultats obtenus. Voici le résultat sur notre serveur de test, suivi des quelques lignes de code adéquates dans la vue et le contrôleur.

Affichage des données d’exemplaire dans BL

Le code à ajouter dans le fichier catalog_controller.rb :

[sourcecode language=”ruby”]
# surcharge de la méthode show du module catalog de blacklight
def show
@response, @document = get_solr_response_for_doc_id
connexion_z3950 = Z3950.new(‘X.X.X.X’, ‘base’, ‘port’)
connexion_z3950.keyword = @document.id
resultats = connexion_z3950.search
@localisations = connexion_z3950.get_localisations(resultats)

respond_to do |format|
format.html {setup_next_and_previous_documents}

# Add all dynamically added (such as by document extensions)
# export formats.
@document.export_formats.each_key do | format_name |
# It’s important that the argument to send be a symbol;
# if it’s a string, it makes Rails unhappy for unclear reasons.
format.send(format_name.to_sym) { render :text => @document.export_as(format_name), :layout => false }
end

end
end
[/sourcecode]

Et dans la vue (le fichier show.html.erb)

[sourcecode language=”html”]<p>
<table>
<tr>
<td>Disponibilité</td>
<td>Localisation</td>
<td>Salle</td>
<td>Cote</td>
</tr>
<% @localisations.each do |loc| %>
<tr>
<td><%= render_bouton_empruntable loc[:empruntable] %></td>
<td><%= loc[:localisation]%></td>
<td><%= loc[:salle]%></td>
<td><%= loc[:cote]%></td>
</tr>
<% end %>
</table>
</p>

[/sourcecode]

Présentation de Blacklight

Total solar eclipse solaire 1999 – Luc Latour sur Flickr – licence CC BY-SA 2.0
Total solar eclipse solaire 1999 – Luc Latour sur Flickr – licence CC BY-SA 2.0 

À la recherche d’une nouvelle interface de consultation de notre catalogue, nous testons actuellement un logiciel développé par plusieurs universités américaines : Blacklight (BL). Ce logiciel présenté lors d’une journée d’étude Couperin sur les discovery tools libres propose via une interface sobre et claire, une recherche par facette hautement configurable. Plusieurs exemples sont proposés sur le site du projet. Voyons son fonctionnement plus en détail.

À proprement parler, ce n’est pas BL qui fournit une recherche par facette mais un de ces composants : Solr, le moteur de la fondation Apache. BL est configuré pour l’interroger au mieux et avec des formats de données connus des bibliothèques. En l’occurrence, BL a été développé pour MARC mais on peut l’adapter pour d’autres formats. Par défaut, il propose différents champs : (titre, sous-titre, auteur, date de publication, sujets, format, localisation, etc.) que l’on retrouve dans les facettes sur la gauche (copie d’écran ci-dessous), ou en coulisses dans l’index de Solr. On peut bien sûr les modifier, en enlever ou en ajouter d’autres.

Blacklight à l'universite de Stanford
Blacklight à l’universite de Stanford

À ce jour, le seul moyen d’alimenter Blacklight fonctionne par Solr. Ce dernier dispose d’un certains nombres de connecteurs pour l’alimenter depuis une base de données, un fichier texte ou des notices en MARC via le programme Solrmarc, intégré par défaut à BL. Un fichier de configuration fait la correspondance entre les champs de BL et ceux des notices. À l’origine, ce mapping est prêt pour le MARC mais on peut l’adapter pour l’UNIMARC. La tâche est a priori aisée pour une correspondance directe de champs mais elle se complique quand il s’agit de les apparier, d’enlever une ponctuation inappropriée, de mettre une phrase en minuscule, etc. Dans ce cas, il est nécessaire de faire appel à des fonctions de traitement existantes ou à redéfinir en JAVA.

Une notice de Blacklight
Une notice de Blacklight

À l’usage, l’import de notices se fait très rapidement même pour un grand nombre d’enregistrements et BL est presque utilisable en l’état. On pourra configurer l’affichage des champs des notices ou des facettes à loisir dans un simple fichier de configuration. Cependant, si on opte pour l’UNIMARC, il reste un problème d’encodage pour les différents formats d’export de notice proposé par BL (en copie d’écran jointe). L’adaptation est délicate car elle nécessite de redéfinir des fonctions du cœur du programme en ruby.

Pour résumer, BL est relativement facile à prendre en main, à installer et à alimenter même quand on ne connait pas bien le fonctionnement de Ruby On Rails, le framework sur lequel il s’appuie. La tâche se complique pour le passer en UNIMARC ou pour des fonctionnalités plus personnalisées comme la connexion à un SIGB. Mais cela fera l’objet d’autres billets dans l’alambic…

Rechercher dans OpenEdition Search

Vous allez être redirigé vers OpenEdition Search