IIPC GA 2015, jour 2 : WARC, WAT, WET et WANE

Si vous venez à la BnF consulter les archives du Web ou que vous utilisez en ligne la Wayback Machine d’Internet Archive, vous pourrez parcourir le Web du passé en le « rejouant » sous la forme de pages qui ressemblent, parfois beaucoup, parfois vaguement à ce qu’elles étaient à l’époque où elles faisaient partie du « Web vivant » comme on l’appelle ici. Vous pouvez, par exemple, regarder à quoi ressemblait le Figoblog en 2005 : sympa pour les nostalgiques ! Cependant, il arrive parfois qu’il manque des bouts (par exemple à cette période la feuille de style CSS n’a manifestement pas été récupérée) ou que le site n’ait simplement pas été aspiré (ou « crawlé » pour employer le terme consacré) à une date précise. Par ailleurs, l’accès aux archives Web mobilise de plus en plus des usages qui n’impliquent pas d’accéder aux pages elles-mêmes en les rejouant, mais aux données qu’elles contiennent, voire aux données contextuelles que sont les informations de formats, de dates, de modalité de collecte, etc.

Le 2e jour de la conférence ouverte d’IIPC, consacré à des ateliers, est entré davantage dans la technique quant aux modalités d’exploitation de ces archives. Il a été notamment question de formats et de protocoles qui permettent différentes modalités d’accès.

La journée s’est ouverte sur une présentation par Herbert Van de Sompel du projet Memento. Memento fournit un protocole pour accéder à distance à différentes archives Web et donc retrouver, à partir d’une URL et d’une date, la version la plus pertinente dans différentes archives disponibles. On crée ainsi de l’interopérabilité entre archives Web, avec pour perspective d’étendre à l’avenir le projet aux « dark archives », c’est à dire les archives qui ne sont  pas librement accessibles en ligne mais dont les métadonnées pourraient être signalées.

Ce principe est illustré dans le service Time travel qui s’est également doté récemment d’un mécanisme de reconstruction permettant de récupérer dans différentes archives les « bouts » qui constituent une même page Web afin de la reconstituer au plus proche. Par exemple, si une archive a préservé le contenu d’une page et une autre sa CSS, on arrivera à afficher la page correctement mise en forme.

Memento a aussi développé Robustlinks, un outil permettant notamment aux auteurs d’articles d’associer leurs publications à une archive et à des métadonnées en Schema.org de façon à assurer qu’elles restent accessibles à travers le temps. Le projet Hiberlink étudie l’impact de tels mécanismes sur les publications scientifiques.

Je ne passerai pas en revue une à une les autres interventions de cette journée, je vais plutôt les synthétiser en évoquant les différents formats qui permettent d’archiver le Web et d’exploiter ces archives de différentes manières.

Le premier de ces formats, c’est WARC : un conteneur qui permet de stocker les fichiers archivés avec un certain nombre de métadonnées, dont les informations liées à la collecte (date, etc.). Ce format normalisé à l’ISO va être révisé cette année.  Le problème avec WARC, c’est que c’est un format assez lourd à stocker et manipuler. Un certain nombre de développements ont été imaginés pour l’alléger, notamment un mécanisme de dédoublonnage qui évite de stocker plusieurs fois le même fichier s’il n’a pas changé depuis le dernier crawl.

On a besoin des WARC si on veut accéder au contenu. Mais si on s’intéresse aux données (ou aux métadonnées) on peut faire appel à des formats plus légers qui ont été développés à cette fin.

Les WAT contiennent les métadonnées de chaque fichier, les informations concernant la collecte et d’autres éléments comme la liste des liens présents dans les pages HTML. Ces informations sont stockées en JSON ce qui permet de les exploiter facilement pour faire toutes sortes de statistiques. On a en général 1 fichier WAT pour 1 fichier WARC et chaque fichier WAT représente environ 15 à 20% de la taille du WARC auquel il correspond. Il existe également une variante nommée WET qui contient tous les éléments textuels d’un WARC.

