Communautés et institutions : la cohabitation impossible ?

J’ai eu souvent affaire à cette question ces derniers temps, que ce soit dans le contexte de l’association Europeana, d’IIPC ou encore des projets collaboratifs de la BnF : comment faire cohabiter harmonieusement les modes de fonctionnement radicalement différents d’une institution et d’une communauté ?

Les institutions ont plusieurs atouts dans leur manche. Elles sont organisées, pérennes et souvent dotées de ressources telles que des moyens financiers ou logistiques. Wikipédia ne pourrait pas exister s’il n’y avait pas quelqu’un qui faisait tourner les serveurs et lançait les campagnes annuelles de collecte de dons. Bien sûr, Wikipédia n’existerait pas non plus s’il n’y avait la communauté pour créer, organiser, surveiller et améliorer les contenus. Le succès de l’entreprise repose sur la bonne entente des deux colocataires, qui se répartissent harmonieusement les tâches ménagères (les anglo-saxons utilisent d’ailleurs le terme de « housekeeping » pour désigner les affaires administratives). Pourtant la lourdeur des institutions, avec les règles parfois rigides dont elles sont obligées de se doter pour fonctionner, peut avoir pour conséquence un désintérêt, une désaffection voire franchement une défiance de la part des communautés.
Face à ce problème, on peut avoir rapidement l’impression d’essayer de réconcilier deux colocataires qui doivent vivre dans le même appartement alors que l’un est maniaque et psychorigide et l’autre joyeux et bordélique. Au départ, sur le papier, on a l’impression qu’ils sont faits pour s’entendre : l’un des deux apportera la bonne ambiance, les fêtes et la bonne bouffe, l’autre se chargera du ménage le lendemain et de la bonne tenue du foyer. Sauf que rapidement la colocation vire au cauchemar, chacun ayant l’impression de donner plus qu’il ne retire de bénéfices dans l’opération.

De façon assez intéressante, j’ai dernièrement eu l’occasion de regarder le problème sous les deux angles, à travers mon expérience dans Europeana et dans IIPC.
Côté Europeana, on observe un équilibre (ou une tension, ce qui revient au même) intéressant entre l’institution, représentée par la Fondation qui met en œuvre le portail Europeana Collections, et l’Association, qui est censée représenter les intérêts de la communauté. Lequel des deux est le plus important ? Qu’est-ce qui apporte plus de valeur au citoyen européen, entre un portail donnant accès à cinquante millions de ressources numérisées et une plateforme destinée à dynamiser un réseau de professionnels ? Le produit ou la communauté ? J’ai déjà donné mon avis sur la question…
Côté IIPC, le consortium qui a atteint l’âge vénérable de 12 ans doit aujourd’hui passer d’un modèle institutionnel (consistant à définir des projets puis les financer et les piloter) à un modèle de communauté où les projets émergent d’eux-mêmes et pour lesquels il agit comme un facilitateur. Ce changement de logique est compliqué à opérer, mais essentiel pour sa survie et sa croissance.
Enfin, ma récente visite à la British Library, avec la présentation des communautés qu’ils animent comme le Knowledge Quarter ou le Digital scholarship avec son Labs, m’a permis de mieux comprendre les différences entre la logique institutionnelle, qui repose sur la mise en œuvre de projets ou de produits, et celle qui anime les communautés. Il s’agit vraiment de deux façons complètement différentes d’aborder un sujet ; elles ne sont pas forcément incompatibles mais reposent à plusieurs égards sur des logiques opposées.

Le point de départ : think big
La communauté se caractérise par un concept de départ autour duquel il y a une compréhension partagée du problème qu’on cherche à résoudre. Des concepts comme « open innovation », « digital scholarship » ou « knowledge quarter » en sont de bons exemples.  Une fois qu’on a réussi à mettre tout le monde d’accord sur le mot à utiliser qui va guider la communauté et faire converger les énergies, le reste suit.
Côté projet, on ne part pas d’un concept mais d’un programme, d’un résultat attendu ou livrable. On définit ce qu’on veut construire, puis on met en place le programme qui permet d’y arriver. Les dix minutes passées à choisir un acronyme imbitable qui deviendra la marque du projet pour le meilleur et pour le pire sont rarement une priorité.
Le « programme » qui sert de point de départ au projet est orienté résultat, alors que le concept qui permet de fonder la communauté est centré sur une compréhension partagée du problème (indépendamment des solutions qu’on peut lui apporter).

