Proposer à ses lecteurs une extension OpenURL Referrer préparamétrée

9 mars 2009 à 1:00 (Formation à la maîtrise de l'information, Logiciels)
Tags: ,

Tout l’intérêt de l’OpenURL, c’est d’afficher les rebonds depuis n’importe quel site proposant des métadonnées bibliographiques vers le catalogue de ma bibliothèque.

Problème : cela implique (en tout cas pour le moment) que vos lecteurs installent sur leurs navigateurs l’extension OpenURL Referrer, dont j’ai déjà parlé, qui transforme les COinS en URL cliquables. Il faut donc leur indiquer le site, leur demander de télécharger l’extention, et leur expliquer comment paramétrer les valeurs à y mettre (essentiellement URL du résolveur, et sa version). On risque de perdre plus de la moitié du lectorat visé par ces consignes.

La meilleure solution est donc de proposer, sur le site de la bibliothèque, l’extension préparamétrée. Cela permet d’esquiver complètement la notion d’OpenURL (amusez-vous à la leur expliquer si vous vous en sentez le courage), et de leur proposer “simplement” : une extension qui permet de rebondir depuis une référence d’ouvrage trouvée sur Internet vers le catalogue de sa bibliothèque, pour voir rapidement si elle le propose ou non.

Quelques explications préalables sont nécessaires.

Qu’est-ce qu’une extension Firefox ?

Sur Internet, vous trouvez ces extensions sous la forme de fichiers XPI. Il s’agit en fait de fichiers ZIP. Lorsque vous cliquez dessus, Firefox les reconnaît comme des ZIP, et les décompresse dans le répertoire contenant tous les paramètres de votre profil d’utilisateur.

Sous Windows, ce répertoire est dans : C:\Documents and Settings\::nom_d_utilisateur::\Application Data\Mozilla\Firefox\Profiles\::nom_du_profil::\extensions

Si vous avez déjà installé OpenURL Referrer, vous retrouverez tous les fichiers décompressés dans le répertoire {6949DC66-E5E4-4bf0-B364-84F23ED81319}, sous “extensions”.

Donc pour modifier les paramètres par défaut de l’extension, il vous faut

  1. télécharger le fichier XPI au lieu de l’installer sur Firefox (donc aller sur le site d’Openly, et faire un clic gauche “Enregistrer la cible du lien sous…”
  2. dézipper le fichier (changer l’extension .XPI en .ZIP si nécessaire)
  3. modifier les fichiers (XML) nécessaires pour que les paramètres par défaut soient différents
  4. rezipper tous les fichiers, remettre une extension .XPI au ZIP obtenu
  5. charger le fichier XPI sur un serveur
  6. pointer vers ce fichier depuis une page du site de la bibliothèque, vantant les mérites de cette extension

Le plus difficile évidemment, c’est l’étape 3. Je vais essayer d’être le plus clair possible, car il me semble que le XML fait peur à certains.

Vidéo 1 : enregistrer le fichier XPI et le dézipper. (étapes 1 et 2)

Modifier les paramètres par défaut (étape 3)

Une fois les fichiers dézippés, vous obtenez un fichier install.rdf et 3 répertoires

4fichiers

Celui qui nous intéresse, c’est le répertoire Chrome.

Il contient un fichier openurlref.jar. Pas de bol, c’est encore un fichier ZIP qui ne dit pas son nom : il faut donc dezipper celui-là aussi.

Cela produit 3 nouveaux répertoires, dont un qui s’appelle content. Dans content, il y a un répertoire openurlref, qui contient un fichier profiles.rdf. C’est celui-là !

Avec tous les dézippages successifs, ce fichier st donc dans chrome\content\openurlref\profiles.rdf.

Vidéo 2 : trouver le fichier profiles.rdf

Remarque : vous noterez qu’après avoir dézippé openurlref.jar et obtenu mes trois répertoires, j’ai supprimé le fichier openurlref.jar. En effet lorsque j’aurai modifié profiles.rdf, les trois répertoires content, META-INF et skin devront être rezippés en un seul fichier qu’il faudra rebaptiser openurlref.jar. Donc l’ancien ne sert plus à rien.

Avant d’ouvrir le fichier profiles.rdf, munissez-vous (si vous avez un résolveur) de :

  • l’URL du résolveur. Moi, je prendrai : http://jubil.upmc.fr/openurl
  • l’URL de l’image qui va être cliquable chaque fois qu’il y aura des COinS
  • ou, si vous ne voulez ou n’avez pas d’image, réfléchissez au texte que vous souhaitez voir apparaître. Par exemple : “Trouver dans ma BU”
    (songez que ces liens sont faits pour apparaître depuis n’importe quel site sur Internet. Le texte ou l’image doit donc faire comprendre que l’internaute va basculer sur le site de sa bibliothèque.)

Le fichier profiles.rdf

C’est un fichier XML, donc, structuré assez simplement.

  • La balise racine est : <RDF:RDF>. On ne s’en occupe pas.
  • La balise <RDF:Seq> contient une série de <RDF:li> qui liste l’ensemble des profils disponibles. Ces profils sont désigné par un nom. Cela ressemble à : <RDF:li RDF:resource=”profiles:1cate Demo”/>
    A cet endroit, je vais rajouter une ligne sur le modèle ci-dessus, qui va donc être :
    <RDF:li RDF:resource=”profiles:Jubil”/>
    Evidemment, il me faut alors créer ensuite un profil ayant pour identifiant Jubil.
  • Une série de balises <RDF:Description>. Ces balises contiennent un certain nombre d’attributs, qui sont les valeurs du résolveur :
    • son identifiant : attribut RDF:about=”profiles:Jubil”
    • son nom : attribut profiles:name=”Jubil”
      Le nom est celui qui apparaît à l’utilisateur dans la fenêtre de paramétrages.
    • son URL : attribut profiles:lsurl=”http://jubil.upmc.fr/openurl“
    • sa version : profiles:use1_0=”false”
      Il faut mettre “false” si la version du résolveur est 0.1, et “true” si c’est 1.0.
    • si je veux que ce soit une image qui apparaisse :  profiles:useimg=”true”
    • l’URL de l’image : profiles:imgurl=”http://jubil.upmc.fr/a/slide/files/projects/upmc/doctype/gallerie/gallerie-1150805377211-134.157.146.58.gif“
    • Le texte alternatif (si l’image n’est pas disponible) — ou le texte tout court si je ne veux pas d’image : profiles:text=”Trouver sur Jubil”

Plutôt que de tout saisir à la main, il vaut mieux évidemment dupliquer un des autres profils et l’adapter.

Vidéo 3 : modifier le fichier profiles.rdf

Remarque : si vous créer un profil avec tous les attributs, mais que vous n’y faites pas référence dans la liste (balise <RDF:li> insérée dans la balise <RDF:Seq>), le profil n’apparaîtra pas. Et il faut le mettre en tête pour que ce soit celui choisi par défaut.

Et une fois installée l’extension, ça donne ceci :

openurlref

Et après ?

  1. Vous remonter au niveau du répertoire chrome, dans lequel se trouve 3 répertoires (content, META-INF et skin).
  2. Vous zippez ces trois répertoires en un fichier openurlref.jar
  3. Vous remonter au niveau le plus haut (jusqu’à voir 3 répertoires — chrome, defaults, META-INF — et un fichier install.rdf), et vous zippez le tout en un fichier openurlRef_Ma_Bibliotheque.xpi

Remarque : petite subtilité supplémentaire, avant de rezipper toute l’extension, vous pouvez aller dans le répertoire defaults\preferences. Il y a un fichier openurlref.js que vous pouvez ouvrir avec WordPad ou le bloc-notes. Il gère le comportement de l’extension lors de son téléchargement par l’utilisateur. Ainsi, vous y trouverez les lignes :

//This is used to signal the extension to pop up the options pane
//when the browser is restarted after an install
pref("openurlref.firstTime", true);

Si vous mettez false au lieu de true, Firefox ne proposera pas à l’internaute de configurer l’extension après installation. Ce qui serait normal : vous l’avez fait pour lui.

Conclusion

Un peu laborieux, peut-être ? Consolez-vous : vous, vous n’avez pas eu à essayer de comprendre ce fonctionnement en l’absence de documentation. C’était plus pénible encore.

Ce qui est intéressant, c’est que ça permet ainsi à une bibliothèque de proposer sur une page, non pas son résolveur OpenURL, mais un service à l’usager, avec copies d’écrans (de Google Scholar, Wikipedia, Citeseer, etc.) à l’appui. Non pas la description, d’une technique, mais le principe-même “Simplifiez-vous la vie !”

Remarque : quoique ne l’ayant pas encore vérifié, je suis sûr par avance qu’une telle manipulation n’empêchera pas les mises à jour, une fois que l’utilisateur aura installé l’extension sur son navigateur. En effet l’extension continuera à aller vérifier sur le site d’Openly si une nouvelle version existe ou non.

P.S.

J’ai essayé de faire le plus clair possible. Mais :

  • si une étape n’est pas claire du tout
  • si ça ne marche pas chez vous

N’hésitez pas à réagir vivement en commentaires.

Il faut préciser aussi que l’installation d’une extension sous Firefox laisse de multiples traces. Il ne vous suffit pas de désinstaller l’extension pour faire comme si elle n’avait jamais été là : donc pour vous assurer que tout fonctionne bien (avant de publier vraiment l’extension sur votre site), testez-là sur un poste qui n’a jamais eu OpenURL Referrer auparavant.

Si tout de même vous voulez (ou devez) testé cette nouvelle extension sur un poste dont Firefox a déjà eu une extension OpenURL Referrer, avec un profil antérieur déjà enregistré, vous pouvez effacer toutes les traces de cette ancienne version de la manière suivante :

  1. Désinstallez l’extension sur Firefox et fermez le navigateur
  2. Allez dans le répertoire C:\Documents and Settings\::nom_d_utilisateur::\Application Data\Mozilla\Firefox\Profiles\::nom_du_profil::\
  3. Supprimez le fichier openurlref_profiles.rdf
  4. Ouvrez le fichier prefs.js (avec WordPad) et supprimez toutes les lignes commençant par : user_pref(“openurlref.
  5. Allez dans le répertoire extensions et supprimez le répertoire {6949DC66-E5E4-4bf0-B364-84F23ED81319}

Voilà, vous avez effacé toutes les traces d’OpenURL Referrer sur votre poste. Vous pouvez installer la nouvelle extension pour voir si elle fonctionne bien.

8 commentaires

Le nouveau Sudoc ! Euh… lequel ?

6 mars 2009 à 6:52 (Moteurs et bases de données, opac)
Tags: , ,

Logo du nouveau Sudoc Voilà, le nouveau Sudoc vient de sortir.

L’Abes nous fournit elle-même la liste des principales nouveautés (dans une mise en page plus sobre que la nouvelle interface).

D’abord, quelques remarques. Puis je reprends ma grille publiée il y a quelques semaines.

Remarques d’ensemble

Seul l’habillage a été modifié (le bleu est un peu plus pâle), et la présence de certains liens supplémentaires. Aucune des fonctionnalités n’a changé.

  • Le fonctionnement des liens vers les notices n’a pas changé.
  • Le champ “Tous les mots” ne permet toujours pas d’interroger sur l’ISBN ou l’ISSN. Donc je ne peux toujours pas avoir un seul plugin de recherche Sudoc me permettant tantôt de chercher sur un sujet, un titre ou un auteur, tantôt de chercher un ISBN.
  • Pas de fil RSS (il va falloir que je remette le mien à jour).
  • Pas d’export dans un format bibliographique (tout le monde n’a pas Zotero, que diable ! Il y en a même qui apprécient Endnote).
  • Le formulaire de recherche était à revoir. Pas les fonctionnalités qu’il propose : l’ordre et la mise en forme des champs disponibles. Vraiment, ce n’est plus adapté.
  • Le lien vers Google Books aurait pu être intéressant. Le problème, c’est qu’il ralentit considérablement le temps de chargement de la page. L’explication doit être la suivante : le lien n’apparaît que si le livre est réellement disponible sur Google. Donc le Sudoc interroge en temps réel l’API de Google (les liens ressemblent à ceci : http://books.google.com/books?id=HcyrGAAACAAJ&source=gbs_ViewAPI), et le temps de chargement est donc tributaire de la réactivité de l’API Google… qui ne semble pas fameuse pour le moment. Peut-être qu’un simple rebond de recherche aurait finalement été plus satisfaisant.
  • J’ai mis du temps à trouver le bouton “Localisation”. Je vous aide : à présent il est au-dessus de la notice.
    Ca n’a l’air de rien, mais je pense que c’était une mauvaise idée : traditionnellement, sur tous les Opacs du monde (sans que j’en connaisse aucune exception) les exemplaires sont mentionnés sous la notice bibliographique, pas au-dessus.
    A mon avis, sur ce bouton-là, il y avait deux améliorations envisageables :

    • soit faire paraître la liste des exemplaires directement sous la notice bibliographique (peut-être risqué s’il y en a un trop grand nombre, je veux bien l’admettre — en même temps, on consulte généralement le Sudoc pour des documents plutôt rares, non ?)
    • soit remplacer l’icône à l’ancienne, qui ressemblait à une flûte de Pan, par une icône un peu plus parlante. Cela dit, le choix de mettre du texte à la place est plutôt bon : c’est plus clair. C’est l’emplacement de ce texte qui est discutable.

    Bon, en même temps, une fois qu’on l’a vu, c’est acquis.

  • Je ne suis pas convaincu par l’ergonomie de la navigation dans l’aide. Cela dit, il y a des copies d’écran, et elles sont proprement détourées et dans du PNG (et pas de l’immonde JPEG). C’est bien. Encore un petit effort et tout le monde osera faire des vidéos dans son aide en ligne.

Quelques points positifs :

  • Si, quand même, les icônes par types de documents sont mieux. J’aime beaucoup celle utilisée pour les thèses
  • Comme le signale l’Abes elle-même, la recherche “Tous les mots” est mise par défaut, et se trouve en tête de liste
  • Le plugin de recherche Sudoc est proposé par le Sudoc lui-même (lien “Ajouter SUDOC”). Dommage qu’il n’intègre pas l’icône du nouveau logo.
    Une petite explication pour les collègues de l’Abes qui me liraient : le plugin de recherche est un fichier XML très court. Pour qu’il propose une zolie icône, il faut qu’il contienne une balise <Image width=”16″ height=”16″>…</Image> ou le contenu de cette balise est l’image elle-même, codée en binaire.
    Pour avoir l’équivalent binaire d’une image (par exemple l’image de la barre d’adresse pour le Sudoc, qui est ici : http://193.52.26.28/img_psi/3.0/favicons/default.ico, il faut la faire passer par cet outil dont la mission est précisément de convertir du GIF (ou autre format) en binaire. On récupère ensuite l’URL obtenue, et on la colle dans le fichier XML du plugin. Ca nous donne ceci.Désolation : ce plugin cherche dans le champ “Tous les mots”, donc ni l’ISBN ni l’ISSN.
  • Des COinS dans les notices détaillées ! En version 1.0 (donc tant pis pour Paris 6, hein : vous n’avez que du 0.1, bande de nazes). On les voit parce grâce à OpenURL Referrer, un lien apparaît tout en haut à droite de la page. Du fait des COinS, Zotero récupère naturellement les données
    J’ai quand même un énorme regret : ces COinS n’ont pas été implémentés dès la liste de résultats. Peut-être parce qu’on estimait qu’il n’y avait pas assez de métadonnées fournies, mais je trouve que c’est vraiment dommage tout de même.

Grille de lecture

Je remarque d’abord qu’aucun de ces critères n’a été amélioré. C’est donc l’occasion de faire le point sur le Sudoc, de manière générale (et pas le “nouveau Sudoc”).

  1. L’URL est significative (http://catalogue.bibliotheque.fr/, ou quelque chose comme ça) –> OK (ça ne change pas)
  2. L’URL n’est pas la même pour toutes les pages du catalogue (page d’accueil, liste de résultats, notice détaillée) –> OK (ça ne change pas)
  3. L’URL contient tous les paramètres de la recherche (mots recherchés, champs interrogés, filtres effectués après affichage de tous les résultats) –> oui au niveau des listes de résultats, non au niveau de la notice détaillée
  4. La page comporte un titre (je ne veux pas voir apparaître l’URL dans mon onglet Firefox) –> OK (ça ne change pas)
  5. Le titre varie selon la page sur laquelle je me trouve (et ne s’appelle pas toujours “Catalogue de la bibliothèque”) –> Non
  6. Le titre récupère les métadonnées du document si je suis sur une notice détaillée –> Non
  7. Le titre n’est pas le nom du logiciel, aussi performant soit-il, ni celui de la société (le titre est une information intéressante pour l’internaute. Et le nom du logiciel n’est pas une information intéressante pour 99% des internautes) –> OK (ça ne change pas)
  8. Quand j’ai cliqué sur un résultat dans une liste, la couleur du titre change pour m’éviter de cliquer deux fois sur le même –> Non
  9. La notice détaillée préciser comment pointer vers elle (pour éviter à l’internaute de récupérer une URL contenant l’identifiant de cession, les mots clés interrogés, etc.), comportant par exemple l’identifiant de notice. –> Non
  10. Une recherche rapide est possible à tout moment où que je me trouve (encart isolé en haut à droite ou à gauche, ou carrément barre de recherche latéral ou supérieure). –> OK (ça ne change pas)
  11. La recherche dans le catalogue n’est pas dans un frame HTML (ce qui bousille les exigences sur le titre et l’URL). –> OK (ça ne change pas)

J’en conclus donc, non pas que je ne sers à rien (ce qui est évidemment le cas), mais que ces critères ne sont pas considérés de manière générale comme fondamentaux, puisque leur réponse positive ou négative est aléatoire.

Conclusion

Je m’attendais à faire une exploration approfondie des fonctionnalités. Mais en fait il n’y a pas grand chose à en dire.

C’est quand même mieux, mais tant qu’à faire une évolution (il n’y en a pas souvent pour le Sudoc), on attendait un peu plus (pas une interface WorldCat, mais quand même).

Même l’aspect d’ensemble (du texte noir, des liens bleus, un fond blanc) n’a pas changé.

Il semblerait que le Sudoc se maintienne donc comme un outil fonctionnel apprécié des professionnels des bibliothèques, qui continueront donc à le recommander. J’ai même vraiment l’impression que les fonctionnalités supplémentaires sont mises pour les professionnelles (la fonction d’analyse du lot, par exemple, qui me laisse perplexe).

Quant à nos lecteurs, l’Abes ne voulait sans doute pas infliger aux statistiques de nos Opac un sévère camouflet.

Je m’excuse auprès des collègues de l’Abes qui y auront mis de l’effort et du coeur : ma déception est à la hauteur de mes attentes. Dans les missions du Sudoc, il y a la perspective d’un grand catalogue universitaire national à destination de nos lecteurs. Parce que ce sont eux qui lisent nos livres, qui les empruntent, qui font des demandes de PEB.

Et une dernière remarque : j’ai voulu limiter une recherche à une bibliothèque (recherche avancée), en cliquant sur un lien me proposant de chercher dans la base des bibliothèques partenaires. Après avoir trouvé la bibliothèque qui m’intéressait, je n’ai pas réussi à rebasculer dans la recherche d’ouvrages. J’ai trouvé ça gênant.

4 commentaires

OpenURL : nationaliser une base bibliographique sans la mutualiser

5 mars 2009 à 5:29 (Moteurs et bases de données)
Tags: , , ,

J’ai déjà eu l’occasion de parler de Periodic, la base d’articles de vulgarisation scientifique entretenue par le SCD de  l’université de Pau, et au contenu indispensable et à l’ergonomie indigeste.

J’ai découvert en arrivant à Nice la base Odin. Le principe est le suivant : l’examen national classant (ENC, ou ECN) pour l’internat de médecine est composé d’items, c’est-à-dire de disciplines médicales (vous en avez la liste ici). Quand arrivent dans la BU de médecine des ouvrages pour la préparation du concours de l’internat, les catalogueurs consultent la table des matières, et indiquent dans la notice de l’ouvrage (notice locale, après redescente du Sudoc), les items que l’ouvrage en question permet de préparer.

Ces notices d’ouvrages sont ensuite exportées pour alimenter une base de données “des ouvrages permettant de préparer l’internat”, avec une recherche par mots ou par item. Un lien pointe ensuite vers la notice détaillée dans l’Opac.

Le rapprochement entre Periodic et Odin est le suivant : il s’agit de deux bases entretenues localement par des SCD, mais avec une utilité largement nationale. On est forcé d’admettre l’intérêt de tels dépouillements, destinés à des publics d’étudiants précis pour lesquels ces ressources sont extrêmement précieuses.

Mais les autres SCD seraient très intéressés pour pouvoir faire siennes ces bases, et éviter de refaire le même travail.

Concrètement, ces bases bibliographiques locales devraient proposer un lien vers le catalogue qui m’intéresse, moi, et pas vers le catalogue des SCD qui les alimentent.

Comment se faire ? Avec de l’OpenURL, évidemment !

Si pour chaque notice d’article ou d’ouvrage, un COinS, encapsulant les métadonnées du document au format OpenURL, est présent dans la page, n’importe quelle bibliothèque de France disposant d’un résolveur OpenURL peut recommander à ses étudiants la base en question, en leur disant d’installer OpenURL Referrer (extension Firefox qui fait apparaître les COinS comme des liens cliquables vers le résolveur qui m’intéresse) sur leur navigateur. De cette manière chaque SCD pourrait se spécialiser dans un public donné, lui fournir une base profilée, et renvoyer vers les autres bases de France (et de Navarre, pour Pau).

Conclusion : tout le monde doit avoir un résolveur OpenURL pour bénéficier des ces bases.

Le temps que tout le monde s’équipe, cela laisse aux SCD qui gèrent ce genre de bases de les développer pour y rajouter des COinS. A vue de nez, si on a une base en PHP, je dirais qu’une telle modification nécessite pour un développeur : 50 minutes de travail.

Et de préférence : mettez des COinS en OpenURL 0.1 et pas en 1.0, pensez aux bibliothèques qui ont un résolveur 0.1 !

Et vous, vous connaissez de ces bases spécialisées, en production locale ?

9 commentaires

Retour sur SFX

5 mars 2009 à 9:51 (Logiciels)
Tags: ,

Daniel a entamé une série d’articles sur SFX.

Cela permet de nuancer le mien, en plus ceux-là sont écrits par un vrai administrateur de SFX !

J’attends la suite avec impatience.

4 commentaires

Pourquoi SFX n’est plus vraiment incontournable

24 février 2009 à 6:58 (Moteurs et bases de données)
Tags: ,

J’attends avidemment des corrections sur ce billet, en particulier de la part d’administrateurs réels de SFX.

Ce que j’écris ici est le résultat d’une succession de déductions, et non le fruit d’informations spécifiques. Donc mes raisonnements peuvent se fourvoyer (et moi avec), ce ne serait pas la première fois.

SFX est le résolveur de liens OpenURL vendu par Ex Libris. Son rôle est donc de recevoir les requêtes OpenURL de sources diverses, et de renvoyer vers le document demandé en fonction des collections d’une bibliothèque spécifique.

Il y a plusieurs situations où un résolveur peut intervenir. Voici celle qui est à l’origine de la norme.

1. Base bibliographique -> Article

Je consulte une base bibliographique (base d’articles). Un article donné m’intéresse, et je veux éviter d’aller (à l’ancienne) dans le catalogue de ma bibliothèque pour voir s’ils sont abonnés à la revue, et s’ils disposent du numéro où est paru l’article.

Un lien OpenURL est généré automatiquement, contenant le titre de l’article, son auteur, l’ISSN de la revue, la date de publication et le numéro du volume (plus éventuellement la pagination).

Comme ma bibliothèque a déclaré son résolveur OpenURL auprès de la base de données, le lien complet (URL racine + partie OpenURL avec les métadonnées) est généré. Je clique dessus. J’arrive sur l’interface propre au résolveur.

Celui-ci interroge le catalogue de la bibliothèque (collections en ligne + papier) et m’affiche directement

  • le lien vers la notice de la revue papier (dans l’Opac)
  • le lien vers l’article de sur le site du fournisseur chez lequel j’achète la revue en question.

Cela implique que le résolveur OpenURL sache

  1. interroger mon catalogue selon la syntaxe qui lui est propre et récupérer les résultats qui en résultent.
  2. oser une requête équivalente au fournisseur de revues.

Donc le résolveur doit avoir accès à l’intégralité de nos collections, mais aussi savoir construire l’URL capable d’interroger chacun des fournisseurs de revues (ScienceDirect, Cairn, Lavoisier, etc.).

Le rôle de la base de connaissances

A Jussieu, pour notre portail documentaire, la société Jouve nous avait développé un résolveur OpenURL “maison” (en réalité, je crois que c’était à partir du résolveur UKoln, mais je n’ai jamais eu confirmation).

Quand on lance une requête sur ce résolveur (par exemple en jouant cette URL), il cherche si nous avons la revue électronique (interrogation d’une base de données locale) et la revue papier (interrogation de notre catalogue).

  • Pour la revue papier : il fournit un lien vers la notice détaillée
  • Pour la revue électronique
    • il fournit l’URL de la revue (URL trouvée dans la notice de la revue)
    • il construit une URL, c’est-à-dire qu’il reprend l’URL qu’il a reçue (ne conservant en réalité que ce qui suit l’URL racine, donc uniquement la partie contenant les infos bibliographiques) en remettant comme URL racine celle qui a été définie pour la revue.

Concrètement, dans une notice de revue, nous devons indiquer (en plus de l’URL de la revue), l’URL racine de la revue, celle qu’il faut utiliser si on a une requête OpenURL a transmettre avec un article paru dans cette revue.

Quand on achète SFX, on s’abonne aussi à une base de connaissances. Ex Libris assure ainsi que les liens vers les revues seront toujours à jour, à savoir :

  • un lien vers une revue ScienceDirect commencera par http://www.sciencedirect.com/openurl? jusqu’au jour ou ScienceDirect décidera de changer cette URL racine sans prévenir : Ex Libris garantit de mettre son résolveur à jour.
  • un lien vers une revue IOP commencera par… Vous avez compris.
  • Pour une revue n’acceptant pas l’OpenURL, SFX (je suppose) garantit une transposition de syntaxe. Par exemple si pour chercher sur un titre d’article le site ScienceDirect a défini le champ “nom d’auteur” comme s’appelant “qs_author” (la norme OpenURL a défini qu’il fallait l’appeler “aulast”), SFX saura faire la transposition.

Dans un tel contexte, le rôle de la base de connaissance est d’être capable à tout moment de retransmettre une requête à une revue à laquelle ma bibliothèque est abonnée.

Mais aujourd’hui, une telle base de connaissance existe déjà, gratuitement : c’est CrossRef.

Sur Jubil, nous indiquions pour toutes les revues que l’URL racine était : http://www.crossref.org/openurl. En effet tous les éditeurs achetés par l’UPMC étaient dans la liste des participants au projet Crossref (si : même les éditeurs français !).

Ils se débrouillent entre eux, nous, nous pointons vers Crossref, et ça marchait bien.

Donc aujourd’hui, il me semble que le modèle de SFX (achat du logiciel + abonnement à une base de connaissance) ne se justifie plus autant, puisque l’on satisfaisait plus de 95% des besoins sans une telle base.

Je ne prétends pas que SFX n’est pas un bon logiciel (ça reste sans doute le meilleur du marché, quoique complexe d’utilisation pour l’internaute — et puis je doute que l’icône SFX soit jamais parlante pour lui1). En outre, implémenter un autre résolveur de manière à ce qu’il sache dialoguer avec notre catalogue et notre base de revues en ligne n’est pas gratuit non plus.

Mais la base de connaissance SFX ne doit pas (il me semble) être décisive pour choisir un résolveur OpenURL. J’aurais même tendance à croire le contraire, et à privilégier les résolveurs qui seraient de simples logiciels.

Si c’était à refaire à Jussieu, je crois qu’un critère plus important serait la version du résolveur (1.0 pour remplacer le 0.1).

1.0 et 0.1

J’en profite pour développer un (tout petit) peu parce que j’ai eu du mal à trouver réponses à mes questions sur ce sujet. En réalité c’est simple :

Un lien OpenURL utilisant la version 0.1 ressemble à ceci :

http://URLracine.fr/openurl?atitle=Titre+de+l‘article&aulast=Smith&aufirst=Patrick&date=2009&issn=1234-5678&genre=article

Un lien OpenURL utilisant la version 1.0 ressemble à cela :

http://URLracine.fr/openurl?url_ver=Z39.88-2004&ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.atitle=Titre+de+l‘article&rft.aulast=Smith&rft.aufirst=Patrick&rft.date=2009&rft.issn=1234-5678&rft.genre=article

L’URL est plus longue, mais à part le début, la seule différence est que chacun des arguments de la version 0.1 est précédé de : “rft.”.

Il vaut mieux acheter un résolveur en version 1.0 parce que :

  • il connaîtra aussi le 0.1 (et on trouve de tout sur Internet : certaines bases de données ne savent produire que l’une ou l’autre ; et les COinS seront dans une version ou dans une autre)
  • le 1.0 a été développé pour décrire toutes sortes d’objets autres que strictement documentaires

SFX est 1.0 (donc également 0.1, cf. deux lignes plus haut).

Je suis assez gêné par la prédominance de SFX sur le marché mondial. Ils sont à l’origine de la norme OpenURL, et cette prédominance est aussi historique. Mais il me semble que les bibliothèques continuent à acheter du SFX surtout à cause de la base de connaissance. Je me demande si le service rendu derrière mérite une telle dépense annuelle.

Conclusion

J’attends à présent les dénégations. Comme je l’ai dit, ce billet n’est que le fruit de raisonnement (et des quelques observations que j’ai pu faire sur SFX, que je n’ai jamais administré). Les commentaires sont les bienvenus pour m’expliquer que je n’ai rien compris et que la base de connaissances de SFX ne sert pas du tout à ça. On peut aussi m’apprendre qu’en réalité le service d’abonnement à la base de connaissance n’est pas payant, mais va avec le logiciel.

Ensuite, je parlais de plusieurs situations où pouvait intervenir un résolveur. Il en existe d’autres. Notamment le lien de catalogue (d’imprimés) à catalogue (d’autres imprimés). WorldCat propose des liens OpenURL (COinS). Le Sudoc serait bien avisé de le faire aussi. Bref, quand on a des imprimés, le résolveur peut n’être utilisé que pour interroger le catalogue, et nul besoin de base de connaissance.

_______________________________

1. Ceci n’est pas une critique sur les capacités du logiciel : je me doute bien que l’icône peut être facilement changée (c’est juste une image déposée sur un serveur). Je constate simplement que la plupart des bibliothèques n’y touchent pas : c’est elles que j’appelle à réfléchir sur cette question.

A mon avis, la question de l’icône ne sera jamais résolue de manière satisfaisante, car il est impossible de décrire un tel service avec une icône simple et parlante. Mais on peut envisager d’y répondre partiellement de la manière suivante :

  1. quand je propose un lien OpenURL depuis mon Opac (collections imprimées), je mettrai une icône : “Accessible en ligne ?” ou qqchose comme ça
  2. quand je propose un lien OpenURL depuis une base bibliographique distante (OvidSP, Inspec, etc.), je mettrai une icône “Ma Bibliothèque”

C’est améliorable, mais le principe de base serait : l’icône est différente si je suis dans ou hors du site de la bibliothèque.

13 commentaires

Zotero pour bloguer sur des ouvrages

4 février 2009 à 11:39 (Logiciels)
Tags: , ,

En lien avec mon billet précédent sur l’OpenURL.

Je maintiens l’idée que dès qu’une référence bibliographique apparaît à l’écran, la machine doit pouvoir identifier la nature de cette information comme telle. Cela permet des rebonds OpenURL si le navigateur est doté d’OpenURL Referrer. Cela permet (et permettra de plus en plus) une meilleure articulation avec les logiciels de gestion bibliographique. En bref, les COinS sont la traduction à destination de la machine du texte libellé en clair pour l’utilisateur.

La seule condition pour les utiliser : ne pas avoir à les saisir manuellement.

Donc si vous tenez un blog qui parle régulièrement de livres divers — je pense notamment aux blogs de bibliothèques — jusque-là vous aviez le choix entre :

  1. écrire à la main la référence de la notice
  2. copier-coller depuis votre Opac, depuis WorldCat, Amazon ou LibraryThing (pour refaire ensuite la mise en forme, car un affichage tabulé n’est jamais ce qu’il y a de mieux pour un billet de blog)

Désormais vous aurez l’obligation de vous simplifier la vie, et de simplifier celle de vos lecteurs :

  1. Vous récupérez la notice biblio dans Zotero (toujours depuis votre Opac, WorldCat, etc.)
  2. Dans Zotero, vous sélectoinnez le titre que vous voulez bloguer, vous faites un clic droit > Créer une bibliographie à partir de l’élément sélectionné
  3. Vous choisissez le style de citation (=mise en forme de la référence — il vous faudra sans doute un peu de temps avant de trouver celui qui vous plait le plus) et Copier dans le presse-papier
    Copie d'écran Export bibliographique
  4. Vous collez dans votre éditeur de blog. Il vous affiche la référence, et il cache une balise span contenant les métadonnées du document.

Donc si un lecteur lit votre billet, est intéressé par l’ouvrage, il peut en récupérer la notice rapidement dans son logiciel de gestion bibliographique.

Si une autre bibliothèque (disposant d’un résolveur OpenURL) lit votre billet, elle peut cliquer sur le lien OpenURL pour savoir rapidement si elle-même possède déjà le document ou non.

De manière plus générale, il me semble inutile (dépassé serait plus juste) d’argumenter sur le bien-fondé d’une telle procédure :

  1. c’est plus simple que le copier-coller
  2. nous enrichissons nos pages de contenus sémantiquement structurés (sémantiquement pour la machine, cela va de soi)
  3. en développant naturellement ce genre de pratiques, nous participons aussi aux usages généraux du web, à la propagation de nouvelles possibilités.

On voit ainsi dans l’exemple ci-dessus que les COinS facilitent le “dialogue” entre une page web (parlant d’un bouquin) et un logiciel de gestion bibliographique. Mais d’une certaine manière, le format OpenURL sous forme de COinS peut fort bien devenir un format d’échange (ou plus exactement d’interopérabilité) entre les différents outils permettant de gé(né)rer des métadonnées : Connotea, LibraryThing, Amazon, Opac, etc.

Actuellement, quand un catalogue de bibliothèque propose l’export de ses notices vers l’un ou l’autre site (par les notices détaillées sur ce site propose une série de sites vers lesquels bookmarquer la notice), la bibliothèque doit assurer une maintenance sur la syntaxe propre à chaque plateforme. C’est la même chose lorsqu’un site de presse propose d’”envoyer” un article vers Digg, Wikio ou Facebook. Or l’OpenURL permet de décrire des sites web, des billets de blogs, à peu près toute ressource que l’on peut souhaiter décrire sur la Toile. Donc il constitue un format d’échange exemplaire.

Bref, il faut aller dans cette direction-là !

3 commentaires

A quoi sert l’OpenURL

13 novembre 2008 à 8:05 (Formation à la maîtrise de l'information, Moteurs et bases de données)
Tags: , , , , , , , ,

Même si on en parle de plus en plus, même si de plus en plus de bibliothèques en sont dotées, je ne suis pas sûr que tout le monde voie clairement comment fonctionne et à quoi sert l’OpenURL. Il est possible que ce billet arrive trop tard et ne soit plus nécessaire. Dans ce cas-là je m’en réjouirai (tout le monde serait au fait de l’OpenURL).

Le principe de base est clair : en tant que chercheur, étudiant, lecteur, je rencontre sur Internet ou ailleurs des notices bibliographiques (articles, livres, vidéos, etc.). A chaque fois que j’en rencontre une, je veux qu’un lien apparaisse qui aille interroger directement le catalogue de MA bibliothèque, pour savoir si celle-ci peut me proposer le document.

Voyons à présent comment ça se concrétise.

Il vous faut deux extensions Firefox (la première fonctionne aussi avec Internet Explorer) pour le visualiser :

  1. OpenURL Referrer
  2. Zotero

OpenURL Referrer

OpenURL Referrer est une extension qui, dès qu’une référence bibliographique (identifiable comme telle par la machine, et pas par l’internaute) est présente sur la page, propose un lien vers le catalogue de la bibliothèque qui interroge ce catalogue pour savoir s’il contient la ressource (le livre s’il s’agit d’un livre, la revue s’il s’agit d’un article).

Donc vous installez OpenURL Referrer, et vous le configurez.

openurl-referrer-11

Je vais le configurer en supposant que je fais mes études au MIT. L’URL du résolveur OpenURL du MIT est : http://owens.mit.edu:8888/sfx_local/. Donc je la mets dans “Link Server OpenURL”. Et dans le champ Display link as Text, je mets : “Trouver le document”.
Si ce n’est pas mis par défaut, il faut cocher comme “version” (sous l’URL) : 0.1

openurl referrer preferences

J’ai trouvé ces paramètres en cherchant sur Google : “MIT OpenURL“

Désormais, chaque fois que le navigateur va rencontrer une référence bibliographique, il va me proposer un lien cliquable “Trouver le document” vers le catalogue du MIT, m’indiquant si la bibliothèque possède la ressource en question.

Cela se voit immédiatement :

Si à présent je ne suis plus au MIT, mais à la l’université d’Angers (il y a des parcours singuliers, parfois), à la place de l’URL précédente propre au MIT, je mettrai : http://sfx6.exlibrisgroup.com:3210/sfxangers.

Et si je suis à Paris 6, je mettrai : http://jubil.upmc.fr/openurl.

A chaque fois, sur les mêmes sites, l’URL pointera sur mon catalogue.

Comment ça se passe ? Le site lui-même ne génère que la fin de l’URL, toujours la même, qui contient les métadonnées de la ressource (titre, auteur, ISSN, etc.). C’est le navigateur qui rajoute la racine déclarée dans les Préférences d’OpenURL Referrer. Tous les résolveurs acceptent une même syntaxe d’interrogation dans l’URL :

[Rq : c'est un livre en français, et le MIT ne l'a pas. L'existence du lien ne promet pas l'existence du livre]

Faire une requête en construisant une URL

Il n’a échappé à personne que pour interroger un moteur de recherche sur Internet (Google, Yahoo, Amazon, catalogue de bibliothèque), on peut

Le champ correspondant aux mots recherchés sera, s’appellera, selon la base : q, p ou “field-keywords”.

Mais pour une référence bibliographique, on peut avoir plusieurs champs qui caractérisent la ressource : auteur, titre de l’article, titre de la revue, ISSN, numéros des pages, etc.

L’idée simple de l’OpenURL, c’est que toute ressource référençant des documents utiliserait le même vocabulaire. La norme OpenURL, c’est donc un standard qui définit que le champ “Nom de famille de l’auteur” ne s’appellera pas “auteur”, “author”, “creator” ou autre, mais “aulast” (pour last name). Tout catalogue qui accepte l’OpenURL doit donc accepter que son champ Auteur s’appelle “aulast”.

De même, le titre de l’article sera, dans l’URL : “atitle” ; le titre de la revue : “title” ; l’ISSN : “issn”, etc.

Comme généralement le catalogue lui-même n’est pas nativement OpenURL, il faut installer un résolveur OpenURL (ou résolveur de liens, ou link resolver, ou link server) qui comprendra la requête OpenURL, la transmettra au catalogue (en Z39.50, par exemple) et récupèrera le résultat pour afficher la notice détaillée. De même que le catalogue a une URL d’accès, le résolveur a une URL spécifique. C’est l’URL racine à indiquer à OpenURL Referrer.

Zotero

Zotero est un logiciel de gestion bibliographique intégrée à Firefox. On remplit sa bibliographie en naviguant sur Internet. On peut y stocker des notices d’articles, de chapitres, d’ouvrages, de conférences, etc., rencontrées un peu partout. Si je fais une recherche dans le Sudoc, une liste de résultats peut être rapidement stockée dans ma bibliographie (liste des sites où Zotero est capable de reconnaître des références biblio et de les importer en deux clics).

Quand j’affiche une notice, j’ai un bouton “Localiser”. Il permet de bricoler la fin de l’URL en vocabulaire OpenrURL, en mettant bout à bout les infos contenues dans la notice (titre, auteur, etc.), et de rajouter en racine l’URL du résolveur indiqué dans les préférences.

localiser1

Preferences Zotero

Autres applications — Que devons-nous faire ?

[Rq préalable : Ex Libris, fournissant le résolveur SFX, de loin le plus répandu, se charge d'un certain nombre de démarches décrites ci-dessous. Tout ce qui nous reste à faire dans ce cas, c'est la comm'.]

OpenURL Referrer permet de générer un lien dès que des métadonnées sont présentes dans la page. Pour cela, il faut que la machine sache qu’il s’agit de métadonnées. Donc les informations doivent être à la fois écrites “en clair” pour l’utilisateur, avec des caractères droits et italiques, et sous forme de balise autofermante  <span> contenant les informations bibliographiques en mode OpenURL : ce sont les fameuses balises COInS dont parlait déjà Figoblog il y a fort longtemps. La balise <span> étant autofermante, un navigateur ne la comprenant pas ne l’affichera pas. Mais si le navigateur sait ce que sont ces balises, il va générer le lien conformément au profil demandé par l’utilisateur, càd rajouter l’URL racine propre à la bibliothèque, et produire le texte (“Trouver le document”) choisi par l’utilisateur.

Une telle balise <span> ressemble (à peu près) à ceci (cf. aussi cette page) :

<span class="Z3988" title="genre=book&amp;aulast=North&amp;aufirst=Simon&amp;title=XML"/>

Ou trouve-t-on des références bibliographiques ?

Les bases de données bibliographiques comme le Web of Science, Pascal, Google Scholar, savent produire ce genre de balises. Si la base est sur abonnement, il faut déclarer son résolveur (et sa version, car il y a deux versions du langage OpenURL…) auprès de son fournisseur. Ainsi, par reconnaissance de l’IP, le fournisseur mettra la bonne URL racine (on parle de “base URL” dans la norme OpenURL).

Les bibliographies d’articles dans les revues en ligne payantes. Sur IOP, IEEE et plein d’autres, l’éditeur du site est capable, à côté de la référence de l’article, de générer un lien OpenURL si on le lui demande gentiment. A noter que nous avons déclaré notre “URL racine” à ScienceDirect — il s’est mis à générer un lien OpenURL uniquement avec les métadonnées de l’article en cours de lecture : on cliquait sur le lien, on basculait sur le site de la bibliothèque qui renvoyait à l’article en question. L’intérêt de la chose m’a laissé pantois. Nous avons retiré le lien.

Exemple de lien OpenURL ("Disponibilité") depuis la bibliographie d'un article

Exemple de lien OpenURL (

Certains services de gestion de bibliographie gratuits et collaboratifs comme Connotea (CiteULike ne le fait pas encore) génèrent déjà des liens OpenURL avec l’extension OpenURL Referrer.

Les pages des sites des bibliothèques, devant prêcher la bonne parole, devraient comporter ces balises <span> à chaque référence bibliographique mentionnée. Les outils pour le faire facilement se multiplient. Et pourquoi pas dans nos catalogues : avec les moteurs de recherche web qui indexent de plus en plus le web invisible, Dieu sait le nombre de manières qu’un utilisateur a de tomber sur une de nos notices, dans notre catalogue, sans être passé par l’interface d’accueil. Donc s’il arrive directement sur une notice de livre, il peut apprécier un lien qui le renvoie directement à sa bibliothèque

A une époque, WorldCat générait ces liens. Du moins je les voyais sur les notices détaillées grâce à OpenURL Referrer. Je ne les vois plus pour l’instant (c’est curieux puisque WorldCat et l’extension OpenURL Referrer sont des produits OCLC). Plus généralement, tous les catalogues collectifs, qui dans une certaine mesure servent aussi de base bibliographique, devraient permettre cette fonctionnalité.

Le signalement des revues en ligne pourrait se faire de cette manière dans le Sudoc, et sur son propre Opac : régulièrement on se demande s’il faut cataloguer les revues en ligne dans le Sudoc. Déjà, si on pouvait demander au Sudoc un lien OpenURL, l’utilisateur pourrait, ayant trouvé une revue (papier ou en ligne), tomber sur le résolveur de sa bibliothèque qui lui dirait si celle-ci a la revue papier et/ou en ligne. De même, un lien dans l’Opac (notamment depuis les notices de revues, mais aussi depuis les monographies avec l’achat croissant de e-books) devrait permettre de rebondir rapidement des collections papier vers les collections en ligne.

Les postes publics des bibliothèques et les ordinateurs portables prêtés devraient donc proposer Firefox avec l’extension OpenURL Referrer préparamétrée (l’extension existe aussi pour IE7, mais je n’ai jamais compris comment les extensions IE fonctionnaient…).

Et pour les développeurs : Zotero ne passe pas d’accord avec les éditeurs de sites. Il s’appuie sur une communauté croissante de développeurs qui s’amusent à décortiquer le codage HTML des listes de résultats dans les catalogues, bases de données et autres, pour faire comprendre au logiciel que, sur telle URL, quand c’est violet c’est le titre, quand c’est vert c’est l’auteur, etc. (on trouve parfois des associations de couleurs un peu indigestes). Autrement dit, Zotero avale une information “mise en forme” et la restructure sémantiquement. Il en faudrait peu pour que Zotero prenne la place d’OpenURL Referrer, et génère à chaque référence rencontrée un lien OpenURL : sur HAL, OAISter, ArXiv, Pubmed, etc., toutes ces ressources gratuites qui ne dépendent donc pas d’éditeurs auprès desquels le fournisseur de notre résolveur OpenURL, non plus que le responsable de la doc électronique, pourrait déclarer les IP de ses utilisateurs.

NB : remarque sur SFX.

SFX est un logiciel remarquable. Mais je n’y ai rien compris la première fois que je l’ai rencontré : plusieurs liens sont proposés d’emblée, et on ne voit pas de raison a priori de cliquer sur l’un plutôt que sur l’autre. L’efficacité est là, mais en terme d’ergonomie il faudrait repenser la page de résultats. Parce qu’il est hors de question de prendre le temps d’expliquer à l’internaute ce qu’est l’OpenURL et poufrquoi il voit ce qu’il voit, alors que l’objectif de l’OpenURL est précisément de rendre la recherche plus intuitive (j’ai une référence — Hop ! je clique — et la bibliothèque m’indique si je peux avoir la notice en ligne ou en salle).

Biblio-webographie

Sylvain Machefert, L’OpenURL dans les institutions françaises, une chance pour la valorisation des ressources électroniques ?, Institut national des techniques de la documentation du CNAM – Mastère professionnel, 06/11/2007, [En ligne], http://memsic.ccsd.cnrs.fr/mem_00000613/fr/

“OpenURL”, Wikipedia, dernière mise à jour : 30/10/2008, [En ligne], http://en.wikipedia.org/wiki/OpenURL

“OpenURL”, Bibliopedia, dernière mise à jour : 18/04/2008, [En ligne], http://www.bibliopedia.fr/index.php/OpenURL

17 commentaires