Les LGA (Longitudinal Graph Analysis) contiennent la cartographie complète des liens à l’intérieur d’une archive Web. Ils permettent de générer des visualisations de données. Le fichier LGA ne représente qu’1% du poids de toute la collection de WARC qu’il cartographie.

Enfin une mention spéciale pour les WANE : il s’agit de stocker les entités nommées contenues dans les pages web, sur le même principe que les WAT (1 fichier WANE pour 1 fichier WARC). Le fichier WANE représente moins d’1% de son WARC.

Si vous lisez ce billet et que vous ne savez pas ce que sont les entités nommées, je vous conseille de vous arrêter un instant et de plonger dans cette notion. Il devient en effet de plus en plus fréquent d’entendre parler d’entités nommées au détour de réunions où de conférences, y compris en présence d’acteurs pas du tout techniques, ce qui laisse à penser que cette notion est aujourd’hui considérée comme acquise pour des bibliothécaires. Pourtant, lors de mon dernier cours donné à des documentalistes en master 2, j’ai pu constater que la plupart d’entre eux ne savaient pas ce que c’était, voire n’en avaient jamais entendu parler.

Ce terme désigne dans un texte les entités qu’on est capable d’identifier, de qualifier en vue de les relier à d’autres informations : des personnes, des lieux, des organisations, des dates ou périodes, des événements, des concepts, etc. Si on reprend les archives du Web, imaginons qu’on a collecté la page d’accueil du site du Monde le 4 novembre 2008, on pourra sans doute identifier la personne « Barack Obama » et le lieu « États-Unis ».

La plupart des initiatives visant à reconnaître les entités nommées qui ont été présentées dans les différentes conférences de l’assemblée IIPC s’appuyaient sur le logiciel de reconnaissance d’entités nommées de Stanford: Stanford NER. Le principe de ce type de logiciel de reconnaissance d’entités nommées est de définir des règles qui permettent, pour une langue donnée, de les reconnaître (par exemple, si une séquence commence par « Monsieur » on peut supposer que ce qui suit est un nom de personne). Ces règles sont affinées ou enrichies par des mécanismes d’apprentissage (machine learning) : on « apprend » à la machine à reconnaître les entités nommées en le faisant manuellement sur un corpus de référence et ensuite, elle se débrouillera toute seule sur des documents similaires.

Lors d’une présentation qui a eu lieu un peu plus tard (jour 4, désolée d’anticiper) mes collègues de la BnF ont présentées les recherches actuellement réalisées par une ingénieure du labex « les passés dans le présent », qui utilise les WAT pour analyser les relations entre les sites Internet qui traitent de la Grande Guerre.

L’intervention de l’historien canadien Ian Milligan fourmillait d’autres exemples d’application de ces différentes techniques pour le champ de la recherche en histoire depuis les années 1990. Pour Ian, il est impossible de faire de l’histoire récente sans utiliser les archives du Web : on passerait à côté de son sujet en évacuant cette source primordiale. Il va jusqu’à proclamer que les archives du Web vont profondément transformer le travail des historiens et l’histoire sociale.

Seul problème : les compétences. En effet, peu nombreux sont les historiens capables de manipuler ce genre d’outils. Si toutefois vous voulez vous lancer, le tutoriel est par ici ;-)

IIPC GA 2015, jour 1 : « context matters »

