Archives de Tag: Web sémantique

Modélisons un peu : le choix d’un type de bases de données

Publié le par

Alors que je préparais mon dernier (ou presque) cours de modélisation de l’année pour les TNAH, m’est venue l’idée saugrenue de faire un arbre de décision qui récapitulerait les critères de choix entre différents types de bases de données : relationnelles, NoSQL, graphes, colonnes, bases de données documents XML ou non, moteurs de recherche… Il y a beaucoup d’options et ce n’est pas toujours évident d’avoir les idées claires.

Je me suis donc tournée vers Gautier, dont le puits de slides reste la ressource n°1 en matière de formation à la donnée, pour qu’il m’aide à trouver les bonnes formulations et à raconter des choses pertinentes du point de vue de l’infrastructure technique. Il faut dire que cette question nous agite depuis pas mal de temps (on se souviendra des quelques nuits blanches qu’on a passées au moment où on a décidé de mettre les métadonnées de SPAR dans un triple-store RDF) et qu’on se sent un peu responsables du prosélytisme qu’on a pu faire autour des technologies du web sémantique, aujourd’hui largement remises en perspective (lire la série de 4 billets à ce sujet sur Les petites cases).

Néanmoins, après quelques années où j’ai carrément refusé de continuer à enseigner RDF et SPARQL en arguant que ça ne servait plus à rien (merci le creux de la désillusion), je constate actuellement un regain d’intérêt pour le web de données, notamment dans le contexte des données « FAIR » pour la recherche. Je vois régulièrement passer des fiches de stage / de poste qui demandent des compétences en web sémantique, que ce soit pour modéliser des ontologies ou pour faire des requêtes SPARQL. Il est donc important de continuer à former des ingénieurs et analystes des données dans ce domaine, mais en prenant la précaution de replacer cette technologie dans le paysage global des systèmes de gestion de données existant à l’heure actuelle. L’enjeu est de bien comprendre dans quels cas elle peut rendre des services, et dans quelles situations il vaut mieux se tourner vers autre chose.

Différents types de modèles

C’était donc le point de départ de ma démarche, et il m’a emmenée assez loin :

  • d’abord, il a fallu rappeler que quand on parle de modélisation de données, on a en fait 3 couches de modèles :
    • le modèle conceptuel, qui décrit des entités du monde réel et leurs relations,
    • le modèle logique qui exprime les données sous une forme pouvant être manipulée par un traitement informatique,
    • et le modèle physique qui correspond à la façon dont l’information est exprimée dans un format ou stockée dans un logiciel.
Schéma présentant les 3 types de modèles : conceptuel, logique, physique. Il reprend ce qui est expliqué dans le texte.
  • À partir de là, j’ai pu détailler les principes et les spécificités des 3 types de modèles logiques :
    • le modèle en tables, qui organise les données en tableaux où chaque colonne correspond à un attribut et chaque ligne à une instance ou enregistrement (c’est le modèle des bases de données relationnelles, mais aussi des jeux de données tabulaires en Excel ou CSV),
    • le modèle d’arbre, adapté pour représenter une information organisée hiérarchiquement sous la forme de documents (par exemple, en XML ou en JSON),
    • le modèle de graphe, où les données sont reliées entre elles suivant la logique des prédicats (en RDF) ou d’autres types de logique de graphe comme les property graphs.
  • On va alors pouvoir s’intéresser aux différents types de SGBD (systèmes de gestion de base de données) qui correspondent à ces modèles :
    • les bases de données relationnelles,
    • les bases de données en colonnes,
    • les bases de données document,
    • les bases de données graphe.

Pour mémoire, ces « bases de données » ou plutôt ces « systèmes de gestion de bases de données » sont des logiciels qui assurent le stockage des données suivant un modèle logique, et fournissent des interfaces – souvent normalisées – pour interagir avec les données. Par exemple, dans une base de données relationnelle, les données sont stockées dans des tables et on interagit avec elles grâce au langage de requête SQL. Passons en revue de manière un peu plus détaillée ces différents outils.

Différents systèmes de gestion de base de données

