Le SGBM et la BCU : « Techpoint et Checkpoint »

La situation actuelle du système

Depuis les années 2010, nous nous sommes investis dans une démarche de modernisation de nos outils documentaires, à l’instar de nombreuses bibliothèques universitaires, soucieuses d’offrir de meilleurs services à leurs usagers.

Nous avons commencé en 2011 par réaliser notre propre site web (avec Drupal) puis, en 2012, notre catalogue (avec Blacklight). Les deux projets ont bénéficié d’abord à nos publics. Cependant, notre système d’information tout entier méritait d’être revu et simplifié. Le projet SGBM arrivait donc à point nommé. Voici en effet la liste de nos outils actuels :

OUTILS CONTENU FORMAT DE DONNÉES
Step + Star Thèses électroniques Métadonnées XML TEF
Sudoc (CBS + WinIBW) Tout imprimé ou électronique Notices UNIMARC
 Le contenu est versé dans :
le SIGB (Absysnet)
Tout imprimé
Thèses tout support
Supports numériques
Collections électroniques acquises et licences nationales
Notices UNIMARC
S’y ajoute ensuite le contenu des deux outils suivants :
1. Résolveur de lien (SFX) Revues électroniques abonn. Métadonnées XML DC
2. Fichiers éditeurs Livres électroniques abonn. Notices UNIMARC
Et le tout est rendu consultable via :
Catalogue (Blacklight) Tout imprimé ou électronique UNIMARC

Nous utilisons différents outils, en fonction du type de document à traiter. Et malheureusement, tous ces outils ne sont pas maniés par tous les bibliothécaires. L’une de nos principales motivations à intégrer le projet SGBM était justement de réintégrer la gestion des ressources électroniques dans le travail quotidien de l’ensemble des collègues.

Du point de vue technique, la réinformatisation s’imposait. Pas de modernisation de nos services sans un nouveau système de gestion performant, alliant robustesse et respect des standards (à la fois de la bibliothéconomie et du web). Nous avions besoin d’un système capable de rendre tous les services attendus comme d’interagir avec des applications développées dans l’établissement, tout en conservant un lien très fort avec le réseau Sudoc.

Le SGBM correspond bien à nos besoins. Tout en participant au projet, nous avons lancé dès 2013 des chantiers pour préparer la migration. Certains concernent spécifiquement les périodiques, afin de mettre à jour tous nos états de collection. D’autres impliquent des corrections de données très importantes tandis que les derniers consistent en des exemplarisations automatiques dans le Sudoc (des corpus entiers ne sont pas encore signalés dans le catalogue national). C’est un travail de longue haleine, mais qui en vaut la peine, car, à ce prix, nous pourrons « migrer » correctement nos données dans le futur SGBM.

Une question de rythmes

Villard de Honnecourt, "Perpetuum mobile" (Image du domaine public)
Villard de Honnecourt, « Perpetuum mobile » (Image du domaine public)

Une fois le constat dressé, il importait d’agir et le projet SGBM nous offrait l’occasion et de nous insérer dans une réflexion globale et de projeter le site universitaire auvergnat dans un cadre d’action répondant à nos attentes.

Comme souvent, le dossier présentait deux versants : un versant interne et un versant externe, l’ubac et l’adret en somme (car, bien sûr, les Auvergnats ont la manie de vouloir tutoyer les sommets !).

