OpenURL est un protocole en cours de normalisation qui sert à créer des liens contextuels. Concrètement, il s’agit de lier des métadonnées (par exemple, les références bibliographiques d’un article) à la ressource elle-même (l’article en plein-texte).

Vous me direz, un protocole de métadonnées, très bien, on en a déjà qui fonctionnent parfaitement, OAI par exemple. Oui mais là, il ne s’agit pas d’un simple lien, mais d’un lien contextuel. Pour une ressource (toujours notre article) on connaît le contexte dans lequel elle est citée (la bibliographie qui la cite), décrite (les métadonnées de l’article et qui les a rédigées), utilisée (le lecteur qui la recherche et les droits dont il dispose), et la façon dont on utilise le protocole (quel résolveur, pour obtenir quel service) pour la lier à ce qu’elle décrit (l’article lui-même).

En fait, la norme OpenURL Framework se compose de trois choses

• le ContextObject : le paquet de métadonnées qui contient les informations sur une ressource et son contexte
• l’OpenURL proprement dit : un protocole de transport de ces paquets basé sur HTTP
• le registry qui contient les spécifications des différents éléments constitutifs des ContextObjects et de l’OpenURL.

Qu’est-ce qu’un ContextObject ?

Il s’agit d’un paquet de métadonnées qui décrivent une ressource et son contexte :

• les métadonnées elles-mêmes (referent)
• leur source : qui a rédigé ces métadonnées (referrer)
• l’objet qui contient l’objet référencé par les métadonnées, par exemple la bibliographie où est prise la citation (referring entity)
• l’utilisateur qui demande le service (requester)

Plus au niveau du protocole lui-même :

• l’adresse du résolveur de lien utilisé (resolver)
• le type de service demandé par l’utilisateur, par exemple "obtenir le texte intégral de l’article" (service type entity).

Que peut-on mettre dedans ?

A l’origine, un ContextObject décrit une ressource bibliographique et son contexte. En réalité, on peut y mettre un peu ce qu’on veut… pourvu que les métadonnées soient dans le bon format.

Le format d’origine pour représenter les ContextObject d’appelle Key Encoded Value (KEV) Il repose sur des paires clef/valeur (par exemple : Nom=Paul).

Dans la deuxième version de la norme (OpenURL 1.0), on peut décrire les ContectObjects en XML, avec un schéma associé spécifique : le schéma XML ContextObject Format (CTX).

A cela s’ajoutent des métadonnées supplémentaires, que l’on peut soit inclure directement dans le ContextObject, soit référencer sous forme de lien (on donne alors l’adresse du schéma qu’elles suivent et l’adresse où on peut les trouver).

Les métadonnées stockées dans le ContextObject doivent suivre les formats de métadonnées autorisés, stockés dans le repository : en KEV on dispose de formats pour books / dissertation / journal / patent, et chacun de ces formats possède sa traduction en XML. En outre, pour le XML seulement, s’y ajoutent entre autres MARC21 et oai_dc.

Les métadonnées ajoutées sous forme de lien peuvent suivre n’importe quel schéma pourvu que celui-ci ait une adresse (URI) et qu’il soit dans le même langage que le ContextObject (soit KEV, soit XML, au choix).

Concrètement, comment ça marche ?

Sur cette question, j’ai été éclairée par le JC-blog et par un papier intitulé tout ce que vous avez toujours voulu savoir sur SFX sans oser le demander.
Les étapes sont les suivantes :

• quelqu’un crée un ContextObject. Par exemple, un éditeur de revues en lignes comme Elzevier. Ou alors, une bibliothèque avec son catalogue.
• le lecteur voit, à côté de la référence bibliographique, un bouton qui correspond à ce ContextObject.
• le lecteur clique, aussitôt le ContextObject est envoyé sous forme de requête HTTP à un résolveur de lien, qui analyse les métadonnées, les droits de l’usager et le service demandé.
• en fonction de ce qui a été spécifié pour l’interface, le résolveur trie les références auxquelles le lecteur peut avoir accès et écarte celles auxquelles il n’a pas accès.
• en réponse, le lecteur reçoit une liste de liens correspondant à sa demande, par exemple l’article complet chez Elzevier + l’article dans une archive ouverte. Mais pas l’article chez un autre éditeur pour lequel sa bibliothèque n’est pas abonnée.

Mais alors, quelles différences entre OpenURL 0.1. et OpenURL 1.0 ?

OpenURL 0.1 a été créé sur la base d’une architecture développée par un logiciel résolveur de lien nommé SFX. C’est à partir de ce produit qu’a été développée la standardisation du protocole de liens contextuels dans le cadre d’OpenURL.

L’OpenURL 1.0. repose donc en quelque sorte sur un retour d’expérience de l’utilisation d’OpenURL 0.1. La norme ainsi élargie a été spécifiée par un document soumis à approbation par NISO de janvier à mars 2004.

Ce qu’OpenURL 1.0 apporte par rapport à 0.1 :

• il intègre le XML
• les notions de « requester », « referring entity » et « service type entity » qui n’étaient pas proprement spécifiées auparavant
• il supporte plusieurs formats de métadonnées et de nombreux namespaces (parmi lesquels : DOI, identifiants OAI, URN, ISBN, ISSN …), et ce de manière extensible
• la 2e partie de la norme intègre la spécification du repository qui contient les spécifications des formats de description des objets contextuels (KEV et XML) + les formats de métadonnées autorisés + les namespaces autorisés + les spécifications de l’encodage des caractères + les spécifications des protocoles de transport des données + les « communautés de profils » qui définissent un mode d’exploitation choisi de la norme (il y en 2, une compatible avec la version 0.1 qui utilise KVE, l’autre étendue qui utilise XML).

Il en résulte que OpenURL 1.0 est d’application potentiellement plus large que la précédente car rien ne spécifie que la ressource décrite doit obligatoirement être d’ordre bibliographique.

En conclusion, OpenURL permet à des résolveurs de liens de lier des métadonnées, pourvu qu’elles soient encodées dans un certain format, à des ressources paramétrées, en tenant compte des droits de l’utilisateur et d’autres paramètres éventuels.

L’application la plus évidente est l’interconnexion des bases de données bibliographiques avec les bases de journaux en ligne, qui se fait directement et de manière quasi transparente pour l’utilisateur, grâce à ce protocole. Mais avec la norme 1.0, cette fonctionnalité pourrait être étendue, et il y a d’autres idées à creuser : booster le catalogue, faire des passerelles avec un entrepôt OAI… que sais-je encore.

Ressources

La norme

• ici et là

Publications

• Library Journal – The Lure of Linking
• Ariadne – The OpenURL and OpenURL Framework: Demystifying Link Resolution
• Du catalogue de la bibliothèque aux ressources du web : applications documentaires de la génération de liens contextuels par Marc Maisonneuve, Paris : ADBS Éditions, 2003 (revue dans le BBF)

Site Web

• celui du comité à l’origine de la norme avec une bibliographie et des powerpoints.