Vacances d’été en RDA

Ah ah, ils sont impayables nos amis du JSC (Joint steering Committee – sous entendu : for the development of RDA).

Souvenez-vous : la dernière fois qu’il a fallu relire les RDA (resource description and access), ce nouveau code de catalogage, c’était presque Noël.

Maintenant qu’il paraît en version définitive, c’est juste avant les deux mois d’été. Et devinez jusqu’à quand vous avez accès gratuitement au RDA toolkit, ce site web qui deviendra le livre (enfin, le site Web) de chevet des bibliothécaires de demain ?

Jusqu’au 31 août.
Alors, pas de risque que les bibliothécaires s’ennuient pendant les vacances.
Et vive l’amitié France RDA !

Un groupe « Bibliothèques et Web de données » au sein du W3C

Le W3C vient d’annoncer le lancement d’un groupe d’incubation « Bibliothèques et Web de données » (Library linked data).
Pour moi, c’est l’aboutissement de plusieurs mois de réflexions, prises de contact, argumentation, maturation, explications, bref pas mal de travail pour aboutir à ce résultat, même si ce n’est qu’un début ! Je suis donc extrêmement heureuse de pouvoir vous en dire plus sur cette initiative.

Pourquoi le W3C ?
Le W3C est le principal organisme de normalisation du Web.
Traditionnellement, les bibliothèques font un important travail de normalisation, soit au sein d’organismes propres à leur communauté (IFLA) soit au sein d’organismes de normalisation traditionnels (ISO, AFNOR). La normalisation est d’ailleurs perçue comme un réel atout de notre communauté.
Aujourd’hui, la tendance est à la recherche de convergence, c’est-à-dire à ne plus faire des normes spécifiques à une communauté, mais des normes valables dans un environnement plus global. S’agissant de technologies de l’information, cet environnement global s’appelle le Web. Il est donc vital que les bibliothèques, aujourd’hui presque totalement absentes de la normalisation au W3C, se mobilisent et se coordonnent pour y participer.
La participation à tous les groupes de normalisation qui travaillent sur des standards potentiellement applicables en bibliothèque est inenvisageable. Ces groupes sont trop nombreux, leur propos est souvent très technique et requerrait de mobiliser fortement les informaticiens des bibliothèques, ce qui est impossible.
L’autre solution était donc de créer une structure, au sein du W3C, correspondant au domaine des bibliothèques, qui leur permettrait de s’exprimer en tant que communauté sur leurs besoins et leurs usages des normes du W3C. C’est le rôle de ce groupe.

Pourquoi un « groupe d’incubation » ?
Un « incubator group » (qui s’abrège en « XG ») a vocation à faire des propositions au W3C sur de nouveaux travaux à démarrer. C’est donc le préalable à toute action plus durable qui pourrait être entreprise au sein du W3C.
Autre avantage, c’est une structure légère à créer : il suffit que 3 organisations membres le soutiennent pour le lancer.
Le Library Linked Data XG va donc travailler pendant un an (jusqu’à fin mai 2011) pour élaborer un rapport dans lequel on trouvera des préconisations pour d’autres actions à conduire sur le plus long terme.

Pourquoi les bibliothèques ?
Du côté des bibliothèques c’était vraiment le bon moment : les formats de demain (RDA notamment) et les projets internationaux majeurs (VIAF par exemple) s’appuient fortement sur les technologies du Web sémantique. Ces actions sont encore expérimentales, jeunes, il est donc temps de les utiliser comme un tremplin pour préparer l’environnement normatif de demain.
Le W3C a été sensible à cette tendance de convergence recherchée par les bibliothèques, et l’intérêt d’un tel groupe n’a fait aucun doute de leur côté.
Cela ne veut pas dire que les autres acteurs « proches », c’est-à-dire principalement du monde patrimonial (archives, musées, etc.) ou de l’édition (éditeurs, libraires…) sont exclus de notre réflexion, bien au contraire. Simplement il fallait se fixer un objectif raisonnable et atteignable, d’où le choix des bibliothèques comme point de départ. Le rapport du groupe devra contenir des recommandations sur les modalités de rapprochement avec ces autres communautés.