Du point de vue interne, la réflexion s’est organisée rapidement, grâce à la désignation d’une Chef de projet, à l’intégration du dossier dans la stratégie globale (Lire ici http://alambic.hypotheses.org/4163 et là, http://alambic.hypotheses.org/5534) et à la diffusion en interne des mutations qui allaient en découler (Journée des personnels 2014, avec la tenue d’un atelier spécifique). Des réunions rassemblent depuis plusieurs mois la Chef de projet, la Responsable des données bibliographiques et deux professionnels BIBAS, pour planifier les chantiers. D’ores et déjà, il est acté qu’un professionnel BIBAS viendra épauler la Chef de projet en septembre 2015, tant ce dossier est capital et qu’un réseau de correspondants, dans les différentes BU, sera en soutien.

À la jonction de l’interne et de l’externe, se trouve la communication interne au site auvergnat, à destination des décideurs et cadres universitaires (Présidents, Vice-présidents, DGS, DSI, Service juridique, enseignants-chercheurs). Chaque fois que ce fut possible, un bilan d’étape du projet SGBM fut exposé, dans le cadre du Conseil de la documentation et du CODEX1. Ainsi, le 13 mai dernier, le dossier fut analysé pendant près d’une heure trente dans cette dernière instance, à l’aune des besoins présents et à venir. Un accord de principe prévaut maintenant pour la suite, avec pour seule réserve majeure la question des coûts, non encore définis, mais qui pourront l’être après la remise de l’étude de l’ADBU, annoncée en septembre 2015.

Dans les montagnes auvergnates, l’eau surgit partout, fraîche d’ordinaire ou brûlante parfois (les « chaudes aigues »). Elle va d’un versant à l’autre. Métaphoriquement, au sens premier comme au sens figuré du terme2, nous pouvons avancer que les « couzes »3 de la réflexion interne permettent de « charrier » des éléments d’appréciation en externe. C’est ainsi que nous avons répondu à l’étude d’impact de l’ABES de mars 2013, par un document de six pages, qui tentait de répondre à la volonté, exprimée par le Directeur de l’ABES, d’appropriation du projet par les partenaires. Nous y prenions des positions discutables, sans doute, mais qui ont été rendues publiques par un envoi sur la liste de diffusion de l’ADBU. Nous avons également souhaité faire remonter d’emblée le sujet important à nos yeux de l’accessibilité, au regard des publics en position de handicap. En outre, nous avons diffusé le projet à l’extérieur de la sphère « enseignement supérieur et recherche », ce qui fut l’occasion de constater que le réseau CANOPE avait entrepris un projet similaire (projet R@cines) et de proposer à l’ABES, par conséquent, une possible interopérabilité entre SGBM et R@cines, pour mieux desservir les ESPE. Enfin, il nous semble que le projet SGBM mérite une communication large, à même d’en montrer toute la portée en-dehors du cénacle des spécialistes de l’Infodoc : l’ABES s’y emploie activement cette année, en mettant à la disposition des sites pilotes des documents réemployables pour partie. Nous pourrions aller jusqu’à donner un nom au projet qui soit moins « métier ».

Qu’en espère-t-on ?

Qu’est-ce qu’un site universitaire comme celui de Clermont-Auvergne peut espérer du projet SGBM à l’horizon 2017 ?

  • Évidemment, une modernisation technique, facilitant l’insertion de la BCU dans les projets de site (comme le projet de carte universitaire unique pour l’ensemble des services), ou dans des projets internes (bascule progressive en RFID)
  • Le bénéfice d’une expertise partagée, avec des retombées offertes en termes de services (création d’API…), en termes de qualité des données et de leur gestion (base de connaissances, Hub de métadonnées les Québécois diraient peut-être « pôle », les Auvergnats « puy », qui vient de podium, rappelons-le et évoque chez nous une relation ombilicale).
  • Un point d’accès unique pour l’ensemble des collections du site Clermont-Auvergne (par collections, entendons les collections produites ou acquises par le site, en matière de pédagogie, de recherche et de diffusion de la culture scientifique, quels que soient les supports et les formats)
  • Un levier interne pour la diffusion des nouveaux formats au sein des personnels de bibliothèque
  • Un appui pour promouvoir l’Accès universel (l’Open access)
  • Une préparation à l’avènement à terme d’un espace européen de la documentation.

Ces espérances sont gagées sur le maintien d’une Agence bibliographique forte et jouant à plein son rôle de coordinateur, car le site universitaire Clermont-Auvergne ne pourrait seul relever ces défis, fût-il en relation avec d’autres universités.

F. Boyer, Directeur de la BCU, et R. Bussemey, Chef de projet SGBM à la BCU.

1. Bureau du Conseil de la documentation, regroupant enseignants-chercheurs désignés par les Présidents et les conservateurs Responsables de service.

2. La métaphore, étymologiquement, renvoie à l’idée de transport.

3. Une couze est un ruisseau de montagne en Auvergne.

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 !

De nouvelles politiques de prêt pour la rentrée universitaire

L’ensemble des bibliothèques universitaires va adopter de nouvelles politiques de prêt en septembre prochain afin d’améliorer le service rendu aux usagers. Les conditions de prêt seront les mêmes dans toutes les bibliothèques : nombre de documents illimité, prolongation, réservation, et possibilité de faire tout cela en ligne.

Cette réforme répond à deux objectifs principaux : simplifier le dispositif pour le rendre plus compréhensible par les lecteurs et rehausser la qualité de service pour la rendre plus conforme aux attentes des usagers.

Des politiques de prêt simplifiées et homogènes

L’an dernier, nous avions évoqué dans un billet le manque de clarté de nos services. Souffrant de l’éclatement géographique et thématique des bibliothèques, notre réseau ne bénéficiait pas d’une stratégie globale en matière de prêt et de services associés. Chaque bibliothèque pratiquait sa politique. Cela contrevenait au principe de la carte unique et nuisait au confort des lecteurs.

Carte de lecteur BCU

Partant de cette analyse, nous avons voulu proposer des solutions visant à clarifier notre offre de services tout en satisfaisant aux contraintes spécifiques des bibliothèques. Un groupe de dix collègues représentant différentes B.U. a alors travaillé de mars à juin 2012 pour élaborer une offre commune, validée d’abord par les bibliothèques universitaires et intégrées. La discussion est actuellement en cours avec les bibliothèques associées, qui partagent notre système de gestion (SIGB).

La mesure principale concerne le prêt standard. Il est caractérisé par :

  • une durée de 14 jours (étudiants et lecteurs autorisés) ou de 28 jours (doctorants, enseignants-chercheurs et personnels de l’université) ;
  • une prolongation d’autant de jours que le prêt initial ;
  • la réservation possible d’un document déjà emprunté.

Une douzaine de bibliothèques vont donc adopter dès septembre 2013 les nouvelles politiques de prêt. Certaines se sont déjà lancées et nous aident à peaufiner le dispositif. Nous avons par exemple constaté que le cas des étudiants de master pouvait être délicat. En effet, ces étudiants ont, selon les disciplines, un comportement documentaire conforme à celui des chercheurs ou à celui des étudiants de licence. Cela n’est pas sans conséquence sur l’usage des collections et la durée de prêt.

Une offre de service améliorée

La possibilité de prolonger ou de réserver un document existe déjà dans le réseau, mais elle sera étendue à l’ensemble des B.U. C’est une demande récurrente des lecteurs qui devrait être ainsi satisfaite.

Nous avons aussi tenté de répondre aux attentes des doctorants et des enseignants-chercheurs en leur proposant, sur demande, un prêt de trois mois renouvelable. Certes, de nombreux collègues, notamment dans les bibliothèques de proximité, pratiquaient ces prêts de longue durée depuis longtemps. Mais cette manière de faire pouvait apparaître bien souvent comme une faveur accordée à quelques privilégiés. Proposé comme un service normal, le prêt de longue durée devrait s’avérer plus efficace.

Nous avons enfin voulu assouplir le régime de sanctions. Nous avons décidé de limiter la durée des suspensions de prêt en la plafonnant à 28 jours, quel que soit le nombre de documents rendus en retard.

En fin de compte, nous espérons, grâce à ces nouvelles politiques de prêt, améliorer la qualité de notre service et l’expérience de nos usagers, et qui sait, limiter la baisse de l’activité de prêt dans nos bibliothèques. Les chiffres de 2014 nous diront si nous avons eu raison.

A lire :
Luc Jodoin : Des politiques de prêt pour les usagers, Espace B le blog des bibliothèques de la ville de Montréal, le 21 janvier 2011.
Thomas Jacqueau : Toutes sortes de types, KohaBulac, le 10 octobre 2009.

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…

Que fait-on de notre catalogue ?

Je profite de mon stage à l’ENSSIB sur l’évolution des catalogues pour réfléchir à voix haute sur ce qu’on peut faire maintenant pour améliorer notre outil. L’objectif étant toujours de satisfaire les besoins de nos publics, notre catalogue doit s’inscrire dans un nouvel écosystème, celui du web de données et des pratiques qui vont avec. Les grands établissements et agences sont aux avant-postes en la matière et nous montrent le chemin à suivre. Toute la difficulté, me semble-t-il, réside pour les autres établissements en la définition d’une stratégie de positionnement entre l’intégration nécessaire dans un réseau de plus en plus vaste et la valorisation d’atouts locaux ou spécifiques.

Le catalogue du jardinier savoyard (1787), Le bibliomane moderne

Un stage passionnant

Je voudrais tout d’abord féliciter Françoise Leresche, qui conçoit le stage, pour la qualité de ses cours et de ses choix en ce qui concerne les autres intervenants. Nous avons bénéficié de leurs lumières tant sur le plan technique que bibliothéconomique. Je vous invite donc à assister à ce stage l’année prochaine, puisqu’il sera reconduit.

Je reste convaincue que le principal outil de médiation de la bibliothèque est son catalogue. Car enfin, pourquoi constituer un catalogue, sinon pour faire connaître au public l’étendue de nos collections ? Aux questions : possédez-vous tel document ? Où ? Nos catalogues actuels répondent très bien. Hérités du modèle de description sur fiches des années 1960, ils sont constitués de notices de publication, et indiquent les localisations. Mais cela reste bien souvent insatisfaisant du point de vue de la recherche par matière et des rapports qu’entretiennent les publications entre elles. Aussi la tendance est-elle de revenir aux exigences premières des catalogues : décrire une oeuvre et donner la possibilité de sélectionner parmi plusieurs documents. C’est l’ambition des FRBR, appuyés par les formats RDF et RDA.

La normalisation et la standardisation en marche

Les évolutions en cours sont suivies de près, voire élaborées par la BnF et l’ABES, entre autres. En participant aux travaux de normalisation de différents groupes et en proposant des outils toujours plus perfectionnés, ces établissements nous montrent le chemin à suivre. Le projet data.bnf.fr est un très bel exemple de ce que permettent des données bien structurées en matière de recherche documentaire. La plateforme Isidore en est un autre.

Néanmoins, on mesure l’écart qui existe entre ces institutions et nous, établissements universitaires lambda, en matière de recherche et développement. Nous sommes forcément à la traîne, à la fois parce que nous attendons après leurs préconisations et parce que nous n’avons pas la même capacité à faire évoluer nos propres outils. En l’état actuel de nos systèmes, que pouvons-nous faire à part attendre que la standardisation oblige nos fournisseurs à prendre en compte de nouveaux formats ? On essaie déjà de rattraper notre retard en mettant au point des catalogues qui ne soient plus des OPACs…

Alors, qu’est-ce qu’on fait ?

On attend.

Mais on participe à la définition de nos besoins informatiques au sein du comité technique SGBM de l’ABES. C’est l’une des manières possibles de faire évoluer nos outils auprès de nos fournisseurs. On mesure d’ailleurs combien il est difficile pour les établissements de renoncer à leur souveraineté dans ce domaine. Mais puisque nous travaillons tous au sein du réseau Sudoc, à quoi bon conserver un outil de gestion propre, sinon pour conserver la maîtrise (toute relative d’ailleurs) de sa personnalisation ?

On réfléchit à notre stratégie de services, à notre place sur le web à côté des « gros » catalogues et réservoirs de données. Si l’on ne peut pas offrir l’exhaustivité d’un catalogue international, national ou collectif, quelle peut être notre plus-value ? Répondre aux besoins d’un public essentiellement local ? Valoriser des collections spécifiques ? Alors oui, proposer un catalogue local de qualité, c’est encore montrer à notre public qu’on assure le confort de sa recherche. C’est dans cette perspective que nous développons un outil de découverte à la BCU.

On réfléchit aussi aux partenariats possibles et aux services mutuellement rendus. Ainsi, certains projets de numérisation peuvent alimenter des plateformes plus ambitieuses comme Gallica, qui, juste retour des choses, augmentent la visibilité de nos collections et contribuent à les faire vivre.

On prépare les équipes. Les nouveaux modèles de conception des catalogues, les nouveaux formats de catalogage (ou traitement des données) vont directement modifier le travail des collègues, notamment les BAS. Il va falloir miser sur la formation continue pour assurer une bonne transition vers les nouvelle fonctions. Technophiles et catalogueurs à la plume d’oie devraient enfin se rejoindre sur les questions de contrôle qualité des données !

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…

Série de l’été : un succès, un regret, un projet (4)

Je vous avais parlé il y a quelque temps de l’homogénéisation nécessaire de notre politique de prêt. Et bien, à ma grande satisfaction, les bibliothèques ont trouvé un terrain d’entente et nous serons à même de proposer une seule et unique offre de service sur tous les sites à la rentrée 2013. Le délai de mise en œuvre est en effet trop court pour septembre, étant donné le paramétrage et les aménagements des locaux nécessaires à certains endroits (notamment pour la gestion des réservations) ainsi que la maquette des brochures informatives, déjà bouclée.

En revanche, le dossier « transfert initial » n’a pas vraiment avancé cette année. En effet, nos collections ne sont encore pas toutes signalées dans le Sudoc et nous tentons d’y voir clair parmi les notices relevant de rétroconversions successives (avec lien ou pas entre Sudoc et base locale) et celles relevant du seul catalogage local. Nous n’avons réglé cette année qu’une étape de mise à jour de notre base suite aux exemplarisations automatiques de 2010 (d’après ISBN). Il reste du pain sur la planche pour exemplariser nos notices sans ISBN…

Le projet qui va m’occuper dans les mois à venir consiste à mettre en service et administrer un nouveau catalogue : un versant public (Blacklight) et un versant professionnel. Concernant le versant professionnel, je vais participer aux réunions du comité technique sur le SGB mutualisé piloté par l’ABES, mais aussi envisager l’adoption de Koha. Beaucoup de paramétrages en perspective !

Mais pour l’heure, place aux vacances !

Moser_010
Par San Diego Air & Space Museum Archives, sur Flickr

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…

De l’utilisation des ressources documentaires : statistiques 2011 du site web

L’analyse statistique du site web et de l’OPAC montre que l’intérêt principal de notre site réside dans la consultation du catalogue et des ressources électroniques, notamment via les listes de revues et de bases de données.

Des clics et des vues

L’architecture de notre site étant ainsi faite, il convient de tenir compte à la fois des pages visitées (vues) et des liens sortants (clics). En effet, les ressources électroniques sont d’abord présentées dans des pages internes (Drupal) avant de sortir du site via le reverse-proxy (EZproxy), alors que le catalogue est toujours accessible hors du site (OPAC AbsysNET sur serveur dédié).

Nom Vues uniques Vues
ressources-numeriques/bases-de-donnees 31027 64924
ressources-numeriques/livres-numeriques 5049 9282
ressources-numeriques/annales-dexamen 3080 4171
ressources-numeriques/accueil 2580 4049
ressources-numeriques/videos-scientifiques 1023 1355
Nom Clics uniques Clics
catalogue.clermont-universite.fr (OPAC) 35287 61757
sicd.clermont-universite.fr (via proxy) 24309 40980
liste az des revues (mode hébergé) 9826 14527
sicd.clermont-universite.fr/ (accueil proxy) 6066 8687

Si la rubrique Ressources numériques du site est la plus fréquentée (42759 vues uniques au total), on constate que l’accès au catalogue constitue l’activité la plus importante (35287 clics), juste devant la liste permettant d’accéder aux bases de données (31027 vues uniques).

Evidemment, on ne saurait réduire l’usage des ressources électroniques à ces chiffres, puisque la consultation de ressources peut se faire sans passer par notre site web. Mais l’objet ici est de regarder à quoi sert le site web lui-même. Que fait-on sur ce site ? Que vient-on y chercher ?

1. le catalogue

Pour l’année 2011, nous avons enregistré plus de 789 000 requêtes. La majorité de ces recherches (41%) ont été menées depuis les postes informatiques des bibliothèques (OPAC, postes internet, postes professionnels). Ce chiffre n’a cessé de diminuer au fil de l’année ; preuve que le catalogue est de plus en plus consulté depuis l’extérieur de la bibliothèque, notamment depuis les UFR, et que ce mode de consultation est désormais majoritaire. Les utilisateurs préparent leur visite à la BU, en particulier ceux qui peuvent demander la communication de leur document à l’avance.

Sans analyser précisément les requêtes, on peut noter qu’il subsiste un taux élevé de recherches infructueuses. En effet, près de 35% des requêtes donnent zéro résultat. Si notre catalogue comporte forcément des lacunes, un taux pareil ne peut s’expliquer que par un nombre considérable de requêtes mal posées. Il est grand temps d’adopter un outil capable d’aider à la recherche !

2. l’accès (authentifié) aux bases documentaires

Notre site web semble être un point d’accès privilégié aux différentes ressources numériques. La page la plus consultée (bases-de-données) est celle qui présente l’ensemble des ressources classées par ordre alphabétique, et qui permet d’y accéder en mode authentifié grâce à un lien proxifié. Cela explique donc aussi que la deuxième place du classement des liens sortants soit occupée par notre proxy (sicd.clermont-universite.fr).

La grande majorité des accès au proxy représente un passage entre la liste alphabétique sur notre site et les ressources sur le site des éditeurs. Dans ce cas, le proxy agit comme serveur d’authentification, de façon transparente pour l’usager. Mais, dans tout de même un quart des cas (6066 clics sur 24309), les usagers utilisent la page d’accueil du proxy comme portail d’accès aux ressources. Cette page d’accueil est rendue visible grâce au lien accès distant figurant dans le bandeau supérieur droit de notre site.

3. l’accès (authentifié) aux revues et articles

Dernière grande rubrique de notre site, la liste alphabétique des revues électroniques remporte un vif succès. Hébergée chez notre fournisseur, cette liste constitue le seul moyen d’accéder facilement et de manière authentifiée aux revues et aux articles électroniques.

Conclusion

Il est bien difficile de donner un sens à la valeur brute de ces chiffres. Est-ce satisfaisant ou non ? Nous ne pouvons procéder que par comparaison. Nous verrons donc comment les choses évoluent les années suivantes. Mais ce billet peut aussi permettre de comparer avec les chiffres d’autres établissements. Je précise à cette fin que la BCU dessert environ 35000 étudiants, issus des deux universités et de trois écoles.