Archives de Tag: métadonnées

LD4P : un « grand soir » pour les bibliothèques américaines ?

Publié le par
 

La semaine dernière, j’étais invitée par Stanford à participer, en tant qu’expert, à un atelier du projet LD4P (Linked Data For Production). Ce projet financé par la Mellon Foundation a pris la suite d’un précédent projet nommé LD4L (Linked data for Libraries) ; il s’agit cette fois d’une initiative conjointe de plusieurs grandes bibliothèques universitaires américaines (Stanford, Harvard, Cornell, Columbia, Princeton) et de la Library of Congress, qui vise à développer concrètement le catalogage « en linked data » pour reprendre leurs propres termes. L’objectif du meeting était de présenter les résultats du projet à ce jour et d’obtenir le retour de la communauté. Une bonne occasion pour moi de remettre à jour mes connaissances sur ce sujet et de mieux comprendre le positionnement des bibliothèques américaines dans la transition bibliographique aujourd’hui.

Le projet LD4P se découpe en fait en plusieurs sous-projets qu’on peut classer en trois catégories :
– ceux qui visent à développer l’ontologie Bibframe et ses extensions,
– ceux qui travaillent sur le processus de catalogage

– ceux qui travaillent sur les outils.

Souvenez-vous, Bibframe c’est ce standard dont l’ambition est de remplacer les formats MARC. Développé et maintenu par la Library of Congress, il est actuellement dans sa version 2.0. – cette nouvelle version parue en avril 2016 est d’ailleurs l’un des livrables du projet.

Comme je le soulignais déjà en 2014, Bibframe constitue un cadre assez générique pour la description de documents de bibliothèque. L’un des objectifs de LD4P est donc de compléter cet effort de modélisation afin de permettre son implémentation concrète, en commençant plutôt par des documents spécialisés (documents cartographiques et géographiques, livres rares, image animée, musique jouée etc.). Le présupposé est qu’il est préférable de partir de cas complexes qu’on pourra ensuite généraliser pour des documents plus simples, plutôt que de commencer par le livre et ensuite se retrouver en difficulté face aux documents spécialisés.
Ce travail a donné naissance à une version dérivée de Bibframe nommée Bibliotek-o ainsi qu’à plusieurs extensions pour les types de documents pré-cités. Il faut cependant noter que certains services, comme le réseau Library.link, utilisent encore d’anciennes versions de Bibframe (Bibframe 1.0 ou Bibframe lite).

Tout ceci débouche sur une prolifération de modèles plus ou moins divergents qui inquiètent les porteurs du projet, ceux-ci se demandant si on ne serait pas en train de constituer de nouveaux silos. Contrairement à ce que laissait espérer le web sémantique tel qu’on l’envisageait au départ, on en arrive à la conclusion qu’on est loin d’être débarrassés des problématiques de conversion, transformation et recopie de données.

Du côté des outils, ce n’est donc pas seulement la question du convertisseur MARC -> Bibframe ou de l’éditeur de données en RDF qui se pose, mais aussi celle de toute la galaxie des outils qui vont permettre de traiter, réconcilier, aligner, contrôler, enrichir, convertir, diffuser et exploiter ces données dans leur nouveau format qui se pose. Les partenaires du projet ont commencé à établir un registre des outils disponibles qui ont été évalués dans ce cadre.

Un des aspects les plus intéressants de LD4P est à mon avis le sous-projet « tracer bullets » qui ambitionne d’articuler plusieurs de ces outils pour démontrer la faisabilité d’une implémentation de bout en bout, pour un sous-ensemble de documents, d’un processus ou workflow basé sur RDF. C’est justement Stanford qui pilote ce sous-projet.
4 types de workflow de catalogage ont été identifiés :
– récupération et enrichissement de données provenant d’un éditeur
– création manuelle de données à l’unité
– dérivation depuis un réservoir type WorldCat
– récupération de données en masse.

Dans un premier temps, c’est le premier workflow qui a été exploré, grâce à une collaboration avec l’éditeur italien Casalini Libri. Stanford bénéficie d’un avantage par rapport aux bibliothèques qui disposent d’un catalogue intégré dont l’interface de consultation pour les usagers repose sur la même base que la production : leur système d’accès est distinct du système de production, il est basé sur le moteur de recherche SolR et le système Blacklight. Le projet « tracer bullet » consiste donc à récupérer les données de l’éditeur, les compléter notamment des liens aux autorités, les transformer de MARC à Bibframe et enfin les verser dans SolR pour l’accès. Il a ainsi été possible de démontrer qu’on pouvait « brancher » sur le système d’accès un nouveau système de production basé sur Bibframe, sans perte de qualité dans l’expérience utilisateur.

La dernière session de travail de ces deux jours était consacrée aux questions de gouvernance, d’engagement des communautés, de formation etc. J’ai participé aux discussions sur la formation, ce qui m’a permis de mesurer l’importance que semble avoir pris le web de données aux yeux des bibliothécaires américains : loin du postulat que je faisais en 2014 en disant qu’il ne me semblait pas utile que tous les bibliothécaires soient formés au RDF, aux ontologies et autres arcanes du web semantique, nos collègues d’outre Atlantique semblent considérer que ce sont là les bases de la profession que tout le monde devrait a minima connaître.

À l’heure où je suis pour ma part (avec mon complice des Petites Cases) plutôt dans une démarche consistant à replacer le web sémantique dans un horizon plus large des données de bibliothèques, cette place étant plus du côté de l’interopérabilité et du partage que de celui de la production, ce décalage m’a pour le moins étonnée. Est-il dû aux années d’expérience que nous avons acquise, en France, sur la gestion de données RDF en production ?

Il ne faut pas oublier que les bibliothèques américaines sont confrontées à une situation bien différente de la nôtre. Leur format, MARC21, ne contient pas de liens entre notices bibliographiques et notices d’autorité : le seul point de contact se fait à travers les « noms », formes figées retenues pour dénommer ces entités de façon normalisée. Cette absence de lien constitue un handicap majeur pour la transition vers des modèles de type FRBR et vers le web de données, d’où une urgence plus grande à changer. Et tant qu’à changer, autant passer directement au format « du futur » plutôt que de faire subir des évolutions majeures à un MARC vieux de cinquante ans.

Par ailleurs, la déconnexion plus importante entre les notices bibliographiques et les données d’autorité qui en résulte conduit à une vision du catalogue comme un réservoir de notices figées appartenant au passé. Phil Schreur, de Stanford, compare ainsi les réservoirs de notice MARC à une dette que nous devrons payer un jour : il nous propose de ne pas aggraver cette dette en créant de nouvelles notices en MARC, mais de commencer dès que possible à produire dans le format de demain, la question du paiement de la dette (ou de la migration de l’existant) étant temporairement remise à plus tard.