Les ressources : fund raising vs. call for proposals
Communautés et projets recourent à des méthodes très différentes pour réunir du financement.
Parce qu’elles reposent sur des concepts partagés et puissants, les communautés ont la capacité d’inciter leurs contributeurs à contribuer à la hauteur des moyens dont ils disposent (ou qu’ils souhaitent apporter), qu’il s’agisse d’argent, de moyens en nature (lieux, fournitures, etc.) ou de compétences. Les moyens apportés peuvent être très petits mais innombrables (cas de Wikipédia aussi bien dans la levée de fonds – crowdfunding – que dans la production de contenus – crowdsourcing) ou ponctuels mais énormes (cas du mécénat apporté par de grosses fondations ou entreprises américaines). Ils sont dans tous les cas difficilement prévisibles à l’avance et obligent la communauté à adapter ses actions aux moyens disponibles, en croissance aussi bien qu’en décroissance suivant la conjoncture.
Côté institutions et projets, le modèle qui prévaut est la subvention : on commence par évaluer combien coûte ce qu’on veut fabriquer, on se partage le gâteau entre partenaires en fonction de l’effort que chacun peut mettre et on va voir un tiers pour obtenir la somme. Ce tiers peut être un pouvoir public (tutelle, agence comme l’ANR…) mais ce modèle est aussi très souvent utilisé par les institutions dans leur recherche de mécénat.

Les méthodes de travail : start small, fail often
Cette différence dans la manière de financer leurs activités a bien sûr un impact sur ce que communautés et projets sont capables de produire et la méthode employée pour ce faire. Là où le projet s’impose dès le départ un résultat à atteindre et un calendrier, la communauté préfère lancer une multitude de petits projets, dont certains échoueront, mais ce n’est pas grave. On est dans la logique de l’essai-erreur, le principe étant de concrétiser aussi vite que possible les idées pour pouvoir se débarrasser rapidement de ce qui ne fonctionne pas et laisser grossir les « best-sellers », presque naturellement emportés par leur succès.

Les dépenses : hacking & yacking
De façon tout à fait logique, les communautés ne dépensent pas non plus leur argent de la même manière que les institutions. Se vivant comme des facilitateurs, elles vont consacrer une part significative de leurs ressources à permettre aux êtres humains qui constituent les communautés de travailler ensemble. Et que font les êtres humains ? Ils mangent, boivent, se rencontrent et communiquent. Rien d’étonnant, donc, que dans une communauté les dépenses soient souvent orientées vers des frais de déplacement, de bouche, de communication ou de logistique. Et s’il y a des emplois à financer, ils seront le plus souvent tournés vers ce type d’activité (planification d’événements, etc.). Le reste, la ressource qui produit réellement du travail, est en fait apportée par la communauté. L’exemple typique c’est le hackathon : l’institution ou l’organisateur fournit un lieu sympa, du café à volonté et des pizzas (yacking), la communauté fournit des idées, de la force de travail et des compétences (hacking).
Vu depuis une logique de projet, l’équilibre financier d’une communauté est une aberration. Un projet va en général consacrer 10 à 20% de son budget à sa propre gestion et communication. Le reste sert à financier des emplois, des équipements, du matériel, bref à acquérir ce que la communauté génère par synergie mais sans garantie de résultat. Si on veut des résultats garantis, il faut aussi garantir les moyens. Cela semble logique, en tout cas vu depuis l’institution…

La mesure du succès : empower & engage
La communauté se considère comme un facilitateur : son objectif principal est d’impliquer (to engage) ses membres et de leur donner des moyens (to empower) pour créer les conditions de la concrétisation de leurs propres idées. L’institution, elle, s’approprie les résultats du projet ou le produit, pas forcément au sens de la propriété intellectuelle mais au moins en tant qu’autorité productrice de ces résultats, généralement mesurables au moyen d’indicateurs. L’approche projet donne donc en apparence un retour sur investissement plus concret. Le résultat est un produit visible, tangible, dont l’institution peut revendiquer la paternité. Pour autant, ce produit sera-t-il suffisamment évolutif, maintenable, et tout simplement réussi ? La communauté de ses utilisateurs sera finalement seul juge.
Quand on cherche à mesurer les résultats de la communauté, on peut avoir l’impression d’une situation contrastée, entre quelques grandes réussites fulgurantes d’une part et une multitude d’initiatives dispersées et pas forcément très pérennes d’autre part. De plus, il n’est pas toujours évident de mesurer la part que la communauté a joué dans le succès d’un projet né en son sein.
Au final, les communautés et les projets ont des moyens très différents de mesurer leur succès. L’objectif premier du projet est de réussir, c’est à dire de livrer des résultats qui correspondent à ce qui était annoncé au départ. Les communautés, elles, cherchent à grossir, à engager de plus en plus de gens, sans poser de limites ou d’objectifs.

Finalement, les communautés sont-elles utiles ?
Si vous vous posez cette question, c’est que vous n’avez probablement pas (encore) intégré le mode de pensée qui sous-tend les communautés. Les communautés sont comme les fées : elles n’existent que par et pour ceux qui y croient. Je n’irais pas jusqu’à dire qu’il suffit de taper dans ses mains, mais l’idée est là : parce que leur but premier est de réunir des gens qui partagent les mêmes valeurs et les mêmes buts et sont prêts à y consacrer des ressources (du temps, des moyens, de l’énergie), les communautés n’ont pas besoin de prouver leur utilité pour exister. Le seul fait qu’elles existent crée de la valeur, une valeur parfois difficilement mesurable et observable de l’extérieur mais clairement ressentie par ses membres, qui perçoivent l’apport de la communauté à leur réussite, même si cet apport est difficile à quantifier ou à retracer de manière directe. Cette valeur se réalise parfois de façon concrète dans des ressources partagées qu’on appelle les communs.