Les bases de données relationnelles sont les doyennes de leur catégorie et en même temps, restent des outils fiables, solides et maîtrisés, qui peuvent rendre des services à différentes échelles, de la gestion d’informations personnelles en local jusqu’au pilotage d’énormes systèmes d’information. Elles sont efficaces pour stocker des données complexes dans des grandes volumétries, en offrant de bonnes performances en lecture (pour consulter les données) comme en écriture (pour produire et modifier les données).
Surtout, les bases relationnelles sont conformes aux propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité), c’est-à-dire qu’elles garantissent la gestion des transactions. Imaginons que vous ayez besoin de faire une modification dans vos données qui va impacter 500 enregistrements : c’est une transaction. Une fois que celle-ci est lancée, la base va soit l’exécuter jusqu’au bout, soit revenir à l’état initial (en cas de plantage par ex.) Si on lui demande une autre modification (une autre transaction) entre temps, celle-ci sera mise en file d’attente. Grâce à ce principe, la cohérence des données est garantie : il est impossible qu’une même donnée soit simultanément dans deux états différents.
Ces propriétés des bases de données relationnelles en font les favorites dans de nombreuses situations. Il peut toutefois arriver que vos données soient trop hétérogènes pour être exprimées en lignes et en colonnes : ainsi, lorsque je décris un inventaire d’archives, il m’est impossible de savoir à l’avance combien il aura de composants et comment j’aurai besoin de les décrire. Dans ce cas-là, d’autres modèles logiques peuvent être plus indiqués (on les regroupe parfois sous le nom de « NoSQL » ce qui veut juste dire que ce ne sont pas des bases de données relationnelles).

Une autre limite des bases de données relationnelles réside dans la contrainte de cohérence qu’imposent les principes ACID : il est (presque) impossible de les exécuter dans les environnements distribués qui caractérisent aujourd’hui le « big data ». En effet, ces environnements reposent sur le principe de scalabilité horizontale : quand j’ai besoin de plus de performance, je rajoute des machines en parallèle. Il devient alors difficile de continuer à garantir la cohérence des données, car elles peuvent être écrites et lues à différents endroits, avec un délai variable de synchronisation (je schématise sans doute beaucoup trop, mais vous voyez l’idée.)
Le théorème de CAP nous enseigne qu’un système ne peut pas être à la fois cohérent (C), toujours disponible (A pour Available) et distribué (P pour Partition) : les systèmes ACID se concentrent sur les deux premiers, et les systèmes distribués sur les deux derniers.

Visualisation du théorème de CAP sous la forme d'un schéma. On voir que les bases de données relationnelles sont entre le C (consistency) et le A (availability)

Si on a absolument besoin de scalabilité horizontale, et que le modèle est assez simple pour être réduit à une seule table, les bases de données en colonnes (Column Store) peuvent s’avérer utiles. Mais cela arrive quand même assez rarement dans le domaine des données culturelles et historiques, donc je ne m’étendrai pas sur ce scénario.

Les bases de données document sont conçues pour accueillir des données semi-structurées sous la forme de fichiers XML ou JSON par exemple. C’est pour cela qu’on parle de base de données orientée document : 1 fichier = 1 document. Elles permettent une montée en charge progressive des volumes de données, c’est à dire qu’il est relativement simple d’ajouter de nouvelles données (sous la forme de nouveaux documents ou fichiers) sans perturber les données existantes.
Leur principale contrainte est d’imposer un modèle centré sur une entité principale : pour que la base soit cohérente, il faut que tous les documents qui la composent soient de même nature (par exemple, des éditions de texte en TEI ou des inventaires d’archives en EAD). Cela va imposer une limite forte : si on a des données transverses à plusieurs documents (par ex. un référentiel de personnes pour les auteurs, producteurs, personnes évoquées ou représentées…) et que celles-ci sont modifiées fréquemment, il va falloir modifier tous les documents où ces données sont présentes, ce qui peut être assez lourd et surtout risqué. Sans la garantie ACID (voir ci-dessus, les bases relationnelles), on peut se retrouver dans une situation où une partie des documents est mise à jour, le système plante au milieu du processus, le reste n’est pas modifié… et paf, incohérence dans les données !

Le moteur de recherche est une base de données document dotée de fonctionnalités particulières : il facilite notamment la recherche plein texte (grâce à la constitution d’un index) et le filtrage par facettes des résultats. Il permet en outre de très bonnes performances en lecture (montée en charge du nombre d’utilisateurs et vitesse de réponse). Par contre, en raison des limites évoquées ci-dessus, on a plutôt tendance à l’utiliser comme stockage secondaire, c’est-à-dire qu’il va servir uniquement en lecture et pas en écriture, celle-ci étant assurée par un stockage primaire dans un autre type de base.

