Les RDA en RDF

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 ;-)

Publicités

VMF : let the mappings be !

I don’t usually blog in english. This is a first experiment. This post is a translation of this one.

On the 9th of november, a looong time ago, I was in London attending the presentation of results from the Vocabulary Mapping Framework project.
They waited almost as long as I to publish their results, so I decided to take this as an opportunity to come back on these results and on the first phase of the project which just came to an end.

First of all, a short reminder of the project’s goals : as stated in their june 2009 announcement, the VMF project aims at creating a mapping of major metadata formats using an OWL ontology.
Well, at first I was somewhat skeptical about it…
It seemed a (too) ambitious goal to me, with a very short deadline. But now I understand it better and I feel able to figure out what this project is all about. It is not about mapping all the metadata standards altogether, but rather about building a tool for creating metadata crosswalks.

Here is how it works (very roughly) :
– imagine you want to create mappings between metadata formats W, X, Y and Z (that is, mappings W–X, W–Y, W–Z, X–Y, X–Z and Y–Z)
– you create a generic ontology, the Matrix (that’s the hell of a name ;-)
– then you map each of your formats to the Matrix (W–Matrix, X–Matrix, Y–Matrix, Z–Matrix)
– and you query the Matrix so that you obtain equivalences between formats (W–Matrix–X, W–Matrix–Y, etc.)
– that’s it : you achieved your goal by creating 4 mappings instead of 6.
Well, if you’re good at numbers, you get that it’ only worth it if you need to map more than 3 metadata standards. But the more formats, the more interesting is the process : so in nowadays metadata world, the return on investment makes little doubt !

VMF uses theINDECS model in order to create an ontology that is « complex enough » to express all the notions or concepts underpinned in the metadata formats. This ontology, expressed in RDF, is the Matrix. You can download it from the website, and for instance, look at it with 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 !

VMF : et que les mappings soient

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 !

Livres dans le Linked Data

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.

Dublin Core, le pouvoir de la simplicité

Suite à une suggestion de Stéphane, je voudrais faire le point sur une question souvent posée quand on parle de Dublin Core : est-ce que le fait d’utiliser Dublin Core va appauvrir mes données ?

La réponse est plus complexe que juste « oui » ou « non ».

D’abord, il n’y a pas un seul Dublin Core. Le Dublin Core, c’est un ensemble de standards dont j’avais rappelé l’articulation dans un précédent billet. Relisez-le, c’est un pré-requis pour la suite.

Maintenant si vous prenez des données dans un format richement structuré, par exemple MARC, et qu’une fois passé en XML, vous lui appliquez une conversion pour le transformer en « Dublin Core simple », oui, vous allez appauvrir vos données, et ce pour trois raisons :
le DC dit « simple » se limite aux 15 éléments « de base » et ne permet pas d’exprimer la richesse contenue dans les Dublin Core metadata terms, donc vous serez obligé de choisir pour chacun de vos éléments en MARC une cible assez générique (par exemple, tous les types de titre, titre propre, titre parallèle, titre original et que sais-je encore vont tous atterrir en « dc:title ») ;
– exprimée en XML, votre notice en DC doit respecter le schéma XML du DC simple, il est donc exclu d’introduire la moindre fantaisie et de « rajouter » quoi que ce soit qui vous permettrait d’exprimer une information plus fine.
Ce scénario, c’est typiquement ce qui va vous arriver si vous faites de l’OAI-PMH, car ce protocole impose de présenter ses données au format Dublin Core simple.

Mais ce n’est pas la seule façon d’utiliser le Dublin Core.
L’ensemble des classes et des propriétés exprimées dans le Dublin Core metadata terms (qui est donc plus large que les 15 éléments de base) peut en effet être utilisé pour exprimer des triplets en RDF.
Mais en RDF, contrairement à XML, chaque triplet est indépendant et signifiant indépendamment de tout contexte, ce qui signifie que je peux tout à fait utiliser pour décrire la même ressource des propriétés du Dublin Core et d’autres propriétés, venant d’autres vocabulaires ou ontologies.
L’utilisation de Dublin Core en RDF est donc deux fois plus riche :
– le vocabulaire lui-même est plus riche et plus détaillé
– et on n’est pas obligé de s’y limiter, on peut le combiner avec d’autres.
Pour prendre un exemple, si je veux décrire une ressource en précisant un lieu, je peux utiliser la propriété « dc:spatial » (qui est plus fine que « dc:coverage », celui-ci pouvant être utilisé pour la couverture temporelle aussi bien que géographique) mais aussi la combiner avec des propriétés d’une ontologie géographique permettant d’exprimer finement les coordonnées (latitude, longitude) du lieu.
Ainsi, pour reprendre mon exemple ci-dessus, si je passe ma notice MARC en RDF, il est probable que certaines parties de la notice pourront être exprimées en utilisant des propriétés du DC, et d’autres non, mais ce n’est pas un problème, je peux les combiner.