Pourquoi le Web de données (Linked Data) ?
Nous avons hésité à focaliser le groupe sur le Web sémantique, mais nous avons finalement préféré le Web de données pour deux raisons.
Déjà, le Web sémantique est un terme dont l’ambiguïté pose problème, même dans les communautés supposées connaître ces technologies. C’est un fait qui est même reconnu au sein du W3C.
Mais surtout, le choix de faire référence au Web de données implique que la problématique du groupe sera l’interopérabilité globale des données de bibliothèques sur le Web, et pas seulement le Web sémantique. Le Web de données inclut la réflexion sur des standards du Web qui ne font pas uniquement partie de la sphère du Web sémantique (comme HTTP ou les URI).
Tout ceci est expliqué dans la charte du groupe.

Qui fera partie de ce groupe ?
Ce groupe a été initié par des acteurs majeurs du monde des bibliothèques, comme la Library of Congress, OCLC, et Talis, et du domaine du Web sémantique comme le DERI, l’Université libre d’Amsterdam, l’Université Aalto à Helsinki, etc.
Tous ces acteurs, ainsi que tous les membres du W3C, peuvent de droit nommer des représentants dans le groupe. De plus, les présidents du groupe peuvent faire appel à des experts invités, même si ceux-ci n’appartiennent pas à une organisation membre du W3C. Le W3C devrait publier bientôt un appel à contributions pour enclencher ce processus de nominations.
Le groupe a trois co-présidents, Tom Baker, Antoine Isaac et moi-même. Nous espérons être rejoints par une vingtaine de participants actifs (qui assisteront aux téléconférences hebdomadaires et rédigeront les documents). Mais la communauté qui va se créer autour du groupe sera beaucoup plus importante : tout le monde pourra suivre la progression de ses travaux, via le wiki et la liste de diffusion publique.

Et maintenant ?
Et maintenant, au travail. Nous avons un an pour faire un bilan de l’état des technologies du Web de données appliquées dans le domaine des bibliothèques, identifier des acquis et des pistes de travail, mettre les acteurs en présence, construire une vision qui fasse l’objet d’un consensus. Je crois que cette année va passer très vite. Si mon blog reste un peu trop silencieux, rendez-vous sur le site du W3C…

Le 2e catalogue dans le Linked Data

Il y a un peu plus d’un an, je vous parlais de Libris, le premier catalogue de bibliothèque à être exposé intégralement dans le Linked data.

Aujourd’hui, il est rejoint par le catalogue de la Bibliothèque nationale hongroise (National Széchényi Library), d’après ce message sur la liste LoD.
Alors vu que ce n’est pas 100% intuitif, voici le « truc » pour voir le RDF : il faut ajouter « data » dans l’URL avant l’identifiant de la ressource (« data »… c’est bien trouvé ça, non ;-)
Dans le RDF on peut voir qu’ils utilisent DC pour les données bibliographiques, FOAF pour les personnes, et SKOS pour les sujets. En outre, certaines de leurs autorités personnes sont alignées avec DBpedia.

La 3e, ça me semble être bien parti pour être la bibliothèque nationale allemande (DNB), si on en croit ce document.. Mais on va attendre sagement qu’ils aient fini de travailler dessus avant d’en dire plus !

A partir de 4, on ne décerne plus de médaille, il fallait se réveiller avant. Non pas qu’on dort, hein, c’est juste que ça prend du temps ;-)
Ceux qui veulent en savoir plus sur pourquoi et comment on met les catalogues de bibliothèque dans le Web de données peuvent regarder la vidéo d’1h30 de mon 5 à 7 de l’ADBS sur ce sujet.

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.

Le problème avec le catalogue…

