Dans le dernier Dlib, on peut lire un article très intéressant de Karen Coyle, Diane Hillmann, Jon Phipps et Gordon Dunsire sur l’expression de RDA en RDF. Il rend compte d’un travail effectué dans le cadre du groupe de travail DCMI/RDA qui comme son nom l’indique travaille sur le rapprochement entre Dublin Core et RDA.

Pour mémoire, les RDA (Resource Description and Access) sont un ensemble de nouvelles règles de catalogage en cours d’élaboration dans la communauté anglo-saxonne, dont le principal caractère novateur est de prendre acte de la modélisation définie par les FRBR.

En fait ce qu’ils présentent dans l’article c’est un premier travail pour exprimer les RDA sous la forme d’une ontologie en RDF, qui est disponible en ligne dans le répertoire de métadonnées de la NSDL.

L’article rappelle qu’il s’agit d’un premier travail, qui arrive en avance de phase par rapport à la version définitive de RDA (prévue en juin). Pourtant, ils ont apparemment couvert sinon tout, du moins une grande partie des concepts et des éléments de description prévus.
Ce qui leur a posé plusieurs problèmes…

Le premier étant l’alignement avec les FRBR. Ils ont redéclaré des principales classes des FRBRer en attendant qu’une ontologie digne de ce nom soit publiée par l’IFLA. Mais les FRBRer n’étant pas tout à fait prévus pour cela, ils ont rencontré différents problèmes :
– ils ont dû utiliser une classe des FRBRoo, la classe Agent, sans quoi ça ne tenait pas la route (!)
– pour pas mal d’éléments RDA, le rattachement aux entités FRBR peut être discuté et on ne peut pas rattacher de façon univoque une propriété des RDA à une seule entité FRBR. Pour pallier ce problème ils ont déclaré les propriétés concernées deux fois, une fois de façon générique, puis une deuxième fois sous la forme d’une sous-propriété rattachée à l’entité FRBR choisie.

Le passage en RDF a l’avantage de mettre un certain nombre de relations en évidence de façon explicite.
Mais il implique aussi des contraintes : notamment le fait de mettre les propriétés sur un seul niveau (et pas imbriqué comme en MARC ou en XML).
Le traitement de certains trucs très spécifiques aux pratiques des bibliothèques, comme les mentions déclaratives (la mention d’édition par exemple, sous la forme « Éditeur : lieu, date ») est d’une complexité abominable dès lors qu’on veut les décomposer en plusieurs sous-parties dont certaines peuvent être des ressources (identifiées par des URI, pour les lieux par exemple) et pas seulement des littéraux (des chaînes de caractères).

L’article contient aussi un argumentaire assez intéressant sur l’utilisation d’un « metadata registry » pour déclarer les entités de RDA.
Le répertoire de métadonnées de la NSDL leur permet ainsi de diffuser à la fois une version lisible pour les humains (en HTML, sous forme de tableaux) et une version pour les machines (en RDF avec des URI). Il permet aussi de gérer le versionning et des mécanismes d’alertes.

L’article conclut enfin en soulignant les principaux avantages de cette démarche visant à modéliser les données des catalogues de bibliothèque pour le Web sémantique : il s’agit de permettre à d’autres acteurs d’appréhender ces donnés de façon plus simple qu’avec les formats MARC (cf. les propos de Google à l’ALA forum) mais aussi de nous aider à tirer le bénéfice de données créées par d’autres, comme DBPedia. Il se termine enfin avec une ouverture aux autres communautés proches des bibliothèques : institutions patrimoniales, éditeurs, etc.

Voilà pour l’article. Du côté du modèle lui-même, on va donc trouver trois choses :
– les classes correspondant aux entités FRBRer (+FRBRoo:Agent)
– les propriétés correspondants aux éléments des RDA
– les concepts conrrespondant aux listes de vocabulaires, à utiliser avec les propriétés.

Après une première et très courte analyse, ce RDA en RDF me semble une initiative assez prometteuse avec laquelle on va pouvoir commencer à s’amuser un peu… Même s’il y a sans doute encore des évolutions à prévoir.
Par exemple, on peut s’étonner de certains choix de modélisation comme le fait d’utiliser systématiquement SKOS:concept pour les vocabulaires. Autre truc bizarre, les vocabulaires sont faits pour être utilisés avec les propriétés mais l’ontologie ne le précise pas formellement ; il faut donc se débrouiller tout seul pour comprendre, par exemple, que la liste de concepts « RDA carrier type » doit être utilisée avec la propriété RDA:carrierType (là ça peut paraître évident, mais ce n’est pas toujours aussi simple malheureusement).

Bref, l’ensemble donne parfois l’impression d’avoir été conçu davantage comme un modèle de données traditionnel que comme une ontologie pour le Web sémantique, et qu’il n’en utilise pas toute l’ingénierie, ou pas correctement.
J’espère que les gens qui en savent plus que moi sur la modélisation d’ontologie n’hésiteront pas à s’exprimer sur le sujet ;-)