Schéma : le stockage primaire contient des data avec un accès principalement en écriture. Le stockage secondaire sert principalement l'accès en lecture pour les utilisateurs. Synchronisation entre les 2.

Finalement, si on a un modèle de données trop complexe pour l’exprimer sous forme de documents, et trop hétérogène pour qu’il rentre aisément dans une base de données relationnelle, cela vaut le coup de regarder du côté des bases de données graphes. Celles-ci sont aux données ce que la lampe magique est à Aladin : « des pouvoirs cosmiques phénoménaux… dans un vrai mouchoir de poche ! » (si vous m’avez lue jusque là, vous me pardonnerez la métaphore.)
Le mouchoir de poche, c’est le modèle de triplet (ou de quadruplet, ou autre, suivant le type de graphe que vous utilisez) : on réduit la complexité du modèle à une logique minimaliste et flexible, qui permet d’exprimer à peu près n’importe quoi (d’où les pouvoirs phénoménaux). Mais… all magic comes with a price. Et le prix à payer c’est que ces modèles sont relativement complexes à manipuler, avec des enjeux de maintenabilité et de performance.

Gif animé extrait de la série "Once upon a time" : Rumplestiltskin lève sa baguette en disant "all magic comes with a price"

Si le monde des graphes vous tente, la question est de savoir si vous avez besoin de placer votre graphe dans le web de données, pour faire le lien avec une communauté qui a décidé d’adopter les standards du web sémantique, notamment RDF et SPARQL (ce qui peut quand même être le cas assez souvent dans le domaine des données culturelles et des données de la recherche). Si oui, vous pouvez envisager d’utiliser un triple-store RDF. Mais il faut garder en tête que ces outils ont souvent des limites de performance et qu’ils sont assez peu maîtrisés dans l’industrie (ce qui veut dire qu’il sera difficile de trouver des prestataires pour les développer et les maintenir).
Si vous n’avez pas d’enjeu de diffusion web, pourquoi ne pas opter pour un autre type de graphe comme les « property graph » ? Cela permet de se débarrasser de certains détails agaçants comme la réification (acrobatie de modélisation nécessaire pour représenter certaines informations dans le modèle de triplet) ou les URI (parce que quand même, les URI, c’est compliqué, et si vous pensez le contraire je vous invite à venir expliquer le concept des préfixes en classe l’an prochain).
Malgré tout, ces outils ne vous offriront pas la même robustesse qu’une bonne vieille base de données relationnelle, et resteront plus difficiles à manier qu’une base orientée document (pour afficher le graphe, il faut le redocumentariser de toute façon, c’est-à-dire choisir les triplets qui décrivent une entité et les réunir dans un document JSON, XML ou autre). Cela vaut donc quand même le coup de se demander si l’exposition dans un SPARQL endpoint ne peut pas être un stockage secondaire : au passage, c’est le cas dans data.bnf.fr, qui est construit avec l’outil Cubicweb de Logilab dans lequel les données sont stockées sous la forme d’une base de données relationnelle, quand bien même on a un modèle logique en RDF (cf ci-dessus : dans ce cas précis, il y a une différence entre le modèle logique et le modèle physique). De la même manière, si on a des données stockées de façon primaire sous forme de graphe, disposer d’un stockage secondaire de type moteur de recherche peut aider à résoudre par exemple des problèmes de performance ou à simplifier l’accès aux données.

L’arbre de décision

Après toutes ces réflexions (pfiou !), nous voici prêts à parcourir l’arbre de décision qui résume tout cela :

Arbre de décision permettant de sélectionner un modèle logique et un système de gestion de base de données en fonction d'un modèle conceptuel.

Cet arbre de décision part du principe que vous avez déjà défini votre modèle conceptuel, que vous savez donc de combien de classes et de relations vous avez besoin, quels sont les attributs de vos entités et s’ils sont plutôt homogènes (toutes les instances d’une classe sont décrites de la même manière) ou pas.

La partie haute du schéma vous permet de déterminer quel est le meilleur modèle logique en fonction de votre modèle conceptuel.
La partie du milieu vous permet de déterminer quel est le meilleur type de système de gestion de base de données en fonction de vos usages.
Enfin, la partie du bas identifie les cas où l’on peut avoir besoin d’un stockage secondaire.

