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 !

Vers l’epub 3.0

Lu dans une dépêche du GFII, l’International Digital Publishing Forum (IDPF pour les intimes) annonce qu’ils vont lancer un travail pour refondre le format « epub », l’un des formats les plus en vogue du « livre numérique ».

(En écrivant cela, je me rends compte que je n’ai encore jamais parlé de livres numériques sur mon blog, ce qui prouve à quel point j’ai laissé se creuser le fossé entre ce que j’absorbe dans ma veille et ce que j’en restitue. Mais bon, tout est là, dans TeXtes… Et puis j’ai pris des bonnes résolutions, comme vous pouvez le constater).

Bref, on peut consulter en ligne le projet de charte du groupe de travail qui va se pencher là-dessus. Il identifie 13 axes d’amélioration pour le format epub :
1. permettre d’embarquer des contenus « riches » (multimédia)
2. meilleur support des langues et des caractères non latins
3. support du niveau « article » pour les journaux et revues
4. support amélioré des métadonnées (ONIX, RDFa)
5. meilleure gestion de la présentation au niveau de la page
6. amélioration de la navigation (table des matières…)
7. alignement avec les standards du Web
8. mécanismes d’annotation
9. représentations mathématiques
10. éléments spécifiques à la structure des livres (glossaires, références)
11. accessibilité (avec DAISY)
12. possibilité d’ajouter des extensions spécifiques à un domaine métier
13. enfin, élaborer une feuille de route pour mettre epub en relation avec les normes officielles au niveau national et international.

Les changements seraient suffisamment importants pour justifier une version « 3.0 » d’epub (tiens, ça manquait de 3.0 ce billet justement ;-) et d’ores et déjà, une convergence avec HTML5 est envisagée.

Si vous pensez que cette liste n’est pas complète, vous avez jusqu’au 20 avril pour répondre à l’appel à commentaires public lancé par l’IDPF.

Qui n’URIsque rien n’a rien

En reprenant mes « vieux » diaporamas sur les identifiants, je me rends compte que j’ai contribué à propager des idées fausses sur les URL et les URI, belles métaphores à l’appui, notamment en proclamant que « une URI est la combinaison d’un nom et d’une localisation » ce qui a pu être compris un peu vite comme « URI=URL+URN ».

Je fais amende honorable en proclamant ici que les URL sont des URI.
Les URN aussi sont des URI, la seule chose de particulier qu’elles ont, c’est qu’elles commencent par « urn: ».

Il faut se débarrasser de la vieille idée reçue que les URL correspondent à une localisation d’un fichier sur un serveur. C’est de moins en moins souvent le cas sur le Web aujourd’hui. Les URL générées par les outils de gestion de contenu, par exemple, sont en fait des paramètres qui permettent de dire au logiciel comment accéder à la ressource.

Une URL, c’est donc
– une URI (parce qu’elle en respecte la syntaxe)
– qui commence (en général) par « http: » (qui est un préfixe d’URI enregistré et donc reconnu)
– qui identifie une ressource principalement par le mécanisme qui permet d’y accéder (par exemple, son emplacement sur le réseau).

Ce mécanisme peut être le nom du fichier et son emplacement sur le serveur.
Il peut être aussi une série de paramètres qui appellent une base de donnée, via un logiciel.
Ou une chaîne de caractères qui va être interprétée grâce à un annuaire qui « sait » où se trouve la ressource en question.

En conséquence de quoi, les URL sont des URI et peuvent prétendre à la pérennité, autant que n’importe quel autre type d’URI, pour un peu qu’on les gère correctement.

Les rapports et différences entre URI, URL et URN sont expliqués dans la RFC 3305.

Archives du Web : une vision