Dans leur livre L’âge de la multitude, N. Colin et H. Verdier qualifient la multitude (ce que j’ai appelé ici les communautés, car à mon avis la multitude n’est pas une réalité unique mais plurielle) d’ « externalité positive » : quelque chose qui est en dehors du projet ou du produit, mais contribue à créer de la valeur qui joue en faveur de sa réussite de manière plus ou moins mesurable. Pour eux, le principal enjeu de la transition numérique, pour les organisations, institutions ou entreprises, est d’entrer en synergie avec la multitude. Pour cela, les institutions doivent devenir des plateformes principalement dédiées à permettre à la multitude de s’en emparer et ainsi déployer sa créativité.
Ce modèle qui a fait le succès des Uber, Amazon, Facebook et autres Twitter implique, pour des institutions comme les bibliothèques, de lâcher prise sur un certain nombre choses : les projets et les produits, les indicateurs de performance, la propriété de ce qu’elles créent. Il suppose de se définir comme une plateforme et donc se recentrer sur le service qu’on offre aux communautés, leur permettant d’exprimer leur créativité ; de se poser en facilitateur d’une expérience plutôt qu’en fournisseur d’un produit (en l’occurrence la collection) ; de concevoir ses propres objectifs en mineure et ceux de ses usagers en majeure. C’est ce que les bibliothèques ont commencé à faire avec la notion de « troisième lieu ».

Parce que toute réflexion de fond sur les bibliothèques ramène toujours à cet ouvrage indispensable qu’est La sagesse du bibliothécaire, je vais conclure en reprenant la citation de Michel Melot retenue par Mathilde Servet dans son article : « Pour atteindre son seuil critique, il faut que la bibliothèque ait de nombreux lecteurs et bien d’autres usages que la simple lecture. La bibliothèque n’existe que par la communauté […] [Le bibliothécaire] ne parle pas pour lui-même mais pour la communauté qu’il sert. Il doit en refléter les goûts et les opinions, mais aussi les ouvrir à d’autres. Son choix doit être celui de la pluralité […], cette “bigarrure” qui caractérise les sociétés libres. »

IIPC 2016 – how to collaborate ?

Il y a deux semaines, j’avais le privilège de partir pour une semaine en Islande à l’occasion de la rencontre annuelle du consortium IIPC pour la préservation de l’Internet : d’abord l’assemblée générale, puis conférence WAC (Web Archiving Conference) et enfin la réunion du Steering Committee, instance de gouvernance du consortium. Ce dernier, constitué de 15 membres issus pour la plupart de bibliothèques nationales, m’a fait la confiance de me confier la présidence du consortium pour un an.

 

Beaucoup d’entre vous m’ont félicitée sur les réseaux sociaux, ce dont je vous remercie, mais je ne suis pas sûre que tout le monde sache exactement de quoi il retourne, donc j’ai décidé de revenir ici sur le consortium IIPC et ce rôle de présidente.

 

Le consortium a été fondé il y a 13 ans par un petit groupe de bibliothèques nationales conjointement avec Internet Archive, fondation américaine à but non lucratif qui s’était donné l’objectif d’archiver le web dès le milieu des années 1990 et était pratiquement la seule organisation, à cette époque, disposant de l’infrastructure matérielle et logicielle permettant d’accomplir une tâche aussi dantesque à grande échelle.
IIPC avait alors pour but de créer des outils communs, de susciter l’émergence d’une communauté et d’alerter sur l’importance de l’archivage du web, afin que se mette en place une dynamique internationale qui assurerait la mémoire du web que nous connaissons.
Le propos introductif de Marc Weber, directeur du Computer History Museum, du colloque Time and temporalities of the Web, en fin d’année 2015, m’a fait réaliser que parmi les nombreux réseaux qui ont existé avant que le web ne finisse par s’imposer, comme Arpanet ou le Minitel par exemple, fort peu ont fait l’objet d’un effort de préservation ; en fait, seuls en ont bénéficié ceux dont les créateurs avaient conscience d’une perte de mémoire potentielle et se sont mobilisés pour sauvegarder leur propre objet.
Le travail d’Internet Archive dès 1996 puis l’investissement des bibliothèques nationales, qui ont cherché à se doter non seulement d’outils mais aussi d’un cadre juridique s’appuyant sur le dépôt légal et de procédures métier héritées de leur tradition professionnelle, ont doté le web d’une mémoire qui a en outre la qualité de ne pas être trop biaisée d’un point de vue historique, en tout cas moins que si elle avait été documentée uniquement par les créateurs du web eux-mêmes.
Avec la fondation d’IIPC, les bibliothèques nationales apportaient à la communauté de l’archivage du web un autre atout : leur capacité à organiser des processus de couverture documentaire au niveau international, comme elles l’avaient fait autrefois avec le contrôle bibliographique universel.

 

