Le futur de la recherche documentaire : RAG time !

Aujourd’hui, je vous parle d’une application de l’intelligence artificielle et plus spécifiquement, des modèles de langues et de l’IA générative, qui est en train de prendre pas mal d’essor en ce moment : le RAG (Retrieval Augmented Generation). Vous n’en avez jamais entendu parler ? Restez branchés, car le RAG pourrait bien rentrer rapidement dans la boîte à outil courante du professionnel de l’information, juste à côté des catalogues, des ressources électroniques et des moteurs de recherche.

Un peu d’historique et de contexte (on ne se refait pas)

Voilà plusieurs années maintenant qu’on me demande régulièrement d’intervenir pour parler de ce que l’IA change ou va changer dans les bibliothèques. Après avoir étudié tous les use-case possibles et imaginables, j’ai développé un savant exercice d’équilibriste à base de « on va pouvoir continuer à faire ce qu’on fait, mais plus efficacement » ou encore « c’est surtout la masse de ce qu’on peut traiter qui change ». Depuis plusieurs années, j’avais vu débarquer les grands modèles de langue (LLM), en particulier BERT et ses petits amis (CamemBERT, FlauBERT etc.) mais globalement, leur utilisation se passait dans la soute, dans des profondeurs techniques difficiles à expliquer à des publics non-avertis. Cela faisait partie de ces outils « invisibles » qui améliorent les données et les services qu’elles rendent, mais sans faire de bruit.

En novembre 2022, quand ChatGPT a débarqué et a démontré sa capacité à masteriser le test de Turing, j’ai été assez rapidement convaincue qu’une fois le phénomène de mode passé, cet outil (et ses petits frères LLM) aurait surtout un impact quand il s’intègrerait discrètement dans nos applications du quotidien : nos gestionnaires de mail (pour répondre plus vite et envoyer encore plus de mails :-/), nos traitements de texte (pour trouver le bon mot à notre place) et… nos moteurs de recherche (dont il reformulerait à la fois les réponses et les questions, en langage naturel).

Le graal du « langage naturel » dans la recherche documentaire est en effet un idéal après lequel on court depuis bien des années. L’enjeu est de se débarrasser des mots-clefs, méthodes de requêtage et autres trucs de professionnels de l’information, pour pouvoir simplement demander les choses à son moteur de recherche préféré comme on le ferait à un humain, en lui posant des questions. La recherche plein texte à la Google ne répond qu’imparfaitement à ce cas d’usage : on peut en effet formuler des questions, il répondra bien quelque chose, mais le lien entre les deux n’est pas garanti.

Comme nous autres bibliothécaires, Google a commencé par tenter de s’appuyer sur les métadonnées pour pouvoir répondre de manière pertinente à au moins certaines questions, avec le « knowledge graph ». Ce qui donne par exemple ceci :

Encore plus récemment, on a vu apparaître autre chose dans la liste de résultats de Google. Dans la copie d’écran ci-dessous, prise à partir de la même question et toujours sur la 1e page de résultats, vous avez à droite le knowledge graph et à gauche, une liste de questions avec leurs réponses (que l’on peut dérouler en cliquant sur la flèche) :

Il suffit de regarder attentivement les questions et les réponses pour deviner que Google utilise ici les ingrédients de sa bonne vieille recette qui marche : analyser les questions que posent souvent les internautes, les réponses qui leur plaisent le plus, et chercher les chaînes de caractère textuelles qui correspondent. Rien de neuf : on sait depuis longtemps que pour améliorer son référencement, il faut formuler le titre de ses pages/billets/vidéos sous forme de question en essayant d’imaginer ce que les internautes se demandent (vraiment, j’avais capté ça en 2004, ce qui a fait de ce billet mon best-seller de tous les temps).

Ce qui change vraiment, c’est la place importante que Google réserve désormais à ce bloc question-réponse sur sa page de résultats, quelle que soit la requête (même si ce n’est pas une question). On peut donc s’aventurer à le prédire : dès qu’on aura réussi à empêcher les LLM de trop halluciner, les modalités de la recherche documentaire vont profondément changer, et laisseront beaucoup plus de place aux questions-réponses et aux échanges en langage naturel.

Je ne m’appesantirai pas ici sur les tests en cours dans ce domaine du côté des grands moteurs de recherche du web, qu’il s’agisse de Google ex-Bard désormais Gemini ou du Copilot de Bing basé sur ChatGPT. Ce qui m’intéresse aujourd’hui, c’est de vous parler de l’un des impacts de cette évolution sur la recherche documentaire en bibliothèque (ou archives), à travers le RAG.

Qu’est-ce que le RAG et à quoi peut-il servir ?

(Ce titre de niveau H2 est cadeau pour le référencement.)

RAG signifie donc Retrieval Augmented Generation ; en français, on parle de « génération augmentée de récupération ».