La situation est sans aucun doute bien différente pour des bibliothèques françaises qui disposent déjà de données liées, même si elles sont encodées en Intermarc ou en Unimarc plutôt qu’en RDF. Nos catalogues lient ainsi de façon très organique données bibliographique et d’autorité, production et accès, création de notices et gestion de données vivantes. Cet état de fait nous donne une certaine avance (qui sera sans doute notre retard de demain…) et nous permet d’envisager une transition bibliographique plus progressive et plus étalée dans le temps : comme le disait récemment une collègue, « Pas de grand soir, mais beaucoup de petits matins ».

L’évolution du modèle d’agrégation de données dans les bibliothèques numériques

Publié le par
J’ai rassemblé dans ce billet quelques réflexions et observations qui m’ont été inspirées notamment par mes travaux au sein d’Europeana ces derniers mois. Tout est parti du sentiment diffus que l’agrégation telle qu’on la connaît actuellement est en train d’évoluer, même s’il est difficile de savoir vers quoi, car je n’ai pas lu de théorie très construite sur le sujet. Donc à défaut de l’avoir trouvée résumée ailleurs, je la propose ici aujourd’hui.

A l’origine…

Vers le milieu des années 2000, lorsque les bibliothèques numériques comme Gallica ou Europeana ont commencé à avoir l’ambition d’atteindre une masse critique, elles ont défini un modèle d’agrégation de données, c’est à dire une méthode permettant de rassembler dans une interface unique des données issues de plusieurs institutions. Ce modèle d’agrégation était essentiellement basé sur le protocole OAI-PMH, inspiré notamment par ce qui se passait dans la communauté des archives ouvertes.

Les principes de ce modèle sont relativement simples :

* du point de vue technique, le protocole OAI-PMH offre un cadre transverse aux professions de la documentation, du patrimoine et de l’information scientifique et technique. Conforme aux standards du web, il repose sur des normes simples à implémenter et des logiciels open source à peine plus complexes qu’une bête plateforme LAMP, à la portée de n’importe quel webmestre sachant un peu ce qu’il fait.
* du point de vue des métadonnées, le format Dublin Core dit « simple » avec ses 15 éléments facultatifs et répétables sert de dénominateur commun pour la convergence syntaxique (avoir des métadonnées qui « entrent dans le même moule » pour prendre une métaphore culinaire – mais la forme du moule ne garantit pas qu’on utilise la même recette pour la pâte à gâteau). Le fait de pouvoir y adjoindre n’importe quel format plus complexe du moment qu’il peut être exprimé en XML semblait au départ une consolation suffisante pour des usages plus avancés. On se repose enfin sur l’asynchronisme du système (moissonnage des métadonnées qui sont ensuite stockées dans un nouvel entrepôt pour construire des services) et sur des technologies de type moteur de recherche plein texte à facettes pour fournir le service d’accès.

* enfin du point de vue des contenus, des arguments politiques et institutionnels plaidaient en faveur d’une consultation des documents numérisés sur le site propre de chaque institution, ce qui lui permettait de préserver son image (sa « marque ») et son audience, généralement l’unique indicateur de succès d’un service de bibliothèque numérique.

Ce modèle d’agrégation a servi de base à la construction de la première version du portail Europeana, qui avait défini à cette fin le modèle ESE (Europeana Semantic Elements), une sorte de DC simple augmenté de quelques éléments de provenance. La simplicité technique du modèle a permis une implémentation rapide débouchant sur le moissonnage des métadonnées décrivant des millions d’objets culturels en seulement quelques mois : un « quick win », en quelque sorte. Dans ce modèle, l’interopérabilité sémantique (la fameuse recette de pâte à gâteau mentionnée plus haut) était assurée par des tiers appelés « agrégateurs », chargés pour un domaine national ou thématique de veiller à l’homogénéité des données grâce à des bonnes pratiques ou des traitements.

Ce que le web de données a changé au modèle d’agrégation

Cependant, quasiment à l’époque où ce modèle se mettait en place à grande échelle, on voyait déjà un autre modèle d’agrégation pointer le bout de son nez : le Linked Open Data (web de données en bon français).

Cela n’avait pas échappé aux concepteurs d’Europeana qui rêvaient de créer autre chose qu’un énième portail de métadonnées comme il en existait déjà beaucoup. Dans une démarche de long terme, le modèle de métadonnées EDM (Europeana Data Model) a été imaginé pour prendre la suite d’ESE en décuplant ses capacités. On pensait alors que l’interopérabilité par les liens, inhérente au web de données, était appelée à remplacer à terme l’agrégation par moissonnage.

Mais ce n’était pas si simple…

* du point de vue technique, le web de données apparaît comme la nouvelle génération qui a tout pour succéder à l’OAI-PMH : encore plus intégrée à l’architecture du web, elle transcende les frontières des métiers et des domaines et s’affranchit en théorie de toute les problématiques liées au stockage des données (car dans l’architecture du web, l’endroit où les données sont stockées est rendu abstrait par l’utilisation des URI et de l’hypertexte). Cependant, en pratique, la construction de nouveaux services à partir de ces données continue à nécessiter une forme de moissonnage ; or on ne dispose pas dans le web de données des mécanismes très pratiques fournis par l’OAI-PMH à cette fin (horodatage des données permettant de ne récupérer que les mises à jour, suivi des enregistrements détruits par ex.). Au final tout ce nouvel environnement technique faisait appel à des compétences qui n’allaient pas de soi pour les informaticiens, ce qui a pu freiner les réutilisations et l’agrégation de données utilisant ces principes au-delà de prototypes ponctuels.
* du point de vue des données, le modèle RDF présente l’avantage d’autoriser la description de de ressources non documentaires, les « entités » qui interagissent avec les documents : personnes et autres agents, sujets, lieux, périodes temporelles… Le web de données a contribué à réhabiliter ce qu’on appelait en bibliothèque les « données d’autorité », réaffirmant leur utilité voire leur caractère essentiel pour permettre l’interopérabilité non plus syntaxique mais sémantique (la pâte à gâteau, pas la forme du moule) des données. Le mythe du moteur de recherche magique qui serait capable, par des traitements automatiques, de compenser l’absence de tels référentiels s’est effondré quand on a constaté que les moteurs fonctionnaient quand même beaucoup mieux quand on y ingérait des données plus riches. L’inconvénient de ces modèles réside toutefois dans leur complexité, qui a pu dans certains cas freiner leur adoption, notamment en l’absence de compétences informatiques adéquates. Par ailleurs, la modélisation des vocabulaires ou ontologies destinés à représenter toute la richesse de l’information des institutions patrimoniales et scientifiques est une gageure qui résiste à toute tentative d’unification ou de consensus ; c’est d’ailleurs bien l’esprit du web de données, qui autorise la coexistence ou la cohabitation de plusieurs modèles reliés entre eux.