Aujourd’hui le consortium IIPC ce sont 50 membres venus de nombreuses régions du globe et dont le profil ne se limite plus aux bibliothèques nationales : des bibliothèques universitaires, des acteurs majeurs dans le domaine de l’audiovisuel ou encore des acteurs privés se préoccupent aujourd’hui de cette question. La conférence annuelle s’ouvre également, de façon de plus en plus prégnante, à des universitaires issus de différentes disciplines, pour lesquels les archives du web sont un objet d’étude et une source de premier plan.
Dans ce contexte, le consortium semble à présent traverser une deuxième crise de croissance (la première ayant eu lieu au moment où le consortium élargissait sa base de 12 membres fondateurs : pour en savoir plus sur l’histoire d’IIPC jusqu’en 2010, lire l’article de Gildas Illien dans le BBF). Ainsi les différentes sessions de l’assemblée générale et de la conférence, sans qu’un thème particulier leur ait été attribué, ont naturellement convergé vers une question récurrente : « how to collaborate » ? Tout le monde s’accordant à reconnaître que la collaboration était aujourd’hui un enjeu majeur et une aspiration généralisée, mais que le « comment » devenait compliqué à définir avec l’élargissement de la communauté, la multiplication de ses centres d’intérêt et de fait, parfois, des divergences de vues. Pour autant, les propositions de collaboration ont été foisonnantes et ont pris de nombreuses formes différentes :
Le panorama : avec plus de 50 institutions et 150 individus autour de la table, un des premiers enjeux réside dans le fait de savoir sur quels projets travaillent les uns et les autres afin de faire émerger des synergies potentielles. Harvard a réalisé récemment un « Web archiving environmental scan » : un travail de 5 mois pour explorer les pratiques de 23 institutions et en tirer 22 opportunités de travaux à conduire. L’idée qu’IIPC puisse être un forum pour mettre régulièrement à jour ce type de rapport et ainsi mieux communiquer sur les pratiques de ses membres a été émise.
Le développement open source : celui-ci reste au cœur des pratiques traditionnelles d’IIPC, et on perçoit aujourd’hui encore des attentes importantes à l’égard des outils majeurs comme le crawler Héritrix (robot qui moissonne les pages web) ou l’open wayback (outil d’accès aux archives web), perçus comme insuffisamment documentés et stabilisés.
Les API : les « gros » outils mentionnés ci-dessus, bien qu’utilisés très largement, sont perçus comme monolithiques et peu évolutifs au regard d’un web qui tend à se modifier techniquement plus rapidement qu’eux. Ainsi la collecte des réseaux sociaux ou encore des plateformes de vidéo sont aujourd’hui des challenges auxquels tout un chacun est confronté. L’idée de travailler sur une chaîne d’outils plus modulaire, souple et évolutive, dont les différentes briques seraient liées entre elles par des API avait déjà été soulevée par Tom Cramer l’année dernière. Mais elle s’est encore renforcée et précisée cette année.
Les normes et standards : fortement liés aux outils, les standards comme le format WARC et ses différents dérivés continuent à jouer un rôle important. L’effort de normalisation requiert la construction d’un consensus et fait donc partie des attentes à l’égard d’IIPC.
Les hackathons : L’exemple d’Archives Unleashed, présenté par Ian Milligan et Matthew Weber, a montré l’importance d’organiser des temps forts d’expérimentation réunissant développeurs, archivistes et chercheurs de toutes disciplines, non seulement pour faire émerger de nouvelles idées et projets de recherche, mais aussi pour mieux comprendre ce matériau particulier que sont les archives web et adapter les outils.
L’étude des usages : l’approche orientée utilisateurs n’est pas une nouveauté au sein de la communauté IIPC qui avait déjà rassemblé des use cases (une première fois en 2006 puis à nouveau en 2013). On a vu cependant émerger de nouvelles méthodes plus orientées études d’usage, comme l’utilisation de « personas » par les archives gouvernementales britanniques.
Les collections collaboratives : là aussi il y a un existant côté IIPC, avec les collections collaboratives qui se sont mises en place d’abord autour des jeux olympiques puis d’autres sujets (la grande guerre, la crise des migrants en Europe…) en utilisant depuis l’an dernier le service Archive It. On a vu cependant émerger d’autres propositions de modèles collaboratifs autour de la collecte, comme le projet Cobweb dont l’objectif est de mettre en commun les ressources de sélection et de collecte à travers un répertoire qui permettrait à chacun de proposer des collections à archiver et à différentes institutions de déclarer leurs collectes.
Le cloud : Brewster Khale, dans sa présentation de la « bibliothèque nationale d’Atlantis » (celle dont le logo est un mermaid cat), va plus loin et renoue avec le vieux rêve d’une grande archive internationale collaborative et reliée, en s’appuyant sur l’idée du cloud : une mutualisation des infrastructures, des ressources et des outils, permettant néanmoins à chaque bibliothèque nationale d’affirmer sa propre identité. On est très proche ici des idées que je présentais récemment au sujet des bibliothèques numériques. Brewster note aussi la difficulté croissante à démêler le web des autres ressources qui intéressent les bibliothèques (livres, revues, audiovisuel…), devenues elles aussi numériques et circulant sur le web, ce qui va nous obliger à penser des interfaces qui ne séparent plus le web du reste de la bibliothèque.

 