Un RAG permet à une intelligence artificielle générative conversationnelle (comme ChatGPT) d’interagir avec un corpus délimité. Celui-ci peut correspondre à un ensemble de documents, un fonds d’archives ou même à un seul document. On peut dès lors poser des questions visant à résumer tout ou partie du corpus ou du document, à vérifier la présence de tel ou tel concept et savoir comment il est traité, ou encore à répondre à des questions précises en se basant sur l’information présente dans le corpus. Bonus non négligeable, grâce au RAG, l’outil est en principe capable de citer ses sources c’est à dire de lister précisément les documents du corpus sur lesquels il s’est basé pour répondre, voire de fournir des extraits et des citations.

Imaginez par exemple que vous tombez sur un article de 50 pages potentiellement intéressant, mais vous n’avez pas le temps de le lire. Vous pourriez alors demander à un agent conversationnel, grâce à votre RAG, de vous le résumer paragraphe par paragraphe, d’en extraire les thématiques principales, de vérifier s’il contient l’idée que vous cherchez ou la réponse à votre question, d’aller droit aux résultats de la recherche qui y est présentée… C’est le cas d’usage qu’a imaginé JSTOR pour son outil AI research tool (beta) :

Les RAG semblent être apparus en 2020 dans l’environnement de Meta. Pour ma part, je les ai découverts (notamment à travers l’exemple de JSTOR) à la conférence AI4LAM de Vancouver en novembre dernier ; néanmoins je ne crois pas que le terme de RAG a été utilisé (ou alors il m’a échappé, on en sera quittes pour vérifier dans les captations vidéo qui devraient arriver bientôt). Sur le coup, j’ai trouvé l’idée intéressante mais un peu anecdotique, peut-être parce que la personne qui faisait l’une des démos avait utilisé ses propres archives et posait des questions sur son chien (les exemples, c’est important). Depuis, j’ai vu passer d’autres applications qui ont attiré mon attention et que je détaillerai un peu plus loin (ça c’est pour vous obliger à lire jusqu’au bout mon billet interminable, quel machiavélisme !)

Comment ça marche ?

Je ne vais pas rentrer dans des détails très techniques, ce qui m’intéresse est comme d’habitude de saisir suffisamment les principes généraux pour comprendre les atouts et les limites potentielles de l’outil.

Les grands modèles de langue comme Chat-GPT présentent la particularité de mélanger une fonction linguistique (construire des phrases correctes dans plusieurs langues) et des connaissances, qui s’appuient sur les données d’apprentissage qui leur sont fournies à savoir, globalement, de grands corpus de texte issus du web ou de bibliothèques numériques. Or, le mélange de ces deux fonctions produit le phénomène qu’on a appelé hallucination, c’est-à-dire que lorsque le modèle n’a pas la connaissance nécessaire, il produit quand même du langage et donc raconte n’importe quoi. Essayez par exemple de demander à Chat-GPT de vous générer la bibliographie d’une personne, il vous fournira des références crédibles mais totalement fantaisistes… Par exemple je n’ai rien écrit de tout cela (encore que l’idée d’une co-publication avec Nathalie Clot soit bien trouvée) :

On ne peut pas vraiment lui en vouloir : ChatGPT est un modèle de langue, son rôle est de générer du langage et pas de rechercher des informations.

Le principe du RAG est donc d’augmenter (A) la fonction générative (G) avec une fonction de recherche (R) dans un corpus externe. Pour effectuer cette spécialisation, il existe plusieurs méthodes possibles : entre l’article initial de P. Lewis et al. en 2020 et celui-ci qui, en 2023-24, analyse 100 publications à propos des RAG, le champ de la recherche s’est déjà complexifié de manière importante, notamment suite à l’irruption de ChatGPT en cours de route. Le schéma ci-dessous, emprunté au 2e article, représente la généalogie de l’évolution des RAG pendant cette période :

Technology tree of RAG research. Source : https://arxiv.org/abs/2312.10997

Je recommande également la lecture de cet article pour les personnes qui souhaiteraient des explications techniques claires et illustrées par des schémas sur le fonctionnement de ces différents types de RAG. Je vais essayer de résumer, mais comme le laisse supposer ce joli graphique, le RAG est un domaine de recherche complexe en plein expansion, qu’il serait difficile de saisir en seulement quelques phrases : je vais donc forcément simplifier de façon un peu caricacturale, pardonnez-moi.

Il y a en gros trois méthodes pour améliorer les résultats d’un LLM en maîtrisant davantage la source des connaissances qu’il utilise pour répondre :

  • le prompt-engineering, qui consiste à agir au niveau du prompt, en y injectant le contenu des références à utiliser pour fournir une réponse correcte et à jour,
  • le fine-tuning, qui consiste à réentraîner le modèle sur un corpus choisi pour lui apprendre à répondre de manière plus spécifique en fonction d’un domaine ou d’un corpus,
  • le RAG proprement dit, qui repose sur la séparation de la fonction langagière du LLM et de la base de connaissances qui la sous-tend.