Le 9 novembre dernier, il y a presque une éternité, j’étais à Londres pour assister à la présentation des résultats du projet VMF : Vocabulary Mapping Framework.
Ils ont attendu presque aussi longtemps que moi pour mettre leurs résultats en ligne, ce qui me donne l’occasion de revenir un peu sur ce projet et ce qui en a résulté dans la première phase, qui vient donc de se terminer.

D’abord, rappelons les objectifs du projet : annoncé en juin 2009, le projet VMF se donnait pour objectif de réaliser un mapping de tous les formats de métadonnées majeurs, au moyen d’une ontologie en OWL.
Vous vous souvenez peut-être que ce projet m’avait à l’époque laissée un peu songeuse…
Oui, c’est vrai, cela me semblait un objectif ambitieux (trop) et je ne voyais pas très bien où ils voulaient en venir, surtout en si peu de temps. Mais maintenant les choses me semblent plus claires et je pense arriver à comprendre ce que ce projet peut apporter. Ce n’est pas un mapping universel de tous les formats de métadonnées, mais plutôt un outil d’aide à la conception de mappings entre des formats de métadonnées deux à deux.

Dans les grandes lignes, le principe est le suivant :
– imaginons qu’on veuille faire correspondre les formats W, X, Y et Z (soit, les mappings W–X, W–Y, W–Z, X–Y, X–Z et Y–Z)
– on crée une ontologie générique, qui s’appelle la Matrice (the Matrix, fallait l’inventer ;-)
– on crée ensuite le mapping de chaque format vers la Matrice (W–Matrice, X–Matrice, Y–Matrice, Z–Matrice)
– on requête la Matrice pour qu’elle propose des équivalences entre deux formats (W–Matrice–X, W–Matrice–Y, etc.)
– on a ainsi obtenu les correspondances entre les formats souhaités en faisant 4 mappings au lieu de 6.
Ceux qui savent très bien compter auront compris que l’opération n’a d’intérêt qu’à partir du moment où on cherche à faire se correspondre plus de 3 formats, mais plus on a de formats, plus le bénéfice est important : dans l’environnement actuel, cela devrait donc être facile de rentabiliser l’opération ;-)

Pour ce faire, VMF s’appuie sur le modèle INDECS pour créer une ontologie qui est suffisamment complexe pour exprimer toutes les notions ou concepts existant dans les différents formats de métadonnées. C’est cette ontologie, exprimée en RDF, qui constitue la Matrice. Vous pouvez la télécharger en RDF sur le site du projet, par exemple pour regarder ce que cela donne dans Protégé.

L’idée est que les différents formats peuvent exprimer des notions proches, mais pas tout à fait équivalentes, et c’est ce « pas tout à fait » qui est un cauchemar pour le producteur de mappings. Un concept peut être exprimé de façon fine dans un format et détaillée dans un autre, il peut être exprimé avec une orientation différente (par ex. « est l’auteur de » et « a pour auteur » : c’est « presque » la même chose, mais « pas tout à fait ») etc. Si on veut concevoir un générateur de mappings, il faut être capable d’embrasser toutes ces nuances, pour les exprimer et clarifier les relations entre les formats.
C’est ce que fait la Matrice, au moyen d’un système de « famille de concepts ». Ce modèle est orienté événement : quand un événement apparaît dans un format de métadonnées (par exemple, l’événement correspondant à une traduction) on va créer dans la Matrice une famille de concepts qui regroupe :
– les acteurs et les objets de l’événement,
– toutes les relations possibles entre ces acteurs et objets.
Ce qui donnera par exemple :

(le traducteur) traduit (la source)
(la source) est traduite par (le traducteur)
(le traducteur) crée (la traduction)
(la traduction) est créée par (le traducteur)
(la source) a pour traduction (la traduction)
(la traduction) est une traduction de (la source)
etc.

Ensuite, les différentes familles de concepts sont articulées entre elles (par exemple, « traduction des sous-titres » serait un concept spécifique rattaché au concept plus générique de « traduction »).
Enfin, on utilisera ces différentes familles de concepts pour relier les différents formats à la Matrice, en respectant toutes les nuances et les logiques intrinsèques de chacun d’entre eux.
Pour l’instant, les gens de VMF ont travaillé à l’alignement des formats suivants avec la matrice : CIDOC CRM, DCMI, DDEX, FRAD, FRBR, IDF, LOM (IEEE), MARC21, MPEG21 RDD, ONIX et RDA, ainsi que le « RDA-ONIX Framework », ce dernier étant le point de départ du projet.

Il en résulte que la Matrice pourra rarement proposer une équivalence simple entre deux éléments de formats différents. Elle proposera plutôt un « chemin » entre ces différents éléments, c’est-à-dire qu’elle parcourra de lien en lien le graphe RDF, pour trouver le (ou les) chemin(s) le plus court d’un concept à un autre. Pour cela, il est prévu de la requêter en SPARQL (mais pour l’instant, il n’y a pas de SPARQL endpoint sur le site du projet).