Et l’interopérabilité, dans tout ça, me direz-vous ?
C’est vrai, le principal atout du Dublin Core, c’est interopérabilité, et c’est pour cela que l’OAI-PMH impose le Dublin Core simple, partant du principe qu’il permet de décrire tout type de ressources.
Pourtant, l’utilisation du DC simple en XML pose de GROS problèmes d’interopérabilité : comme il appauvrit les données, il y a une infinité de façons de l’appliquer, et les résultats, à la fin, sont rarement compatibles : on a tendance à « bourrer » l’information tant bien que mal dans les 15 éléments, voire à les répéter un nombre incalculable de fois au point de ne plus savoir où on en est. Mais bon, c’est toujours mieux que rien ; donc on crée des règles, ou des profils d’application, pour s’assurer que tout le monde fait (un peu) la même chose.
En RDF, le Dublin Core est un vrai atout pour l’interopérabilité car il permet à une multitude de gens d’exprimer la même chose de la même manière, à un niveau de granularité plus fin. Au lieu que chacun réinvente la roue et crée sa propre propriété « titre », ou « auteur », on utilise le Dublin Core, qui permet au moins, pour un large ensemble de ressources décrites en RDF, de repérer assez facilement les « titres » et les « auteurs ». Ensuite, on complète avec d’autres propriétés créées exprès ou prises dans d’autres vocabulaires.
C’est la raison pour laquelle le DC joue un rôle essentiel dans le Linked Data, qui est d’ailleurs le sujet de la conférence DC 2009 à Séoul.

IFLA (4) – User generated content, tagging sémantique et Web 2.0

Mieux vaut tard que jamais ;-) je poursuis ma série de comptes-rendus de l’IFLA (ce qui me rassure c’est qu’en regardant les autres blogs la plupart n’ont pas eu beaucoup plus de temps que moi pour bloguer pendant le congrès… C’est que ça occupe, un congrès de l’IFLA…)

Un autre thème sur lequel je voudrais revenir, c’est celui des contenus générés par les utilisateurs (UGC de leur petit nom).

Comme nous avons beaucoup parlé de Web 2.0, la question du « tagging » s’est posée à différentes reprises, avec un constat un peu déprimant : les utilisateurs ne vont pas tagguer dans les catalogues de bibliothèque. Faire des listes, oui, tagguer ailleurs, peut-être, mais dans les catalogues ? peu de chances.
Un jour autour d’un verre, nous avons échangé quelques idées amusantes pour essayer d’envisager une méthode pour contrebalancer cette tendance… Par exemple un système similaire à Booking.com : quelques jours après la fin de votre séjour, on vous envoie un mail avec un questionnaire pour évaluer l’hôtel. Et si on faisait de même quand un lecteur emprunte un livre à la bibliothèque ?
Une autre idée consistait à proposer une étagère de retour de prêt qui serait compartimentée en fonction de l’intérêt du bouquin (intéressant – ennuyeux – etc.) : apparemment ça a déjà été testé, si vous avez vu ça quelque part je serais curieuse d’en avoir la référence.
Blague à part, ce qu’il faut en retenir comme toujours, c’est que si on veut générer des contributions des utilisateurs, il faut que ce soit 1. facile, 2. pertinent par rapport à leur pratique, et 3. que cela fasse partie d’un dispositif d’incitation.
Ces trois critères sont semble-t-il parfaitement remplis par l’application de correction de l’OCR de la numérisation de la presse à la Bibliothèque nationale d’Australie (voir la présentation de Pam Gatenby à l’IFLA – voir le site – voir les informations sur le projet). Et ça marche : comme quoi, on peut arriver à mobiliser les utilisateurs sur des tâches pénibles et en plus ils adorent ça ;-) Noter qu’ils diffusent le code de leur application en open source.