* du point de vue des contenus : RAS, ils ne sont pas vraiment concernés par cette phase et restent accessibles suivant des modalités plus ou moins similaires au modèle d’agrégation précédent.

Côté Europeana on peut mentionner, outre la mise en œuvre d’EDM au sein d’un nombre croissant de projets thématiques, la création d’un entrepôt en Linked Open Data permettant la redistribution des données en RDF et en SPARQL. Le portail lui-même a migré sous EDM en 2013 mais sa dernière version baptisée « Europeana Collections » ne tire pas encore tout le parti de la richesse du modèle.
A la BnF, data.bnf.fr est né mais reste un petit frère de Gallica se contentant de liens avec son aîné dont il ne bouleverse pas l’existence. Bref, on peut parler d’une phase « d’éveil » qui conduit à examiner sous un jour nouveau les possibles et à faire ressentir le besoin d’un vrai nouveau modèle d’agrégation, dépassant les limites de l’OAI-PMH et tirant les enseignements du web de données.

Vers un modèle de mutualisation

Dans un contexte de moyens contraints mais aussi d’évolution de la technologie et des usages, un nouveau modèle commence aujourd’hui à émerger, basé sur le principe de la mutualisation des investissements et notamment des infrastructures.
* du point de vue technique, ils s’agit de mutualiser les infrastructures du point de vue du stockage des données ou encore des traitements (conversions, diffusion…) Les données passent dans les mêmes tuyaux et les mêmes moulinettes, ce qui représente une économie à la fois en ressources machines et en développement d’outils. Des modèles de type cloud permettent d’effectuer cette mutualisation dans des espaces physiquement communs mais logiquement indépendants (façon moule à madeleines). Il n’y a donc pas forcément agrégation à ce stade, mais elle sera évidemment facilitée par la suite.
* du point de vue des données, l’ambition est de dépasser les contraintes liées à l’adoption d’un modèle ou format commun. On attend des outils nouveaux qu’ils soient suffisamment flexibles pour s’adapter à tous types de formats et qu’ils supportent facilement les conversions de l’un à l’autre : c’est la leçon tirée des étapes précédentes, qui ont démontré qu’il était toujours préférable de travailler les données dans leur format source, qu’aucun format « commun » même riche ne peut remplacer. Le web de données reste un modèle d’interopérabilité prometteur grâce aux URI, aux liens entre les ressources et à la sérialisation JSON-LD, beaucoup plus simple que les syntaxes précédemment utilisées pour exprimer le RDF. Des vocabulaires comme Schema.org visent à permettre de faire du web sémantique comme Monsieur Jourdain faisait de la prose.

* du point de vue des contenus : on commence dans la sphère culturelle à dépasser le paradigme qui voulait que les contenus, pour des raisons politiques, ne soient consultables que sur le site d’origine, position devenue intenable (si elle l’a jamais été) du point de vue des usages. Que ce soit par copie des fichiers ou via des API comme IIIF, qui fournit un mécanisme pour appeler de manière distante des images numérisées avec leurs métadonnées en JSON-LD, la tendance est à l’agrégation des contenus eux-mêmes dans l’interface commune, ce qui permet de mutualiser également les outils complexes que sont les visualiseurs de documents.

Gallica et Europeana, pour continuer sur ces deux exemples, ont toutes deux entamé une mutation progressive vers ce nouveau modèle. Du côté de Gallica, cela se concrétise par l’intégration de documents de partenaires qui n’avaient pas encore trouvé leur outil de diffusion et par la réalisation de bibliothèques numériques en « marque blanche », Numistral et la Grande Collecte. Côté Europeana, le nouveau portail Collections utilise IIIF pour présenter directement sur son site les médias numérisés, avec zoom en haute résolution et feuilletage le cas échéant.

Derrière cette modification en apparence ponctuelle, c’est en fait une refonte complète du modèle d’agrégation qui se profile du côté d’Europeana. Après avoir défini un cadre de publication (Europeana Publishing Framework) et, en partenariat avec DPLA, un cadre juridique, Europeana s’interroge actuellement via le forum des agrégateurs sur le rôle et la fonction de ces derniers. Le projet Europeana Cloud, qui s’est déroulé de 2013 à 2016, permet d’imaginer un avenir où de nombreuses fonctions de stockage et de traitement de données seront mutualisées dans une infrastructure commune, ce qui évitera aux agrégateurs de faire face aux mêmes problèmes en développant chacun des solutions différentes.

Le rôle des agrégateurs évoluerait alors vers une fonction de centre d’expertise au service d’acteurs plus modestes ou disséminés, qui les accompagnerait dans l’agrégation de leurs données directement dans l’infrastructure cible. On pourrait imaginer la centralisation de traitements coûteux et complexes à mettre en œuvre comme les alignements de référentiels ou les enrichissements automatiques de métadonnées. L’utilisation de mécanismes comme IIIF présente l’avantage de conserver la lisibilité des flux d’audience (on comptabilise tout de même des « hits » sur le site fournisseur) tout en favorisant des usages plus fluides. C’est la promesse de pouvoir non seulement centraliser dans les portails la visualisation des contenus, mais aussi constituer plus facilement des bibliothèques numériques de niche, agrégeant et éditorialisant des contenus sélectionnés à un niveau local.

En conclusion : aujourd’hui, demain ou après-demain ?

Sans vouloir avoir l’air de lire dans les entrailles de maquereau, ce que j’ai pu observer ces derniers mois me donne à penser que le nouveau modèle d’agrégation n’est pas encore tout à fait mûr et ne le sera pas avant au moins 3 à 5 ans. Il ne dit pas encore son nom et ressemble aujourd’hui à un patchwork d’initiatives en ordre dispersé dont il est assez difficile de voir le motif global, à moins de prendre beaucoup de recul, ce que j’ai essayé de faire ici. Certains aspects techniques relèvent encore de la promesse et demandent à démontrer leur faisabilité. On pourrait également avoir des surprises et voir de nouveaux dispositifs émerger. Cependant, je suis convaincue que l’on tendra inévitablement vers ce nouveau modèle qui s’installera d’abord en parallèle du modèle OAI-PMH, toujours efficace, et du web de données qui continue à se développer.
A suivre, rendez-vous dans 3 ans ?
En attendant, je me permets de vous solliciter, vous qui avez eu le courage de lire ce long billet jusqu’au bout :
– si vous avez encore le temps de faire de la veille et si vous connaissez d’autres exemples de modèles d’agrégation qui évoluent dans le même sens ou dans un sens différent,
– si vous en savez plus que moi sur les aspects techniques et que cela vous inspire des suggestions ou des réfutations,
– si vous agrégez des données et que ces perspectives vous parlent,
exprimez-vous dans les commentaires ci-dessous, vous aurez ma gratitude éternelle.