Je dirais donc que VMF a produit plutôt un générateur de mappings qu’un mapping universel, ce qui semble déjà un objectif plus raisonnable… En fait, du point de vue de la modélisation, l’approche est très séduisante.
C’est une approche qui cherche à être générique sans pour autant réduire les formats à un plus petit dénominateur commun, ce qui est louable. Elle prend en compte les spécificités et la complexité de chaque format.
Pour autant, ce qui n’est pas exprimé dans la Matrice, c’est la logique intrinsèque des jeux de données eux-mêmes, qui peut varier d’une application du format à une autre. En cela, c’est probablement utile d’avoir un générateur de mapping qui propose plusieurs options pour chaque élément, et qui permette ensuite au producteur du mapping de choisir ce qui lui semble le plus pertinent par rapport à ses propres données.

Les étapes suivantes du projet, telles qu’elles ont été présentées à la journée du 9 novembre, incluent :
– la validation des mappings déjà effectués par les autorités compétentes pour chacun des formats (les mappings sont pour l’instant « expérimentaux »)
– l’ajout de nouveaux mappings
– la recherche d’un modèle économique qui permette au projet de se développer sur le long terme.

Si vous voulez plus de détails sur comment fonctionne la Matrice et la création des mappings, un seul document, celui-là (PDF, 27 pages).
Je vous recommande également le billet de Sylvie Dalbin, qui est me semble-t-il assez complémentaire avec le mien. Avec ça, vous avez tous les éléments !

Il y a quelques temps, j’étais au Bookcamp 2 à Paris, où j’avais proposé d’animer un atelier sur le Web de données.

Pourquoi le Web de données ? Parce qu’il me semble urgent que les gens du livre – et pas seulement les bibliothèques – réfléchissent si possible ensemble à l’exploitation et à la valorisation de leurs métadonnées sur le Web, dans un mode ouvert, partagé et collaboratif.
Quand je dis collaboratif, ce n’est pas au sens « Web 2.0 » (je te taggue, tu me taggues par la barbichette etc.) mais plutôt au sens du Web de données : chacun produit ses données de façon standard, les met à disposition sur le Web de façon ouverte, et tout le monde peut les réutiliser et créer de la valeur.
L’avantage du Web sémantique dans ce contexte, comme je l’expliquais dans le « use case » présenté à Florence et sur lequel je suis revenue dans l’atelier du bookcamp, c’est de ne pas obliger toute la chaîne des producteurs à adopter le même format de métadonnées (ce qui est impossible, comme la vie nous le prouve chaque jour) et d’éviter les conversions d’un format à l’autre.

Probablement inspiré par ces cas d’utilisation livresques, Got s’est lancé dans la création d’un démonstrateur de ce que l’on peut déjà agréger comme données sur les livres avec ce qui est disponible aujourd’hui dans le linked data, c’est à dire rien que des données ouvertes, librement disponibles, en encodées en RDF. Le résultat est là : linked book mashup.
Vous remarquerez qu’il y a déjà (un peu) de données de bibliothèques dedans : celles de Libris, les autorités de la Library of Congress, et des liens avec Rameau.
Le reste provient de Freebase, DBpedia, etc.
Je vous laisse apprécier le résultat, avec un début de FRBRisation, des données enrichies, des visuels… Des tas de choses intéressantes. L’exemple le plus complet étant le Seigneur des Anneaux.

Cela doit être dans l’air du temps, car à peut près en même temps nous avons découvert que Talis avait aussi réalisé un démonstrateur du même acabit : Semantic Library.
L’approche est assez différente, reposant sur l’idée de mettre en valeur les liens entre les œuvres, les auteurs, les personnages, les sujets, etc. et de faciliter la navigation, plutôt que sur le fait d’agréger toutes les informations sur une page en mode « mash-up ». Mais c’est également très intéressant.
Autre point à noter : le site de Talis redistribue les données de son service en linked data.

Pour en revenir au BookCamp, je pense que l’atelier a été un moment riche d’échanges et de réflexions, même si ce qui frappe au premier abord c’est le flou autour de la notion de « web sémantique » et même de « web de données ».
Nous avons essayé de dépasser les problématiques purement techniques pour voir ce que le Web de données pouvait vraiment apporter en termes de service aux gens du livre.
Bien sûr, nous sommes revenus sur la question des droits de réutilisation et des licences, et celle de la valeur des données, qui est une question centrale notamment pour les bibliothèques.
Finalement, nous avons discuté organisation et compétences (deux thèmes qui me tiennent fort à cœur ;-) car si nous voulons vraiment que le Linked Data ait un avenir dans les bibliothèques, il va falloir que différents niveaux d’acteurs s’y intéressent et s’y investissent. De ce point de vue, la désaffection de la profession pour les questions de métadonnées (yes, MARC c’est tellement has been) me paraît inquiétante. J’espère qu’en démontrant les possibilités du Web sémantique pour le livre, nous pourrons réhabiliter un peu l’intérêt de ces choses certes à première vue un peu techniques et rébarbatives, mais tellement importantes.