Retour sur SFX

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.

Pourquoi SFX n’est plus vraiment incontournable

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 lui¹). 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.

A quoi sert l’OpenURL

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.

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

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 :

• sur Google Scholar (exemple de recherche “Einstein”)
  
  
• sur l’article Einstein en anglais, partie Références, de la Wikipedia.
  
• Sur d’autres sites utilisant la même technologie.

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 :

• Au MIT : http://owens.mit.edu:8888/sfx_local/?genre=book&aulast=North&aufirst=Simon&title=XML&isbn=2-7440-0698-X
• A Angers : http://sfx6.exlibrisgroup.com:3210/sfxangers?genre=book&aulast=North&aufirst=Simon&title=XML&isbn=2-7440-0698-X
• A Paris 6 : http://jubil.upmc.fr/openurl?genre=book&aulast=North&aufirst=Simon&title=XML

[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

• soit aller sur le site et mettre des mots dans le formulaire de recherche
• utiliser une URL qui reproduit cette requête : la recherche “openurl” donnera
  • sur Google : http://www.google.fr/search?q=openurl
  • sur Yahoo : http://fr.search.yahoo.com/search?p=openurl
  • sur Amazon : http://www.amazon.fr/s/ref=nb_ss_w?&url=search-alias%3Daps&field-keywords=openurl
  • sur WorldCat : http://www.worldcat.org/search?qt=worldcat_org_all&q=openurl

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.

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 (

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