Réflexion autour de Bibframe et la formation au Web sémantique

Publié le par

Je n’avais jamais eu le temps de me pencher véritablement sur Bibframe, ce « format » développé par la bibliothèque du congrès dans le cadre de sa transition bibliographique, avec pour objectif annoncé de « remplacer les formats MARC ». J’ai pu récemment réparer ce tort grâce à une étude d’une collègue de la BnF (merci Suzanne) suivie d’une très riche discussion avec plusieurs autres collègues (privilège des grandes maisons !)

Au départ, l’idée de Bibframe nous a laissés plutôt songeurs. Pour commencer, peut-on vraiment parler de « format » ? Naturellement, entre gens habitués depuis plusieurs années à manipuler des vocabulaires RDF et des triplets, nous avons plutôt employé le terme de « modèle ». Or, ce modèle est assez troublant. Sans se raccrocher explicitement à d’autres modèles/vocabulaires comme FRBR ou Dublin Core, il ne paraît pas non plus incompatible avec eux.
En termes d’usage, difficile également d’avoir les idées claires : Bibframe serait-il un « format » de production ? Dans ce cas il ne paraît pas assez détaillé. Un « format » d’échange ? Mais alors pourquoi n’avoir pas privilégié un vocabulaire existant et déjà bien implanté, comme le Dublin Core… Serait-il alors un « format » destiné principalement à transformer en graphe des notices MARC existantes ? Hypothèse peut-être la plus plausible, mais la souplesse du modèle est telle qu’il permettrait de le faire de mille façons différentes.
Au terme de la discussion, Bibframe ne nous semblait pas avoir vraiment de sens dans une perspective technique. Rien de ce qui est fait dans Bibframe ne semble impossible à faire en combinant des vocabulaires existants comme par exemple dans le modèle de données de data.bnf.fr. On a donc l’impression d’avoir affaire au énième standard qui vient se surajouter à tous les autres pour essayer de les réconcilier… et ne fait que créer une nouvelle couche de complexité (cf cette fameuse BD).

Cependant, en y réfléchissant en résonance avec divers événements, j’ai commencé à regarder les choses autrement.

D’abord, il y a eu Semweb.pro, le mois dernier, et la conférence de clôture de Phil Archer. Dans celle-ci, il a émis l’idée que l’important à transmettre à nos développeurs et autres professionnels n’était pas « faites du Web sémantique » car dans la plupart des cas, ils n’avaient en fait pas besoin du niveau de complexité qui est associé à cette technologie. Pour, lui il suffit dans la plupart des cas de se limiter à trois choses :
– attribuer des URI,
– penser en graphe,
– faire du JSON-LD (cette sérialisation très simple de RDF semble être la meilleure promesse d’adoption par les développeurs depuis l’invention du Web sémantique).
Alors ils feraient du Web sémantique sans y penser, comme Monsieur Jourdain faisait de la prose.

Ensuite, j’ai participé le 26 novembre à la 2e saison de la formation du CNFPT « les catalogues au défi du Web ». Au cours des différentes discussions, notamment la très intéressante table ronde de l’après-midi, je réfléchissais au fait qu’il ne serait ni possible, ni utile de former tous les catalogueurs ou tous les bibliothécaires au Web sémantique.
Je me suis souvenue qu’à l’époque où j’ai fait l’ENSSIB, nous avions des cours sur la modélisation des bases de données relationnelles et sur le requêtage SQL. A part pour les tordus dans mon genre qui ont besoin de comprendre comment fonctionnent les choses sous le capot, cela n’avait aucun intérêt. Difficile de placer le curseur de l’apprentissage technologique pour des gens qui n’auront pas à pratiquer au quotidien… C’était ce qu’on appelait dans le temps « le niveau technico-stratégique » : le niveau de base de connaissance technique qui permet de comprendre et donc de décider. Mais tout le monde n’en a pas besoin.

En effet, après avoir déployé pas mal d’énergie à essayer de former des bibliothécaires au Web sémantique (on a même écrit un bouquin, c’est dire) je suis aujourd’hui convaincue que la plupart d’entre eux peuvent vivre très confortablement sans savoir ce qu’est le Web sémantique ou comment ça marche. Par contre, ils manipuleront et pour certains, créeront de la donnée en RDF, mais façon M. Jourdain, sans en avoir conscience.
Finalement, seuls les modélisateurs de données ont vraiment besoin de connaître et comprendre en détail le Web sémantique et ils sont assez peu nombreux. D’ailleurs, cela fait peu de différence avec la situation antérieure : combien de catalogueurs savent qu’en fait de MARC, il produisent en réalité de l’ISO 2709 stocké dans les tables d’une base de données relationnelle ?
Pour revenir à Bibframe, je pense qu’on pourrait interpréter de cette façon le besoin d’avoir un « format » pour remplacer MARC.
Si on souhaite que les catalogueurs et les développeurs de SIGB (ces deux groupes en priorité) manipulent des URI et des triplets sans avoir besoin d’une formation extensive à RDF, SPARQL, OWL etc., et sans même avoir besoin de maîtriser les 5 vocabulaires de base du Web sémantique, nous avons besoin d’un outil (appelons-le « format ») qui permette d’expliquer de manière simple le nouveau modèle des données bibliographiques. Nous avons besoin qu’il soit suffisamment homogène et cohérent pour qu’on puisse expliquer ce format, uniquement ce format, et que dans la phase de transition cela permette aux catalogueurs et aux développeurs de SIGB d’acquérir une maîtrise des données suffisante pour les tâches qu’ils ont à effectuer. Enfin, nous avons besoin que ce « format » ait un nom afin de pouvoir faire passer aux managers des bibliothèques et aux décideurs un message simple : « on va remplacer MARC par X ».

Alors, pourquoi pas Bibframe ?
Bibframe est un outil qui est déjà associé à la transition bibliographique et à l’idée qu’il y aura un « après-MARC » que l’on doit commencer à construire dans les bibliothèques. Il est suffisamment souple pour être compatible avec les anciens formats (MARC aux différents parfums) et les nouveaux modèles (FRBR & Co). Bien sûr il manque encore pas mal de choses dans Bibframe (rien n’est fourni, par exemple, pour décrire les autorités) mais on pourrait le compléter ou l’étendre, l’adapter à nos besoins, en faire un profil français, voire établir ses correspondances avec d’autres vocabulaires du Web sémantique que nous utilisons par ailleurs.

Bibframe n’est en fait pas un format mais un « cadre » (framework, comme son nom l’indique) permettant d’accompagner la transition vers le Web sémantique pour les bibliothèques.
A l’heure où nous entamons en France notre propre transition bibliographique nationale, nous aurons dans doute également besoin d’un outil qui serve de support à la formation des producteurs de données et des développeurs, et qui soit plus simple que la machine de guerre Web sémantique : des URI, un graphe, une sérialisation simple.
Je ne sais pas si Bibframe sera cet outil mais on pourrait en tout cas s’inspirer de la démarche.