En réalité, selon les types de RAG, on va combiner ces différentes méthodes pour optimiser les résultats obtenus. Par exemple, en injectant des sources de référence dans les prompts, on va permettre au LLM de tracer l’origine des connaissances qu’il utilise pour formuler sa réponse, voire lui donner des éléments pour fournir des réponses plus à jour (la base de connaissance de la version publique de ChatGPT, par exemple, s’arrête en 2021). Par contre, il existe des risques de brouillage entre les connaissances d’origine du modèle et le corpus choisi. Le fine-tuning nécessite de réentraîner le modèle, ce qui peut être assez lourd en terme de calcul et nécessite de disposer de grands corpus de vérité terrain adaptés. En revanche, le fait de séparer le langage des connaissances a l’avantage de permettre de travailler avec des modèles de langue plus légers – c’est ce que nous a expliqué Pierre-Carl Langlais à la dernière réunion du chapitre francophone d’AI4LAM que vous avez manquée malheureusement, mais que vous devriez pouvoir revoir en vidéo bientôt.

Des exemples ?

Si vous voulez en savoir plus sur le principe des RAG, lire des explications un peu plus techniques (mais quand même accessibles) et découvrir un outil que vous pouvez vous-même tester, allez voir du côté de WARC-GPT, un outil open-source développé par le Lab de l’Université de Harvard (présentationgithub). Son objectif est de permettre d’explorer des paquets d’archives web au format WARC. Vous allez me dire que si vous ne travaillez pas sur les archives du web, ce n’est pas très intéressant… et pourtant ! Si vous utilisez des ressources accessibles en ligne comme à peu près n’importe qui, il est globalement très facile de les empaqueter en WARC (par exemple avec Conifer ou Archiveweb.page).

Sinon, vous pouvez aussi tester Nicolay, un outil qui expérimente le RAG sur 15 discours d’Abraham Lincoln, représentant environ 300 pages de texte (présentationdémogithub).

Au niveau français, j’ai aperçu des expérimentations à droite ou à gauche, mais je n’ai rien de concluant à vous montrer pour l’instant. Pourtant, si on en croit les très nombreuses références commerciales que l’on peut trouver sur Internet, comme par exemple celle-ci (qui est par ailleurs plutôt bien faite pour qui recherche des explications en français), le RAG est aujourd’hui une technologie bien maîtrisée par l’industrie. Donc si vous avez des exemples sous la main, n’hésitez pas à me les signaler, je les ajouterai à ce billet.

Pour revenir au domaine de la recherche documentaire et des bibliothèques, il me semble que le RAG offre des opportunités d’exploration de grands corpus que je serais surprise de ne pas voir fleurir dans les mois ou années qui viennent. Par ailleurs, si ce genre de méthode doit révolutionner à terme la recherche documentaire et voir nos recherches par mots-clef disparaître au profit de prompts, comme la recherche par équation a disparu au profit de de la recherche plein texte… On a intérêt à comprendre comment elles fonctionnent et à apprendre à les maîtriser. Car le prompting, c’est comme la recherche documentaire : ça pourrait paraître simple à première vue, mais c’est une compétence de la litératie numérique qui ne s’invente pas.

Je vous propose de conclure ce billet en écoutant The entertainer’s Rag (Tony Parenti’s Ragpickers Trio, 1958) sur Gallica. RAG time !

Ce billet a été rédigé à 100% à base d’intelligence humaine.

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

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

Archiver le web pour les chercheurs : mode d’emploi

Depuis deux ans, grâce au projet ResPaDon, je travaille de manière un peu plus approfondie sur les usages des archives web pour la recherche, et ça tombe bien car mes nouvelles activités depuis octobre me conduisent en ce moment d’une part à me replonger dans ma thèse en vue de son édition, et d’autre part à enseigner sur le sujet.

Alors en attendant la journée d’étude professionnelle et le colloque « Le web, source et archive » qui vont conclure ce beau projet respectivement le 13 mars à la BnF et les 3-5 avril à Lilliad, voici en mode mise en bouche un petit mode d’emploi pour les chercheurs qui ont besoin d’archiver des contenus web.