Il a fallu 134 diapos à Gautier pour expliquer tout cela. De mon côté, j’y passe une vingtaine d’heures en cours. Ici je vous propose une grosse tartine de texte assortie d’un outil de pensée visuelle : il va de soi que cela n’épuise pas le sujet, mais j’espère quand même que ce billet pourra rendre quelques services (que celles et ceux qui veulent qu’on écrive un manuel complet sur la data lèvent la main !)

Reblog : les technos du Web sémantique ont-elles tenu leurs promesses ?

Publié le par

Il y a quelques années, quand j’ai proposé à Gautier et Antoine de publier au Cercle de la librairie une synthèse de ce que nous avions appris en pratiquant avec ces technologies, mon objectif était de stabiliser nos connaissances dans un manuel, afin de les rendre réutilisables. C’est ainsi qu’est né Le web sémantique en bibliothèque, le livre, fin 2013. J’espérais aussi qu’on pourrait arrêter de se répéter en formation et que cela nous aiderait à passer à autre chose…

Je ne pensais pas si bien dire, puisque dès l’année suivante, j’écrivais « qu’il ne serait ni possible, ni utile de former tous les catalogueurs ou tous les bibliothécaires au Web sémantique« . Nous avons poursuivi cette réflexion au fil des conférences et formations, adaptant petit à petit notre discours à un nouveau constat : les technologies du Web sémantique ne répondraient pas à tous nos espoirs, et devaient trouver leur juste place dans le paysage de la donnée d’une manière plus générale. Un constat parfois amer, quand il s’agissait d’y renoncer dans le contexte de la production, parfois plein d’espoir quand les grands acteurs du web les intégraient dans leur stratégie d’interopérabilité.

Gautier revient aujourd’hui sur cette réflexion avec une somme en 4 articles, dont la lecture est indispensable pour qui veut comprendre l’évolution de notre pensée ces 5 dernières années s’agissant de cette technologie que nous avons longtemps mise en avant :

Le Web sémantique nous aide-t-il vraiment à améliorer la visibilité des ressources patrimoniales sur le Web ? Pourquoi le Linked Entreprise Data n’a-t-il pas révolutionné la conception des systèmes d’information ? Dans quels cas l’investissement dans un mapping vers RDF en vaut-il la peine ? Comment peut-on continuer à défendre les modèles orientés entités si on ne veut plus les implémenter en RDF ? Vous trouverez réponse à ces questions et bien plus sur Les Petites Cases.

Vous l’avez compris, je souscris largement aux conclusions qu’il présente et que nous partageons dans notre cadre professionnel, dans les formations que nous assurons ensemble ou chacun de notre côté, et dans notre salon ;-) Mais j’apporterais peut-être quand même pour ma part une nuance ou un complément d’information.

Dans son 2e billet, Gautier revient sur les limites d’OAI-PMH et dans sa conclusion, il remet en cause l’idée de décentralisation en arguant qu’elle est illusoire en l’état actuel de la technologie. L’OAI-PMH, malgré ses faiblesses, est un modèle qui fonctionne bien parce que justement, il procède par recentralisation des données qui ont été moissonnées. Or, la communauté patrimoniale à l’heure actuelle se focalise sur le développement d’un standard qui vise à réaliser la décentralisation des bibliothèques numériques en termes de contenus : IIIF. Dans une démarche caractéristique de la manière dont la communauté appréhendait le Web sémantique il y a 5 ans, IIIF utilise certains éléments de la technologie – les URI, le JSON-LD – sans se réclamer du Web sémantique ou du Linked Data. Pour Gautier, le choix de JSON-LD est anecdotique et relève d’un espoir qu’on avait à l’époque : que ce genre de détail ferait « cheval de Troie » pour installer la technologie. Pour moi, il témoigne d’une forme de maturité qui replace les briques de la techno à leur juste place dans un ensemble plus large. Néanmoins, le problème est toujours le même : pour exploiter les données, même avec IIIF, il faut rencentraliser les métadonnées. Et pour les recentraliser, il faut qu’elles soient homogènes ce qui exige soit de se mettre d’accord sur une syntaxe commune quelle qu’elle soit, soit de faire des conversions ou mappings…

En fin de compte, ce détail montre que la communauté patrimoniale est encore en train de réfléchir à son modèle d’agrégation des données. L’interopérabilité reste le principal (l’unique ?) cas d’usage du Web sémantique, et les portails ont encore de beaux jours devant eux. Nous garderons donc un œil attentif dans cette direction…

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.