Un réservoir de données liées…

Publié le par

En farfouillant dans les archives du Figoblog pour produire un document, je retombe sur cet article d’avril 2006 dans lequel je suggérais :

Moi je verrais bien l’évolution du catalogue vers un statut de base « pivot », contenant des données en XML qu’on pourrait réutiliser à volonté, dans des applications adaptées aux différents types d’usagers.

5 ans après, je ne sais pas si je suis complètement monomaniaque ou franchement visionnaire, mais j’ai toujours la même vision. A quelques détails près.

Je pensais XML, parce que je n’avais pas encore réalisé qu’il n’était pas vraisemblable de vouloir faire entrer toutes les données du catalogue, dans leur diversité, dans un même modèle documentaire.
Il a fallu s’extraire des carcans de la pensée documentaire pour considérer que ce dont nous avons besoin, ce n’est pas un format unique, mais un modèle générique capable d’intégrer de façon souple et auto-descriptive différents formats.

J’avais aussi pressenti que le problème n’était pas d’imaginer les nouveaux usages, mais d’imaginer un réservoir de données capable de s’adapter à tous les usages possibles :

Il y a des usages, multiples, différents, et aucun outil miracle ne saura tous les contenter. Il faut des données fiables et souples, qu’on peut sortir, transformer, adapter, réutiliser. Pour moi c’est ça le futur du catalogue.

En fait, j’envisageais déjà le catalogue comme un système métastable, c’est à dire capable d’intégrer les évolutions de façon naturelle, et pas uniquement comme des facteurs de remise en cause et d’instabilité.

En fait, il fallait pousser le raisonnement jusqu’au bout : ce qui m’inspirait ces réflexions c’était le modèle du Web. Or, le Web, en tant qu’espace global d’information (un espace où on peut naviguer d’une page à l’autre sans rupture, ni technologique, ni dans l’expérience utilisateur : il suffit de « cliquer »), nous apprend précisément ceci : si on veut que de larges quantités d’informations puissent interopérer, il faut accepter qu’elles soient produites de façon hétérogène, et n’imposer que le niveau minimal de normalisation permettant à toutes ces informations de cohabiter dans le même espace.

Les systèmes d’information actuels (dont les catalogues) posent exactement ce type de problème : ils sont instables au sens où leur équilibre est sans arrêt remis en cause par quelque chose de nouveau (un nouveau format, un nouveau besoin, une nouvelle fonctionnalité), et ils sont hétérogènes parce qu’à chaque nouveau besoin, on donne une réponse spécifique.

Le Linking Enterprise Data correspond à l’application des principes du Linked Data au domaine de l’entreprise. Je ne vous parle même pas d’exposer les données sur le Web. L’enjeu est seulement d’utiliser le Web (ou le Web sémantique) comme modèle pour la conception du système d’information. On adopte un niveau de normalisation minimal pour toutes les applications, de façon à ce que les données soient interopérables et reliées (avec des URI). A partir de là, le système devient métastable, capable de maintenir une certaine stabilité dans un contexte en évolution. Quand un nouvel usage émerge, la donnée est déjà disponible, il suffit de l’agréger pour la retraiter.

La masse des données manipulée dans les catalogues (surtout les gros) rend illusoire l’adoption d’une base unique, d’un format unique. Techniquement, les problèmes de performance et de cohérence sont exponentiels. Du point de vue de l’utilisateur, le modèle est rigide, inadapté aux évolutions.
Il faut adopter un modèle qui est prévu, de façon inhérente, pour être permissif aux évolutions. RDF par exemple.
Dès lors le catalogue, plutôt qu’un réservoir unique, est une plate-forme, un environnement cohérent au niveau local (à l’intérieur de la bibliothèque) dont le rôle majeur est de relier les données et de les rendre disponibles.

Merci à Got d’avoir partagé ses lumières avec moi sur ce sujet.

DC 2010…

Publié le par

Me voici donc à Pittsburgh pour la conférence «Dublin Core 2010», où le DC fête ses 15 ans, et la conférence ses 10 ans.
Un petit mot sur cette communauté : on compte ici environ 150 personnes, ce qui fait peu, je trouve, si on considère que c’est une des conférences majeures sur les métadonnées (à croire que les experts en métadonnées ne sont pas légion ;-)

Bien qu’il y ait beaucoup de «nouveaux», de gens qui comme moi assistent à leur première conférence DC, ma première impression a été celle d’une communauté arrivée à un moment critique de son existence, en quête d’un difficile équilibre entre l’expérience sur laquelle elle est assise, associée à un certain effet d’inertie, et son image de communauté innovante ancrée dans l’écosystème du Web.
Ainsi, quand la communauté se retourne pour regarder les 15 années passées derrière elle, ce n’est pas sans une certaine amertume… Impression qui ressortait particulièrement de la «Keynote» de Stu Weibel, un des fondateurs du DC, qui est revenu sur les succès et les échecs de 15 années de normalisation. Un bilan quand même assez désabusé, face à la complexification croissante de ce qui se voulait un standard simple, et les difficultés pour se conformer véritablement au mode de fonctionnement et au développement du Web.

Mais à part cela, le Linked Data est partout, et l’initiative du LLD XG a été citée de façon répétée, apparaissant comme une porte de sortie, ou plutôt un espoir de transition vers quelque chose de nouveau, un nouveau souffle pour la communauté.
Il faut dire qu’avec 42 use cases collectés, le LLD XG semble réunir le matériau nécessaire pour démontrer à la fois l’importance et l’utilité du Web de données, et la voie pour y arriver.
J’ai assisté à une grande partie de la session «spéciale» sur le Linked Data organisée par Karen Coyle et Corey Harper. Dans le groupe de travail «Library Community», le Linked Data était aussi à l’honneur, avec une présentation du XG, et des initiatives allemandes (Univ. de Mannheim et DNB).

Autre sujet brûlant, les FRBR. Il y avait une session plénière qui leur était consacrée, mais on en a aussi beaucoup parlé dans la session spéciale Linked Data, qui portait sur les «domain models».
Cela soulève beaucoup de questions : les FRBR sont-ils trop complexes ? sont-ils le modèle adapté pour décrire l’information des bibliothèques, en particulier une information «héritée» (legacy data) qui n’est pas conforme au modèle ? Est-ce que la complexité du modèle ne risque pas de complexifier les données ?

A suivre…

Petite visite guidée de RDA

Publié le par

Pour ceux qui n’auraient pas encore eu l’occasion de jeter un oeil au RDA Toolkit, voici un petit guide de ce que l’on peut y trouver (NB : j’avais pris ces quelques notes à l’époque où il était encore en accès libre…)