Je relisais ce matin le billet de B. Calenge « Pourquoi les catalogues ne peuvent pas être 2.0 » et je me disais que la vision qu’il donne du catalogue est tout à fait dans l’air du temps, c’est-à-dire, dans un mouvement de désaffection à l’égard de l’outil qui a incarné depuis tant d’années (depuis toujours ?) le cœur du métier de bibliothécaire.

En fait, le problème avec le catalogue, c’est justement sa nature multiforme et la difficulté de définir précisément à quoi il sert. Les bibliothécaires ont longtemps projeté leur propre vision du catalogue sur les usagers, et c’est ce qu’ils font encore quand ils essayent de construire le « catalogue 2.0 ». Mais en même temps, le catalogue est leur outil de travail, un outil de « gestion », principalement dédié à la « localisation » des ouvrages d’une bibliothèque donnée, un outil « local ».

Quand B. C. parle de « laisser disséminer les données bibliographiques » il se place dans une toute autre vision ; il n’est plus question « du catalogue » mais « des données ». C’est autre choses, on sort de cette vision centrée autour d’un outil.

Éviter la redondance (donc que plein de catalogueurs ressaisissent plein de fois la même information), permettre de lier les données du catalogue, permettre de les réutiliser, ce sont là les principaux défis du catalogue aujourd’hui.
Un pléthore de rapports ont été publiés récemment sur ce sujet ou des sujets connexes :
réflexions du NISO sur la chaîne de production des métadonnées du livre
réflexions de la Library of Congress sur le « marché » des notices MARC
– réflexion d’OCLC sur l’utilisation des champs MARC, dans une perspective de rationalisation du catalogage pour atteindre différents objectifs, dont l’utilisation par des machines
– etc.

Ce qui tend à en faire non plus un outil destiné à des humains, mais un ensemble de données réutilisables par des machines…

… donc nous pousse vers le Web sémantique. Dans ce billet, Karen Coyle explique bien quelles sont les limites des formats MARC quand on essaye de rendre les données des catalogues plus utilisables dans le Web. Il paraît clair qu’il faudra aller au-delà des formats MARC pour y arriver, et vers le Web sémantique… mais comment s’en sortir avec toutes ces données existantes en MARC qui sont dans nos catalogues ? qui pourra piloter cet énorme changement ? Plus grave, les acteurs majeurs ont-ils vraiment intérêt à y aller, ou freinent-ils des 4 fers ?

J’y vois une autre difficulté : cette évolution ne fera qu’amplifier la tendance à la désaffection des bibliothécaires pour ces sujets, de la formation initiale (apprendre à cataloguer, c’est vraiment trop has been) aux enjeux stratégiques et budgétaires des bibliothèques (investir dans le catalogue, c’est vraiment trop has been).
Qu’on ne se méprenne pas, je trouve cela normal, et même justifié, que la plupart des collègues se recentrent sur les questions de publics, de médiation, etc. plutôt que sur les questions rébarbatives de métadonnées.
Mais ces métadonnées, on en aura besoin. Elle constituent la colonne vertébrale de tout le reste. Pas de bibliothèques numériques, de blogs, de machins 2.0 sans une solide base de métadonnées sur laquelle construire tout cela.
Les bibliothécaires qui constitueront ce réservoir de métadonnées seront moins nombreux mais plus experts ; leurs compétences seront d’autant plus précieuses, car c’est un sujet complexe, beaucoup plus complexe que ce qu’on pourrait imaginer.
Il ne faut pas abandonner les métadonnées.

Les RDA en RDF

Dans le dernier Dlib, on peut lire un article très intéressant de Karen Coyle, Diane Hillmann, Jon Phipps et Gordon Dunsire sur l’expression de RDA en RDF. Il rend compte d’un travail effectué dans le cadre du groupe de travail DCMI/RDA qui comme son nom l’indique travaille sur le rapprochement entre Dublin Core et RDA.