Face aux possibilités du Web 2.0, la question critique de l’indexation sujet a été posée (pendant la table ronde de la conférence satellite Emerging trends… à Florence) : devrait-on arrêter d’indexer de façon aussi complexe que nous le faisons aujourd’hui ? L’indexation sujet, jugée à la fois coûteuse à produire et trop complexe à utiliser, était en question.
A mon avis à l’heure actuelle prendre une décision aussi radicale est impossible, d’autant qu’on sait pertinemment que les utilisateurs veulent des accès sujets, et qu’ils ne veulent pas les créer eux-mêmes (puisqu’ils ne veulent pas tagguer dans les catalogues).
Une solution envisageable pourrait résider dans le « tagging sémantique » par des bibliothécaires : c’est-à-dire, en fait, exploiter la richesse des vocabulaires contrôlés, mais sans la contrainte de la syntaxe, et en utilisant la puissance des ontologies pour les relier et les augmenter.
C’est intéressant, mais il va falloir du temps pour mesurer toutes les implications d’une telle évolution. Elle mériterait d’être organisée, évaluée, préparée au niveau international, pour permettre une évolution concertée des données bibliographiques dans le monde, vers le Web sémantique. L’IFLA peut sûrement jouer un rôle dans ce type de changements.
Et puis, mon petit doigt me dit qu’on a pas encore imaginé toutes les possibilités qu’ouvre une initiative comme Rameau en skos en termes d’exploitation sémantique des données…

Au final, et pour en finir avec le Web 2.0 dans les bibliothèques à l’IFLA, je voudrais noter une idée que j’ai retenue des différents événements qui ont abordé cette question, en particulier la conférence satellite, la session « Social computing tools for learning and knowledge sharing » (dans laquelle j’ai particulièrement apprécié l’intervention de Moira Fraser), et la rencontre du SIG « Libraries and the Web 2.0 ». Cette idée c’est que la bibliothèque 2.0 commence avec des petites choses toutes simples : avoir un compte Twitter, un blog, communiquer par l’image et la vidéo et pas seulement par du texte, sortir du paradigme de la présentation magistrale avec powerpoint. Être 2.0, c’est un peu comme se brosser les dents après chaque repas, ou manger cinq fruits et légumes par jour : quelque chose qui doit rapidement devenir un réflexe naturel du quotidien, pas une contrainte. Sinon, c’est voué à l’échec.

IFLA (2) – La valeur des données

Comme dans toute conférence internationale, la valeur ajoutée de l’IFLA se situe souvent autant dans les conversations informelles, à la terrasse des cafés, que dans les conférences elles-mêmes.

Parmi les différents points abordés aussi bien de façon formelle qu’informelle, au cours de la conférence satellite à Florence et des premières rencontres qui ont eu lieu dans le cadre du congrès de l’IFLA lui-même, Je vais être obligée de choisir bien arbitrairement ceux que je vais développer, parmi bien d’autres sujets tout aussi intéressants.

Le premier que je vous propose dans cette série concerne la valeur des données.

L’une des questions qui se posent lorsqu’on parle de linked data, ou même simplement d’open data, c’est la question de la valeur. Souvent posée en termes de popriété juridique (licensing), elle témoigne d’une crainte, diagnostiquée comme étant celle des décideurs, que les données soient « volées », « aspirées », ou autrement indument exploitées.
L’analyse généralement partagée ici, plutôt à un niveau perçu comme opérationnel ou technique, est qu’il faut dépasser cette vision héritée du monde des biens physiques et ouvrir les données, faciliter leur réutilisation, aussi bien techniquement que juridiquement. Je parle ici des données produites par la bibliothèque, pas des contenus qui pourraient être couverts par des droits de propriété intellectuelle. Mais en ce qui concerne les contenus, existe également la préoccupation que ce qui est dans le domaine public reste dans le domaine public, et ne fasse pas l’objet d’une nouvelle protection, par les institutions, à l’occasion de la numérisation. Je ne développerai pas davantage sur ce point, et vous renvoie à S.i.lex qui couvre remarquablement tous ces sujets.

