Skip to content

Zotero : vers la fin de l’OpenURL ?

25/05/2010

Je ne sais si comme moi vous avez passé du temps, ces dernières années, à comprendre comment fonctionne l’OpenURL, ce qu’il permet, etc.

Si ce n’est pas le cas… non, cette fois-ci je ne vous renverrai pas aux différents billets antérieurs sur ce sujet. Car une discussion en cours dans le groupe des développeurs de Zotero laisse entendre que les jours de ce format sont comptés.

J’avoue que je n’en vois pas encore toutes les conséquences, mais plutôt que d’y réfléchir seul, je m’empresse de vous en traduire certains passages afin que vous puissiez d’emblée vous en faire une idée.

L’intégralité de la discussion peut se suivre ici.

Tout est partie de la demande de quelqu’un voulant savoir quel était la meilleure manière d’intégrer des métadonnées bibliographiques dans un wiki, de manière à ce qu’elles puissent être récupérées par Zotero.

Certains intervenants le renvoient au mode de référencement biblio dans Wikipedia, et évoquent les COinS, c’est-à-dire la possibilité d’avoir, de manière cachée dans une page web, les métadonnées au format OpenURL.

Intervient alors Erik Hetzner, dont je traduis le message avec son aimable autorisation :

(en italiques, il cite des messages antérieurs)

Une partie de cette intégration [pour rendre le site zotero-compatible] consiste essentiellement à exposer les données pour être récupérées par Zotero. Les COinS OpenURL nous semblent le choix adapté.

COinS est un bon point de départ parce que c’est un standard qui peut être embarqué dans une page web. Notez que les objets contextuels [context objects] ont un avenir limité car un format plus riche (comme RDF) finira sans doute par les remplacer

Excusez-moi par avance pour jouer les trouble-fête.

Avec tout le respect que je vous dois, je doute que les COinS soient un choix pertinent. Ce n’est pas un standard, une recommandation ou un projet d’internet, c’est une manière très compliquée d’embarquer  [embed] des métadonnées dans du code HTML, et pour ma part je n’ai pas l’intention d’utiliser l’OpenURL, de perdre mon temps à apprendre ses idiosyncrasies.

Je ne suis pas non plus satisfait des unAPI, même si j’en pense beaucoup plus de bien que des COinS. Ça utilise un mécanisme particulier, spécifique aux unAPI, qui pourrait facilement être remplacer avec des lien, du bon vieux HTTP et de la content negociation [expression que je suis incapable de traduire]. […]

Quand on visite « Rendez votre site Zotero-compatible », il est conseiller d’utiliser l’une de ces deux solutions. Pour le projet sur lequel je travaille actuelleemnt, ce que je voudrais est diminuer la charge de travail pour que ce qui supporte les linked data supporte aussi Zotero. Voici quelques pistes pour l’obtenir.

Par exemple, comment faire savoir à Zotero comment récupérer les métadonnées d’un item en utilisant au choix la content negociation ou une URI différente ? Dans un contexte de linked data, si j’ai une URI A qui représente un livre (une ressource non-informationnelle), et une URI A’ qui est une description en HTML de ce livre, comment puis-je faire en sorte que Zotero signale à un utilisateur lisant A’ qu’il existe aussi une représentation alternative de A’ qui fourni des métadonnées identifiables par une machine [machine-readable] à propos de A ?

Ainsi, je peux imaginer répondre à ce besoin dans le <head> de la page HTML de la manière suivante :

<link rel="alternate" type="application/rdf+xml" href="">">

Permettant ainsi à Zotero de savoir qu’une représentation RDF de l’information contenue dans A’ est disponible à l’endroit signalé.

Et sur une page contenant des résultats de recherche, je pourrais mettre :

<div xmlns:dc="http://purl.org/dc/elements/1.1/"
about="/a_book">
<span property="dc:creator">John Doe</span>.
<a href="/a_book"><span property="dc:title">A book</span>.</a>
<a type="application/rdf+xml" href="/a_book"/>
</div>