Le Web sémantique en 10 mn, 40 mn, 2h et… 2 jours

Publié le par

Un petit interlude publicitaire… Pour ceux qui n’auraient pas le temps ou le courage de lire dans son intégralité l’ouvrage sur le web sémantique en bibliothèque que j’ai commis avec Gautier et Antoine, je tenais à rappeler ici l’existence de quelques alternatives :

Puisque je suis dans la pub, j’en profite pour signaler que la susdite série de vidéos du CNFPT contient d’autres choses intéressantes, et notamment une intervention sur les identifiants pérennes par Sébastien Peyrard. Un visionnage qui pourra utilement être complété par la lecture du vade-mecum sur les identifiants pérennes à l’attention des producteurs de données, réalisé dans le cadre de la feuille de route web 3.0 du ministère de la culture. Celui-ci propose un parcours en 12 questions, illustrées d’exemples, pour bien concevoir ses identifiants pérennes pour le web de données.

#EuropeanaElects : ma campagne sur Twitter

Publié le par

europeana-test

Europeana, je la connais depuis sa plus tendre enfance. En fait, elle n’était même pas encore née qu’on était dans une salle de réunion à Luxembourg, avec quelques collègues dont certains sont depuis devenus des amis, et on parlait d’interopérabilité comme on lance une balle à la passe-à-dix, priant pour qu’elle ne retombe jamais.

Puis il y a eu cette époque où on rêvait qu’Europeana ne soit pas encore un énième portail, où devant une bière sur une place ensoleillée de La Haye on griffonnait sur un bout de papier notre idée du réseau d’informations sémantiques, œuvres, personnes, événements… qui donnerait du sens à l’information culturelle diffusée sur le web. C’est comme ça qu’on s’est lancés dans la création du Europeana Data Model, EDM de son petit nom.

Puis il y a eu l’ère des projets, avec leur cortège de « proposal submissions », « work packages », « deliverables », « prototypes » etc. Ils sont bientôt devenus tellement nombreux que même les organiser et comprendre comment ils s’articulaient les uns avec les autres était devenu un défi. Pendant ce temps, le portail, lui, s’enrichissait de nouvelles fonctionnalités, s’ouvrait à des expositions virtuelles, agrégeait toujours plus de données provenant de toujours plus d’institutions dans toute l’Europe.

Où en est-on aujourd’hui ? Une nouvelle version du portail est en train de voir le jour. Même si on est encore loin de notre rêve initial, les progrès sont énormes. Et surtout, ce qui me paraît beaucoup plus important, le portail n’est que la partie émergée de l’iceberg.

Pour moi, la grande réussite d’Europeana, ce n’est pas d’avoir agrégé toutes ces données (même si je ne dis pas que c’était facile) mais d’avoir fourni une énorme impulsion dans la communauté culturelle en Europe pour permettre la numérisation du patrimoine. Des pays ou des institutions qui n’en auraient jamais fait un axe prioritaire se sont organisés pour obtenir des financements et lancer des projets. Ceux qui s’étaient déjà lancés ont apporté leurs collections mais aussi leur savoir-faire et leur expertise. Cet effort a été transverse (archives, bibliothèques, musées, audiovisuel) et a facilité l’émergence d’une préoccupation pour l’interopérabilité des collections même quand celles-ci sont constituées d’objets par définition uniques. Enfin Europeana a été un ardent promoteur de l’open data.EUfinal01-Cloud-V8-1024x768

La stratégie d’Europeana a évolué pour aller vers une infrastructure numérique partagée dont l’objectif est de servir aussi bien la communauté des professionnels des institutions européennes que celle des usagers. Les données ont été ouvertes en Linked Open Data, et leur redistribution via des dispositifs d’API pour encourager des réutilisations diverses et variées est considéré comme aussi importante, voire davantage, que le portail lui-même. L’ambition est également de partager des outils de traitements de données, d’enrichissement, de transformation et de préservation qui permettront aux institutions qui n’ont pas les moyens de les construire d’en bénéficier et d’enrichir leurs données et leurs services.

Enfin, Europeana est devenu un réseau, une communauté. Cette communauté partage son expertise professionnelle, technique et scientifique mais aussi sa motivation et son implication pour rendre accessible la culture européenne au plus grand nombre grâce au numérique. Construire et animer une communauté est une tâche ardue et parfois ingrate, mais c’est aussi ce qui permet aux idées de naître, de murir, de circuler et finalement de déboucher sur des projets et des réalisations qui peuvent transformer davantage que nos métiers et nos communautés. Transformer le monde par la culture, c’est l’ambition d’Europeana.

