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

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

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…

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…

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

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

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

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

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…

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.

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