Au départ, Dublin Core, ça a l’air simple : il y a 15 éléments, tous facultatifs et répétables, et voilà.

Après, ça se complique : à ces 15 éléments (le Dublin Core dit « simple ») vient s’ajouter le Dublin Core qualifié, dans lequel on dispose d’attributs pour préciser le sens des 15 éléments de base.
Par exemple, pour prendre un truc simple et connu, on peut qualifier l’élément DC:coverage par l’attribut « spatial » ou « temporal ».

En fait, le DC qualifié n’est qu’une manière d’utiliser les Dublin Core metadata terms (DC terms), une liste d’éléments de métadonnées maintenus par le DCMI (Dublin Core metadata initiative).
Certains de ces éléments de métadonnées correspondent aux 15 éléments de base.
D’autres correspondent à autre chose : notamment des propriétés (isPartOf, isFormatOf etc.), des référentiels complémentaires (comme par exemple la liste des types qu’on peut utiliser dans DC:type), etc.

Tout ça fait partie d’une logique commune, le Dublin Core Abstract Model (DCAM), qui a la couleur du RDF, la saveur du RDF, mais… n’est pas du RDF.

Après, il y a différentes méthodes pour encoder le Dublin Core : en HTML, en XML, en RDF.
Dublin Core simple et qualifié correspondent à des schémas d’encodage en XML.
Il y a aussi des schémas d’encodage en RDF.

Le résultat, c’est que Dublin Core, tout le monde connaît. On sait que c’est des métadonnées, que ça s’exprime en XML, que ça va bien sur le Web et que ça a un rapport avec le Web sémantique. Mais en pratique, on n’y comprend plus rien.

Donc voici un petit glossaire à l’usage des gens qui se réfèrent au Dublin Core. C’est tout ce qu’il faut retenir pour réussir à y comprendre quelque chose.
– L’ensemble des termes du Dublin Core, c’est le Dublin Core Metadata Terms. On peut les appeler par leur petit nom : les DC terms.
– Parmi ces termes, il y a 15 éléments de base, le coeur historique du Dublin Core : c’est le Dublin Core Element Set.
– Parmi les expressions en XML du Dublin Core, le Dublin Core simple utilise les 15 éléments de base et uniquement ceux-là, alors que le Dublin Core qualifié peut utiliser d’autres DC terms.
– RDF est le langage le plus naturel pour exprimer du Dublin Core (Terms ou Elements) suivant le modèle abstrait du Dublin Core, le DCAM.
– Le DCMI est une organisation qui maintient l’ensemble.

J’espère que c’est – un peu – plus clair…

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.