Pour mémoire, les RDA (Resource Description and Access) sont un ensemble de nouvelles règles de catalogage en cours d’élaboration dans la communauté anglo-saxonne, dont le principal caractère novateur est de prendre acte de la modélisation définie par les FRBR.

En fait ce qu’ils présentent dans l’article c’est un premier travail pour exprimer les RDA sous la forme d’une ontologie en RDF, qui est disponible en ligne dans le répertoire de métadonnées de la NSDL.

L’article rappelle qu’il s’agit d’un premier travail, qui arrive en avance de phase par rapport à la version définitive de RDA (prévue en juin). Pourtant, ils ont apparemment couvert sinon tout, du moins une grande partie des concepts et des éléments de description prévus.
Ce qui leur a posé plusieurs problèmes…

Le premier étant l’alignement avec les FRBR. Ils ont redéclaré des principales classes des FRBRer en attendant qu’une ontologie digne de ce nom soit publiée par l’IFLA. Mais les FRBRer n’étant pas tout à fait prévus pour cela, ils ont rencontré différents problèmes :
– ils ont dû utiliser une classe des FRBRoo, la classe Agent, sans quoi ça ne tenait pas la route (!)
– pour pas mal d’éléments RDA, le rattachement aux entités FRBR peut être discuté et on ne peut pas rattacher de façon univoque une propriété des RDA à une seule entité FRBR. Pour pallier ce problème ils ont déclaré les propriétés concernées deux fois, une fois de façon générique, puis une deuxième fois sous la forme d’une sous-propriété rattachée à l’entité FRBR choisie.

Le passage en RDF a l’avantage de mettre un certain nombre de relations en évidence de façon explicite.
Mais il implique aussi des contraintes : notamment le fait de mettre les propriétés sur un seul niveau (et pas imbriqué comme en MARC ou en XML).
Le traitement de certains trucs très spécifiques aux pratiques des bibliothèques, comme les mentions déclaratives (la mention d’édition par exemple, sous la forme « Éditeur : lieu, date ») est d’une complexité abominable dès lors qu’on veut les décomposer en plusieurs sous-parties dont certaines peuvent être des ressources (identifiées par des URI, pour les lieux par exemple) et pas seulement des littéraux (des chaînes de caractères).

L’article contient aussi un argumentaire assez intéressant sur l’utilisation d’un « metadata registry » pour déclarer les entités de RDA.
Le répertoire de métadonnées de la NSDL leur permet ainsi de diffuser à la fois une version lisible pour les humains (en HTML, sous forme de tableaux) et une version pour les machines (en RDF avec des URI). Il permet aussi de gérer le versionning et des mécanismes d’alertes.

L’article conclut enfin en soulignant les principaux avantages de cette démarche visant à modéliser les données des catalogues de bibliothèque pour le Web sémantique : il s’agit de permettre à d’autres acteurs d’appréhender ces donnés de façon plus simple qu’avec les formats MARC (cf. les propos de Google à l’ALA forum) mais aussi de nous aider à tirer le bénéfice de données créées par d’autres, comme DBPedia. Il se termine enfin avec une ouverture aux autres communautés proches des bibliothèques : institutions patrimoniales, éditeurs, etc.

Voilà pour l’article. Du côté du modèle lui-même, on va donc trouver trois choses :
– les classes correspondant aux entités FRBRer (+FRBRoo:Agent)
– les propriétés correspondants aux éléments des RDA
– les concepts conrrespondant aux listes de vocabulaires, à utiliser avec les propriétés.

Après une première et très courte analyse, ce RDA en RDF me semble une initiative assez prometteuse avec laquelle on va pouvoir commencer à s’amuser un peu… Même s’il y a sans doute encore des évolutions à prévoir.
Par exemple, on peut s’étonner de certains choix de modélisation comme le fait d’utiliser systématiquement SKOS:concept pour les vocabulaires. Autre truc bizarre, les vocabulaires sont faits pour être utilisés avec les propriétés mais l’ontologie ne le précise pas formellement ; il faut donc se débrouiller tout seul pour comprendre, par exemple, que la liste de concepts « RDA carrier type » doit être utilisée avec la propriété RDA:carrierType (là ça peut paraître évident, mais ce n’est pas toujours aussi simple malheureusement).