Et mon rôle de présidente, dans tout ça ? Le renouvellement de l’accord de consortium début 2016 a été l’occasion de remettre sur la table la question de la stratégie d’IIPC et ses ambitions, ainsi que de revoir sa gouvernance : ont ainsi été créés trois « portefeuilles » (« portfolios »), trois thématiques qui permettent d’appréhender le consortium sous trois angles différents : le développement des outils, l’engagement des membres et la recherche de nouveaux partenariats.
Ce changement amené par le précédent président, Paul Wagner de Bibliothèques et Archives Canada, pouvait paraître couler de source mais il a été reconnu par certains des membres les plus anciens du steering committee comme une étape essentielle, et avec raison. Il apporte en effet deux éléments qui seront sans doute clefs pour le développement d’IIPC à l’avenir : d’une part une gouvernance plus engagée, d’autre part une lisibilité de la stratégie qui devrait lui permettre de passer cette nouvelle étape de croissance, c’est-à-dire de cesser d’être un groupe ou un club exclusif réservé à quelques experts pour devenir une communauté, dans toute sa richesse et sa diversité.
Prenant le relais de Paul au 1er juin 2016, mon rôle sera d’accompagner cette nouvelle organisation et de l’installer dans le fonctionnement quotidien du consortium et en particulier du Steering Committee, avec pour ambition de transformer les idées en actions concrètes, même si celles-ci ont dans un premier temps une ambition limitée.
Sur ce je vous laisse, j’ai un « strategic plan » à rédiger ;-)

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 !

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.

CPV en orbite

Cela faisait un moment (en fait, un an et demi) que j’attendais ça : nous avons enfin lancé le Centre Pompidou Virtuel. On va pouvoir arrêter de l’appeler comme ça et parler simplement du nouveau site du Centre Pompidou.



Comme tous les sites Web, il n’est pas parfait, il va devoir encore beaucoup évoluer, nous avons encore plein de projets (heureusement, sinon je serais en plein baby blues…) mais c’est quand même un grand moment de bonheur !

Bien sûr ma communauté d’intérêt favorite, informée de l’événement sur Twitter, s’est jetée sur le nouveau joujou à la recherche du RDF… et en est revenue toute dépitée. Oui, c’est vrai, le Web sémantique est au cœur de la machine mais on ne le diffuse pas pour l’instant. Comme je l’expliquais à l’IFLA cet été, nous n’avons pas fait du Linked OPEN Data mais du Linked ENTERPRISE Data. C’est à dire que nous avons appliqué les technologies du Web sémantique à nos propres données afin de construire notre propre service.

C’est quand même du Web sémantique, du vrai de vrai, et notre site est véritablement construit dessus, en production. J’ai eu l’occasion d’expliquer tout ça, avec l’aide de Got qui a présenté quelques projets complémentaires, lors du séminaire IST de l’INRIA en début de semaine. (C’était vraiment bien, si vous n’avez pas pu y assister, je vous recommande le livre).

Est-ce que cela signifie qu’on va en rester là ? Pas du tout.
La première étape sera de rendre le RDF plus visible en intégrant des métadonnées (probablement du Schema.org) dans les pages HTML. Comme cela, on exploitera la richesse des informations disponibles tout en les rendant accessibles à d’autres et en améliorant notre stratégie de référencement.
La deuxième étape sera de développer des mécanismes permettant à d’autres de réutiliser nos données, et d’y associer la licence ouverte qui va bien. Je l’ai dit plusieurs fois dans des conférences, c’est une suite logique, et cela s’inscrit complètement dans l’ADN du projet qui est par nature ouvert.
Mais avant d’y arriver, il va falloir traverser en louvoyant deux couches d’astéroïdes.

La première est liée au statut des contenus : en tant qu’œuvres du XXe et XXIe siècles, ils sont pour la plus grande partie encore protégés par les droits de propriété intellectuelle.
À ma connaissance, l’ampleur du chantier de collecte d’autorisations que nous avons entrepris est sans précédent (nous ne pouvons nous réfugier ni derrière le domaine public avec une barrière temporelle ni derrière le fair use anglo-saxon).
Ce sont souvent des négociations et des explications avec des personnes qui ne sont pas familières avec la technologie et qu’il faut rassurer sur notre démarche. On veut construire le site avec eux, pas contre eux, et cela nécessite d’avancer pas à pas.
Aujourd’hui, le fait que les contenus peuvent être protégés même si les data sont libres est un discours qu’on a même du mal à expliquer à des professionnels de l’information, alors avec les ayants droit cela risque d’être un long chemin semé d’embûches.