Si on le déroule dans l’ordre (ce qui n’a peut-être pas de sens, vu qu’il y a des liens dans tous les sens, c’est un hypertexte ;-) mais bon il faut bien commencer quelque part), on rencontre d’abord une introduction qui présente les objectifs de RDA, le lien avec les FRBR et autres standards, et une liste des « core elements ».

Viennent ensuite les sections 1 à 4, consacrées à l’enregistrement des attributs des
– manifestations et items,
– œuvres et expressions,
– personnes, familles et organisations,
– et concepts, lieux et événements (cette section n’est pas encore développée sauf pour les lieux).
Dans RDA, les attributs jouent un rôle essentiel puisque ce sont les éléments qui constituent la description elle-même, et donc qui permettent d’identifier les entités. Chaque entité est ainsi décrite avec des « core elements », qui sont plus ou moins obligatoires, et des éléments additionnels qui ne doivent être utilisés que s’ils sont nécessaires pour identifier l’entité.
Pour tout ce qui peut servir de point d’accès, au sens bibliographique du terme (ce par quoi l’utilisateur cherche), donc les œuvres, expressions, personnes etc., on construit également un « point d’accès autorisé » avec un titre ou nom préféré, et des variantes.

Viennent ensuite les sections consacrées aux relations entre entités.
La section 5 est consacrée à l’enregistrement des « relations primaires » c’est-à-dire les relations structurelles entre entités du groupe 1 : Œuvre, Expression, Manifestation et Item. Elles sont supposées être exprimées dans cet ordre, sauf qu’on peut sauter l’Expression si on veut.
Les sections 6 et 7 sont consacrées aux relations entre les entités du groupe 1 et celles des groupes 2 et 3 (celles du groupe 3 ne sont pas encore développées).
Les sections 8, 9 et 10 sont pour les relations internes à chaque groupe d’entité (le groupe 3, vous l’avez deviné, n’est pas encore développé).
L’expression de toutes ces relations fait appel à des « relationships designators » dont les listes sont enregistrées en annexe :
– annexe I pour les relations entre une entité du groupe 1 et une entité du groupe 2 (ce qu’on pourrait appeler les « rôles »);
– annexe J pour les relations internes entre les entités du groupe 1;
– annexe K et L pour les relations internes aux groupes d’entités 2 et 3.

Ces relations constituent une sorte de spécialisation ou d’interprétation de FRBR, au sens où des choix assez radicaux ont été effectués.
Par exemple, s’agissant des « rôles », le « creator » ne s’applique qu’à l’œuvre, alors que l’expression, elle, a un « contributor ». La manifestation peut avoir un publisher, un distributor, et un manufacturer ; quant à l’item, il peut avoir un owner et un custodian.

Les règles elles-mêmes peuvent porter sur les sources d’informations à consulter (même si « take this information from any source » est probablement la phrase qui revient le plus souvent dans RDA, surtout quand il s’agit des œuvres et ce genre de trucs…), et sur la façon de transcrire les informations. Il y a un certain nombre de règles particulières pour les manuscrits, les documents et œuvres audiovisuel(le)s, ou encore les documents électroniques (y compris des informations techniques et des informations sur les restrictions d’accès).

Enfin pour certains éléments, on dispose de référentiels qui permettent de prédéterminer une liste de valeurs à utiliser.
Noter ainsi que le support se décline en trois éléments :
– le type de média, qui indique le type de matériel à utiliser pour accéder au contenu, dans une liste qui inclut « unmediated: Media used to store content designed to be perceived directly through one or more of the human senses without the aid of an intermediating device » (j’adore…)
– le type de support, à préciser pour chaque média (par exemple si le média est « computer », le support peut être « computer disc », computer tape », etc.)
– et enfin l’étendue (? « extent ») qui indique le nombre d’unités (et éventuellement de sous-unités) qui constituent la ressource : par ex. 3 microfiches, 2 computer discs etc.

Au final, après le rapide tour d’horizon de RDA que j’ai effectué, voici quelques impressions personnelles :
– beaucoup de souplesse : les règles ne sont pas très directives ; elles proposent souvent des alternatives, des exceptions, ou laissent la porte ouverte à l’interprétation…
– du flou, parfois : il faut la plupart du temps décortiquer les exemples pour réussir à comprendre où les règles veulent nous emmener…
– et pas mal d’implicite : il faut connaître ses FRBR sur le bout des doigts. Les RDA ne vous donneront pas de clés pour décider comment dépatouiller les cas complexes et limites d’identification des œuvres. Si vous cherchez à déterminer quelle est précisément la relation à utiliser pour raccrocher le dernier livre de bain que vous avez offert à votre tout-petit et qui s’intitule « la petite sirène » à l’œuvre d’Andersen, autant vous le dire tout de suite, la réponse ne se trouve pas dans les RDA.
Bref, les RDA ne sont pas du prêt à consommer. Il me semble qu’il y a un gros travail d’accompagnement et de documentation à effectuer avant de mettre cela entre les mains d’un catalogueur…

Enfin, sachez que même si vous n’avez pas accès au Toolkit dans sa version payante, vous pouvez télécharger tous les schémas qui représentent les différentes entités, leurs attributs et relations, et incluent les principales définitions.

Le catalogueur, l’usager et le système

Publié le par

Comme je parcourais le RDA Toolkit, profitant de sa temporaire gratuité (jusqu’au 31 août, je le rappelle), je me suis sentie dériver librement au fil de pensées inattendues.

S’appuyant sur les FRBR et sur les principes internationaux de catalogage, les RDA rappellent une chose qu’on parfois trop tendance à négliger quand on parle de catalogage : le but du catalogage, c’est de répondre aux besoins des utilisateurs, tout en rationalisant les moyens qu’on déploie pour y arriver :

The data should meet functional requirements for the support of user tasks in a cost-efficient manner.

Non, le catalogage n’a pas été inventé par les bibliothécaires pour se faire plaisir (ou pas uniquement).

Les lecteurs de ce blog, quand on leur parle FRBR, se souviendront peut-être des fameux 3 groupes d’entités et de l’articulation entre Œuvre, Expression, Manifestation et Item. Je suis à peu près sûre que parmi les gens qui ont des notions quelconques de FRBR, peu d’entre eux se souviennent que les FRBR, c’est aussi une description détaillée des opérations effectuées par les utilisateurs, réparties en 4 grands groupes : trouver, sélectionner, identifier et obtenir. S’y ajoute le niveau de pertinence des différentes métadonnées pour accomplir ces tâches.

