Skip to content

Pourquoi SFX n'est plus vraiment incontournable

24/02/2009

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.

Publicités
13 commentaires
  1. dbourrion permalink
    25/02/2009 13:14

    Quelques ajouts/réflexions :

    1. La base de connaissance (KB pour Knowledge Base) a un coût annuel, effectivement. Ou plutôt, ses mises à jour ont un coût, en proportion de la licence SFX

    2. La question de l’icône ne compte pas (ça se remplace 😉 )

    3. Au-delà de ça, je ne sais pas quelles sont les fonctionnalités que propose un résolveur uniquement logiciel (stats, BDD des abonnements actifs, etc…) : est-ce que le vôtre, de résolveur, proposait de tels outils qui font que SFX est presque (j’ai dit presque) un début d’ERM…

    4. La KB peut servir / sert aussi de « bases de données » sur les contenus des bouquets, etc… L’on peut en extraire des trucs du genre : tous les URLS du DOAJ – tu te souviens, le fichier avec lequel je t’ai saoulé ?… – qu’on va utiliser par ailleurs

    5. Mais tout ça, c’est (presque) des détails. Je m’explique : il me semble que la question n’est pas SFX ou autre chose, mais : comment se fait-il que seulement 30 % environ des bibs ont un résolveur de liens (avec KB ou uniquement logiciel) ? Le choix de telle ou telle solution, telle ou telle configuration, est presque secondaire. Y entrent divers éléments commerciaux (ça c’est le boulot des partenaires commerciaux) ; et budgétaires ; et fonctionnels (la bib a quelqu’un d’assez autonome pour bosser comme ça ou comme ça, ou pas) ; et « psychologiques » (le fait de payer pour une KB peut rassurer, etc).. Et effectivement, chacun peut/doit se poser la question que tu poses au moment du choix du résolveur.

    Mais d’abord, il faut avoir compris l’énorme intérêt d’un résolveur…. D’où ma question : pourquoi aussi peu de résolveurs en production ? Personnellement, c’est ça qui m’interpelle d’abord.

  2. 25/02/2009 15:29

    @dbourrion : Merci de ces précisions
    Point 2. Sur l’icône je suis d’accord : j’incriminais plutôt les bibliothèques qui la laissaient telle quelle. Mais c’est un aussi un choix qui peut s’expliquer (si si, certainement).
    Mais je n’ai pas encore trouvé vraiment d’icône convaincante. Les liens OpenURL présents dans Jubil (portail doc de l’UPMC-Paris 6) sont sous cette icône :
    Mais quand on est sur une base distante (OvidSP, etc.), je faisais apparaître le logo de Jubil, en espérant faire comprendre à l’internaute qu’on allait ainsi basculer sur le portail pour interroger nos ressources.

    Point 3. Non non, notre résolveur faisait juste résolveur, càd transition entre une requête OpenURL et nos ressources papier+en ligne.
    Mais du coup, ça veut dire que quand on rédige un cahier des charges, il faut ajuster les questions en connaissance de cause : cherche-t-on un résolveur ou un truc qui fasse aussi plein de choses genre Gestion & signalement de ressources électroniques ?
    C’est aussi pour insister sur cette distinction que j’ai rédigé ce billet : si l’achat d’un SFX fait peur, au moins il faut se hâter d’avoir un « simple » résolveur.

    Point 5. Pourquoi crois-tu que je multiplie les billets sur l’OpenURL et ses possibles applications ? Parce que la plupart des collègues ne perçoivent pas encore complètement l’évidence d’un tel outil, son caractère indispensable, dont la nécessité se place au même plan que l’Opac lui-même, et bien devant tout ce qui est à la mode en ce moment :

    Pages de couverture en couleurs

    Possibilité de tagger et commenter

    Interface de recherche à la Google

    Et même devant les fils RSS sur des requêtes, pq ses applications sont bien plus larges (et il est plus difficile de bricoler un résolveur qu’un fil RSS : cf. mon billet sur le Sudoc !)

    Conclusion : je vais continuer mes billets sur l’OpenURL (faut que je trouve des sujets d’accroche).
    Et je serais intéressé que tu développes un jour le bénéfice de ces mises à jours à la base de connaissances (ce que ça apporte en terme de services), par rapport à un résolveur OpenURL qui ne serait qu’un intermédiaire entre une requête OpenURL et les ressources locales d’une bibliothèque.

  3. ShaunleMouton permalink
    25/02/2009 15:54

    La question que je me pose ardemment est: l’utilité théorique d’un résolveur peut être évidente… maintenant, dans les bibliothèques qui l’ont mis en place, est-ce réellement utilisé par les utilisateurs (=chercheurs=faible proportion des usagers de la bibliothèque= coût énorme par usager)???
    Le doute m’assaille…

  4. 25/02/2009 16:45

    Vous vous posez la même question pour les fils RSS ?
    Ou une question alternative : l’Opac est-il réellement utilisé par nos lecteurs à proportion du temps que nous y passons ? Probablement non. Faut-il arrêter de cataloguer ?

    Pour répondre plus sérieusement : les outils disponibles induisent eux-mêmes des comportements.
    Il y a des outils à inventer pour les résolveurs OpenURL. Quelle BU disposant d’un résolveur propose sur son site de télécharger le plugin OpenURL Referrer préparamétré (avec le résolveur de la bib par défaut au lieu de http://resolver.ukoln.ac.uk/openresolver/) ?
    Quelle BU propose un téléchargement de Zotero avec le résolveur préparamétré ? Car dans Zotero, il y a un bouton « Préférences » avec un champ OpenURL > serveur de résolution, où la valeur par défaut de ce champ est : http://worldcatlibraries.org/registry/gateway. Quand un chercheur consulte une notice d’article sur Zotero, il a ainsi un bouton « Localiser » qui lui permet d’aller sur le résolveur OpenURL de la bibliothèque.

    En outre, les utilisateurs s’en servent probablement sans le savoir : quand ils vont sur Google Scholar depuis un poste de l’Université, un lien vers leur BU leur est proposé d’office.
    Idem pour les bases du Web of Science ou d’OvidSP, si le responsable de la doc élec a indiqué à ses fournisseurs l’URL de son résolveur (mieux : quand on achète SFX, Ex Libris vous déclare auprès des fournisseurs).
    A Jussieu (où nous n’avions pas SFX) nous avions déclaré notre résolveur auprès des éditeurs IEEE et IOP. Ainsi, quand un lecteur lisait un article et consultait les références biblio de cet article, un lien OpenURL apparaissait (il était forcément reconnu, de par son IP comme venant de l’UPMC) pour lui permettre de trouver l’article en ligne en deux clics.

    Donc les bibliothécaires doivent comprendre toutes les possibilités de l’OpenURL, pour en déduire les outils adéquats qui permettraient à l’utilisateur de ne pas avoir à connaître le mot « OpenURL ». Ils-z-en ont de la chance !

    Enfin, j’ignore le coût d’un résolveur posé tel quel. J’ai du mal à croire qu’il soit si énorme si ce n’est pas SFX mais le simple développement d’un outil Open source. Quelqu’un a une idée de l’ordre de grandeur ?

  5. dbourrion permalink
    25/02/2009 18:24

    @ShaunleMouton : l’utilité d’un résolveur n’est pas théorique, loin de là ! Il suffit d’en utiliser un une fois (souvent sans s’en rendre compte, nos usagers ne se doutent sans doute pas qu’ils utilisent un résolveur et heureusement pour eux…)

    Le résolveur met le plein texte d’un article à UN clic de sa référence en BDD bibliographique (cf. http://detoutsurrien.wordpress.com/2009/02/10/moins-cest-mieux/) quand la bibliothèque est abonnée à la ressource ; et rapproche l’usager au maximum de la ressource quand la bibliothèque n’y est pas abonnée.

    Sans résolveur, votre usager effectue sa recherche en BDD biblio, note les références, repart dans votre catalogue ou votre abédaire, recherche la revue, s’y connecte, recherche la bonne année, le bon numéro, la bonne page, etc… se perd ; s’aperçoit que la bib n’est pas abonnée…

    Et la documentation électronique ne concerne pas que les chercheurs : le résolveur marche dans tous les sens, genre vers Factiva, etc…

    Bref, pour moi, le résolveur est essentiel aussitôt qu’il y a doc. électronique (c’est dire…)

  6. 25/02/2009 20:47

    @dbourrion : et moi, je milite en permanence pour insister sur l’intérêt d’un résolveur entre catalogues d’imprimés (Sudoc -> catalogue local, par exemple), donc même sans doc élec.

  7. Sylvain permalink
    01/03/2009 13:29

    Encore un article très intéressant et qui pose de bonnes questions sur l’openurl.

    Je n’avais pas pensé aux possibilités offertes par crossref en terme de construction d’url, mais ce résolveur nécessite quand même que la bibliothèque soit inscrite (même si ça a l’air gratuit dans la plupart des cas http://www.crossref.org/03libraries/index.html). Mais peut être que les bibliothèques sont déjà souvent inscrites, je ne sais pas.

    Sinon en ce qui concerne les solutions opensource, même pas besoin de développer quelque chose from scratch, il existe déjà des choses ( http://www.openlinker.org/ par exemple). La version 0.1 de la norme est très basique et il n’est pas compliqué de faire le résolveur, d’autant qu’il existe déjà des sources accessibles pour traiter les openurl (en perl : http://search.cpan.org/~timbrody/URI-OpenURL-0.4.6/ par exemple).

    Mais comme je le disais dans mon mémoire (http://memsic.ccsd.cnrs.fr/mem_00000613/fr/) le problème d’un outil open source ne vient pas de l’outil en lui même mais de la KB. Car cette kb intègre comme tu le notes la construction des liens vers la cible, ce qui est une chose (et en effet si on part sur crossref, ou sion mise sur le fait que de plus en plus de cibles acceptent les liens openurl en entrée, ce besoin deviendra moindre), mais cette kb intègre aussi les périodes de couvertures des différents périodiques (avec éventuellement intégration des embargos), et comme l’indique Daniel, la possibilité de définir des bouquets.

    Même si cette information est disponible par ailleurs (dans un ERM ou dans le catalogue de la bibliothèque), il faudrait pouvoir interroger de manière dynamique l’ERM ou le catalogue sur ces informations, on passe alors à du développement spécifique dont le coût risque de dépasser celui de la base de connaissance fournie par l’éditeur du résolveur.

    Mais si tu as des idées sur les possibilités de ne pas avoir à faire un nouveau signalement des périodiques s’il est déjà fait par ailleurs, ça m’intéresse (à moins que ce soit déjà expliqué dans le billet et que quelque chose m’ait échappé)

  8. 02/03/2009 09:49

    @Sylvain : L’inscription à Crossref est effectivement gratuite. Elle s’est faite sans difficulté pour nous. Elle est imposée quand on dépasse un certain nombre de clics/jour. J’ignore comment une bibliothèque est censée évaluer le nombre de clics en question pour savoir s’il lui faut s’inscrire ou non, mais dans le doute…

    Sur le point 2 : Effectivement, on peut estimer que la base de connaissance SFX est beaucoup plus intéressante qu’un résolveur sans base, parce que beaucoup plus intelligente : elle ne renverra pas vers un article si la bibliothèque possède la revue, mais pas pour l’année de parution de l’article.

    Mais là où je voulais en venir avec mon billet, c’est qu’à mon avis pour acheter un résolveur, une bibliothèque ne doit pas être arrêtée par l’ampleur des fonctionnalités (et éventuellement des coûts) d’un logiciel proposant une base de connaissances : sans base de connaissance, un résolveur rend déjà d’énormes services.
    C’est dans cette idée qu’il est aussi indispensable (selon moins) qu’un catalogue en ligne : on n’attend pas du catalogue qu’il soit le parfait reflet de la collection (après récolement intégral, dédoublonnage des notices d’autorités, etc.) pour le mettre en ligne.
    Même sans collection numérique, il est utile de disposer d’un résolveur : notamment parce que cela me permet, si je navigue tranquillement sur Internet, de profiter des COinS qui prolifèrent (cf. ces références Wikipedia, par exemple) de plus en plus automatiquement. Comme j’espère les trouver bientôt dans tous les catalogues de bibliothèques, j’espère pouvoir rebondir rapidement de n’importe quel catalogue vers le mien (actuellement, seulement WorldCat et certaines implémentations de Koha).
    Dans cette perspective, il n’est nul besoin de base de connaissance.

    La base de connaissance, c’est l’origine du résolveur OpenURL : associer aisément des références d’articles en ligne aux articles eux-mêmes. Depuis, l’utilisation de ce standard est multiforme — et l’essentiel de ses potentialités reste sans doute encore à inventer.

  9. 02/03/2009 10:20

    Ayant reçu un mail (tout à fait courtois, je précise, et surtout explicatif) d’Ex Libris, j’ai corrigé dans le billet certaines formulations qui ne semblaient pas forcément claires (et rajouté une note de bas de page sur la question de l’icône SFX), et j’ajoute ici certaines de leurs précisions pour lesquelles je ne trouve pas vraiment de place :

    Sfx n’est pas un résolveur de liens ‘simple’. Il comporte plusieurs ‘modules’ publics qui sont autant d’outils permettant à l’usager d’aborder vos collections de périodiques électroniques: une liste AZ de titres de périodiques électroniques et imprimés, un menu SFX contextuel proposant des services (texte intégral, localisation dans des catalogues, formulaire de PEB, Remarques à l’institution, etc) et un formulaire de recherche CitationLinker pour savoir immédiatement si l’institution propose le texte intégral pour un article ou un ebook ou à défaut des services alternatifs. A tout ça s’ajoute des fonctionnalités supplémentaires (liste AZ que l’usager peut intégrer à son navigateur, présentation des requêtes effectuées par les autres institutions…). Une seule interface d’administration permet de paramétrer les collections et de calculer les services que l’institution veut présenter à ses usagers. C’est un outil de guidage pour les usagers afin de les amener vers le service le plus pertinent en fonction de sa requête.

    Donc d’emblée SFX est plus qu’un résolveur, en réalité. Ce qui est une très bonne chose ; la bibliothèque doit donc définir en amont ce dont elle a besoin : un résolveur… ou davantage. Ce qui rend difficile la comparaison entre les différents logiciels, et difficile la rédaction d’un cahier des charges (on risque de viser précisément SFX, ou de viser complètement à côté).

    Pour les catalogues de bibliothèques, il peut effectivement y avoir un PlugIn z3950. Il a pour but, à partir des métadonnées de l’OpenURL (généralement ISSN ou ISBN) de savoir si un document existe dans le catalogue. La réponse sera Oui ou Non (0 ou 1). Si le catalogue donne une réponse positive, le service ‘rechercher ce document dans le catalogue’ est proposé à l’usager.

    Voilà une fonctionnalité extrêmement séduisante, je l’avoue : un rebond vers le Sudoc, par exemple, notamment si ma bibliothèque n’a pas la revue ou le livre qui m’intéresse.
    Le rebond PEB, également proposé par SFX, est une fonctionnalité intéressante.
    Là encore, cela permet de distinguer ce qui est du pur « Résolveur OpenURL » et ce qui est services supplémentaires.

    Merci à eux pour ces précisions.

  10. shaun le mouton permalink
    05/03/2009 15:19

    pour poursuivre sur l’usage:
    – les BU qui ont mis SFX en place ont-elles procédé au préalable à une étude d’usage de leur documentation?
    – une idée chiffrée de l’usage de SFX?
    – proportion de sources openURL consultées? (sachant que a ma connaissance aucune source francophone ne l’est et que sans openURL aucun gain particulier par rapport à Google Scholar)…
    – hormis le plein texte, que proposez-vous comme service? J’ai fait un tour d’horizon en France et étranger et hormis parfois Google Books ou Scholar… quel gain?
    – enfin, peut-on avoir un retour sur la constitution en local de la base de donnée. Par-ce que de ce que j’en ai vu, c’est un travail de titan dans un pauvre tableur excel avec marcos et compagnie sur des centaines de lignes…

  11. 05/03/2009 17:13

    @Shaun :
    1. Je n’ai aucune statistiques sur personne.
    2. Qu’est-ce que tu appelles « Source OpenURL consultée » ?
    Qu’est-ce que ça signifie « qu’aucune source francophone ne l’est » : qu’elle n’est pas OpenURL ou qu’elle n’est pas consultée ?
    Il y a peu de bases de données francophones. Francis et Pascal (sur OvidSP) peuvent être en français, et peuvent produire des liens OpenURL
    Ensuite, une page comme celle-ci est française et contient des liens OpenURL (il suffit d’avoir OpenURL Referrer pour les voir)
    3. Hormis le plein texte ? Ma foi, c’est déjà énorme.
    L’OpenURL, ce n’est pas que du plein texte : c’est un standard d’encodage de métadonnées bibliographiques : votre page HTML stocke des métadonnées de manière structurée. Il me semble que les usages restent encore à inventer, mais sur une page comme ça on trouve l’accès au formulaire de demande de PEB + relancer la requête dans le Sudoc.

    En fait les possibilités, encore une fois, reste à inventer. L’objectif de base de l’OpenURL, c’est de permettre à l’usager de transférer des métadonnées (titre, auteur, ISSN, etc.) d’une application à l’autre en 1 clic (et en ignorant ce que sont des métadonnées et ce qu’est l’OpenURL).
    Il est clair qu’on n’a pas encore fait le tour de toutes les applications que ça peu impliquer.
    Après, il faudrait voir ce que ça apporte réellement d’avoir un écran surchargé de services, avec un résolveur qui propose à la fois (pour un article donné) :
    – l’accès au texte intégral
    – un lien le Sudoc
    – un lien vers une demande de PEB
    – un lien pour rechercher les articles citant celui-ci sur Google Scholar
    – la même chose, mais sur le Web of Science
    – des revues portant sur le même sujet que la revue où est paru l’article en cours
    – etc., etc.

    4. Tu parles de « constitution en local de la base de données ». Je dois comprendre « Base de connaissance » ? Si c’est le cas, je le redis encore une fois : ON PEUT AVOIR UN RESOLVEUR DE LIENS SANS BASE DE CONNAISSANCES, uniquement avec son catalogue de revues en ligne et son catalogue de documents imprimés (périos et livres).
    Bien sûr, ça rendra moins de services, mais ce sera déjà énorme : partout où il y aura des métadonnées, je pourrai cliquer dessus pour savoir si ma bibliothèque peut me proposer le document.
    De toute façon, on entretient déjà des catalogues de revues en ligne et des catalogues d’imprimés : donc aucun travail supplémentaire.

Trackbacks

  1. Retour sur SFX « Encore un biblioblog…
  2. OpenURL : si vous avez raté le début « Encore un biblioblog…

Commentaires fermés

%d blogueurs aiment cette page :