Personnellement, ce qui m’intéresse davantage, c’est une approche complémentaire qui consiste à dire qu’un véritable changement de paradigme est nécessaire et qu’il doit porter non seulement sur l’ouverture des données, mais aussi sur la façon de mesurer leur valeur. Les indicateurs portant sur les collections (nombre d’items…) et sur les utilisateurs (nombre de visites/lecteurs) devraient être remplacés par des indicateurs qualitatifs et quantitatifs permettant de mesurer la valeur des données ouvertes : nombre de réutilisations dans différents contextes, nombre de liens, etc.
Cette question de la valeur (et du changement de paradigme) est abordée dans la communication sur l’API d’Europeana que j’ai traduite en français.

Puisqu’on parle de valeur, il se trouve que justement j’ai assisté ce matin à la session sur les statistiques dans laquelle je présentais un article sur les archives du Web (très largement rédigé par Gildas Illien). Dans cette session il était justement question d’évaluation et différentes méthodes et cas d’utilisation ont été présentées.
J’ai été assez frappée notamment par le projet NUMERIC, un projet européen présenté par Roswitha Poll, qui porte sur l’évaluation de la numérisation au niveau européen. C’est surtout la méthodologie qui m’intéresse ici.
L’évaluation continue par des indicateurs fournis régulièrement (type nombre de documents / notices / lecteurs etc.) n’est pas la seule méthode d’évaluation. Lorsqu’on essaye de couvrir un territoire ou une activité qui est au-delà des frontières d’une institution, l’évaluation par questionnaire peut être plus pertinente. Elle permet de réunir des informations sur les pratiques de diverses institutions, de les recouper et de donner une image à un niveau global (national ou européen) de l’impact d’une activité. Evidemment cette image n’est pas continue dans le temps, elle constitue une vision à un moment donné, et elle porte souvent sur un échantillon, plus ou moins représentatif, de données. Mais cela reste une approche essentielle qui permet de toucher du doigt certaines réalités ordinairement difficile à saisir.
C’est probablement ce type d’évaluations et d’indicateurs qui nous seraient utiles pour mesurer l’impact national et international des données ouvertes et leur valeur d’usage.

Le mapping ultime

Dans ce communiqué de presse, est annoncée la naissance d’une initiative ambitieuse : Vocabulary mapping framework.
Il s’agit d’une extension des travaux de rapprochement entre les RDA et ONIX, visant à rendre intéropérables les principaux standards de métadonnées descriptives : Dublin Core, Onix, RDA, MARC21, DOI, FRBR, LOM, etc.
La méthode proposée : réaliser un mapping universel permettant de créer des passerelles (crosswalks) entre ces vocabulaires afin de faciliter les transformations d’un format à un autre. Les mappings seront exprimés en RDF/OWL. Ce résultat est attendu pour le 9 novembre 2009, où il sera formellement présenté lors d’une conférence à la British Library.
Les étapes suivantes envisagées sont la génération automatique de mappings entre n’importe quelle paire de formats, et l’existence d’un site qui permettra de maintenir et de faire évoluer les conversions.
Derrière le projet, on trouve le DOI, la British Library et le JISC (entre autres).

Mon avis personnel : le projet n’est pas seulement ambitieux, mais un petit peu délirant. J’ai beau croire fort dans les technologies du Web sémantique, pas sûr qu’elles permettront de résoudre tous les problèmes de mappings en 6 mois.
Et puis :
– est-ce que cela a vraiment un sens de faire un mapping absolu, indépendamment de la nature et de la spécificité des données et de la façon dont chaque format est implémenté ?
– n’y a-t-il pas un peu à boire et à manger dans la liste de métadonnées ci-dessus (des formats, des modèles conceptuels, des vocabulaires, des systèmes, etc…)
– enfin quel est l’intérêt du DOI (et de l’IDF, International DOI Foundation) pour soutenir un tel projet : le revendre ? vendre les résultats ? vendre le service ? rendre plus de gens dépendants du DOI ? mettre le DOI au centre du monde (ce petit monde qu’est le milieu de l’informatique documentaire) ?

A suivre de très près.

Les catalogues sur le Web

Hier j’étais à Médial à Nancy pour une Journée d’études sur les catalogues nouvelle génération ».

Je ne sais pas si ce diaporama apportera quoi que ce soit sans les explications qui vont avec, mais en tout cas j’avais envie de le partager, ainsi que le plaisir que j’ai eu à faire cette présentation devant un public intéressé, attentif et indulgent.
J’en profite aussi pour remercier Françoise L. pour les quelques diapos que je lui ai empruntées et surtout pour ce qu’elle m’a apporté par ses réflexions.