Bref, l’ensemble donne parfois l’impression d’avoir été conçu davantage comme un modèle de données traditionnel que comme une ontologie pour le Web sémantique, et qu’il n’en utilise pas toute l’ingénierie, ou pas correctement.
J’espère que les gens qui en savent plus que moi sur la modélisation d’ontologie n’hésiteront pas à s’exprimer sur le sujet ;-)

Message de service

En raison de problèmes de spam, désormais les commentaires sur Figoblog sont modérés a priori.

Bon, vu la foule de gens qui se pressent pour commenter, je sens que ça ne va pas vous gêner énormément.
Surtout vu la foule de billets que j’écris en ce moment.

Mais au cas où vous mettriez un « vrai » commentaire, ne vous inquiétez pas de devoir attendre un ou deux jours avant de le voir apparaître.

Histoire de ne pas avoir fait le billet rien que pour ça, je vous offre en prime une photo d’un bouquin que j’ai récemment emprunté à la bibliothèque :

Un livre qui vous apprend que manger une figue n’est jamais un acte totalement anodin.

VMF : et que les mappings soient

Le 9 novembre dernier, il y a presque une éternité, j’étais à Londres pour assister à la présentation des résultats du projet VMF : Vocabulary Mapping Framework.
Ils ont attendu presque aussi longtemps que moi pour mettre leurs résultats en ligne, ce qui me donne l’occasion de revenir un peu sur ce projet et ce qui en a résulté dans la première phase, qui vient donc de se terminer.

D’abord, rappelons les objectifs du projet : annoncé en juin 2009, le projet VMF se donnait pour objectif de réaliser un mapping de tous les formats de métadonnées majeurs, au moyen d’une ontologie en OWL.
Vous vous souvenez peut-être que ce projet m’avait à l’époque laissée un peu songeuse
Oui, c’est vrai, cela me semblait un objectif ambitieux (trop) et je ne voyais pas très bien où ils voulaient en venir, surtout en si peu de temps. Mais maintenant les choses me semblent plus claires et je pense arriver à comprendre ce que ce projet peut apporter. Ce n’est pas un mapping universel de tous les formats de métadonnées, mais plutôt un outil d’aide à la conception de mappings entre des formats de métadonnées deux à deux.

Dans les grandes lignes, le principe est le suivant :
– imaginons qu’on veuille faire correspondre les formats W, X, Y et Z (soit, les mappings W–X, W–Y, W–Z, X–Y, X–Z et Y–Z)
– on crée une ontologie générique, qui s’appelle la Matrice (the Matrix, fallait l’inventer ;-)
– on crée ensuite le mapping de chaque format vers la Matrice (W–Matrice, X–Matrice, Y–Matrice, Z–Matrice)
– on requête la Matrice pour qu’elle propose des équivalences entre deux formats (W–Matrice–X, W–Matrice–Y, etc.)
– on a ainsi obtenu les correspondances entre les formats souhaités en faisant 4 mappings au lieu de 6.
Ceux qui savent très bien compter auront compris que l’opération n’a d’intérêt qu’à partir du moment où on cherche à faire se correspondre plus de 3 formats, mais plus on a de formats, plus le bénéfice est important : dans l’environnement actuel, cela devrait donc être facile de rentabiliser l’opération ;-)

Pour ce faire, VMF s’appuie sur le modèle INDECS pour créer une ontologie qui est suffisamment complexe pour exprimer toutes les notions ou concepts existant dans les différents formats de métadonnées. C’est cette ontologie, exprimée en RDF, qui constitue la Matrice. Vous pouvez la télécharger en RDF sur le site du projet, par exemple pour regarder ce que cela donne dans Protégé.