La deuxième difficulté tient à la nature de l’institution et de son activité. Moi qui viens des bibliothèques, je suis imprégnée jusqu’à la moelle d’une culture de l’échange de données qui est pour nous une évidence. Dans les musées, j’ai l’impression qu’il faut commencer par démontrer la valeur ajoutée de la démarche, et aussi rassurer, sur le plan institutionnel, sur le fait que l’institution ne va pas se trouver dépouillée de ses ressources propres si elle ouvre ses données.
La démarche de faire du site du Centre Pompidou un immense centre de ressources offrant gratuitement l’accès à tous les contenus numériques n’était déjà pas une évidence et a représenté plusieurs années de travail. Nous travaillons quotidiennement à réconcilier cette approche « documentaire » perçue comme un ovni avec les besoins de visibilité concrets et immédiats de nos collègues dans les autres services.
L’idée que ce centre de ressources doit être ouvert sur l’écosystème du Web, interagir avec d’autres jeux de données, les enrichir et s’en enrichir à son tour est pour moi une évidence, mais institutionnellement cela a besoin d’être approfondi, expliqué et démontré. C’est un de mes chantiers pour les mois à venir.

IFLA 2012 (suite) – Quelques questions existentielles sur le Linked Data

Pour clore cette série de billets sur mon voyage à l’IFLA, je voulais revenir sur quelques idées fortes qui se sont avérées récurrentes quand il a été question de Web sémantique et de Linked Data.

