J’ai eu l’occasion de participer à OAI10, le CERN – UNIGE Workshop on Innovations in Scholarly Communication qui a eu lieu entre le 21 et le 23 juin à Genève. C’était la première fois pour moi, bien qu’en marge de précédents événements, j’avais déjà eu l’occasion de rencontrer certains de mes collègues actuels, alors que personne n’aurait imaginé que l’on puisse travailler un jour ensemble.

À noter que @grolimur avait mis en place des pads pour y prendre publiquement, et si possible de façon collaborative, des notes.

Ci-dessous un bref retour sur le workshop de Herbert Van de Sompel. Les supports de présentation sont en ligne et j’en donne une copie ici :

• oai10-signposting-overview.pdf
• oai10-resourcesync.pdf

SignPosting

SignPosting revient à ajouter des relations typées dans les entêtes de message HTML (HTTP Header). Ces types permettent d’indiquer la « nature » de la relation, afin de faciliter la navigation pour les clients (navigateur web, client Zotero, …). Par exemple, dans le HTTP Header d’une page d’un article, on pourra trouver le weblink suivant : link: <URI> ; rel="describedby".

Ce lien indique que cet article est décrit par les métadonnées située à l’URI donnée. L’intérêt du fait que l’information se trouve dans le HTTP Header est qu’elle peut donc être obtenue sans devoir afficher ou parser le contenu de la page elle-même. Les relations disponibles sont délibérément générales et devraient pouvoir s’appliquer à un grand nombre de cas. On peut indiquer une licence ou les métadonnées. À l’inverse, il est possible de pointer depuis les métadonnées vers le documents qu’elles décrivent (rel="describes"). Les relations sont définies par des RFC et il est possible d’ajouter ses propres relations, définies par une URI, mais elles ne seront pas reconnues par l’extérieur.

Les persistent identifier sont un cas intéressant. Le plus souvent, lorsque l’on atteint une page HTML contenant un article, l’URL qu’affiche le navigateur n’est pas nécessairement le PID de l’article, par exemple son DOI. Un weblink de type rel="identifier" permet de l’indiquer, ce qui peut faciliter la création d’un bookmark, ou le partage de la ressource.

Cette technique facilite aussi l’identification sur une ressource des liens qui concerne directement cette ressource, parmi la multitude de liens qui s’y trouve. Par exemple, rel="item" type="application/pdf" précise que l’URI ainsi typée représente une instance de la ressource au format PDF. De même, dans le cas des métadonnées, les weblink permettent de les trouver plus facilement et même d’indiquer leur format (par exemple du XML)

ResourceSync

ResourceSync est un standard développé pour résoudre les difficultés auxquelles le protocole OAI-PMH répond mal. Contrairement à son prédécesseur, ResourceSync s’appuie sur une approche Web et ne se préoccupe pas tant des archives institutionnelles que des ressources elles-mêmes, dont il ne considère pas seulement les métadonnées, mais également les contenus. Le standard s’appuie à la fois sur les sitemaps et un protocole de notification push, à savoir Pubsubhubbub, devenu WebSub.

Le standard considère la situation en ces termes : une source, à savoir un serveur, contient des ressources, c’est-à-dire n’importe quel objet numérique possédant un URI, qui changent au cours du temps ; des destinations, autrement dit des applications, utilisent les ressources de la source et pour ce faire a besoin de se mettre à jour en fonction des modifications des ressources de la source (ou des sources).
Il est utilisable avec des petites collections ou des archives complètes et de grandes tailles, permet des fréquences de synchronisation variables, selon les besoins et intègre une vérification de l’intégrité des ressources (bitstream accuracy basé sur un checksum).

Du point de vue de la destination, l’initialisation de la synchronisation avec la source passe par le baseline sync, puis, le suivi des modifications constitue le incremental sync et enfin l’audit afin de vérifier si l’on a bien obtenu ce que l’on était censé obtenir, à la fois en terme de couverture de l’ensemble des ressources visées que de l’intégrité de celles-ci.
Du point de vue de la source, il s’agit de publier un inventaire, une photo de l’état de l’archive au temps T, à savoir une liste d’URI, puis de publier les changements qui sont intervenus entre T_n et T_n+1, qui est également une liste d’URI correspondant à ces changements. Les changements peuvent également prendre la forme de notifications poussées par la source.

L’inventaire ne considère que les ressources existantes au moment T, ce qui implique que les ressources supprimées ne sont pas indiquées, pas même leur suppression. Ces suppressions seront plutôt présentes dans la liste des changements. Les notifications, elles, sont poussées via WebSub aux destinations qui s’y sont abonnées. Elles doivent forcément indiquer la période concernée.

Le framework est modulaire, il n’est pas obligatoire de l’implémenter en entier, mais il est possible de se concentrer sur les fonctionnalités répondant aux besoins de la communauté considérée. Il est possible de décrire les fonctionnalités implémentées en plus de décrire le contenu, les métadonnées et les changements qui ont lieu dans l’archive elle-même.

Au centre de ResourceSync se trouve le sitemap. On lui ajoute un namespace rs: qui supporte des liens (ln:) et des métadonnées (md:). Pour éviter des sitemaps trop volumineux, il est possible d’utiliser un index qui référence plusieurs sitemaps.
Par exemple, un inventaire (resource list), pourra être décrite ainsi dans le sitemap :

rs:md capability="resourcelist" at="[date au format ISO]"
rs:md hash="[…]" lenght="[…]" type="text/html"
rs:ln rel="index" href="[URL]"

XMPP aurait également pu être choisi pour les notifications, mais il a le principal désavantage de nécessiter l’ouverture de ports spécifiques, alors que WebSub utilise les ports standards du web. La liste des changements prendra également la forme d’un sitemap :

rs:md capability="changelist-notification" from="[date au format ISO]" until="[date au format ISO]"
rs:md change="created" datetime="[date au format ISO]"
rs:ln rel="up"` href="[URL].capabilitylist.xml"

Ce standard fait bien entendu partie des réflexions autour du NextGen Repositories. S’il y a peu d’espoir que les éditeurs commerciaux se mettent à le supporter d’eux-mêmes, les logiciels open source et les archives institutionnelles devraient le mettre en œuvre.