Pour commencer l’année sur une note lyrique, j’ai envie de revenir sur quelques réflexions qui me sont venues lors d’IPRES et de la journée « Active Solutions » d’IIPC. En effet, à cette occasion, pas seulement parce que je me trouvais en Californie, qu’il faisait brumeux le matin et soleil l’après-midi et que San Francisco est une ville magnifique, mais aussi parce que j’étais bien entourée et parce que les organisateurs desdits événements ont fait un boulot superbe, j’ai eu l’impression de transcender la connaissance que j’avais de l’archivage du Web, ses modalités et ses finalités.

Pour comprendre, il faut dire que je côtoie l’archivage du Web depuis maintenant quelques années, géographiquement et intellectuellement, et de suffisamment près pour m’être forgé quelques idées fausses (ou idées reçues) sur cette activité. Pour les énoncer un peu comme ça en vrac :
– l’archivage du Web, c’est intrinsèquement lié au dépôt légal ;
– les utilisateurs sont des gens du futur qu’on ne connaît pas et dont on ignore les vrais besoins ;
– les gens qui font de l’archivage du Web sont une toute petite communauté avec des compétences et des besoins très spécifiques.
Et oui, il a fallu que je traverse la planète pour enfin comprendre la portée de cette activité qui se déroulait juste là, à côté de moi, sous mes yeux depuis des années.

D’abord, je me suis rendu compte que l’archivage du Web, ce n’est pas seulement le dépôt légal, et de fait, cela ne concerne pas que les bibliothèques nationales. L’archivage du Web est un ensemble de techniques qui permettent de constituer une collection locale et pérenne à partir de contenus accessibles en ligne. En fait, il y a une multitude d’applications possibles à cela : archiver des périodiques en ligne comme le fait LOCKSS, constituer des collections de sources pour des équipes de chercheurs d’une université, archiver ses propres publications Web pour en garder la mémoire, etc.
Vu comme cela, l’archivage du Web peut être utilisé par tout type d’établissement, et à une variété d’échelle. Les « private LOCKSS networks » utilisent ainsi le dispositif technique de LOCKSS, à l’origine conçu pour collecter des revues en ligne, pour collecter des archives Web partagées de toute sorte. Le service « Archive It » proposé par Internet Archive permet à des institutions qui n’ont pas les moyens de mettre en place des processus d’archivage du Web de constituer quand même ce type de collections, en se reposant sur un intermédiaire technique. Bref, dès lors qu’on est capable de cibler les besoins d’un public et de s’organiser en processus, on peut constituer une collection, dont le public en question n’est donc pas forcément lointain et hypothétique : il existe un besoin et un public pour les archives du Web, tout de suite, maintenant.
En fait, dans un monde où la plupart des médias et des contenus que nous connaissons effectuent une translation vers le Web, les archives du Web permettent d’envisager l’archivage de ce qui n’est pas archivable, c’est-à-dire tout le contexte d’une activité ou d’un événement tel qu’il transparaît à travers les publications et les conversations sur le Web. Tout est là, disponible, en ligne : les logiciels, les réseaux sociaux, les données et les sources que les chercheurs utilisent, la documentation que les utilisateurs créent eux-mêmes sur leur vie et mettent en ligne. Ainsi, la meilleure façon de donner une idée dans le futur de ce que sont les mondes virtuels comme Second Life, n’est-elle pas d’archiver les blogs, les copies d’écran, les extraits vidéo… qui sont la capture, par les utilisateurs eux-mêmes, de ce qui se passe dans ces univers…
C’est ici que cela fait vraiment sens de parler « d’archivage » du Web, car on est dans des démarches documentaires qui travaillent sur la source, le contexte, le fonds, dans une logique plus proche de l’archivistique que de la bibliothéconomie.

