PUBLIC MARKS from decembre with tags catalogue & openurl

Principalement, l’OpenURL est fait pour permettre d’accéder rapidement à une ressource rencontrée quelque part sur Internet : un lien OpenURL tient compte du résolveur auquel vous êtes (institutionnellement) rattaché et vous propose * un lien vers l’article en ligne, s’il s’agit d’une ressource en ligne * un lien vers la notice dans le catalogue de votre bibliothèque, s’il s’agit d’un document papier. Pourquoi ? D’abord pour le principe. A partir du moment où nous mettons en ligne des métadonnées, il est normal de les fournir dans un format à peu près standard, permettant de les réexploiter. Et ceci indépendamment des usages que, moi-même, je pourrais imaginer : Donc si une bibliothèque de médecine dispose d’un résolveur OpenURL, elle peut indiquer notre catalogue à ses étudiants : ils font une recherche et rebondissent ensuite vers leur propre BU, grâce au plugin LibX que celle-ci aura pris soin de leur proposer.

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 : 1. Après avoir installé Firefox et l’extension GreaseMonkey, vous allez sur bibli.othequ.es 2. Vous sélectionnez votre bibliothèque (et pas une autre, et pas plusieurs) et vous modifiez le script.....

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.

The URI microformat takes advantage of OpenURL and existing link resolver solution.It defines a convention of plugging URI metadata in HTML page. If it is adopted and widely used,now a microformat-aware application (be a greasemonkey script, or a web service) can grab the identifier and point to your local OpenURL resolver, you immediately get the copy from local library. It is very similar to COINS, but it's much simpler and cleaner, anyone can understand and use it, and its aplication can be beyond traditional research library. e.g. in a public library, you can use amazon as catalog and immediately check if it's available in local collection. COinS provides a great number of additional capabilities that URI microformat can't support. Since COinS can't be dismissed for this reason, it doesn't make sense to me to create yet another standard that does the same thing with so little savings.I will grant that the COinS is less intuitive.....