Le premier point portait sur les licences et de l’open data. Ce sujet avait été inscrit à l’agenda de la session des bibliothèques nationales, et il a surgi également lors de nos deux événements sur le Web sémantique (la table ronde OCLC et la session du SWSIG). On commence à voir les « gros » se poser réellement la question pour une partie de leurs données de l’ouverture complète, sans la moindre contrainte, façon CC0 : la British Library, la Deutsche Nationalbibliothek, la BnF. De même, OCLC a récemment ouvert les données de WorldCat en Schema.org sous licence ouverte. Les données sont fournies dans les pages en RDFa, mais on peut aussi télécharger un « dump » (gros fichier avec plein de données dedans) partiel contenant 1,2 millions de ressources. Ce choix de licence montre qu’OCLC reste attaché au principe de la citation de la source, allant jusqu’à fournir des guidelines sur la meilleure façon de citer ses sources s’agissant de données. Je trouve ce document très intéressant en ceci qu’il aborde les différents cas possibles, depuis l’attribution sous la forme d’une mention globale (genre, « ce site/service/article utilise des données de Worldcat sous licence ODC-by ») jusqu’au simple fait d’utiliser les URIs de WorldCat dans le jeu de données, qui est considéré comme une forme d’attribution en soi ! L’intermédiaire entre les deux consiste à ajouter dans la description de son dataset un triplet avec un « DC:source » vers WorldCat. On pourra lire avec grand bénéfice quelques commentaires sur la stratégie d’OCLC sur le blog CC. Bien que je sois globalement d’accord, je les trouve un peu sévères sur les guidelines et la question de leur applicabilité dans le contexte du Linked Data. Il me semble au contraire que le fait de considérer la simple utilisation des URI comme une forme d’attribution contribue à intégrer juridiquement le principe qui est au cœur du Linked Data (« follow your nose », naviguer dans les données en suivant les liens). Et justement, cela fait plusieurs années qu’on proclame, nous les Linked Data évangélistes, que vos données – même réutilisées – ramèneront toujours de la valeur et de la visibilité à votre institution ne serait-ce qu’à travers les URI. C’est donc réconfortant de lire cela dans les guidelines d’OCLC… Sans vouloir m’étendre davantage sur OCLC, je trouve pour finir que ces quelques pas qu’ils font en direction du Linked Open Data sont significatifs d’une tendance beaucoup plus importante : le modèle économique de la vente des données, c’est fini. Et tous les acteurs qui reposaient là-dessus uniquement vont devoir se creuser la cervelle pour trouver autre chose. Quant à ceux, comme les bibliothèques nationales, qui y voyaient un sympathique à-côté fournissant quelques petits revenus quand même, ils vont pouvoir libérer leurs données avec la conscience tout à fait tranquille… bonne nouvelle non ? (A lire absolument pour se détendre sur le sujet : pourquoi les bibliothèques ne sont pas en open data, par Mace Ojala sur Cyc4libs.) Une fois les données ouvertes, c’est bien joli mais on aimerait bien pouvoir savoir qui va les utiliser et comment. Et là c’est le trou noir, le black out. Les données libérées sont désespérément muettes quant à leur usage, tout au plus dispose-t-on de logs sur un serveur qui semblent témoigner d’une activité, mais laquelle… Or la communauté ayant maintenant bien intégré l’idée que nous ne pouvons pas aller plus loin sans démontrer la valeur ajoutée de l’open/linked data en termes de réutilisations, cette question est devenue cruciale. C’était d’ailleurs le sujet de ma keynote à DC2011. A l’époque c’était presque révolutionnaire, et j’avais lancé ce slogan : « we need to stop citing the BBC », parce qu’il me semblait impensable que nous puissions tenir encore plusieurs années sans avoir un autre exemple digne de ce nom à présenter. Quand je dis « digne de ce nom », ce n’est pas que les autres applications sont indignes, mais je voulais parler d’exemples démontrant l’usage des données du Linked Data en production, et pas seulement de manière expérimentale, cet usage étant assorti d’une vraie réflexion et d’un discours sur ce que cela apporte à l’institution. Quand on discute avec les collègues de la BBC (on peut aussi lire leur use case sur le site du W3C) ils expliquent que l’approche Linked Data est complètement intégrée à la conception de leur système d’information, dont une partie est considérée comme « externalisée » sur le Web (en gros, ils corrigent les notices de Wikipédia au lieu d’éditorialiser leur propre site) et dont la clef de voûte réside dans l’attribution des URI qui permettent d’unifier le système. En fait, ils ont eu avant la lettre cette vision du Linked Enterprise Data (minute copinage : vous trouverez une très bonne explication du LED en français ici), c’est-à-dire l’utilisation des principes et des technologies du Linked Data à l’intérieur du système d’information pour unifier les données entre les différentes applications. C’est d’ailleurs cet aspect que j’ai choisi d’approfondir quand j’ai présenté le Centre Pompidou virtuel pendant la table ronde OCLC (comme quoi je ne raconte pas toujours la même chose !) J’ai comparé le principe à celui d’un intranet, qui utilise les technologies du Web mais au bénéfice interne de l’institution, sans parler de publication. Eh bien là c’est la même chose, une première étape où on fait en quelque sorte du Linked Data en interne – avant, je l’espère, d’envisager d’ouvrir les données. Ainsi, le premier argument pour convaincre une institution de faire du Linked Data pourrait être la perspective d’améliorer les processus internes. Mais si on parle d’open data, il faut aussi être capable de démontrer la valeur ajoutée de l’ouverture, en terme de réutilisation. Martin Malmsten suggérait de partir d’un principe simple : contribuez ce qui est unique chez vous, et bénéficiez de l’ensemble. A mon avis, il reste cependant nécessaire de démontrer *comment* on bénéficie de l’ensemble, et pour cela il nous faut connaître les utilisateurs du service et les cas d’usage. D’où la question : comment faire pour connaître les utilisateurs de nos données ouvertes ? On a failli repartir tous avec des tee-shirts « if you build it, they will come ; if you break it, they will complain » (l’idée étant de casser le service pour que les utilisateurs se manifestent ;-) Mais plus sérieusement, l’approche proposée par Neil Wilson (BL) m’a semblé très sensée : c’est à nous de construire la communauté, en contribuant éventuellement dans un premier temps à la mise en place de services tiers, pour montrer l’exemple. Enfin, le troisième défi souligné par mes camarades de la British Library et de la bibliothèque royale de Suède est celui de la mise à jour des données. Il est aussi lié au point précédent, en ceci qu’on constate que les consommateurs actuels de Linked Data ont tendance à faire porter leur préférence sur un dump plutôt que d’utiliser les données liées en temps réel, pour diverses raisons notamment techniques sur lesquelles je ne vais pas m’étendre ici. Au temps pour le graphe global : ce qu’on utilise aujourd’hui en réalité, c’est bien souvent une photographie des données à un instant T, et suivant la fréquence de mise à jour du dump source et de l’application cliente, la fraîcheur du service est inégale. Du coup, côté OCLC et Libris, on privilégie une approche où la version RDF de chaque notice fait partie intégrante du service, dans un esprit très Linked Data. Ils voudraient inciter leurs utilisateurs à utiliser directement ces données plutôt que des dumps qui vont se périmer très vite. Côté British Library et BnF, on rafraîchit tous les mois, et on voudrait passer à un rythme hebdomadaire. Et moi, je suis bien placée pour savoir que rafraîchir quotidiennement est un défi, mais que dans certains cas c’est aussi une nécessité. Donc, on voudrait que notre Linked Data soit plus intégré aux processus de production des données, et pas seulement en bout de chaîne (cf. ce que je disais plus haut sur le LED). On voudrait des applications qui « suivent leur flair » (follow your nose, donc) en temps réel au lieu d’avaler des gros fichiers une fois de temps en temps. Et enfin, on voudrait un processus de notification qui permette aux consommateurs de données de savoir quand un dataset ou une ressource a été mis à jour (c’est là que Martin s’est mis à parler d’Atom et de PubSubHubbub, le protocole au nom marrant). Cette problématique renvoie à la question de la provenance, sur laquelle travaille le DCMI, en lien avec le W3C qui avait fait un groupe d’incubation sur le sujet. Mais ce n’est pas tout ; dans le Linked Data on exprime les triplets sous la forme d’un document, un fichier qui contient les données sous une forme RDF/XML ou autre. La question est donc de savoir comment utiliser ce document pour transmettre aussi des informations de notifications concernant les mises à jour. Mince, je m’étais dit que j’allais faire un petit billet pas trop long et voilà le résultat… En tout cas, nous allons aborder tous ces sujets, Got et moi, dans notre présentation au séminaire INRIA en octobre. Pour ceux qui n’ont pas pu s’inscrire, les actes seront publiés, en français dans le texte. Ces questions seront également au cœur de la présentation que je vais faire en keynote de la 2e journée de la conférence SWIB 2012, à Cologne, le 27 et 28 novembre prochains (je me permets de l’annoncer en avant-première, le programme devrait être publié très prochainement). Alors venez nombreux ! Commentaires bienvenus par mail, sur Twitter @figoblog et sur Facebook pour ceux qui y sont.