Là où cela devient intéressant, c’est que ces archives du Web de toute nature, ces collections, elles ont une homogénéité matérielle sans précédent. A l’image du matériau qui les constituent, les collections Web sont totalement granulaires, et intégrées : elles sont à la fois constituées d’unités très petites, et à la fois globales car toutes ces unités sont compatibles entre elles. De plus, elles sont élaborées par une communauté qui a su s’organiser pour partager ses outils, ses formats, ses processus.
Ce qui fait que les archives du Web sont en fait une grande collection partagée, techniquement et structurellement homogène. C’est la politique documentaire qui fait la spécificité des différents « nœuds » de cette grande collection, qui justifie que telle bibliothèque conserve telles données, et telle autre, etc.
Qui dit homogénéité technique et collection partagée suppose une approche de la préservation numérique cohérente et globale. Les travaux effectués sur le format WARC (qui permet de stocker les archives du Web et de les exploiter) laissent entrevoir une réflexion plus que prometteuse en ce sens : en effet ce format a été réfléchi dès le départ pour intégrer les problématiques de gestion des fichiers mais aussi de leurs métadonnées, y compris les métadonnées techniques et de provenance si nécessaires à la préservation. Il gère aussi les liens entre les fichiers, les versions, les métadonnées.
Du point de vue des stratégies de préservation, il me semble que les archives du Web nous ont fait vraiment avancer en nous obligeant à reconsidérer la traditionnelle opposition binaire entre migration et émulation. Il y a quelques années, on pensait qu’on ne pourrait jamais préserver quoi que ce soit sans migrer. Puis revirement à 180° : on s’est rendu compte qu’on n’aurait pas les moyens de migrer, et tout à coup on ne jurait plus que par l’émulation. Les stratégies envisagées actuellement sont plus subtiles, elles cherchent à combiner les deux approches, à trouver un équilibre. Il n’y aura pas de traitement unique et radical pour la conservation à long terme d’un matériau aussi divers, souple et mouvant que les archives du Web.

Évidemment, nous sommes encore au début de l’histoire des archives du Web et il y a encore des problèmes, d’énormes problèmes (c’est le mot) : d’abord la masse… Des millions ou milliards de fichiers… des centaines ou milliers de Teraoctets… des dizaines ou centaines de formats… nous sommes face à une échelle qui peut donner l’impression d’un défi un peu fou, limite décourageant.
La maturité des outils et des processus laisse encore à désirer, face à des choses qu’on n’a pas encore essayé de faire et qui sont donc encore au stade de la théorie (comme migrer l’ancien format de stockage des archives Web, ARC, vers le nouveau format normalisé WARC) : il va falloir progresser à petits pas, expérimenter, commencer petit sans se laisser démonter par l’ampleur du chemin à parcourir.
Et puis il y a le Web lui-même, dans ses composantes les plus complexes : le web caché (dans des bases de données) – le Web verrouillé (derrière des mots de passe ou des DRM) – le Web exotique et bizarre (en termes de formats de fichiers, qui chaque jour naissent et meurent…) – le Web spammé et vérolé (mais c’est quand même le Web : ne faut-il pas aussi en garder la mémoire ?)