Catalogues en ligne et qualité des données

Ce billet est un résumé du rapport d’OCLC : Online Catalogues : what users and librarians want, publié en avril 2009.

Le rapport d’OCLC porte sur la définition de la qualité des données du catalogue (de Worldcat en particulier, même si la plupart des conclusions peuvent être extrapolées), qui n’est pas la même pour les bibliothécaires et les utilisateurs. Ce sont les usages du Web qui obligent à repenser les objectifs et les modes de fonctionnement des catalogues.
Les priorités (en termes de qualité) des bibliothécaires sont le dédoublonnage et l’utilisation (correcte) des autorités. Celles des usagers sont l’accès aux ressources elles-mêmes (pas seulement à leur description : delivery vs. discovery) et la simplicité d’utilisation des outils leur permettant d’être autonomes.
Le rapport s’intéresse aussi aux besoins des bibliothécaires en tant que professionnels (acquéreurs, catalogueurs, etc.) et prend en compte l’accès à Worldcat par Z39.50.
Les méthodes utilisées pour l’enquête incluaient des focus groups, un questionnaire en ligne, et un questionnaire ciblé pour les professionnels.

Les résultats : ce que veulent les usagers

Pour l’usager, l’accès à la ressource (delivery) est aussi important, voire plus important que le fait d’être à même de la trouver (discovery). Donc ce qui compte c’est

  • de disposer de notices enrichies (résumés, tables des matières, etc. mais aussi des critiques, des notes…) surtout pour permettre d’évaluer si ce qu’on a trouvé correspond à ses besoins ;
  • le classement de résultats par pertinence doit être efficace et évident (on doit comprendre immédiatement pourquoi tel résultat sort en premier)
  • il faut faciliter par des liens directs le passage de la « trouvaille » (notice) à l’accès à la ressource (document).

La recherche par mots-clefs est « reine » mais la recherche avancée et les facettes sont essentielles pour s’y retrouver dans la masse. Les facettes permettent d’affiner sa recherche de manière guidée, sans avoir à parcourir d’interminables listes de résultats. Elles sont bien comprises et vite adoptées par les usagers. Toutefois pour que cela fonctionne, il faut que les données soient indexées de manière structurée.

Dans la liste des éléments de données essentiels pour trouver l’information, l’importance des localisations / données locales (par ex. informations sur la disponibilité) est à souligner.
En ce qui concerne les éléments qui permettent de décider si le livre est pertinent (couverture, résumé, critiques), l’usager souhaite en disposer dès la liste de résultats. Mais en ce qui concerne les critiques, les avis sont partagés avec un clivage assez traditionnel entre experts/chercheurs et étudiants/jeunes/amateurs : les premiers ne les jugent utiles que si elles sont « éditoriales » ou professionnelles, les seconds sont prêts à exploiter des critiques rédigées par d’autres usagers.

Du point de vue de la qualité des données, le besoin d’accéder facilement à des ressources en ligne directement à partir des catalogues de bibliothèque demandera probablement une croissance de l’investissement concernant la gestion des métadonnées de liens et l’interopérabilité avec des données externes.

Les résultats : ce que veulent les bibliothécaires

Comme les usagers, les bibliothécaires définissent la qualité en fonction de leurs objectifs : mais ce sont des objectifs professionnels de type renseignement bibliographique ou sélection /acquisition. Ils se retrouvent avec les utilisateurs sur le besoin d’enrichissement pour évaluer les ressources (plutôt des tables des matières et des résumés que des couvertures, sauf pour les bibliothèques publiques). Mais ils sont aussi obsédés par le dédoublonnage.

Pour le reste cela varie beaucoup selon les types de bibliothèques et les zones géographiques. Les bibliothèques spécialisées accordent une importance particulière à l’ajout des tables des matières et aux liens vers des ressources en ligne. Les bibliothèques publiques s’intéressent plutôt à la mise à niveau des notices abrégées.
Même chose pour les fonctions : les besoins varient de manière importante entre un catalogueur, un directeur de bibliothèque, un agent de service public, un acquéreur… En commun à toutes les fonctions on retrouve le dédoublonnage, les tables des matières, et les liens vers des ressources en ligne.
Les catalogueurs ont des demandes particulières visiblement liées à la récupération de notices dans Worldcat : plus de notices pour des ressources non anglophones, correction et amélioration des notices. Les directeurs de bibliothèque attachent plus d’importance à l’enrichissement par des résumés et des couvertures. Les bibliothécaires de services de référence bibliographique accordent de l’importance aux résumés et aux localisations.