Vous allez me dire, c’est quand même assez spécifique, il y a finalement assez peu de gens qui sont concernés. Mais en fait si. Cela peut arriver à tout le monde de tomber sur un lien mort, une erreur 404 (à commencer par moi-même quand je cherche des vieux trucs dans mon blog, vu que j’ai pété toutes mes URL).
Si on anticipe un tout petit peu ce problème, en tant que chercheur (au sens très large de « quelqu’un qui cherche », quel que soit le sujet, il arrive qu’on tombe sur des ressources en ligne dont on n’est pas sûr qu’elles seront encore là demain (par exemple le blog d’une personne irresponsable qui ne fait pas attention à la préservation de ses URL) voire dont on est sûr qu’elle n’y seront plus (par exemple une fiche de poste intéressante pour réfléchir aux compétences d’étudiants en master).
Dans ces cas-là, si on veut fonder une réflexion scientifique qui tient la route, pouvoir citer la ressource dans un article ou tout simplement en garder la trace, on a besoin de l’archiver.

Voici quelques méthodes qui peuvent être utilisées pour ce faire, de la plus simple à la plus complexe.

1. Zotero : vous utilisez déjà cet outil pour vos références bibliographiques, vous avez déjà installé une extension sur votre navigateur préféré pour sauvegarder en un clic une référence. Si vous le faites sur une page web lambda, le mode « snapshot » archive une copie de la page et vous pourrez la rejouer plus tard. [Edit] Cette méthode peut néanmoins finir par peser lourd sur votre disque dur ; heureusement il existe une extension Memento qui permet de récupérer dans Zotero un lien vers la Wayback Machine d’Internet Archive.

2. Le service Save Page Now d’Internet Archive : également doté de son extension, il vous permet non seulement de chercher une copie archivée d’une page si vous tombez sur une erreur 404, mais aussi d’archiver en 1 clic la page que vous consultez (et si besoin, tous ses liens sortants) dans la Wayback Machine. Cela évite d’encombrer votre disque dur, vous garantit de pouvoir la retrouver, peut être utile à d’autres gens et en plus, il y a plein d’autres fonctionnalités vraiment cool comme la cartographie de site…

3. Les outils de WebRecorder.io : derrière ce service, une communauté d’ingénieurs (dont Ilya Kremer) qui travaillait au départ sur l’idée de « browser-based archiving » c’est à dire d’archiver les sites en se basant sur la navigation d’un internaute. Plus besoin de cliquer sur les pages une à une, un outil comme archiveweb.page (toujours sous la forme d’une extension) vous permet d’enregistrer toute une session de navigation et de l’éditer après. Il y a aussi l’outillage nécessaire pour constituer une archive web avec Python pour les plus aventureux.

4. Hyphe : outil développé par le MediaLab de Sciences Po, il permet de constituer de véritables corpus web. Là, on entre quand même dans les outils plus spécifiques pour les chercheurs qui utilisent le web comme source de façon plus systématique.

5. Le BnF DataLab : si vraiment le web est votre sujet de recherche ou votre principale source, vous finirez sans doute par vous tourner vers des dispositifs plus institutionnels qui permettent d’entrer dans des partenariats avec les organismes en charge du dépôt légal de l’Internet : la BnF et l’Ina. Ceux-ci proposent des outils spécifiques pour naviguer dans les pétaoctets d’archives web amassées depuis plusieurs dizaines d’années, par exemple – sur certains corpus – la recherche plein texte, l’analyse de la tendance d’un terme ou des métadonnées et statistiques diverses.
Dans le DataLab, suite aux travaux conduits dans le projet ResPaDon, il est possible d’utiliser Hyphe pour explorer le web archivé par la BnF. Certains projets accueillis en partenariat peuvent aussi bénéficier de collectes « à la demande », pour lesquelles bibliothécaires et chercheurs vont s’associer pour constituer ensemble un corpus pérenne à des fins de recherche.

Il y en a donc pour tous les goûts, y compris pour les webmestres qui peuvent par exemple utiliser le service Arquivo404 pour proposer sur leur site un lien vers les archives web du Portugal quand la page est introuvable (pourquoi le Portugal me direz-vous, eh bien cette archive partage avec Internet Archive la caractéristique d’être en accès ouvert, là où la plupart des archives web institutionnelles, soumises aux conditions d’accès du dépôt légal, sont consultables uniquement sur place dans les établissements).

Si le sujet vous intéresse, on se retrouve le 13 mars à la BnF, ou à défaut sur Twitter et/ou Mastodon (oui c’est nouveau !) pour de nouvelles aventures avec les archives web.

What is a lab ?

Mes pérégrinations autour du projet Corpus continuent (pour ceux qui n’auraient pas suivi les épisodes précédents, ils se trouvent ici et ). Les 13 et 14 septembre derniers, j’ai ainsi participé à une rencontre à la British Library sur le thème : « Building Library Labs« . Organisé par l’équipe du British Library Labs, ce séminaire a réuni plusieurs dizaines de bibliothécaires et chercheurs pour des ateliers de réflexion sur ce qu’est un « Lab » en particulier dans les bibliothèques nationales, à quoi ça sert, comment on le fait tourner et ce qu’on y fait.

Je serais bien en peine de résumer en détail les discussions très riches qui ont eu lieu lors de cette journée, mais parce qu’un joli dessin vaut mieux qu’un rapport de 150 pages (ou pas, enfin je vous laisse juger…) j’ai tenter de sketchnoter ce qui me semblait le plus important à retenir.

Pour transcrire tout ça en quelques mots : j’ai trouvé qu’il ressortait de ces journées une forme de consensus à la fois autour de l’approche proposée, de ses objectifs et de la définition de ce que peut être un « Lab » dans une bibliothèque nationale. En gros, toutes ces institutions investissent depuis 10 ans ou plus dans la constitution de collections numériques massives, et souhaitent à présenter développer des usages nouveaux de ces collections, en s’appuyant sur les possibilités ouvertes par l’outil informatique (genre TDM mais pas seulement).

Les bibliothèques nationales sont un peu différentes des bibliothèques universitaires : elles ne bénéficient pas toujours d’un bassin de population cible attribué (chercheurs et étudiants), mais par contre elles ont ces masses de données, plus ou moins accessibles, plus ou moins bien documentées, qui ne demandent qu’à rencontrer des usagers. Du coup, le public cible des « labs » n’est pas seulement composé de chercheurs, mais aussi d’artistes, d’entreprises, de développeurs, d’archivistes… et surtout, surtout, des bibliothécaires eux-mêmes : les collègues sont les premiers bénéficiaires du Lab.

Les composantes essentielles des Labs sont les données, qu’on cherche à diffuser de la manière la plus efficace possible, en les documentant et les assortissant d’exemples concrets. Le fait de proposer un site web comme point d’accès à tout cela est une première étape, voire dans certains cas un but en soi. Certains ont un lieu physique, d’autres non, mais tous organisent des événements, de différentes natures, essentiels pour faire communauté.

Une autre caractéristique majeure des Labs réside dans leur dimension expérimentale. Différents dispositifs, qu’il s’agisse d’appels à projets, de hackathons ou autres, conduisent à la création, en coopération entre bibliothécaires et chercheurs, de réalisations qui ne sont pas forcément vouées à durer. On s’autorise l’échec et on multiplie les outils et les compétences diverses pour réussir ces expérimentations sans avoir la pression des longs projets exigeants dont on a davantage l’habitude dans nos institutions.

Plusieurs bibliothèques pilotes en la matière, notamment la British Library et la KB aux Pays-Bas, ont raconté le « voyage » qui les a conduits où ils sont aujourd’hui. On a voyagé sur les routes de Grande-Bretagne avec le premier « roadshow » de nos collègues anglais, ri avec le créateur du premier et très basique site web de la bibliothèque néerlandaise. Et ensuite, on a tenté de mettre en commun nos approches dans un Google Doc gargantuesque qui devrait être transformé en livre dans les mois à venir. Vous pourrez aussi retrouver les vidéos sur la chaîne Youtube du BL Labs prochainement.

Côté BnF, le rapport d’Eleonora Moiraghi sur les besoins des usagers du futur service d’exploration des données propose des pistes de réflexion convergentes avec ces approches. Le carnet de recherche de la BnF relate les différents ateliers organisés dans le cadre du projet Corpus. Et le site API et données propose déjà une vue d’ensemble des données disponibles et des moyens d’y accéder.

Plongée dans les humanités numériques à Berlin

Cette année, mes pérégrinations estivales ne m’ont pas conduite à l’IFLA en Pologne (coucou à ceux qui y sont !) mais « seulement » à l’une des conférences satellites, organisée par la section des Bibliothèques académiques et de recherche conjointement avec DARIAH et LIBER. Cette conférence, qui s’est donc tenue à Berlin du 15 au 17 août, avait pour thème Digital Humanities – Opportunities and Risks: Connecting Libraries and Research et j’étais invitée à présenter l’une des deux « keynotes », l’occasion pour moi de parler du projet Corpus qui est l’un de mes centres de préoccupations phares du moment.

iflaDH

La conférence a commencé par une intervention introductive de Toma Tasovac, directeur du Centre pour les Humanités Numériques de Belgrade à qui a été posée la difficile question : comment peut-on définir les humanités numériques ? Il répond : avec réticence. Les humanités numériques ne sont pas une discipline, mais une communauté de pratiques.

Les présentations de la journée suivante ont brillamment illustré la diversité des pratiques en question, de l’organisation d’un éditathon dans Wikipédia à la création d’une collection d’archives web en histoire de l’art, de l’exploration approfondie d’un poème d’Apollinaire à la création d’un site collaboratif documentant le patrimoine architectural brésilien. Dans ma propre présentation, j’ai donné plusieurs exemples de projets dans lesquels la BnF a été impliquée, qui posent pour la bibliothèque la question de la mise à disposition de corpus numériques massifs dans le contexte de la science numérique (digital scholarship – expression que je trouve plus inclusive que celle d’humanités numériques, car certains des projets sur lesquels nous travaillons ne viennent pas des humanités). Ruth Wallach est revenue sur cette question de savoir « qui en est, qui n’en est pas » en citant Stephen Ramsay : sommes-nous tous des « edupunks » qui faisons des humanités numériques à la mode artisanale, avec les moyens du bord ?

Cependant, en tant que satellite de l’IFLA, cette conférence ne s’intéressait pas aux DH en soi mais en tant qu’elles questionnent le rôle des bibliothèques. Dans sa présentation, Toma Tasovac a appelé de ses vœux des bibliothèques numériques qui offriraient un accès aux textes non pas comme des objets statiques, mais sous la forme de services et de workflow, permettant non seulement de les utiliser de façon flexible via des API mais aussi de reverser les enrichissements réalisés par les chercheurs.

Sur ce dernier point, il prenait l’exemple de l’OCR en rappelant qu’il « ne faut pas avoir honte d’un mauvais OCR » mais qu’il est par contre important de permettre aux chercheurs de le corriger.

Dans ce contexte, les bibliothèques numériques sont vues comme des infrastructures qui doivent permettre aussi bien la lecture rapprochée que distante (close reading, distant reading). Elles partagent avec les DH l’enjeu de l’interopérabilité et de la communication. Certaines données peuvent être d’accès restreint (Toma utilise l’excellent euphémisme shy data) mais il est important d’expliciter les conditions de leur usage par les chercheurs : c’est le but de la future « Charte de réutilisation des données culturelles » que DARIAH et Europeana sont en train d’élaborer. Si ce sujet vous intéresse, je vous engage à répondre au sondage en cours sur les principes de la charte.

S’est également posée la question de savoir quelle formation il serait nécessaire de donner aux bibliothécaires chargés de ces questions. Lotte Wilms, qui travaille au Lab de la KB (Pays-Bas), a présenté un programme de formation sur 5 jours, qui se tiendra à la rentrée, et dont les composants essentiels rappellent fortement ce qui pourrait être la formation de base d’un data librarian...

Si vous souhaitez en savoir plus, voire rejoindre la communauté des « DH librarians », sachez que deux groupes de travail sont en train de se monter, de façon complémentaire : un groupe « libraries » au sein de DARIAH piloté par Tamara Butigan et Sally Chambers, et un groupe « Digital Humanities » au sein de LIBER piloté par Lotte Wilms et Andreas Degkwitz (plus d’infos ici). A suivre donc, l’un des prochains épisodes étant le symposium auquel je participe à Francfort en octobre : New Directions for Libraries, Scholars, and Partnerships: an International Symposium et peut-être plus près de vous géographiquement, la journée d’études de l’ADEMEC à Paris le 14 octobre : Humanités numériques et données patrimoniales : publics, réseaux, pratiques. Venez nombreux, en plus c’est gratuit !

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…

Les catalogues sur le Web

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

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

Catalogues de bibliothèques et développements agiles

Dans le dernier numéro de Code4Lib Journal, deux informaticiens de la bibliothèque nationale de Suède publient un article intitulé « User-Centred Design and Agile Development: Rebuilding the Swedish National Union Catalogue ».

Il s’agit d’un retour d’expérience sur l’adoption d’une méthode de développement dite « agile » pour le catalogue collectif des bibliothèques suédoises, Libris.
Il s’agissait de reconstruire le système de A à Z, en un an seulement, y compris la partie moteur de recherche. Pour favoriser l’innovation, ils ont opté pour mener en parallèle une conception orientée utilisateurs, s’appuyant sur des études d’usages, et un développement itératif de type agile (SCRUM).
Côté étude d’usages, ils ont d’abord fait un questionnaire, puis des focus groups conduits sur la base de scénarios d’utilisation, et enfin des tests d’usabilité sur un prototype et une interface en version beta. Tout ça nous est assez familier, mais ce qui est nouveau, c’est d’adapter la méthode de développement de façon à ce que les retours des utilisateurs puissent être pris en compte dans la réalisation informatique au fil de l’eau.

Dans une méthode agile, l’objectif est de prendre en compte le fait que les conditions et les objectifs peuvent évoluer avec le temps, même pendant que se déroule le projet.
Cela implique de favoriser :
– les individus et leurs interactions plutôt que les processus et les outils
– les logiciels qui fonctionnent plutôt qu’une documentation extensive
– la collaboration avec le client plutôt la négociation contractuelle
– de répondre au changement plutôt que suivre un plan pré-établi.

Comme le dit très justement l’article, ces principes, pour séduisants qu’ils sont surtout vus depuis les utilisateurs du futur système, posent un certain nombre de problèmes. D’abord, ils sont plus inconfortables pour les décideurs, qui perdent en visibilité sur les charges et les dates ce que le projet gagne en souplesse. Il est donc important d’obtenir dès le départ le soutien des décideurs sur la méthodologie, et de bien leur expliquer que même s’ils ne peuvent pas voir les spécifications, le produit final sera bon. D’autre part, le code ainsi construit peut au final s’avérer instable, ce qu’ils ont résolu dans le projet cité en planifiant une session de 3 semaines dédiée à une évaluation fine de la qualité du code.
Tout cela est en grande partie une question de confiance et un des facteurs décisifs du projet a été la mise à disposition d’un espace commun pour les développeurs, où se tenaient également les réunions de travail avec l’équipe projet.

En conclusion, leur retour d’expérience est plutôt bon sur la méthode agile, qui semble avoir évité bien des écueils. Ce qui leur manque c’est plutôt la documentation et le transfert de compétences entre développeurs. Et ils auraient voulu impliquer encore davantage les utilisateurs dans le processus.
Je ne voudrais pas paraphraser la conclusion, qui est classe, donc la voici :

Finally, we would like to conclude that working with user-centred design in combination with iterative development is a better, faster and cheaper way of software development, compared to traditional models. Better – the product being released at the end is a more up-to-date and bug-free version than had we worked with a more traditional approach. Faster – it is our conviction that with traditional methodology we would not have finished on time, or at least not with the same amount of features implemented. Cheaper – if the same number of people are able to do a better job in a shorter amount of time, it is a more cost-effective way of getting the job done.

Il faut reconnaître que le résultat est pas mal du tout : même en suédois, on arrive à s’en servir ce qui prouve que niveau usabilité, c’est plutôt bien fait !!! Enfin pour expérimenter moi aussi la méthode agile en ce moment, je dois dire que cela me paraît effectivement très prometteur pour les projets innovants en bibliothèque.
Merci à Pintini pour la référence.

ISWC 2008 (5) – exploiter les données

Alors voilà : on a créé plein de beaux triples, des URIs, des ontologies, on a tout publié sur le Web of data… et qu’est-ce qu’on fait maintenant ? La conférence était assez riche en présentations d’outils ou de cas d’utilisation de toutes sortes qui montrent toute la puissance qu’apporte le Web sémantique en termes d’utilisation des données.
Je ferai ici une mention spéciale au Semantic Web challenge, un concours annuel qui a pour objectif de montrer des réalisations concrètes. Cette année, le challenge se divisait en deux branches : une branche « ouverte » (open track) dans laquelle on pouvait proposer n’importe quelle application, et une intitulée « billion triple challenge » dont l’objectif était de présenter des outils capables de manipuler une quantité importante de données.
Au moment de la « poster session », tous les participants au challenge ont fait des démos de leurs outils, et 5 outils ont été sélectionnés pour la finale dans chaque catégorie. Le lendemain, chacun des 5 élus a présenté dans le grand amphithéâtre son outil en une dizaine de minutes et cela a été une session pleine d’émerveillements. La plupart des exemples que je vais vous présenter dans ce billet en sont tirés (mais pas tous).
Par contre je ne parlerai pas de tout, alors ne m’en voulez pas ;-) vous pouvez retrouver tout cela sur le site du Challenge.