EUfinal07-Impact-V9Il ne faut pas oublier qu’Europeana est née d’une idée politique : elle a encore les moyens, grâce aux énergies qu’elle fédère, de peser en faveur des politiques culturelles des États de l’Europe et d’aider à mobiliser des moyens pour continuer à les développer. C’est parce que je crois sincèrement que sans Europeana, nous ne serions pas où nous en sommes aujourd’hui en matière de développement de l’accès numérique à la culture, qu’il était important pour moi de faire partie de l’association et de candidater pour devenir membre du conseil. On m’a invitée à faire campagne pour les élections qui se dérouleront en ligne du 3 au 9 novembre : c’est l’occasion pour moi de (re)poster sur Twitter quelques liens et idées sur Europeana. A suivre sur #EuropeanaElect.

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.

Faisons-le arriver !

Publié le par

Et voilà, après un an de travail et même plusieurs années de préparation, la journée satellite de l’IFLA sur le Web de données en bibliothèque est passée.

Nous avions intitulé cette journée « Let’s make it happen! » (titre que les collègues de la BnF ont fort heureusement traduit par « du projet à la pratique » et pas « faisons-le arriver » – la traduction est un art… ;-) parce que nous voulions que cette journée aborde le Web de données sous l’angle des mises en œuvre concrètes et non de la recherche ou de l’expérimentation.

Les participants ont bien joué le jeu, en choisissant de présenter leurs réalisations du point de vue de la gestion de projet (dans le cas de data.bnf.fr) ou du retour d’expérience (avec TEL, la NDL du Japon ou encore Electre).
J’ai trouvé très intéressante l’analyse proposée par Lukas Koster et Rurik Greenall, qui ont détaillé de façon plutôt abstraite les différents chemins qu’il est possible d’emprunter pour implémenter un projet de Web de données en bibliothèque, du do-it-yourself à l’utilisation de logiciels commerciaux en passant par l’open-source.
La question des autorités était omniprésente, de même que celle des vocabulaires qui ont été abordés sous différents angles (les créer, les maintenir, les utiliser) lors de la session de l’après-midi.

En parallèle de la conférence, nous avions également organisé deux ateliers, l’un destiné aux débutants et l’autre aux managers, afin de permettre des échanges plus interactifs.
Le tutoriel « débutants », animé par Ted Fons d’OCLC, a fait apparaître le fait que trois ingrédients sont indispensables pour faire du Web de données en bibliothèque : des personnes compétentes, des données et des outils. Si on n’a pas au moins deux des trois, mieux vaut s’abstenir !
Pour ma part j’animais avec Gildas Illien le tutoriel pour les managers. Nous avons essayé de donner quelques clefs pour susciter l’adhésion à un tel projet à l’intérieur d’une organisation, aussi bien auprès d’équipes opérationnelles comme les catalogueurs qu’auprès des décideurs. Les discussions ont été nourries et fort riches.

Enfin, j’avais invité plusieurs fournisseurs de logiciels et de services à clore la journée en partageant autour d’une table ronde ce que signifiait pour eux faire du Web de données en bibliothèque.
Pour Shlomo Sanders, d’Ex-Libris, la recette consiste à engager les développements internes de leurs logiciels dans la direction du Web sémantique, par exemple en utilisant systématiquement des URI. Pour Richard Wallis, d’OCLC, il s’agit de passer d’une logique orientée notice ou document à une logique qui s’appuie sur les « entités » (personnes, œuvres, concepts…). Enfin Nicolas Chauvat de Logilab a décrit ce que le Web pouvait apporter aux bibliothèques en termes de scalabilité et d’extensibilité.

Au final une journée réussie, si l’on en juge par les retours des participants. Les articles et résumés sont déjà en ligne, les présentations et captations vidéo des interventions devraient les rejoindre prochainement.
Un grand merci à tous ceux qui ont participé à l’organisation d’une façon ou d’une autre et à tous les participants qui étaient nombreux au rendez-vous.