La dernière fois que j’ai assisté à une rencontre d’IIPC, le consortium pour l’archivage de l’Internet, c’était en 2009 à San Francisco. Par une sorte de coup du sort, je me retrouve aujourd’hui de nouveau en Californie, cette fois à Stanford, pour assister à l’assemblée générale 2015 du consortium qui a bien grandi (pour suivre l’événement sur Twitter, c’est #iipcga15).

Coit Tower depuis Russian Hill, sur Filbert str.

C’est assez amusant de voir que certaines des choses que j’écrivais à l’époque sont toujours – et plus que jamais – d’actualité, même si le sujet de l’archivage du Web semble avoir subi entre temps une petite révolution copernicienne puisque, lors de cette journée d’ouverture, on a moins parlé d’archivage que d’usage. En fait j’en ai retenu principalement deux choses :

  • d’une part, que « le contexte c’est important » (pour citer Paul Wagner, actuel président du steering committee d’IIPC) – vous me direz, pour des archives, c’est quasiment un truisme ;
  • d’autre part, que si on n’arrive pas à les rendre utilisables, cela ne sert pas à grand chose de les conserver.

Dès la conférence d’ouverture, pour laquelle nous avions l’honneur d’accueillir Vinton Cerf (vous savez, celui qui n’a pas inventé le Web) en compagnie de Mahadev Satyanarayanan (alias Satya, de Carnegie Mellon University), la question posée était celle de la facilité d’accès ou même de l’expérience utilisateur dans le domaine de l’archivage de l’Internet. En effet, après que V. Cerf ait introduit l’enjeu de la préservation des contenus dynamiques et en particulier exécutables (genre des logiciels ou des data contenues dans des logiciels), Satya a présenté le projet Olive qui vise à rendre l’expérience d’une machine virtuelle aussi fluide qu’un streaming sur Youtube.

Toute personne qui a un jour essayé de lancer une machine virtuelle (par exemple, pour faire tourner un OS Windows sous Linux et ainsi essayer de sauver un vieux powerpoint dont vous voulez absolument récupérer les 52 diapos animées sans avoir besoin de les retaper…) ne peut qu’être saisie d’émerveillement devant la mécanique présentée par Satya, qui permet, en quelques secondes, de faire revivre successivement une vieille version de Windows, le jeu Oregon Trail pour Mac (1990) ou encore d’accéder au Web d’aujourd’hui avec un navigateur Mosaïc 1.0.

Cependant, si on veut utiliser ce genre de méthode pour préserver des sites Web ou même des contenus exécutables, quels qu’ils soient, tels qu’on les connaît aujourd’hui, la question du contexte se pose rapidement : quelle quantité de Web va-t-il falloir « aspirer » pour disposer de tout le contenu nécessaire pour rendre ces objets utilisables de manière similaire à ce qu’ils étaient à l’origine ? Et je ne vous parle même pas de la question de l’Internet des objets, certains objets connectés étant difficiles, voire impossibles à émuler sur une machine virtuelle en raison de leur matérialité.

La question des usages de ces archives de l’Internet et en particulier, des outils nécessaires pour les utiliser est restée centrale pendant toute la journée.

Les exemples danois et anglais ont permis de voir comment les archives du Web peuvent être utilisées pour analyser le domaine Web national d’un pays : taille, format, contenus, etc.

La première session de l’après-midi posait la question de l’archivage de données très personnelles telles que les profils Facebook ou les photos et vidéos de famille, mais du point de vue des individus eux-mêmes. On a ainsi appris que beaucoup de gens ne se soucient guère de voir leur mur Facebook préservé, voire s’y opposent carrément parce qu’ils le font constamment évoluer, de façon à ce qu’il reflète leur perception de leur identité à un instant T. Et pour les plus jeunes, il semblerait qu’ils soient persuadés que de toute façon, tous ces contenus publiés sont conservés automatiquement par quelqu’un quelque part…

D’une façon générale, la préservation des archives familiales semble avoir été profondément bouleversée, voire parfois remise en cause, par l’irruption du numérique parce que dans une famille, celui qui a le rôle de l’archiviste n’est pas forcément celui qui maîtrise l’informatique domestique (c’est là que je me suis félicitée d’avoir à la maison un geek qui s’est pas mal intéressé à la préservation numérique :-D). C’est que créer des contenus est perçu comme plus gratifiant que de passer du temps à les gérer et les organiser…une vérité qui ne me semble pas non plus totalement étrangère à la problématique de la gestion des collections numériques dans les bibliothèques.

Enfin la journée s’est terminée avec la présentation du projet BUDDAH : Big UK Domain Data for the Arts and Humanities, autour des archives Web de la British Library. Ce projet vise à promouvoir l’usage des archives du Web comme matériau pour la recherche, à travers diverses initiatives comme ces vidéos de présentation. Le projet a aussi débouché sur un prototype permettant une recherche à facettes dans l’ensemble des 160 téraoctets d’archives de la British Library : Shine. Shine propose aussi un outil de recherche de tendances, qui permet de comparer l’évolution des occurrences d’un mots dans les archives du Web sous la forme d’un graphique.

C’est là que revient la question du contexte, avec plus d’acuité que jamais. L’un des enjeux majeurs pour que les chercheurs puissent aujourd’hui exploiter de façon satisfaisante les archives du Web est la construction de corpus documentés. On a en effet besoin de savoir comment l’archive a été constituée, voire de la manipuler et de définir des sous-ensembles avant de commencer à en analyser le contenu, faute de quoi on risque de se retrouver avec des résultats biaisés. Ces projets démontrent aussi la pertinence d’une approche de type « big data » : beaucoup des résultats qui nous ont été présentés exploitaient les archives Web sans jamais aller jusqu’à la consultation des pages, en fouillant simplement les données, les métadonnées associées aux objets et aux collectes. Cela implique bien sûr des compétences tout à fait spécifiques pour ces historiens du Web, telles que l’exploitation de données quantitatives et leur visualisation graphique.

Pour conclure, la communauté IIPC semble aujourd’hui préoccupée de rendre les collections qu’elle a pu créer depuis plusieurs années immédiatement utilisables par des chercheurs d’aujourd’hui, qu’il s’agisse d’inventer des outils ou de documenter le contexte de ces archives. Cet enjeu apparaît quasiment comme une question de survie : il y a urgence à démontrer l’intérêt et l’utilité de ces collections. Les web-archivistes sont extrêmement attachés à démontrer l’importance de leur travail, qui pourtant ne fait pas de doute quand on voit qu’en deux ans, 60% des contenus Web du domaine .uk ont disparu, été déplacés ou modifiés :

De façon assez ironique, l’un des meilleurs moyens de légitimer l’usage des archives du Web aujourd’hui semble être d’inviter des chercheurs à écrire un livre sur le sujet. Numérique, bien sûr, et accessible… sur le Web !

Big data et bibliothèques

Le big data (« mégadonnées » pour ceux qui veulent parler français) ce n’est pas tout neuf, cela fait quelques années qu’on en parle ; d’ailleurs, le Gartner hype cycle le place en 2014 sur la pente descendante qui va plonger dans le ravin de la désillusion. J’en déduis que c’est le bon moment pour les bibliothèques de commencer à s’y intéresser sérieusement  – mais non, pas parce que les bibliothèques ne s’intéressent qu’à ce qui est dépassé, mais parce qu’on commence à voir au-delà du « buzz » pour se diriger vers le plateau de la stabilité.

En tout cas, c’est le moment que j’ai choisi pour ma part pour lancer une veille sur le sujet. D’avance je sollicite l’indulgence des éventuels lecteurs du Figoblog, ce travail étant rétrospectif et réalisé dans un temps limité. Si vous avez des critiques ou des références intéressantes que j’aurais loupées, n’hésitez pas à les mentionner en commentaire.

D’abord quelques éléments de définition (vous pouvez aussi lire Wikipédia) : le big data se caractérise par la règle des 3 V : volume, vélocité, variété. On parle de masses énormes de données (de l’ordre du téra ou du péta octet, voire plus) produites dans une temporalité de l’ordre de la seconde et qui peuvent être de toute sorte : structurées ou non, du texte, de l’image, du mail, n’importe quoi. L’exemple emblématique c’est Twitter qui génère 7 téra-octets de données par jour (toujours selon Wikipédia).

A cause de ces 3 V, les données en questions ne sont pas manipulables avec des outils classiques comme les bases de données relationnelles. Et ce d’autant que l’enjeu est de les exploiter en temps réel (l’exemple typique étant l’analyse des données de la bourse par les traders, où tout peut se jouer dans une nanoseconde). Des outils spécifiques ont donc été créés pour permettre de les stocker et de paralléliser les requêtes, le plus connu étant sans doute le framework Hadoop.

Pour savoir en quoi cela peut nous intéresser, nous bibliothécaires, je vous invite à lire par exemple cette introduction de base au big data sur le site de l’ALA (2013) ou à feuilleter ce diaporama de la Library of Congress (2012). Si vous avez un peu plus de temps, un cours en ligne (environ 1h, 2013) est disponible sur le site Digitization 101 (sur lequel je n’avais pas mis les pieds depuis une éternité, ça fait plaisir de retrouver Jill en vidéo !) Vous allez me dire que je ne vous propose que des vieux trucs en anglais… alors vous pouvez tenter les vidéos du colloque « Quelles stratégies de recherche face à la nouvelle massification des données » organisé par l’ADBU en décembre 2014. Cependant, on y trouve plutôt un panorama des enjeux stratégiques que des explications ou solutions techniques.

Pour synthétiser, j’identifie aujourd’hui trois pistes de réflexion pour les bibliothèques.

La première réside dans le fait que les « data » sont de plus en plus un objet que les bibliothèques de recherche en particulier vont être amenées à collecter et conserver, en tant que produit du travail des chercheurs, au même titre qu’on le faisait auparavant pour leur production documentaire imprimée puis numérique (articles, thèses, etc.). Or ces données ont des caractéristiques différentes des documents : elles se présentent sous la forme de flux et non de stock (« data is a lifecycle » ) et nécessitent des outils d’analyse pour pouvoir être utilisées.
Un exemple d’application de ces réflexions à la bibliothèque de l’Université de San Diego est détaillé dans cette vidéo de 30 mn (déc. 2013) :

Deuxième piste de réflexion : l’utilisation du big data pour analyser les statistiques de consultation des bibliothèques en vue de fournir de nouveaux services aux usagers ou aux bibliothécaires. C’est ce que fait le réseau des bibliothèques de Singapour : un réseau de bibliothèques publiques qui a développé l’utilisation du big data pour analyser les statistiques des prêts en lien avec les données bibliographiques, et ainsi proposer à ses usagers des recommandations.
Cette technologie est aussi utilisée pour gérer la politique d’acquisition en prenant en compte des données telles que le profil sociologique des lecteurs qui fréquentent chaque bibliothèque du réseau, les contraintes de place et le taux de rotation des collections.
L’article présente des développements intéressants sur la méthodologie de mise en place « des » projets big data : en effet, chaque application big data pour un usage particulier est perçue comme un projet à part entière, avec son équipe propre qui travaille sur le profilage des données à utiliser.

Enfin, la troisième piste c’est l’évolution des usages des chercheurs. Je suis tombée un peu par hasard sur ce compte-rendu d’une journée d’étude tenue par des sociologues à la British Library (2013) qui me semble bien illustrer le problème. Dans certaines disciplines, notamment en sciences humaines, l’enjeu de l’exploitation des collections par les chercheurs est en train de se déplacer : ils ne veulent plus « lire » le contenu des documents mais exploiter de façon globale la collection et son organisation par les bibliothécaires, qui devient signifiante en tant que telle. Savoir combien de documents concernant tel ou tel sujet ont été publiés entre telle ou telle date, combien d’occurrences du nom d’une personne, d’un lieu ou d’un concept apparaissent dans un corpus donné deviennent des clefs de recherche aussi intéressantes que ce qu’on pourrait apprendre en dépouillant dans le détail ces documents ou ces corpus.
Dès lors, la question va être de savoir si les bibliothèques seront capables d’offrir aux chercheurs un service de big data sur les collections qu’elles conservent : leur permettre de définir leur propre corpus, leurs critères et d’appliquer des outils d’analyse pour extraire de nouvelles informations à partir des données.

Ayant eu récemment le plaisir de rouvrir le dossier Archives de l’Internet, j’ai enfin réussi à entrevoir l’étape qui prendra la suite de la vision que j’avais eue en 2009 lors de la journée IIPC. Il me manquait alors l’idée que les outils qui permettraient d’étudier cette collection ne se limiteraient pas à la restituer telle quelle ou à l’indexer en plein texte, mais nécessiteraient de la triturer sous tous les angles en extrayant, autant que possible, les data. Si dans les archives du Web il y a de la donnée structurée (par exemple celle qui serait issue du Web de données…) cela pourrait bien être un atout de premier plan. Je pense que j’aurai l’occasion de creuser cette idée dans les mois à venir.

Je vais conclure cette réflexion avec cet article récent sur le big data en France (via GFII) qui s’inquiète de ne pas le voir décoller. On pourra aussi utilement feuilleter la feuille de route big data du ministère de l’Économie pour achever de se convaincre que les bibliothèques françaises ont encore quelques années lumières à parcourir avant d’apparaître dans le paysage. Mais ce seront des années intéressantes.

Un dernier lien à ne cliquer que si vous êtes un geek hardcore, trouvé sur le profil twitter de Got que je remercie comme d’habitude pour les discussions sur le canapé.

Pourquoi j’ai accepté de sacrifier mes URL

Suite au déménagement du Figoblog, certaines personnes ont été émues par ma décision de ne pas assurer la continuité de service sur les URL des billets. En effet, comment peut-on consacrer tant d’énergie à défendre la cause des identifiants pérennes et se retrouver au final, tel le cordonnier, si mal chaussé ? Quelques explications s’imposent.

D’abord, un mot sur la cause technique. Comme je l’indiquais dans mon précédent billet, le Figoblog tourne maintenant sur une plateforme hébergée, à savoir WordPress.com. Si Got avait eu la main sur le serveur, il aurait pu mettre en place une réécriture d’URL : mes adresses en « /node/[identifiant-du-billet] » étaient en effet suffisamment simples pour que cela puisse fonctionner et l’identifiant a bien été récupéré dans les métadonnées du billet lors de la migration. Mais c’est ça, le problème du SAAS : on n’a pas toutes les fonctionnalités qu’on veut.

Ceci posé, comment aurais-je pu faire pour éviter ce drame, ce génocide, la mort de plus de 600 pauvres petites URL qui n’avaient fait de mal à personne ?

Pour commencer, j’aurais pu choisir une autre plateforme offrant cette fonctionnalité. Il aurait alors fallu que je fasse un critère de priorité de cette fonction, critère qui se serait trouvé prépondérant par rapport aux autres intérêts de WordPress.com (notoriété, gratuité, simplicité d’utilisation, etc.) bon, ce n’est pas le choix que j’ai fait ; il me semblait que les avantages de l’utilisation de cette plateforme, dont le fait qu’on a migré en 24h chrono, surpassaient les inconvénients.

J’aurais aussi pu choisir de laisser mon blog où il était et d’en commencer un nouveau. Après tout, c’est ce que font beaucoup de gens : voyez par exemple ARHV qui a déménagé pour l’Atelier des icônes avant de fermer boutique et passer sur Image sociale. Sur chacun de ses « anciens » blogs, un message indique qu’il est fermé et pour lire la suite, renvoie au nouveau. De fait, les vieux liens vers ARHV que j’ai pu créer dans mes anciens billets fonctionnent toujours.
C’est à dire qu’au lieu de tuer 600 URL, j’aurais pu accepter de laisser mourir mon blog tout seul… Mais tout entier.
Ah non. Ça, ce n’était pas possible. Vous voyez, je suis quelqu’un qui a besoin de changement. Souvent, je déplace tous les meubles de mon salon. Et quand j’en ai marre de déplacer les meubles et que je recherche un changement plus radical, je déménage. Mais je n’ai encore jamais déménagé en abandonnant tous mes meubles et mes cartons derrière moi.
En plus, pour être très franche, je n’ai pas l’intention de me remettre à bloguer beaucoup plus souvent ; alors quitter un blog pour en créer un nouveau qui resterait vide, cela n’avait pas tellement de sens.
Enfin, dans l’opération, j’aurais perdu la notoriété associée à mon nom de domaine : figoblog.org. Le fait que les gens le connaissent, ainsi que son référencement.

Donc quand Got m’a annoncé que les URL allaient être brisées, j’ai dit « tant pis ».
Comment puis-je encore me regarder dans une glace et dormir sur mes deux oreilles après avoir pris une décision pareille ? J’ai plusieurs choses à dire pour ma défense.
La première, c’est que ce n’est qu’un blog. Je n’ai jamais pris le moindre engagement institutionnel quant à la pérennité des URL de chaque billet. Le web change, bouge, chaque jour des URL naissent et meurent. Il y a des dizaines, des centaines de liens morts dans les vieux billets du Figoblog que j’ai emmenés avec moi dans ce déménagement. C’est la vie. Si on veut une image figée du web, il faut aller dans les archives (ou le dépôt légal).
La deuxième, c’est que d’un point de vue fonctionnel, j’estime qu’aujourd’hui on dispose de tous les outils nécessaires pour retrouver un billet, à commencer par le moteur de recherche intégré (là, à gauche). Et grâce à ma nouvelle plateforme, on tombe directement sur ce moteur quand on arrive sur un lien mort sur mon blog.
Last but not least, il me semble que l’usage principal d’un blog n’est pas (ou rarement) d’accéder aux vieux billets par des favoris. En général on les retrouve par son moteur de recherche préféré et de toute façon ce sont les nouveaux billets qui comptent (même si en me relisant j’ai trouvé quelques vieux trucs intéressants !) Quant aux twitts et autres posts Facebook qui sont mes principaux référents, ils sont encore plus éphémères…

Que peut-on retenir de cette aventure ? Et bien, que la pérennité a un coût. Maintenir des URL implique de trouver un équilibre entre le niveau de pérennité nécessaire et attendu des identifiants et les moyens dont on dispose pour les maintenir.
Sur mon ancien blog, le fait même de bloguer était devenu compliqué, laborieux, je ne pouvais plus voir le design en peinture, il y avait des bugs et du spam et plein d’autres inconvénients. Il fallait migrer. Got et moi n’avions que des moyens humains très réduits à consacrer à cette migration et nous avons dû faire des choix. Nous avions tout testé avec succès sur WordPress.com : l’import des anciens billets, les fonctionnalités front et back-office… Si je m’étais crispée sur cette histoire d’URL, tout était à refaire et la migration sans doute remise aux calendes grecques.

Pour résumer, la maintenance des URL était une fonction secondaire en termes d’usage, pour laquelle nous n’avions pas de politique stricte, et dont le coût était tel qu’il était susceptible de menacer l’activité elle-même (le blog). Dans ces cas-là, il faut savoir faire son deuil.

Le Figoblog nouveau est arrivé

Pour fêter en beauté le nouveau cru 2015, le Figoblog fait peau neuve.

Ça fait du bien (le design du site n’avait pas été rénové depuis 2008) mais surtout, mon très cher administrateur du site et moi-même avons décidé d’aller dans le sens de l’histoire. Nous abandonnons un système basé sur un logiciel open source et une exploitation internalisée (dans notre salon) pour aller vers une plateforme en SAAS (Software as a service).

Cette évolution va certes limiter un peu les fonctionnalités, mais elle permettra au Figoblog de bénéficier régulièrement et sans douleur des améliorations courantes de la plateforme et de son support. Par exemple, je devrais voir disparaître mes problèmes de spam et vous pourrez de nouveau mettre des commentaires (youpi !) Finis les thèmes mitonnés à la main avec notre plus beau Photoshop+CSS, là aussi je rentre dans le rang en adoptant l’un des nombreux thèmes librement disponibles.

Par ailleurs je quitte Drupal pour WordPress, non pas parce que je n’étais plus heureuse avec Drupal (et nous resterons bons amis) mais parce que les fonctionnalités de WordPress sont suffisantes pour mes besoins.

Bon, il y a juste un « léger » « petit » inconvénient : dans l’opération, toutes les URL des anciens billets vont être perdues. Pensez également à rafraîchir vos flux RSS. Je pense que la page 404 va être la plus visitée du site pendant un temps. Ah, les identifiants pérennes…

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

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

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

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

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

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

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

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

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

Faisons-le arriver !

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

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é]

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…