Bye bye, communauté Louvre

Il vous reste exactement une semaine, si vous ne l’avez pas encore fait, pour aller visiter une dernière fois le site Communauté Louvre avant qu’il ferme pour de bon ses portes. Enfin, ses pages.

Créé il y a moins d’un an grâce à une opération de mécénat, le site s’était donné pour objectif de permettre aux internautes intéressés par le musée du Louvre de s’exprimer et de partager leur propre regard sur les œuvres.

Derrière l’affirmation que cette expérimentation a servi à expérimenter des dispositifs qui seront désormais intégrés au site louvre.fr, on ne peut pas s’empêcher de s’interroger sur le constat d’échec, ou au moins de déception que révèle cette fermeture.

Qu’a-t-on appris avec Communauté Louvre ?
On a appris qu’il fallait constituer la communauté avant de construire l’outil, si efficace soit-il. Que le participatif repose non pas sur Monsieur Tout le Monde, mais sur des gens qui ont un intérêt à participer.

Appel à commentaires

En cette période estivale, l’activité dans votre bibliothèque se ralentit… Vous avez peur de vous ennuyer…

Si vous n’êtes pas encore partis en vacances, à vos stylos ! Il vous reste encore une semaine pour poster des commentaires sur le brouillon du rapport final du groupe W3C Library Linked Data, le LLD XG.

Pour faciliter les choses, nous avons posté l’intégralité du rapport sur un blog où vous pouvez très facilement ajouter des commentaires. Après quelques hoquets, il est maintenant tout à fait opérationnel.

C’est par ici.

La contribution de tous est essentielle pour que ce rapport soit utile à la communauté et trouve son public. Alors surtout, n’hésitez pas.

Bon été !

Sem Web Pro

Ces deux derniers jours, j’ai participé à la conférence Semweb.Pro. L’objectif de cette première édition était, je crois, de montrer qu’il existe une communauté professionnelle et des applications industrielles pour le Web sémantique en France. Et l’objectif a, je crois, été atteint !

Environ 130 personnes étaient présentes entre les deux journées : la conférence proprement dite le 1er jour, et les tutoriels le 2e jour. Quelques impressions à chaud…

J’ai beaucoup apprécié l’ouverture d’Ivan Herman, qui a fait le point sur les travaux en cours dans le domaine du Web sémantique au W3C, de la nouvelle version de SPARQL aux travaux qui vont démarrer sur « RDF next steps », en passant par les évolutions de RDFa. Bon c’est vrai, dès le matin à 9h, les requêtes SPARQL direct c’était un peu sévère ;-) mais au moins ça annonçait la couleur.

Ensuite, nous avons assisté à 4 présentations de produits qui permettent de publier des données en RDF : EMFtriple, CubicWeb, Semsoft et Asterid. Personnellement, cette partie de la conférence m’a moins emballée, mais je pense que c’est juste parce que ça ne correspondait pas à mes centres d’intérêt à ce moment-là.

L’après-midi la parole était aux producteurs, avec une table ronde sur l’ouverture des données publiques (à laquelle j’ai participé), et la présentation de la BBC (j’adore toujours autant leurs réalisations, c’est vraiment excellent).
Enfin quelques réalisations intéressantes : SemWebVid pour annoter des vidéos automatiquement, les explications d’Antidot sur l’utilisation des technos du Web sémantique dans un moteur de recherche, et Datao pour les interfaces graphiques.
Ça s’est terminé avec des « lightning talks » auxquels je n’ai malheureusement pas pu assister.

Deuxième jour, les tutoriels : c’était dur, il fallait choisir ;-) mais je dois dire que tous ceux auxquels j’ai assisté étaient de grande qualité. Grâce à Got je n’ai plus peur de RDFa… et je salue tout particulièrement le travail de l’équipe Datalift, je pense que leurs diapos feront date dans le monde du Web de données français.

Pour finir, je tire mon chapeau aux organisateurs de la conférence pour la logistique, les salles, le café, les croissants, le wifi, le fil twitter, le déjeuner au self du coin, tout ! Et ce qui était surtout agréable c’était de voir réunie toute la communauté et de partager ces deux jours avec tout plein de gens passionnants. J’espère qu’on remettra ça l’année prochaine !