Il y a plusieurs façons d’exploiter les données du SemWeb. Je les ai classées en 4 catégories…

Les « triple store »
Un « triple store » est une base de données optimisée pour stocker des données en RDF. En général on utilise le langage de requête SPARQL, langage normalisé du Web sémantique, pour interroger ou extraire les données.
Dans cette catégorie, mention spéciale à Virtuoso qui n’a pas été dans les 5 élus du « billion triple challenge » mais s’est fait remarquer pour avoir réussi à indexer 11 milliards de triples en SPARQL avec des temps de réponse paraît-il très impressionnants. Pour la scalabilité, ils se posent là.
Pourquoi n’ont-ils pas été retenus pour le « billion triple » alors, me direz-vous ? Parce que le challenge consistait pas seulement à stocker les données, mais à les exploiter.

Les raisonneurs
Un des principaux intérêts d’avoir des données en RDF et des ontologies, c’est de pouvoir faire des inférences, c’est-à-dire déduire des informations exprimées les informations implicites (par ex., si A est cousin(e) de B et que la propriété « cousin(e) de » est symétrique, alors B est cousin(e) de A). Il existe donc des outils, raisonneurs ou moteurs d’inférences, dont le rôle est de parcourir les triples et de générer des inférences, ce qui crée de nouveaux triples qui peuvent être ajoutés au stock disponible pour être à leur tour exploités.
Deux outils de ce type ont été présentés : Marvin et SAOR.
MARVIN met l’accent sur la scalabilité et la possibilité de générer un maximum de triples tout en évitant de créer des doublons. La qualité des noeuds ajoutés n’est pas prise en compte, l’objectif étant plutôt de mettre à disposition des chercheurs une méthode permettant de tester différents algorithmes de raisonnement sur de larges ensembles de donnés. Il a gagné le 3e prix du challenge dans sa catégorie.
Le second, SOAR, ayant pour objectif de servir à alimenter un moteur de recherche (SWSE, voir ci-dessous) s’intéresse au contraire beaucoup aux questions de qualité de l’information générée (veiller à ce que les inférences aient du sens) et de temps de réponse.
Je ne rentre pas dans les détails, car très franchement, ça me dépasse… Mais il est bon de savoir que ces engins existent. Pour ceux qui seraient restés interloqués devant l’échange de commentaires de mon précédent billet, sachez que l’on peut également faire de petites inférences avec SPARQL. Il « suffit » de ranger l’ontologie dans le même triple store que les données, et de les requêter ensemble. Un jour, Got vous expliquera en détail comment marche SPARQL et comment on peut faire de petites inférences avec (pas vrai ?)