Certes, c’est un peu compliqué de combiner RDFa avec des liens fournissant plus d’informations, mais j’obtiens ainsi des métadonnées sur un livre et un lien vers toutes les métadonnées sur ce livre.

Quand il y a quelque temps j’ai travaillé un peu au développement de Zotero en implémentant un unAPI, j’aurais préféré, pour aller plus loin, pouvoir garder ce temps de développement pour du linked data pour Zotero. […]

Dans les messages des intervenants suivants, on trouve notamment :

[Avram Lyon] L’idée d’utiliser RDFa a déjà été évoquée par les développeurs de Zotero. Etant donné qu’OpenURL/COinS n’est apparemment plus développé [voilà une info nouvelle pour moi, que je n’ai pas contrôlée], il y a peu de chances que soient fixés les bugs existants (champs manquants, pas d’auteurs multiples). Heureusement, RDFa devrait pouvoir être implémenté assez facilement, ce qui supprimerait le besoin d’un unAPI.

[Bruce d’Arcus] Exemple d’encodage de notice bib produite par un style (feuille CSL) en cours de réalisation
<li property="dc:references">
<span property="dc:creator" typeOf="foaf:Person">
<span content="Jane" property="foaf:givenname">J.</span>
<span property="foaf:surname">Doe</span>
</span>
<span property="dc:creator" typeOf="foaf:Person">
<span content="John" property="foaf:givenname">J.</span>
<span property="foaf:surname">Smith</span>
</span>
<span property="dc:title">Some title</span>
<span prefix=", " property="bibo:volume">12</span>
<!-- the below prefix funkiness if for debugging -->
<span prefix=" else-if 2 WORKS " property="bibo:isbn">34239845</span>
</li>

[Erik Hetzner] J’aurais besoin pour Zotero

1.  d’une manière simple de lier des métadonnées lisibles par des machines [machine-readable] dans un format compris par Zotero (comme MARC ou MODS), par exemple en utilisant une balise <link>

2. d’un outil d’extraction des données pour RDFa, utilisant sans doute une ontologie bibliographique [dans un message précédent, Bruce d’Arcus a renvoyé au site http://bibliontology.com/example]

Je pense 1) que ce serait plus simple que d’implémenter un unAPI, et plus en phase avec les linked data ; et 2) que c’est une bonne manière d’avancer dans l’embarquement de métadonnées dans du HTML, encore une fois en phase avec les linked data

[Bruce d’Arcus] Je pense que nous devons cesser de penser en terme d’intégrations de notices bibliographiques et plus en partage de données [shared data]

Conclusion

Aucune pour le moment. Je ne suis pas un spécialiste du web des données, du RDFa et des triplets, et en plus cette discussion est encore en cours.

Ce qu’il faut retenir, c’est que le web ne se mettra pas à l’OpenURL : si Zotero lui-même commence à chercher des alternatives, c’est que les sites « normaux » ne seront jamais motivés.

Amazon et Google ne soutiendront et ne produiront sans doute jamais « naturellement » d’OpenURL (Google le fait pour Google Scholar, ce qui est une manière certes intéressante et pertinente, mais limitée de le faire).

En revanche, on sait que Facebook a décidé d’entrer (à sa manière) dans le web des données. Google y est déjà, évidemment. Pour Amazon, je ne crois pas (je n’ai rien vu passer à ce sujet, en tout cas). Mais manifestement c’est vers ça que l’on va. Et les bibliothèques ont tout intérêt à ne pas se conserver leurs petits outils dans leur coin.

Le dernier billet de Manue va exactement dans le même sens : les bibliothèques ne sont pas des gens à part (ou, pour mieux dire encore, les bibliothécaires sont des documents comme les autres :-)).

OpenURL était une manière d’être en avance dans l’embarquement de métadonnées, la facilitation de leur libre circulation.

De même que les formats Marc étaient en avance. Dans les années 1970.

Donc pour l’instant, ma seule conclusion est :  suivez bien le mouvement, car il se pourrait que dans quelques mois ou années il soit complètement has been d’acheter un résolveur OpenURL — en ce sens que d’autres outils, non bibliothéconomiques, proposeront bien plus et bien mieux.