Cette semaine nous poursuivons nos travaux à l’IFLA avec, en ce qui me concerne plus particulièrement, deux réunions du Semantic Web SIG :
– lundi à 15h, un « business meeting » c’est-à-dire une réunion de travail. Comme les réunions des standing committee, celle-ci est ouverte à toutes les personnes intéressées par l’avenir du groupe, ses activités… Nous évoquerons en particulier la nécessité de nommer un nouveau responsable de groupe, puisque je vais passer la main.
– Mardi à 16h c’est la « session ouverte » cette fois : au menu, discussions en petits groupes sur des sujets liés au Web de données et au Web sémantique, un peu comme l’année dernière.

J’espère que vous serez nombreux à venir parmi les 1000 français qui participent à ce congrès lyonnais !

IFLA satellite meeting : Linked Data in Libraries

Publié le par

Cet été, le 14 août, aura lieu à la BnF une conférence satellite de l’IFLA intitulée Linked Data in Libraries: Let’s make it happen! Elle est organisée par la section Information Technology de l’IFLA et le groupe d’intérêt spécialisé sur le web sémantique, le SWSIG dont je suis responsable.

L’appel à communication est encore ouvert pour une semaine. Les inscriptions sont aussi ouvertes, pour ceux qui sont assez mordus pour avoir envie de s’inscrire avant même de connaître le programme…

La conférence est organisée en deux sessions parallèles : une session de présentations, articles et tables rondes, et une session dédiée à des tutoriels ou ateliers.
En ce qui concerne la conférence elle-même, je ne peux pas en dire plus pour l’instant, nous attendons les (nombreuses, j’espère) soumissions d’articles.
L’idée des ateliers est de permettre à un public peu familier de ces notions (Web sémantique, Linked Data, RDF etc.) d’assister à cette conférence dans un esprit de découverte. Les ateliers sont conçus pour cibler des publics particuliers : un atelier stratégique pour les managers et décideurs, et pour les métadonneurs pratiquants, un atelier d’initiation et un atelier d’approfondissement. En toute logique, on vous invite donc à vous inscrire à un seul des trois ateliers, suivant votre profil.

Il n’est nullement obligatoire de participer au congrès de l’IFLA lui-même (qui a lieu la semaine suivante à Lyon) pour participer à cette conférence-ci donc n’hésitez pas à vous inscrire.
Dernière précision : la conférence, bien qu’ayant lieu à Paris, se déroulera intégralement en anglais, sans traduction simultanée.

Plus d’info sur le site de la conférence et le site du SWSIG.

Le Web sémantique en bibliothèque [texte imprimé]

Publié le par

Je trouve enfin le temps d’annoncer ici la sortie du livre Le Web sémantique en bibliothèque que j’ai rédigé avec la complicité d’Antoine Isaac et Gautier Poupeau. Oui, un livre en papier, je vais enfin avoir ma notice d’autorité dans le catalogue de la BnF !

Couverture

D’abord c’est une super excuse pour le ralentissement des publications sur ce blog : pensez, quand on est occupé à écrire un livre, c’est plus compliqué de garder le rythme du blog en parallèle. Au final, tout y est condensé en 171 pages, disponibles également au format numérique.

Vous y trouverez une synthèse de tout ce que nous racontons régulièrement dans les formations et les journées d’étude, augmentée de quatre cas pratiques, tirés de notre expérience personnelle, qui vous aideront à conduire votre propre projet de Web sémantique en bibliothèque (ou dans tout autre établissement culturel ou non d’ailleurs, l’intérêt de l’ouvrage n’étant pas limité aux bibliothèques mais pouvant toucher les professionnels de l’information en général).

Un petit mot enfin sur les coulisses de l’élaboration de cet ouvrage : l’idée m’en est venue lors d’un salon du livre en discutant avec Martine Poulain, qui dirige la collection Bibliothèques du Cercle de la librairie et que je remercie d’avoir cru en ce projet, même lorsqu’il m’a fallu plus d’un an pour trouver le temps d’en poser la première ligne.
J’ai rédigé une grande partie du texte qui constitue cet ouvrage à partir du matériau brut que constituaient nos notes, articles, présentations etc. à tous les trois. Les idées qu’il contient n’auraient jamais pu voir le jour sans les longues conversations que j’ai pu avoir avec mes deux co-auteurs, qui ont également relu le tout (plusieurs fois !) avec l’œil scrutateur qui assure une critique constructive.
Je remercie enfin mes différents interlocuteurs chez Electre pour avoir assuré dans un temps record une publication d’une grande qualité, malgré la technicité du contenu, et pour avoir veillé au moindre détail (jusqu’à la couleur figue de la couverture !)

Bonne lecture…