Les outils de recherche
Haha. Voilà qui est délicat, j’ai failli appeler ça les « moteurs de recherche sémantique » mais ça ne va pas du tout. Ca, ça ou encore ça, ce sont des choses qu’on a tendance à appeler des moteurs de recherche sémantique mais ils n’ont RIEN à voir avec le Web sémantique donc sachez-le : ce n’est pas du tout de ce genre de choses que je parle.
Les outils dont je parle ici sont des moteurs de recherche dont la vocation est spécifiquement d’exploiter des données en RDF et en particulier les données présentes dans le Linked Data.
Sindice est un moteur de recherche qui permet d’exploiter des données publiées en RDF, qu’elles se trouvent dans des triple stores, dans des fichiers RDF, ou dans des pages HTML sous forme de métadonnées (microformats ou RDFa – pour en savoir plus sur RDFa, cliquez ici). Sindice surveille, collecte et indexe ces données (apparemment il opère aussi des fonctions de raisonnement mais je ne sais pas lesquelles). Ensuite, il met à disposition tout cela sous forme d’API pour qu’on puisse l’utiliser dans une autre application. Sindice est une des briques essentielles du Web of data car il va permettre de trouver les triples que l’on veut mettre dans les interfaces d’accès (voir ci-dessous).
Après, il existe d’autres moteurs de recherche qui exploitent les données en RDF mais je ne les ai pas tous vus en détail, et ils ont été écartés du « billion triple challenge » pour la même raison que Virtuoso. J’ai par exemple pas mal entendu parler de SWSE (paper), un moteur orienté objet qui fournit un point d’accès en SPARQL (ce que ne fait pas Sindice).

