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.

A l’origine, le catalogue était un meuble, composé de tiroirs et de fiches, trônant dans la salle de référence. Pour le consulter, il fallait s’y rendre. Les données étaient prisonnières d’un objet.

Alors, on a fait des catalogues imprimés : diffusés en plusieurs exemplaires, on pouvait les consulter à distance. Mais c’étaient toujours des catalogues en papier, uniquement compréhensibles pour les yeux avisés de lecteurs humains. Les données étaient prisonnières d’un support.

Alors, on a fait des SIGB : informatisées, les données devenaient manipulables par machine ce qui facilitait grandement leur accès, leur gestion, leur production. Mais le SIGB était une boîte noire, rigide, parfois incompréhensible : les données étaient prisonnières d’un logiciel.
Les SIGB libres ont été un espoir qu’on pourrait ouvrir la boîte, mais ça n’a pas pris. Sans doute parce que ça n’en valait pas l’investissement : même si on pouvait, grâce au code source ouvert, tourner une vis ici, ajuster un boulon là, les données étaient toujours prisonnières de la base de données.

Alors, on a créé les formats standards et les protocoles d’échange. Grâce à eux, on peut sortir les données du SIGB pour les échanger ou les réutiliser. Mais malgré l’étonnante capacité de notre communauté à se normaliser et se contraindre elle-même, il y avait toujours une étiquette de champ inapropriée, un $a appliqué de manière différente, un indicateur vide avec un sens particulier, une donnée locale non standard. Les protocoles sont toujours une barrière, un passage obligé pour faire sortir – aux forceps – les données.
Ajuster les mappings entre les formats et paramétrer les protocoles est une opération horriblement complexe, et coûteuse. Ou alors, elle « lave plus blanc » en nivelant les données par le bas, les privant de leur richesse.
Les données sont prisonnières de leur propre structure.

Arrive le Web sémantique. En atomisant la structure des données, il les rend toutes égales, et libres.

Au-delà des formats et des protocoles, le Web sémantique a le pouvoir de vraiment libérer les données. Libres, nos données seront plus riches, plus pérennes, plus interopérables. Osons redonner le pouvoir aux données.

Ok, c’est un non-sens de parler de « FAQ » pour un sujet sur lequel jamais personne ne pose de questions. Disons que voici quelques réponses aux questions que je me pose souvent à moi-même ;-)

C’est quoi, déjà, RDF ?
Comme son nom l’indique, c’est un cadre de description de ressources. C’est un modèle conceptuel qui permet de décrire des choses. Toutes sortes de choses.

Je suis bibliothécaire. En quoi suis-je concerné par RDF ?
Comme dit, RDF sert à décrire des choses. Or, les bibliothécaires décrivent des choses. Tu es donc très très concerné, cher ami.

Admettons. Peux-tu me dire à quoi RDF pourrait me servir, par exemple ?
Eh bien, par exemple, RDF pourrait te permettre d’améliorer la façon dont tu décris les choses. Non seulement les livres, mais aussi les ressources en ligne, les lieux, les gens, les concepts.

Alors, RDF peut m’aider à améliorer mon catalogue ? Comment ?
Aujourd’hui, ton catalogue est conçu sous la forme de fiches : des fiches bibliographiques, des fiches d’autorité… Toutes ces fiches sont informatisées bien sûr, mais la base de données que tu appelles catalogue fonctionne elle-même comme une collection de fiches.
En conséquence, chaque information qui figure sur une fiche (dans une notice, si tu préfères, que ce soit une notice bibliographique ou une notice d’autorité) n’est compréhensible que dans cette fiche. Si tu l’en sors, tu perds toutes les relations implicites qu’elle entretient avec les autres informations de la notice.
Si tu utilisais RDF pour décrire tes ressources, tu n’aurais plus des fiches mais des données, ce qui veut dire que chaque petit élément de description à l’intérieur de chaque fiche serait explicitement relié à tous les autres, et aurait une signification par lui-même. Tes données seraient beaucoup plus puissantes, indépendantes, libres.

D’accord, alors RDF améliore mes données?
Pas du tout. RDF ne fait que les représenter différemment. Tes données sont déjà très bien : elles utilisent un format complexe et structuré, le format MARC, qui contient déjà beaucoup d’informations intéressantes en expliquant à quoi elles servent (grâce aux fameux $a etc…) RDF ne va pas améliorer tes données, seulement les aider à travailler davantage.

Oui mais… Je ne suis même pas encore passé à XML. Tu ne crois pas que c’est un peu tôt pour regarder RDF ?
Diable non. RDF n’est pas un concurrent de XML. En théorie, tu pourrais complètement sauter l’étape XML. En pratique, c’est vrai que ce sera plus facile si tu sais déjà exprimer tes données en XML.

Alors c’est quoi, la différence entre RDF et XML?
Il y en a de nombreuses. Pour ne pas t’embrouiller, je vais simplement te dire que XML permet de réprésenter tes données sous forme d’arbre, suivant une hiérarchie. L’objet que tu décris (par exemple, un livre) est à la racine de l’arbre. Les éléments de ta notice sont ses branches et ses feuilles.
Avec RDF, tu représentes tes données sous forme de graphe, avec des liens entre les données. Imagine que ta notice est une étoile ; ce que tu décris est au milieu, et chaque élément de description est à la pointe d’une branche. Avec RDF, non seulement tu peux choisir ce que tu mets au centre de ton étoile (un livre, ou une personne, un sujet, un lieu, autre chose), mais en plus, tu ne te contentes pas de suivre le chemin le long des branches, tu sais où tu vas car les relations entre tes données sont typées. Tu peux aussi te promener d’étoile en étoile en cheminant le long des branches.