Et ce sera vraisemblablement à nous, bibliothèques, de réclamer des éditeurs de logiciels de faire évoluer leurs produits pour nous proposer, non plus des résolveurs OpenURL, mais des résolveurs RDF (quoique cette dénomination soit certainement une hérésie — Got, ne passe pas par là !). Cette demande doit passer par des cahiers des charges, par des groupes d’utilisateurs, par des remarques informelles, etc. Mais elle devra passer.

Précision : je ne suis pas alarmiste ni prophète, je ne suggère pas de jeter les résolveurs OpenURL aux orties, je pense que les bibliothèques qui sont en train de lancer un marché pour avoir un résolveur ont tout à fait raison de le faire car aucun autre outil à l’heure actuelle ne peut rendre des services identiques. Je voulais juste signaler que se profile déjà un début de commencement d’avenir, et que sans forcément nous positionner aujourd’hui, il faut au moins en suivre l’évolution.

6 commentaires
  1. B. Majour permalink
    25/05/2010 11:24

    Content negociation : http://fr.wikipedia.org/wiki/N%C3%A9gociation_de_contenu

    Bon, pas très parlant.
    Surtout qu’il s’agit plutôt d’une interface qui est comme une gare de triage suivant les capacités des navigateurs.

    Bien cordialement
    B. Majour

  2. 25/05/2010 11:31

    @B. Majour : merci pour le renvoi à la Wikipedia (pour une fois, je n’y avais pas pensé :-()
    Ce n’était pas tant la définition que je cherchais, qu’une expression convaincante pour traduire l’expression anglaise. D’où mon choix de le laisser en anglais. Dans le contexte, comprendre qu’il s’agit grosso modo de manipuler des données peut suffire…

  3. bibliogum permalink
    09/12/2012 13:21

    Pour que les choses restes claires dans ma tête : openURL est le standard sur lequel s’appuie les résolveurs de liens aujourd’hui mais si demain il devient plus mieux d’utiliser RDFa (qui a déjà bien poussé les COinS dehors cf. sur en.wikipedia), il faudra toujours un résolveur+kb pour faire le lien avec le full text ?

  4. 10/12/2012 09:38

    C’est à peu près ça mais pas tout à fait (je peux déjà répondre à la question finale : oui, « il faudra toujours etc. »)
    L’OpenURL permet de structurer des URL d’interrogation avec une syntaxe standardisée pour les différents paramètres (le titre d’article sera atitle=, etc.)
    Donc la question est : est-ce que les bases de données vont continuer de savoir réagir à cette syntaxe ou non.

    Ensuite, il y a le côté COinS : pour proposer dans une page web des métadonnées bib structurées de manière à générer un lien OpenURL, les balises <span> étaient la solution retenue.
    Et un plugin ou une bookmarklet activait ces COinS pour les faire précéder de l’URL racine du résolveur OpenURL.
    Mais à partir du moment où les métadonnées sont présentes de manière structurée dans la page web, en utilisant la syntaxe RDFa, la question est : comment le navigateur génère-t-il un lien permettant d’interroger un résolveur.
    Rien n’empêche de bricoler une extension Firefox ou Chrome qui identifie les métadonnées bibliographiques RDFa dans les pages, pour produire, à l’affichage de la page, des liens cliquables (avec URL racine pré-renseignée par l’internaute dans son navigateur) qui concatènent les différentes informations fournies pour proposer un lien OpenURL pointant vers le résolveur.

    Mais oui, il faut un résolveur et une base de connaissance, puisque pour un même article référencé dans une note de bas de page Wikipedia, un Parisien n’utilisera pas les mêmes collections qu’un Niçois (par exemple) pour aller consulter ledit article.

Trackbacks

  1. Cactus Acide » » L’observatoire du neuromancien 05/25/2010
  2. post_hebdo (weekly) « Boîte de conserve

Les commentaires sont fermés.

%d blogueurs aiment cette page :