L’initiative OAI-ORE, développée dans l’environnement de l’Open Archive Initiative, vient de sortir en version « alpha » ses premières specifications. Depuis le début, je regarde d’un oeil attentif ces travaux qui me semblent répondre à pas mal de questions pertinentes dans l’environnement des bibliothèques numériques, comme par exemple celle de l’interopérabilité des objets complexes. En effet l’objectif d’ORE est de rendre « machine readable » des descriptions de documents complexes qui sont présents sur le Web. Autrement dit, passer du Web de documents au Web of data…

Dans la partie « Abstract Data Model » de la spec, j’avoue trouver avec bonheur certaines de mes grandes espérances puisqu’il y est largement question des technologies du Web sémantique. Je vais essayer d’expliquer le modèle de façon simple (ce n’est pas évident car il est décrit dans la spec de façon embrouillée, si je peux me permettre – c’est une version alpha…)

L’objectif d’ORE est d’échanger des descriptions de ressources qui s’agrègent les unes les autres de façon très souple. Un regroupement (intellectuel en général) de ressources est appelé Aggregation et est obligatoirement décrit par un document unique, la Resource Map. Cette Resource Map est un ensemble de triples en RDF, qui décrivent l’Aggregation elle-même, les ressources qu’elle agrège, et leurs relations entre elles et avec des objets extérieurs. Certaines relations sont imposées (notamment celle entre Resource Map et Aggregation) et donc il y a des « triples obligatoires » dans la Resource Map.

Le modèle est très souple en ce qui concerne les ressources elles-mêmes, leurs agrégations, leurs métadonnés, les relations. Une ressource agrégée peut par exemple être aussi une agrégation d’autres ressources. Une même ressource peut être agrégée par plusieurs agrégations. Etc.
Par contre, la notion de Resource Map est beaucoup plus contraignante : elle ne décrit qu’une seule agrégation, elle a des métadonnées obligatoires (un créateur pour la « confiance », et un « timestamp » pour gérer les mises à jour), et on doit pouvoir la représenter dans un format (la « sérialiser » comme ils disent). Bref, la Resource Map est un document.
Comme c’est un document, elle a elle-même un identifiant (une URI), on parle alors de « Named Graph » (traduction en français ?) Cette notion de Named Graph me semble assez complexe, j’avoue que je n’ai pas trop compris mais cela semble être un truc qui sert à attacher des triples ensemble, donc à transformer des données en documents.

On peut exprimer une Resource Map avec un profil ATOM. C’est même la seule solution proposée pour l’instant (même si ce n’est qu’une façon possible, en théorie n’importe quelle méthode pour encoder des triples en RDF pourrait faire l’affaire, d’autres formats sont envisagés pour l’avenir comme GRDDL.)

Quelques remarques : tout cela me donne l’impression d’une conception qui ne va pas au bout de ses ambitions. Bien sûr le modèle est très souple et on pourrait sans doute l’utiliser pour rendre interopérables plein de formats d’empaquetage comme METS, MPEG21 DIDL, etc. En s’appuyant sur RDF, il s’abstrait des problèmes d’interopérabilité que pourrait poser une souplesse aussi absolue.
Mais quand même, il y a un truc qui me chiffonne, c’est qu’en théorie, en RDF on pourrait s’abstraire de la formalisation d’une carte de structure telle qu’elle est proposée par la Resource Map. Quand on RDFise on rend la structure du « document » implicite puisqu’on atomise la granularité. Il doit donc y avoir un intérêt (que là tout de suite je ne vois pas) pour lui ré-imposer un format de « document » et vu que le format de document est Atom, je suppose que c’est pour pouvoir échanger des « documents » entre des machines (comme on fait avec RSS). On voit bien ici l’héritage du protocole OAI, qui sert à échanger des « notices » (qui sont elles-mêmes des sortes de documents, enfin on pourrait en discuter).
Je ne peux pas dire pourquoi mais je le ressens comme quelque chose de rigide. C’est du RDF mais… pas du vrai Web of Data.
Finalement ce qui me gène c’est l’équivalence 1- 1 entre la Resource Map et l’Aggregation. A quoi bon être si rigide, pour permettre ensuite une récursivité presque délirante dans les niveaux en-dessous ? C’est comme si on mettait de façon artificielle un couvercle sur une casserole sans parois ;-)

Et les spécialistes, ils en pensent quoi ? Les geeks, c’est à vous. Pardon pour les autres qui n’ont rien compris à ce billet.