Les interfaces de navigation
C’est dans cette catégorie que je vais ranger les deux gagnants du Semantic Web Challenge.
Dans la catégorie « billion triple », c’est SemaPlorer qui l’emporte. Il s’agit d’une interface d’exploration de données en RDF qui démarre avec de la géolocalisation et continue avec de la navigation à facettes. Vous pouvez regarder la démo sous forme de vidéo sur le site : c’est assez séduisant en termes de fonctionnalités. Enfin évidemment, ce qui a surtout pesé dans le résultat c’était l’architecture sous-jacente, avec du cloud computing d’Amazon (EC2), et 25 triple stores distincts qui sont fédérés par un point d’accès SPARQL, NetworkedGraphs. Le résultat est donc assez bluffant mais plutôt moche.
On ne peut pas en dire autant du gagnant de l’open track : Paggr. Imaginez un genre de Netvibes, mais dans lequel toutes les données seraient converties en RDF pour pouvoir être reliées et exploitées en déchaînant toute la puissance du Web sémantique. Bah, je vois bien que vous n’arrivez pas à imaginer ;-) alors regardez la vidéo, et je vous raconte juste le truc qui m’a le plus bluffée : quand il a glissé le nom d’un de ses contacts sur le widget Google maps, et qu’en analysant je ne sais quelles données ça lui a localisé la personne…
Un petit dernier pour la route : Freebase Parallax, une interface à facettes pour naviguer dans les données de Freebase. Elle est vraiment pas mal celle-là.