Autres résultats intéressants

L’étude est quand même très orientée livres. Il faut attendre la page 47 du rapport pour voir apparaître autre chose que de l’imprimé ! (il y est dit que les bibliothécaires qui travaillent au contact direct du public sont conscients de l’importance, pour les usagers, d’avoir accès à des contenus enrichis et à des formats autres que l’imprimé, notamment audio et vidéo. Faut-il en déduire que tous les autres bibliothécaires ne s’intéressent qu’au livre ?)

Les éléments de données considérés comme importants par les bibliothécaires sont liés à la recherche de documents précis. Par exemple, la présence de l’ISBN est une priorité essentielle pour nombre d’entre eux. Quand on leur demande ce qu’ils amélioreraient dans les données du catalogue si on leur donnait une baguette magique, les bibliothécaires répondent qu’ils mettraient des ISBN partout ;-)

Alors que les exigences des bibliothécaires sont liés à leur conception traditionnelle des données structurées, les utilisateurs en bénéficient (recherche avancée, facettes) mais n’en ont pas conscience – ce qui les conduit à ne pas exprimer que c’est important pour eux. C’est aussi pour cela que les bibliothécaires accordent plus d’importance à la correction des données.

La perception des besoins des usagers par les bibliothécaires montre une prédominance de l’enrichissement (couvertures, tables des matières, résumés). L’accès aux ressources en ligne vient seulement après, alors que c’est le premier choix des usagers, suivi de l’augmentation des accès sujets.

Conclusions

Il y d’importantes différences dans la perception de la qualité du catalogue, entre les usagers et les bibliothécaires. Cette différence est due à des objectifs différents, mais aussi à un écart de compréhension quant au fonctionnement des données structurées.
Le fait que les usagers trouvent utile la recherche avancée suggère que l’investissement dans la structuration fine des données et l’utilisation de formes contrôlées pour les noms et les sujets représentent un vrai bénéfice pour les usagers, y compris dans les catalogues de demain.

En ce qui concerne les bibliothécaires, leurs différentes fonctions affectent leurs priorités concernant la qualité des données. Les catalogueurs et les acquéreurs valorisent la structure formelle du catalogue, par exemple les index par champs et les autorités, et reconnaissent son importance.

Noter qu’entre l’ouvrage de Charles Cutter Rules for a Dictionary Catalog et les RDA, les principes d’organisation de l’information sont toujours les mêmes. Mais il n’est pas clair que ces principes ont vraiment été testés au regard des attentes des usagers.
Sur le Web, les principaux acteurs ont adopté une démarche à l’opposé : on ne conceptualise que très peu, on procède par essai-erreur. C’est ce qui a permis le développement des principes de « user-centered design ».
Ce qu’il faut maintenant, c’est intégrer le meilleur des deux mondes, étendre la définition de ce que nous entendons par « qualité » dans les catalogues en ligne, et déterminer qui en est responsable. Pour cela, il faudra :

  • augmenter les liens vers des ressources en ligne ou au moins des extraits
  • enrichir l’information sur le contenu (« subject information ») mais pas en utilisant l’indexation matière traditionnelle
  • prendre la mesure du rôle critique des identifiants (ISBN, et autres).

Recommandations pour ceux qui définissent les besoins des futurs catalogues (oui, je me sens un peu visée là, pas vous ?) :

  • analyser, comparer et rééquilibrer l’investissement de la bibliothèque dans les tâches de catalogage, de fourniture de liens et d’enrichissement de notices
  • explorer, avec des partenaires (bibliothèques ou autres) les différents moyens d’obtenir des enrichissements (par ex. des API -> détour chez Karl)
  • encourager la R&D pour améliorer le classement de pertinence
  • accorder plus d’importance aux fonctions d’accès aux ressources
  • automatiser la création des métadonnées et limiter la redondance des tâches, au niveau des réseaux de bibliothèques, et avec d’autres partenaires.