Les RDA reprennent ces tâches pour rappeler à quoi sert chaque partie de la description, ce qui n’est pas du luxe. Cela leur permet de définir les « core elements », dont on a toujours besoin quoi qu’il arrive, et les autres qui ne sont à renseigner qu’en tant qu’ils sont indispensables pour accomplir les tâches utilisateurs.
En cela, ma compréhension de RDA (je n’ai pas fini de les lire, c’est donc plutôt une impression globale) c’est qu’une grande liberté est laissée au catalogueur (ou à l’agence pour qui il travaille) pour décider plus précisément des éléments nécessaires à la description de telle ou telle ressource.
Derrière cette liberté se cache l’économie du catalogage. En effet, RDA nous laisse entrevoir un monde meilleur où on ne décrirait d’une ressource que ce qui est vraiment nécessaire pour la trouver, l’identifier, la sélectionner et l’obtenir, et rien de plus. Un monde où au lieu de répéter N fois l’information, on pourrait relier les ressources et les descriptions entre elles. Un monde où on aurait des descriptions pour des parties, des descriptions pour le tout, et des descriptions hiérarchiques qui les combinent.

Dérivant toujours le long du fil de mes pensées, j’ai saisi l’effluve évanescent d’un souvenir, ou plutôt, d’un leitmotiv que j’ai entendu maintes fois prononcé, chuchoté dans les couloirs : c’est le fantôme du catalogage à niveaux qui revient.
Moi qui suis une (relativement) jeune professionnelle, je n’ai connu du catalogage à niveaux que ces réminiscences lointaines, comme un spectre qu’on aurait eu tant de mal à chasser, et qui s’obstinerait à revenir par la petite porte.
Alors, me suis-je demandé, au fait, c’était quoi le catalogage à niveaux, et pourquoi diable l’a-t-on abandonné ?
Après une courte recherche dans mon moteur préféré, je suis tombé sur cet article de 1988 qui explique que le catalogage à niveaux, c’était :

une présentation élégante, rationnelle : les éléments communs de la notice sont mis en dénominateur commun ; les éléments propres aux volumes sont donnés à la suite les uns des autres

et qu’on l’a abandonné parce qu’il était mal géré par certains formats MARC (notamment nord-américains) et par les progiciels de catalogues de bibliothèques.
Je ne résiste pas à vous proposer cette autre citation d’une saveur toute particulière (nous sommes, je le rappelle, en 1988) :

L’arrivée de nouveaux supports de diffusion utilisant des logiciels documentaires puissants permettant des combinaisons de clés variées et la recherche par mots clés sur la totalité de la notice, confirme aujourd’hui que la séparation des informations est une technique dépassée.

Un élan de nostalgie m’a emportée à l’idée qu’on a renoncé à quelque chose qui était pratique pour les catalogueurs ET pour les utilisateurs, parce que les formats et les systèmes ne savaient pas le gérer.
Puisse l’avenir nous préserver d’un monde où on définit les formats en fonction des systèmes, et les usages en fonction des formats. Voilà à quoi sert l’étape de modélisation : à définir les objectifs du modèle et le modèle lui-même, avant de concevoir les outils qui vont l’exploiter.

NB : en fait, les notices à niveaux n’ont pas totalement disparu du catalogue de la BnF. L’intermarc permet de gérer des « notices analytiques » pour le dépouillement de plages de disques, lots d’images, etc…

Après Göteborg, Singapour : un cadre pour les Application Profiles

Publié le par

Après avoir entendu parler (ou reparler ?) à plusieurs reprises des « profils d’application » (application profiles ou AP) du Dublin Core, que ce soit dans le LLDXG ou à l’IFLA, j’ai éprouvé le besoin de me replonger dans tout cela. Force est de constater que je ne m’y étais pas intéressée de près depuis plusieurs années, alors que le développement de RDF et du Web de données a conduit le DCMI à revoir complètement son modèle abstrait (le DCAM, Dublin Core Abstract Model) et cette notion d’Application Profile, vers 2007.

Il n’est pas dans mon propos d’entrer dans les détails du DCAM aujourd’hui. Ce modèle est surtout utile en tant que référent pour le vocabulaire un peu particulier utilisé dans le monde Dublin Core.
Plus intéressant, à mon avis, est le Singapore framework for Application Profiles, un autre document du DCMI qui a le statut de « recommended resource » (autrement dit, ce n’est pas un standard, mais il est important quand même).

Ce document, le cadre de Singapour, a été proposé à la conférence DC en 2007 (décidément une année cruciale). Il définit les différents éléments constitutifs d’un Application Profile.
Quand on applique un standard de métadonnées, il existe différents niveaux qui doivent être pris en compte pour favoriser l’interopérabilité : bien sûr il faut respecter la syntaxe, le nom des éléments, la façon adéquate de les utiliser selon qu’ils sont obligatoires ou pas, répétables ou pas, etc. Mais pour aller plus loin, il faut aussi définir précisément les valeurs de ce qu’on met dans ces éléments, et éventuellement la façon de construire ces valeurs.

Je vais faire une comparaison pas du tout triviale avec le monde des bibliothèques.
Nous avons des standards qui sont des formats de métadonnées (MARC par exemple, et ses « différents parfums » comme dirait l’autre).
Nous avons d’autres standards qui sont des règles de catalogage et expliquent comment, à partir d’un document qu’on a entre les mains, on va déterminer quel est le titre, l’auteur principal, l’éditeur, etc. et comment il faut les transcrire dans la notice. Cette deuxième famille de norme comprend AACR2 pour les anglo-saxons, ISBD pour le reste du monde, et RDA pour l’avenir (peut-être).
Nous avons également des standards qui décrivent le modèle sous-jacent de toute cette information et à quoi elle sert : ce sont les FRBR et leurs petits frères FRAD (vient de sortir en français) et FRSAD.
Construire un Application Profile, cela revient à embrasser toute la palette de ces normes pour une communauté définie, et à formaliser le résultat.

Le Singapore framework définit ainsi les éléments suivants comme constitutifs d’un AP :
– les spécifications fonctionnelles (functional requirement ou FR – ça vous rappelle quelque chose ?) et le modèle du domaine : ce sont les représentations abstraites qui définissent l’objectif de notre AP, et elles sont obligatoires ;
– le Description Set Profile, sur lequel je vais revenir dans un instant ;
– et les guides d’utilisation (guidelines) pour le contenu et pour l’encodage, tous deux optionnels. Ce sont les équivalents de nos règles de catalogage mais aussi, guides et outils du catalogueur divers.