Inclassables et inoubliables
Je ne peux pas arrêter ce billet déjà beaucoup trop long sans évoquer les deux projets qui sont peut-être les plus riches d’enseignements pour notre communauté.
Le premier a reçu le 3e prix dans l’open track, il s’agit de Health Finland. Il s’agit d’une sorte de portail qui donne accès à une masse hétérogène d’informations médicales en Finlande. Son objectif est de faire se rencontrer les requêtes des citoyens internautes avec des données très structurées et modélisées dans des vocabulaires professionnels parfois hermétiques. Pour cela, il ont modélisé les différents vocabulaires professionnels en SKOS et les ont alignés avec une ontologie de haut niveau qui, elle, utilise un vocabulaire « grand public ». C’est vraiment une approche très convaincante.
ClioPatria n’a pas été présenté dans le Challenge mais on nous en a parlé dans les lightening talks (voir mon twitter) ainsi que dans la présentation du projet e-culture dont j’avais parlé dans ce billet. J’adore toujours autant le projet, et je ne suis pas la seule car il a été assez remarqué dans les « best papers awards ». Donc, il utilise ClioPatria, une plateforme de navigation dans des données en RDF qui utilise le concept de facettes mais aussi les requêtes SPARQL et un système de clustering assez séduisant. On a également appris qu’il allait être utilisé par Europeana.

J’aimerais bien continuer à vous raconter mais ce billet m’a épuisée… Je pense que je vais laisser de côté les outils pour passer à autre chose. De toutes façons, il sera toujours temps d’y revenir plus tard dans un billet plus détaillé sur l’un ou l’autre.

A l’Est, du nouveau

La dernière lettre de la section Information Technology de l’IFLA contient deux articles intéressants.

Le premier relate l’expérience de la bibliothèque universitaire de Vilnius pour mettre en place des services 2.0. Ce que je trouve intéressant dans cet article c’est qu’il ne présente pas le versant technologique de la chose (dont on a soupé, franchement : des articles qui expliquent encore ce que sont les blogs et les wikis !). Il se positionne du point de vue de ce qui pose vraiment problème dans la mise en place d’un projet de bibliothèque 2.0 : la mobilisation des agents et l’accompagnement au changement. Ainsi, avant de mettre en place des services 2.0 dans la bibliothèque, ils ont sondé les personnels (et l’encadrement en particulier) sur leur niveau de compétences technologiques puis ont organisé un plan de formation approprié.
L’initiative a débouché sur un blog interne, un blog des guides touristiques de la bibliothèque, un compte delicious, et un wiki pour le personnel qui permet d’avoir toutes les informations sur le plan de formation en question.

Le second décrit l’initiative PIONER qui a permis à des bibliothèques numériques polonaises de créer une Fédération qui bénéficie de son portail. Un framework en open source, dLibra, a été développé pour être mis à disposition des bibliothèques locales pour mettre en ligne leurs fonds. Ensuite l’ensemble est fédéré via OAI-PMH.

Pour le contexte : la section IT de l’IFLA est là où se discutent les enjeux des évolutions technologiques pour les bibliothèques. On y parle beaucoup de « library 2.0 » en ce moment forcément, mais pas seulement : cet été à Montréal elle co-organisait avec la section Préservation et l’ICABS (qui s’occupe de normes bibliographiques) une conférence sur la préservation numérique pour laquelle avec plusieurs collègues nous avions écrit cet article (traduction française). L’été prochain, il y aura une pré-conférence satellite à Florence sur le thème « Emerging trends in technology: libraries between Web 2.0, semantic web and search technology »… et j’espère bien y aller !