Mais malgré tout, je me disais, là-bas à San Francisco, que cette petite communauté (mais pas si petite que ça en fait) des Web-archivistes, avec son action pragmatique, efficace, une fois qu’elle aurait avancé et résolu ces problèmes, allait nous aider à absorber d’une façon plus globale les défis de gestion et de préservation des autres types de collections numériques.
A San Francisco, j’ai eu une vision : celle d’une révolution copernicienne. De la même façon que le Web est en train d’absorber l’information du monde, les archives du Web finiront par se présenter assez naturellement comme la solution technique la plus simple pour traiter, par exemple, la collecte de machins numériques de toute sorte, le versement de ces machins dans les systèmes de préservation, la migration de gros volumes de données, le pilotage des stratégies d’émulation, la gestion des moyens, des coûts et des indicateurs, etc. etc.
Enfin, parmi les trucs (le « contexte ») que l’on va pouvoir archiver sur le Web, il y aura aussi tous les facilitateurs de préservation numérique : la documentation des logiciels et des formats par exemple.
C’est un peu fou de penser qu’aujourd’hui, on a une approche complètement dissociée de nos techniques documentaires traditionnelles et de l’archivage du Web. Ainsi, toutes les travaux de constitutions des répertoires de formats (Pronom, UDFR etc.) ont mis tout ce temps à déboucher sur une initiative expérimentale de publication dans le linked data appelée P2. Dans le linked data, c’est à dire sur le Web. Pourquoi on se tuerait à inventer des processus de réplication, de partage de données, etc. alors qu’ils existent déjà, entre le Web sémantique et les archives du Web…
Pareil pour la gestion des collections d’objets numériques. On est en train de construire des usines à gaz spécifiques pour gérer les millions de fichiers qu’on produit dans le cadre de nos ambitieux programmes de numérisation. Franchement c’est du très beau travail, mais je suis sûre qu’on finira par se réveiller un matin et se rendre compte que les bibliothèques numériques ne sont qu’une collection Web parmi d’autres. Non ? Et qu’avec l’archivage du Web, on a déjà des solutions scalables, pragmatiques, efficaces.
Il reste un truc qui me manque dans cette vision, c’est de savoir comment on pourrait rapprocher tout cela de nos réflexions sur la publication des données de bibliothèques dans le Web sémantique. Tout est une question de données qui sont là présentes sur le Web et qu’on relie entre elles. Il me semble que si on arrivait à progresser vraiment sur la publication des données structurées dans le Web sémantique, en utilisant des technos vraiment Web comme le fameux HTTP-range14 (plus connu sous le nom de « Cool URIs for the semantic Web »), on arriverait aussi à faire progresser les services qu’on est capable de construire sur les archives du Web ; de faire un peu mieux que la recherche par URL et la recherche plein-texte à pertinence relative ; et peut-être même de construire des choses intéressantes en matière de collecte ciblée et de stratégies de continuité de collection et de conservation.
Mais pour l’instant tout ceci n’est encore qu’au stade de l’intuition.

Pour en savoir plus, deux articles à lire dans l’ouvrage Les collections électroniques, une nouvelle politique documentaire (sous la dir. de Pierre Carbone et François Cavalier, éditions du Cercle de la Librairie, collection Bibliothèques, 2009) :
– « Quelle politique documentaire pour l’archivage des sites internet » par Gildas Illien et Clément Oury
– et « La conservation des documents numériques » par votre serviteuse.

Modéliser le Linked Data

Quand on se lance dans la modélisation, je suppose qu’à un moment on atteint un degré de complaisance (ou peut-être de folie furieuse) qui amène à tout théoriser, et pour que le modèle tienne la route, on finit par être obligé de créer des modèles qui expliquent comment on modélise les modèles.

Ça va vous paraître fou, mais en fait, c’est utile.

En juin j’ai visiblement raté une bonne occasion d’aller à Madrid pour la conférence Linked data on the Web 2009.
A noter dans les papiers de cette conférence, deux propositions intéressantes pour aider à modéliser le Linked Data.

La première, c’est IRW : Information Resources on the Web Ontology, par Harry Halpin et Valentina Presucci.
Pour les puristes, l’ontologie elle-même est ici.
Cette ontologie s’attaque à des notions sur lesquelles on peut gloser pendant des jours : les ressources informationnelles et non informationnelles, les représentations, les réalisations Web d’une ressource, et leurs URI respectives. La seule question qu’elle ne pose pas (probablement par pudeur ;-) c’est… la notion de document.

L’autre c’est un vocabulaire pour gérer la provenance dans le Linked Data, par Olaf Hartig de l’Université Humboldt de Berlin.
La spécification est ici pour les puristes, et pour ceux qui aiment plutôt les petits dessins, le powerpoint est .
Il s’agit de contribuer à l’établissement de la confiance dans le Linked Data en modélisant les informations de provenance qu’on peut associer à un ensemble de données.

Il y a plein d’autres trucs intéressants dans cette conférence. C’est juste que j’ai pas encore eu le temps de regarder.