Je ne reviens pas sur les modèles et sur les guides.
Le Description Set Profile (DSP) fait l’objet d’un document normatif DCMI encore au stade de « working draft ».
Le DSP est un document XML qui permet de décrire les différentes propriétés qu’on utilise dans notre AP, et jusqu’à un certain point, la façon dont on les utilise.
Le DSP prend complètement acte de RDF, au sens où il ne se restreint absolument pas aux propriétés du DC (voir ici pour un rappel). On peut donc construire un Application Profile en piochant dans les différents vocabulaires qu’on veut, FOAF, DC, etc. du moment que les propriétés qu’on utilise sont identifiées par une URI. Jusqu’ici, on est bien dans l’esprit de RDF.
Le DSP permet aussi de préciser un certain nombre de choses sur la façon dont on utilise ces propriétés. On peut préciser si l’objet doit être une ressource (identifiée par une URI) ou un littéral (une chaîne de caractères), ou si la propriété doit être obligatoirement une sous-propriété d’une propriété plus générique. On peut également définir qu’une propriété est obligatoire ou non, répétable ou non.

Bref, le DSP est conçu pour permettre de « valider » un ensemble de triplets RDF en fonction de règles prédéfinies (on parlerait d’un « pattern » en anglais, et ce sera compliqué à traduire). Le but étant d’obtenir des descriptions, ou si vous voulez des notices, le plus homogènes possibles. Il existe un document du DCMI qui définit les différents niveaux d’interopérabilité que l’on peut atteindre. Le DSP permet d’atteindre un niveau d’interopérabilité optimal !
Cette notion de validation, en réalité, est un non-sens en RDF. Les ontologies ne servent pas à valider les données. Elles se contentent de décrire les choses et leurs qualités, mais elles ne sont pas prescriptives. Ce n’est pas parce qu’il y a une propriété foaf:geekCode que tous les gens qu’on décrit en utilisant foaf sont nécessairement des geeks (ou doivent le devenir ;-) A l’inverse, en RDF, chaque triplet est indépendant ; il n’y a pas de notion de « notice », donc aucun moyen de dire que si on veut décrire une personne, il est obligatoire de mentionner son nom de famille – par ex.
Pour autant, si on veut pouvoir vérifier que certaines règles sont respectées pour produire certains types de données, on aura besoin de ce genre de mécanisme. Cela peut être le Description Set Profile tel qu’il se présente actuellement, mais on pourrait imaginer (et les gens du DCMI y réfléchissent) d’autres formalismes, des schémas XML, des schématrons, ou même des requêtes-type pour exprimer cette notion de validation.

Le Singapore framework for Application Profiles et le Description Set Profile sont donc des documents qui à mon sens méritent toute notre attention, car ils font le pont entre le monde du Linked Data et celui des bibliothèques où tout est encore articulé autour du paradigme de la notice. Il me paraît clair que nous aurons besoin de ce type de formalisme – je ne dis pas celui-là en particulier, mais quelque chose de ce genre – si on veut porter toute la complexité des données des bibliothèques dans le Linked Data. Ou ne serait-ce qu’une partie.

Vacances d’été en RDA

Publié le par

Ah ah, ils sont impayables nos amis du JSC (Joint steering Committee – sous entendu : for the development of RDA).

Souvenez-vous : la dernière fois qu’il a fallu relire les RDA (resource description and access), ce nouveau code de catalogage, c’était presque Noël.

Maintenant qu’il paraît en version définitive, c’est juste avant les deux mois d’été. Et devinez jusqu’à quand vous avez accès gratuitement au RDA toolkit, ce site web qui deviendra le livre (enfin, le site Web) de chevet des bibliothécaires de demain ?

Jusqu’au 31 août.
Alors, pas de risque que les bibliothécaires s’ennuient pendant les vacances.
Et vive l’amitié France RDA !

Le problème avec le catalogue…

Publié le par

Je relisais ce matin le billet de B. Calenge « Pourquoi les catalogues ne peuvent pas être 2.0 » et je me disais que la vision qu’il donne du catalogue est tout à fait dans l’air du temps, c’est-à-dire, dans un mouvement de désaffection à l’égard de l’outil qui a incarné depuis tant d’années (depuis toujours ?) le cœur du métier de bibliothécaire.

En fait, le problème avec le catalogue, c’est justement sa nature multiforme et la difficulté de définir précisément à quoi il sert. Les bibliothécaires ont longtemps projeté leur propre vision du catalogue sur les usagers, et c’est ce qu’ils font encore quand ils essayent de construire le « catalogue 2.0 ». Mais en même temps, le catalogue est leur outil de travail, un outil de « gestion », principalement dédié à la « localisation » des ouvrages d’une bibliothèque donnée, un outil « local ».

Quand B. C. parle de « laisser disséminer les données bibliographiques » il se place dans une toute autre vision ; il n’est plus question « du catalogue » mais « des données ». C’est autre choses, on sort de cette vision centrée autour d’un outil.

Éviter la redondance (donc que plein de catalogueurs ressaisissent plein de fois la même information), permettre de lier les données du catalogue, permettre de les réutiliser, ce sont là les principaux défis du catalogue aujourd’hui.
Un pléthore de rapports ont été publiés récemment sur ce sujet ou des sujets connexes :
– réflexions du NISO sur la chaîne de production des métadonnées du livre
– réflexions de la Library of Congress sur le « marché » des notices MARC
– réflexion d’OCLC sur l’utilisation des champs MARC, dans une perspective de rationalisation du catalogage pour atteindre différents objectifs, dont l’utilisation par des machines
– etc.

Ce qui tend à en faire non plus un outil destiné à des humains, mais un ensemble de données réutilisables par des machines…

… donc nous pousse vers le Web sémantique. Dans ce billet, Karen Coyle explique bien quelles sont les limites des formats MARC quand on essaye de rendre les données des catalogues plus utilisables dans le Web. Il paraît clair qu’il faudra aller au-delà des formats MARC pour y arriver, et vers le Web sémantique… mais comment s’en sortir avec toutes ces données existantes en MARC qui sont dans nos catalogues ? qui pourra piloter cet énorme changement ? Plus grave, les acteurs majeurs ont-ils vraiment intérêt à y aller, ou freinent-ils des 4 fers ?

J’y vois une autre difficulté : cette évolution ne fera qu’amplifier la tendance à la désaffection des bibliothécaires pour ces sujets, de la formation initiale (apprendre à cataloguer, c’est vraiment trop has been) aux enjeux stratégiques et budgétaires des bibliothèques (investir dans le catalogue, c’est vraiment trop has been).
Qu’on ne se méprenne pas, je trouve cela normal, et même justifié, que la plupart des collègues se recentrent sur les questions de publics, de médiation, etc. plutôt que sur les questions rébarbatives de métadonnées.
Mais ces métadonnées, on en aura besoin. Elle constituent la colonne vertébrale de tout le reste. Pas de bibliothèques numériques, de blogs, de machins 2.0 sans une solide base de métadonnées sur laquelle construire tout cela.
Les bibliothécaires qui constitueront ce réservoir de métadonnées seront moins nombreux mais plus experts ; leurs compétences seront d’autant plus précieuses, car c’est un sujet complexe, beaucoup plus complexe que ce qu’on pourrait imaginer.
Il ne faut pas abandonner les métadonnées.