Autre chose, j’ai entendu parler des FRBR… Est-ce que RDF va m’aider à FRBRiser mon catalogue ?
Mmh, oui et non. Comme je te le disais, RDF ne va pas améliorer tes données. Donc s’il manque des choses dans tes données, comme la notion d' »oeuvre » dans les FRBR, elles manqueront toujours. Par contre, la façon de représenter tes données en RDF est beaucoup plus proche de FRBR que tes notices classiques, justement grâce au principe du graphe et parce que les relations sont explicites et typées.

C’est vraiment super ! Mais quand je lis « RDF – OWL – SPARQL – SKOS – N Triple » et des trucs comme ça, je me dis que tout cela est vraiment trop compliqué pour moi. Non ?
Evidemment, je te mentirais si je te disais que tu vas t’en sortir en un jour avec toutes ces notions et les technologies qui y sont associées. Mais il faut aussi se souvenir que RDF c’est avant tout exprimer les données sous forme de phrases simples (sujet – verbe -complément), c’est-à-dire que c’est avant tout une façon de concevoir les choses, de les modéliser. Avec un peu de gymnastique cérébrale, tu arriveras sans problème à maîtriser le modèle. Quant à la technique, je t’assommerai avec cela après !

Tout ça a l’air très bien, mais cela va me demander un gros effort : peux-tu me promettre qu’il en vaut la chandelle ?
Pas vraiment, hélas, mais ce que je peux te dire, c’est qu’en ce moment il y a vraiment des choses qui se passent autour de RDF. On en entend de plus en plus parler, y compris dans le domaine de l’industrie et dans celui des bibliothèques. Ce qu’il faudrait, c’est que des gens qui ont de grosses masses de données sous la main les mettent en RDF pour permettre de jouer avec et de voir si ça nous aide à faire décoller nos catalogues. Je ne te cache pas que je compte un peu sur toi, là…

Ok, je vois où tu veux en venir, mais je n’ai pas vraiment envie de me retrouver tout seul à utiliser ce format et ne plus être intéropérable avec ma communauté. C’est important pour nous en bibliothèque.
Je te rassure tout de suite. RDF n’est pas un format. C’est un modèle. Tu peux l’utiliser en conjonction avec des formats très répandus comme le Dublin Core. Tu peux l’exprimer en XML. Et tu ne seras pas tout seul, car contrairement aux formats MARC et leurs dérivés en XML, RDF est commun à beaucoup d’autres communautés que la tienne. C’est encourageant pour l’avenir.

Je te remercie. Peux-tu me donner quelques trucs simples à lire pour aller plus loin ?
Je trouve que ce n’est pas facile de dénicher des présentations très pédagogiques de RDF pour l’instant, surtout en français. Mais j’en ai référencé quelques-unes dans mon précédent billet, en particulier celle sur TEF qui est indispensable.
Tu peux aussi lire RDF pour les nuls et plein d’autres billets sur les Petites Cases (attention, certains sont plus techniques que d’autres… celui-là contient une bibliographie en français.)

Le projet VIAF, Virtual International Authority File, est un projet d’OCLC research qui vise à l’origine à aligner des listes d’autorités (notamment sur les noms propres) en vue de constituer une base de référence internationale.

Les premiers à tester ont été la Library of Congress et la Deutsche Bibliothek, qui travaillaient donc à l’alignement de leurs thésaurus respectifs ainsi que c’était décrit ici (ppt) ou là.

Dès le départ, le projet affichait des intentions intéressantes en termes d’utilisation des technologies du Web sémantique. Il était aussi question de choses plus traditionnelles mais sur lesquelles on se posait aussi des questions, comme l’utilisation de l’OAI pour échanger des notices d’autorités (alors que, soyons clair, à première vue ce n’est pas fait pour ça).
De plus, cela s’inscrivait dans la continuité de services intéressants offerts par OCLC autour des autorités comme Worldcat Identities qui est un bon exemple de ce qu’on peut obtenir en "faisant travailler les données" comme diraient Lorcan et ses amis.

Aujourd’hui, d’après cette communication prévue à l’IFLA 2007 à Durban, le projet s’élargit avec de nouveaux partenaires, et le discours se radicalise assez nettement autour de l’idée de Web sémantique : ce n’est plus présenté comme une possibilité éventuelle de seconde main, mais comme le coeur du projet. Un projet qui devrait aider les bibliothèques à être parmi les briques fondatrices du SemWeb en mettant à disposition leurs données avec de belles URI !

L’avenir nous dira s’il s’agit là de l’acte de naissance d’une nouvelle tendance en bibliothèque, une tendance d’ouverture sans complexe au Web sémantique, une tendance qui nous permettrait de tenir le pari de Yann …

Vu avec d’autres com’ de l’IFLA, sur Resourceshelf.