La TMA expliquée par la plomberie

Ceux qui ont à gérer une prestation de maintenance (tierce maintenance applicative ou TMA) pour leur catalogue ou leur site Web pourraient se reconnaître dans cette aventure qui démontre que de l’informatique à la plomberie, il n’y a qu’un pas. Ce petit mode d’emploi est directement inspiré de faits réels vécus avec mon plombier.

Épisode 1 : la Hotline
– Allô ? Je vous appelle pour signaler une fuite d’eau…
– Bonjour. Vous êtes en contact avec notre répondeur téléphonique. Nos bureaux sont ouverts du lundi au vendredi, de 9h à 12h et de 14h à 17h. Merci de renouveler votre appel.
*clic*

Épisode 2 : la Hotline (suite)
– Allô ? Je vous appelle pour signaler une fuite d’eau…
– Avez-vous vérifié que le robinet était bien fermé ?
– Euh… Oui…
– C’est sûrement les joints. Changez les joints et rappelez-nous.
– Mais je ne crois pas que…
*clic*

Épisode 3 : la qualification de l’incident
– Allô ? Je vous appelle pour signaler une fuite d’eau. C’est pas les joints.
– Et c’est grave ?
– Oh oui, quand même.
– Grave au point d’appeler les pompiers et qu’ils défoncent votre porte si nécessaire ?
– Euh non, quand même pas mais…
– Alors rappelez dans quinze jours.
*clic*