L’idée est que les différents formats peuvent exprimer des notions proches, mais pas tout à fait équivalentes, et c’est ce « pas tout à fait » qui est un cauchemar pour le producteur de mappings. Un concept peut être exprimé de façon fine dans un format et détaillée dans un autre, il peut être exprimé avec une orientation différente (par ex. « est l’auteur de » et « a pour auteur » : c’est « presque » la même chose, mais « pas tout à fait ») etc. Si on veut concevoir un générateur de mappings, il faut être capable d’embrasser toutes ces nuances, pour les exprimer et clarifier les relations entre les formats.
C’est ce que fait la Matrice, au moyen d’un système de « famille de concepts ». Ce modèle est orienté événement : quand un événement apparaît dans un format de métadonnées (par exemple, l’événement correspondant à une traduction) on va créer dans la Matrice une famille de concepts qui regroupe :
– les acteurs et les objets de l’événement,
– toutes les relations possibles entre ces acteurs et objets.
Ce qui donnera par exemple :

(le traducteur) traduit (la source)
(la source) est traduite par (le traducteur)
(le traducteur) crée (la traduction)
(la traduction) est créée par (le traducteur)
(la source) a pour traduction (la traduction)
(la traduction) est une traduction de (la source)
etc.

Ensuite, les différentes familles de concepts sont articulées entre elles (par exemple, « traduction des sous-titres » serait un concept spécifique rattaché au concept plus générique de « traduction »).
Enfin, on utilisera ces différentes familles de concepts pour relier les différents formats à la Matrice, en respectant toutes les nuances et les logiques intrinsèques de chacun d’entre eux.
Pour l’instant, les gens de VMF ont travaillé à l’alignement des formats suivants avec la matrice : CIDOC CRM, DCMI, DDEX, FRAD, FRBR, IDF, LOM (IEEE), MARC21, MPEG21 RDD, ONIX et RDA, ainsi que le « RDA-ONIX Framework », ce dernier étant le point de départ du projet.

Il en résulte que la Matrice pourra rarement proposer une équivalence simple entre deux éléments de formats différents. Elle proposera plutôt un « chemin » entre ces différents éléments, c’est-à-dire qu’elle parcourra de lien en lien le graphe RDF, pour trouver le (ou les) chemin(s) le plus court d’un concept à un autre. Pour cela, il est prévu de la requêter en SPARQL (mais pour l’instant, il n’y a pas de SPARQL endpoint sur le site du projet).

Je dirais donc que VMF a produit plutôt un générateur de mappings qu’un mapping universel, ce qui semble déjà un objectif plus raisonnable… En fait, du point de vue de la modélisation, l’approche est très séduisante.
C’est une approche qui cherche à être générique sans pour autant réduire les formats à un plus petit dénominateur commun, ce qui est louable. Elle prend en compte les spécificités et la complexité de chaque format.
Pour autant, ce qui n’est pas exprimé dans la Matrice, c’est la logique intrinsèque des jeux de données eux-mêmes, qui peut varier d’une application du format à une autre. En cela, c’est probablement utile d’avoir un générateur de mapping qui propose plusieurs options pour chaque élément, et qui permette ensuite au producteur du mapping de choisir ce qui lui semble le plus pertinent par rapport à ses propres données.

Les étapes suivantes du projet, telles qu’elles ont été présentées à la journée du 9 novembre, incluent :
– la validation des mappings déjà effectués par les autorités compétentes pour chacun des formats (les mappings sont pour l’instant « expérimentaux »)
– l’ajout de nouveaux mappings
– la recherche d’un modèle économique qui permette au projet de se développer sur le long terme.

Si vous voulez plus de détails sur comment fonctionne la Matrice et la création des mappings, un seul document, celui-là (PDF, 27 pages).
Je vous recommande également le billet de Sylvie Dalbin, qui est me semble-t-il assez complémentaire avec le mien. Avec ça, vous avez tous les éléments !

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.