Bibli.othequ.es : deux mois plus tard
J’ai souvenir que Silvère avait signalé, lors de la publication de son billet « Quand un informaticien de 25 ans invente un SUDOC des bibliothèques publiques » (le 24 avril 2009), qu’il avait accru considérablement le nombre de consultations quotidiennes moyen de Bibliobsession.
Comme je voulais bénéficier moi aussi de la manne statistique que représentait la nouvelle, je m’étais fendu d’un billet sous un angle différent : comment rendre visibles, compréhensibles et aisément manipulables ce genre de services, que nous avons parfois tendance à faire proliférer ?
Concernant spécifiquement ce projet monté par Damiano Albani, et rendant un service prodigieux à nos lecteurs, comment faire en sorte qu’il soit réellement utilisé, sachant qu’il nécessitait de leur part une série de manipulations ?
Pour poser la question différemment : comment réduire au maximum pour ses lecteurs la complexité et le nombre des manipulations pour bénéficier de la fonction développée par Damiano ?
Avant de répondre à cette question, j’avais dans l’idée de comparer d’abord la liste des bibliothèques que Damiano avait intégré à son outil — avec les sites web des bibliothèques, pour décompter celles qui mentionnaient ledit outil. Le dernier billet de Bertrand Calenge m’incite à rebondir plus tôt que prévu (toujours dans le même esprit « parasite » consistant à bénéficier des centres d’intérêts du jour… — soit dit en passant, je n’ai malheureusement rien réussi à trouver sur Michaël Jackson, pas même un pipe, sinon vous y auriez eu droit aussi ;-)).
Un service en 5 étapes
De toute façon, un rapide sondage sur Yahoo Site Explorer (pages pointant vers le site Bibli.othequ.es) fait voir clairement qu’aucune bibliothèque n’a exploité l’information à destination de ses lecteurs. Plusieurs collègues (dont Bertrand Calenge, d’ailleurs), considèrent que c’est finalement un outil bien pratique pour les professionnels des bibliothèques, mais qu’il est difficilement envisageable de le présenter aux lecteurs. En effet celui-ci doit :
- Utiliser Firefox
- Installer Greasemonkey
- Aller sur bibli.othequ.es
- Sélectionner sa ou ses bibliothèques sur la carte
- Télécharger le script
On estime assez vite que cette série d’étapes est éliminatoire. Du reste, je suis d’accord.
Mais il me semble qu’il y a eu une incompréhension sur l’outil, due notamment à la manière dont Damiano l’a présenté lui-même. En effet le site met en avant le côté Catalogue collectif. Silvère a fait de même (en évoquant un Sudoc des bibliothèques publiques). C’est effectivement un aspect extrêmement intéressant de l’outil.
Mais une bibliothèque n’aurait-elle pas tout à gagner à oublier cet aspect-là, pour se concentrer sur la dissémination de ses collections (et seulement des siennes) ?
Un service en 2 étapes
Voici comment je vois les choses :
- L’internaute cherche avant tout des ouvrages en cherchant sur Google. Donc il tombe sur Amazon.
- Une fois sur Amazon, il faut lui fournir une information sur la disponibilité du titre dans sa (et non ses) bibliothèque.
Hypothèse : vous êtes bibliothécaire et vous voulez mettre en avant ce service pour votre bibliothèque :
- Après avoir installé Firefox et l’extension GreaseMonkey, vous allez sur bibli.othequ.es
- Vous sélectionnez votre bibliothèque (et pas une autre, et pas plusieurs)
- Vous téléchargez ainsi un script qui va se « ranger » dans l’extension GreaseMonkey
- Vous avez la possibilité de récupérer le texte du script en question (ouvrable avec WordPad). Il est spécifique à la sélection que vous avez faite. Cf. vidéo pour récupérer un script téléchargé dans GreaseMonkey.
- Vous « enregistrez sous » le texte en question, vous le déposez sur un espace accessible en ligne, et vous le proposez au téléchargement sur une page de votre site web (appelez le fichier bibliotheques.user.js – .js étant l’extension des fichiers JavaScript).
<update>J’ai fait une erreur à l’étape 5, dans mon interprétation du fonctionnement du script. Cf. discussion en commentaires. J’aurais dû me renseigner plus avant, mais je n’ai pas envisagé que le script ne contenait pas la sélection des bibliothèques. C’est idiot de ma part et ça fausse l’ensemble du raisonnement — sauf si l’outil évolue, naturellement 🙂</update>
Ainsi, sur la page en question, vous pouvez titrer : Retrouvez nos collections en surfant librement sur Internet ou quelque chose comme ça, et limiter la démarche à deux étapes (pour ceux qui ont Firefox)
- Télécharger GreaseMonkey (pour éviter à vos utilisateurs de passer par le site Add-ons de Mozilla, pointez directement sur le fichier d’extention https://addons.mozilla.org/fr/firefox/downloads/latest/748/addon-748-latest.xpi). Vous voyez dans le nom du fichier qu’il s’agira toujours de la dernière version.
- Télécharger le script que vous avez mis sur votre serveur
Et oubliez le passage par bibli.othequ.es et la sélection sur la carte.
Un service en 1 étape ?
Je ne sais pas si vous vous souvenez : je m’étais efforcé d’expliquer clairement (mais pas « simplement », j’en ai conscience) comment proposer à vos lecteurs une extension OpenURL Referrer préparamétrée. Cela dans le but d’éviter de se lancer dans des explications sur le mot « openurl » et le détail du paramétrage de l’extension (version 0.1 ou 1.0 ? etc.)
J’ai dans l’idée qu’il doit être possible de proposer sur son site l’extension GreaseMonkey contenant déjà le script de votre bibliothèque.
Vous n’auriez plus qu’à dire à vos lecteurs : cliquez ici, et vous n’aurez plus jamais besoin d’aller sur notre catalogue, vous pourrez retrouver nos collections partout ailleurs !
(c’est un peu à cela que je pensais quand, dans mon uchronie version « Dissémination » (piste 3), je mentionnais les livres des bibliothèques dans tous les rayons Fnac.)
Donc oui, comme le dit Bertrand Calenge, tous les acquéreurs (du moins ceux dont les catalogues ont déjà été paramétrés par Damiano) devraient doivent installer cet outil. Mais je suis sûr qu’on peut encore trouver une solution satisfaisante pour en faire bénéficier aussi nos lecteurs. Parce qu’après tout, ce n’est pas à nous que nos propres Opac font le plus peur ! 😉
Bibliothèques [reloaded] 
Questionné sur le sujet, Damiano explique que le script est standard et que la sélection de la bibliothèque sur son site génère un simple cookie que va repérer le script. La question paraît donc plus complexe: comment fusionner le script et le cookie?
Pour poursuivre cette démarche, nous proposons depuis cette semaine à Metz un firefox pré-paramétré, intégrant le script de Damiano… mais qui ne fonctionne pas pour le moment car il ne parvient pas à repérer son cookie. Pour le coup on serait dans le « o clic »… Je suis assez frustré de ne pas être arrivé (pour l’instant) à ce que la dissémination soit pré-installée sur le navigateur de l’usager sans aucune intervention de sa part…
C’est « intimidant » cette mise en production de mon service 🙂
Je suis en train de regarder ce que OpenURL pourrait faire dans mon projet. Que mon serveur devienne un resolver OpenURL ?
shaunlemouton:
Pour cette histoire de cookie, c’est-à-dire en fait l’identifiant de la (les) bibliothèque(s) « cible », il existe des solutions, qui nécessitent cependant une (petite) prise en charge du côté de mon serveur.
Mon script Greasemonkey est en fait une fusée à 2 étages : mon user.js est juste un pointeur vers le « vrai » script, ce qui me permet de faire des MAJ sans « redéployer » une nouvelle version du user.js.
Donc, comme solution à notre problème, ou bien on rajoute un identifiant « figé » dans l’URL n°2 du script, par exemple : http://bibli.othequ.es/userscript/data?site=scd.univ-metz.fr
Ou bien même je détermine le « site d’installation » via le reverse DNS des requêtes HTTP, qui ressemblent actuellement à : « info4.scd.univ-metz.fr ».
La première solution est plus fiable et claire mais oblige à décider d’une nomenclature (ici, les noms de domaine).
Ensuite l’astuce est que le cookie soit positionné comme il faut quand l’URL n°2 est téléchargée (automatiquement à chaque fois que le script est exécuté, sauf si mécanisme de cache).
@Shaunlemouton : je ne comprends pas. Si le cookie correspond à un profil chez bibli.othequ.es, et si le profil est « stocké » sur bibli.othequ.es (mais peut-être ne comprends-je pas bien le système en question ?), en quoi est-ce gênant que plusieurs ordinateurs exploitent ce même cookie ?
Ou alors, le site de la bibliothèque ne peut-il délivrer le cookie en question quand on ouvre la page de son site où elle explique comment télécharger le script ? Le cookie d’un site ne peut peut-être pas être délivré par un autre site ?
@Damiano : je n’y connais rien en cookies (cf. les lignes ci-dessus !). Que signifie le besoin « que le cookie soit positionné comme il faut » ? Quoi qu’il en soit, oui, il faudrait effectivement que l’URL du site soit dans le script. Sauf que cela pose un problème si l’usager utilise effectivement plusieurs bibliothèques, ou si un réseau de bibliothèques veut proposer un script contenant l’ensemble de son réseau, non ?
Un cookie est créé/positionné par un serveur Web, en réponse à une requête HTTP. C’est le cas par exemple sur mon site quand on sélectionne les bibliothèques sur la carte, qui dit alors au navigateur de stocker en local uniquement les identifiants (arbitraires) que j’ai assignés à ces bibliothèques. Lesquels identifiants sont ensuite automatiquement passés en paramètres par le navigateur au service de recherche, qui s’en sert pour déterminer les données de configuration de ces bibliothèques (serveur Z39.50, etc).
« Ou alors, le site de la bibliothèque ne peut-il délivrer le cookie en question quand on ouvre la page de son site où elle explique comment télécharger le script ?
Le cookie d’un site ne peut peut-être pas être délivré par un autre site ? »
Non, pour cause de sécurité évidente, ce n’est pas possible 🙂
Mais, grâce à un petit « hack », on pourrait imaginer en effet faire « en douce » une requête HTTP vers mon service pour positionner le cookie depuis la page d’accueil du site de la bibliothèque. Mais c’est loin d’être fiable comme solution.
D’où l’idée de matérialiser cette information de configuration dans le script Greasemonkey, correspondant à des valeurs « par défaut », en plus de l’éventuel cookie « bibli.othequ.es » avec les identifiants.
Mais voudrais un mécanisme où les identifiants de bibliothèques restent « en interne » à mon code. Par exemple utiliser la notion de nom de domaine, un peu comme les espaces de nom XML, comme étiquette correspondant à un ensemble de bibliothèques, qui puisse être évolutif.
J’espère que mon explication n’est pas trop compliquée 🙂
@Damiano : non, l’explication n’est pas trop compliquée, et l’idée d’un hack n’est pas satisfaisante.
Pour les identifiants des bibliothèques, le nom de domaine ou l’URL du catalogue ne serait pas aberrante. Mais n’existerait-il pas pour les bibliothèques publiques un identifiant équivalent au RCR (id des BU dans le Sudoc), bien que n’ayant évidemment pas le même rôle ?
On trouve dans l’annuaire des bibliothèques publiques sur le site du Ministère de la Culture des notices de bibliothèques comportant un champ Ref. en bas de notice (ex. BM de Pontarlier).
Quelqu’un sait-il si cette référence est stable et pérenne ? ou bien interne à la base ?
oulàlà! Je n’avais pas vu la suite de commentaires ici…
Damiano, je ne suis pas sur d’avoir tout compris…
« Donc, comme solution à notre problème, ou bien on rajoute un identifiant “figé” dans l’URL n°2 du script, par exemple : http://bibli.othequ.es/userscript/data?site=scd.univ-metz.fr »
c »est quoi l’url n°2 du script? Est-ce que tu propose une manip de ma part (à installer dans mon installeur) ou ce sont justes des reflexions pour l’adaptation de ton script?
En clair: est-ce que je peux faire quelquechose moi-même?
« En clair: est-ce que je peux faire quelquechose moi-même? »
Non, tout seul, je vois pas de possibilité. Il faut que je mette en place un mécanisme côté serveur 🙂
Pas forcément très compliqué en soi, mais ça « remet en cause » une de mes fonctionnalités de mise en cache du script.
Donc faut que je trouve une solution à ce problème.
C’est bon, ça devrait marcher maintenant cette idée de script « pré-configuré » pour Metz.
Pour que ça marche, il faut modifier quelque chose dans le script GreaseMonkey.
Au lieu de l’URL « généraliste » :
« http://bibli.othequ.es/userscript/data »
il faut mettre dans ce cas :
« http://bibli.othequ.es/userscript/data/scd.univ-metz.fr »
(j’ai utilisé cette « étiquette » scd.univ-metz.fr, je ne sais pas si c’est pertinent)
Et la recherche se fera automatiquement pour « l’ensemble Metz », sans avoir à aller configurer quelque chose via la carte de France (en l’occurence, sans devoir positionner le cookie de configuration).
Pour l’instant, « l’ensemble Metz » ne contient que le catalogue du SCD de l’Université mais je pense rajouter bientôt la bibliothèque municipale (si seulement j’arrive à interopérer avec leur OPAC…)
@Damiano : j’ai l’impression (mais peut-être comprends-je mal) que tu pars sur une piste dangereuse.
En effet tu vas définir des identifiants spécifiques pour chaque combinaison possible et imaginable (définition se faisant à l’avance ou au fur et à mesure) ?
N’est-il pas possible que pour chaque profil, « l’identifiant » soit une concaténation (avec séparateur) des identifiants des opac sélectionnés (l’URL du catalogue faisant un identifiant logique) ?
Non, il n’y a pas besoin d’avoir des identifiants pour « chaque combinaison possible et imaginable ». Uniquement pour ceux qui veulent « nommer » une certaine configuration 🙂
Actuellement, j’utilise en interne de mon service des identifiants « opaques » (lettres et chiffres en hexadécimal), formatés de façon normalisée.
Il ne sont pas « privés » dans le sens où ils transitent entre le script GreaseMonkey et le serveur, mais sont utilisés de façon « cachée », sans que l’utilisateur ne les manipule.
C’est la même idée que le DNS : l’utilisateur manipule des noms de domaines par que c’est plus facile et qu’ils sont pérennes, alors qu’en dessous c’est bien les adresses IP qui servent. Lesquelles adresses IP peuvent varier sans que l’utilisateur s’en aperçoivent.
Voilà l’objectif de mon système d’étiquette.