Épisode 4 : la planification de l’intervention
– Allô, bonjour, je suis le plombier de la société XX, mandaté par votre propriétaire pour votre problème de fuite.
– Ah, enfin, super !
– Je peux vous proposer d’intervenir demain entre 13h et 16h.
– Euh mais… c’est que ce n’est pas l’horaire qui m’arrange forcément le plus…
– Je n’ai rien d’autre à vous proposer.
– Ah bon ? Ah. Eh bien d’accord, à demain 13h.
*clic*

Épisode 5 : la planification de l’intervention (suite)
– Allô, voilà, c’est au sujet de la fuite, vous m’aviez dit que vous passeriez entre 13h et 16h mais il est déjà 16h15 et…
– Ah oui, c’est vrai. Désolé, j’ai été retenu chez un autre client.
– Mais j’ai posé congé pour vous attendre, moi ! Vous auriez au moins pu me prévenir.
– Désolé. Je peux passer demain, entre 13h et 16h.
– Eh bien en termes d’horaires ce n’est pas ce qui m’arrange le plus…
– Je n’ai rien d’autre à vous proposer.
Damn it. Très bien, à demain.
*clic*

Épisode 6 : la solution de contournement
– Elle est sérieuse, votre fuite, dites-donc.
– Ben oui, c’est ce que je me tue à vous…
– Du coup, il faut changer toute l’arrivée d’eau. Je ne vais pas pouvoir le faire aujourd’hui, mais rassurez-vous : cela ne fuira plus, vu que j’ai condamné votre évier de cuisine.
– Ah ? Mais ça va être moins pratique… Combien de temps je vais rester comme ça ?
– Eh bien, nous allons vous envoyer un devis.

Épisode 7 : le devis (option 1 : plombier qui va droit au but)
– Alors il y a deux solutions. Soit on refait la tuyauterie de façon apparente. Évidemment ce sera moins joli, mais sinon il faut défoncer les murs, les plafonds, le parquet…
– OK, OK. Va pour la tuyauterie apparente.

Épisode 7bis : le devis (option 2 : plombier doué en marketing)
– Eh bien cela vous fera X000 euros.
– Quoi !? Mon Dieu ! Mais comment est-ce possible, j’ai presque autant intérêt à racheter un autre appartement.
– Eh bien le problème c’est qu’il faut défoncer les murs, les plafonds, le parquet…
– Ce n’est pas possible. There has to be another way.
– Oui : sinon on refait la tuyauterie de façon apparente. Évidemment ce sera moins joli, mais…
– OK, OK. Va pour la tuyauterie apparente.

Il faut rendre justice à mon plombier : en général passée l’étape du devis tout se déroule pour le mieux. Et à la fin on a un évier neuf, c’est chouette quand même. Jusqu’à la prochaine fuite.