Oubliez tout ce que j’ai pu écrire sur la conservation du document numérique depuis 6 mois et lisez ça. C’est complet, c’est bien propre et en plus c’est validé a priori (ça prend juste un peu plus de temps, quoi).

Il y a une nouvelle liste de discussion gérée par le JISC sur le thème des entrepôts de données numériques.

Il y a un nouveau site propulsé par la Bibliothèque nationale des Pays-Bas (KB) pour réfléchir sur l’accès à très long terme aux documents scientifiques sous forme électronique.

Il y a Lorcan Dempsey qui partage ses réflexions sur le problème de la conservation pour les bibliothèques numériques.

C’est intéressant… mais je suis un peu occupée par autre chose.

J’ai déjà eu l’occasion de vous parler des répertoires de formats et de leur utilité pour la préservation du document numérique ici ou là. Comme j’ai eu la chance depuis de me pencher de plus près sur ce problème, je vous livre quelques idées et liens utiles.

Alors d’abord, pourquoi un répertoire de formats ? La question peut être abordée de plusieurs points de vue :

• la sélection : j’ai un contenu, dans quel format le représenter ?
• l’identification : j’ai un objet numérique, dans quel format est-il ?
• la validation : j’ai un objet numérique censé être au format X, est-ce exact ?
• la caractérisation : j’ai un objet au format X, quelles sont ses propriétés ?
• l’évaluation : J’ai un objet au format X avec des propriétés Y, quel est le risque d’obsolescence ?
• le traitement : j’ai un objet au format X avec des propriétés Y, comment réaliser l’opération Z sur ce format ?

Répondre à toutes ces questions revient à parcourir les différentes étapes qui vont nous conduire de la création du document numérique à sa préservation sur le long terme, en passant par l’étape essentielle qu’est l’injection dans une archive OAIS. Parce que dans cette archive on a besoin de savoir la nature de ce qui est conservé, et parce qu’on a besoin de créer des programmes capables d’émuler ou de migrer ce contenu, avoir un référentiel qui contient les moyens d’identifier ces formats et leurs spécifications est indispensable.

Cette prise de conscience n’est pas nouvelle dans le monde du numérique, et il existe aujourd’hui différentes initiatives qui visent au moins en partie à atteindre cet objectif.

D’abord il y a des choses qui existent depuis un bout de temps et n’ont pas un objectif de conservation : par exemple le répertoire des MIME TYPE de l’IANA, celui du département de la justice américain (à vendre sur CD-Rom), ou le Wotsit des programmeurs. Aucun de ces répertoires ne répond au besoin spécifique de conservation, parce qu’il manque des données essentielles et notamment les signatures, internes ou externes, qui permettent d’identifier (automatiquement de préférence) le format auquel on a affaire.

A l’opposé, on trouve des initiatives dont l’objectif est exclusivement l’évaluation en vue de la conservation, et qui mettent donc l’accent sur la méthodologie d’évaluation des risques d’obsolescence des formats. Parmi ceux-ci, je citerai deux initiatives : l’Inform Metodology d’OCLC et le travail de la Library of Congress sur les formats.
La première est au sens strict une méthologie de gestion des risques. Je pense qu’elle a plus ou moins été appliquée par la NLA qui n’a hélas pas encore publié les résultats de son travail.
La seconde est une méthodologie de projet de numérisation, qui inclut le problème de la sélection d’un format quand on numérise. L’approche est assez complète mais il manque le principe de la validation automatique du format, c’est à dire l’utilisation de logiciels qui vérifient la conformité du format et de ses propriétés par rapport aux attentes de l’archive. C’est donc une approche bibliothéconomique assez classique. Par contre, la méthode d’évaluation en vue de la préservation est intéressante.

Et puis pour finir je parlerai des répertoires de formats qui ont pour but l’identification et la validation des formats, tout en étant neutres et objectifs (pas d’évaluation donc), ce qui augmente les chances de recevoir des descriptions de formats propriétaires de la part de leurs producteurs. L’un d’eux, dont j’ai déjà parlé, est Pronom avec son outil DROID. En apparence, on a là celui qui va le plus loin dans l’accomplissement de l’objectif cité, puisqu’il est le seul à mettre au point un répertoire de formats avec l’outil qui va avec pour les identifier automatiquement. Dans les faits, il est encore assez peu rempli.

Le dernier dont je parlerai ici, GDFR , mérite un coup de chapeau car il vient d’obtenir 2 ans de financement de la part de la Mellon foundation. Propulsé par les gens de la bibliothèque universitaire d’Harvard, GDFR a pour objectif de constituer un répertoire de formats neutre, global, international, complet, etc. Il s’est doté d’un modèle de données qu’on peut voir à l’oeuvre dans l’expérimentation FRED, c’est -à-dire qu’il s’est doté de règles qui définissent le contenu de la description d’un format, incluant un identifiant pérenne ce qui est très utile pour toutes sortes d’applications. Pas loin de GDFR, on trouve aussi un outil de validation automatisée : JHOVE qui contrairement à DROID, ne fonctionne pas en attanquant directement un répertoire de formats, mais grâce à des plug-ins qui contiennent les infos nécessaires. En cela JHOVE est une sorte d’outil inachevé, et on peut espérer qu’avec le développement de GDFR il deviendra plus complet. Lire cet article intéressant sur GDFR.

Monsieur Stephen Abrams, de Harvard, est personnellement une mine d’informations que je remercie pour son défrichage intense du sujet (en espérant qu’il pardonnera mes récupérations parfois littérales de ses idées). Il était à Gottingen pour iPRES et vous pouvez lire, écouter et même regarder son intervention ici. Merci aussi à Julien dont j’ai récupéré l’historique.

Lien vers la version officielle.

Je viens de découvrir, à travers Lorcan Dempsey et Peter Suber, un système (un software) d’archivage de documents numériques qui s’appelle aDORe et qui a l’air assez intéressant.

Le système repose sur l’archivage de paquets, en appréhendant ces paquets non pas de façon documentaire (un objet = un document) mais de façon pragmatique comme des trains de bits continus qu’on va ranger dans des boîtes. Cette approche est particulièrement utile quand on gère une archive qui reçoit des gros batch de 1.000 à 100.000 documents… Chaque batch est donc considéré comme un paquet. aDORe dissocie pour chacun de ces gros paquets les métadonnées, qui vont être enregistrées en continu sur une « cassette XML » nommée XMLtape, et les documents eux-mêmes qui sont encapsulés dans des fichiers ARC (le format de fichier de l’archivage du Web).

On peut stocker n’importe quel format de fichier dans un ARC, les différents fichiers étant séparés les uns des autres par des métadonnées textuelles et identifiés par une URI : c’est ce qu’on appelle les « ARC records ». ARC étant un format conçu pour contenir plein de fichiers dans une boîte, il atomise le problème de la granularité en le renvoyant aux métadonnées associées.

Les métadonnées associées sont enregistrées ici dans le format qui nous fait le plus plaisir pour gérer des objets complexes (METS, MPEG21 ou autre) et stockées dans la fameuse XMLtape, qui est aussi une sorte de capsule. Celle-ci peut contenir jusqu’à 1.000.000 de descriptions de documents.
Grâce à l’utilisation des formats de gestion des objets complexes, on a la possibilité d’utiliser ces métadonnées pour gérer la structure et la granularité des objets : ces métadonnées vont faire référence aux identifiants (URI) présents dans les fichiers ARC pour organiser les fichiers suivant leur structure logique.

A l’intérieur des ARC, on a donc des « ARC records », c’est à dire des enregistrements qui correspondent à un fichier numérique (au niveau de granularité le plus fin) et qui sont identifiés par une URI. Dans les métadonnées stockées sur la cassette XML, on se « raccroche » à ces URI grâce à un lien encodé suivant le protocole OpenURL.
Ensuite, on va créer pour chaque ARC un résolveur OpenURL, et pour chaque XMLtape un entrepôt OAI. Donc, on obtient finalement un stock de métadonnées en XML accédées via l’OAI, et un stock d’objets numériques accédés via un résolveur OpenURL.

Pour récapituler en s’appuyant sur le modèle OAIS :
La première opération compliquée est la constitution du SIP. On constitue les XMLtape et les ARC, mais avec le pré-requis que l’on dispose de métadonnées au format METS ou MPEG21, et que celles-ci contiennent des liens au format OpenURL (pas insurmontable, mais il faut y penser avant). A tous les niveaux, il faut aussi gérer l’attribution de plein d’identifiants uniques et pérennes dont on aura besoin pour l’accès.
L’avantage, c’est qu’une fois qu’on a fait cette opération, on ne touche plus à rien : le SIP, l’AIP et le DIP sont physiquement confondus. Cela suppose qu’on n’a pas d’opération à faire sur ces paquets (une migration de format par exemple) donc qu’on maîtrise bien le contenu, ou sinon il faut les re-verser intégralement (avec de nouvelles métadonnées, et de nouveaux identifiants).
En fait, l’AIP est un couple XMLtape/fichiers ARC qui lui correspondent, et le DIP est un couple métadonnées MPEG21 ou METS/objet numérique.
On dispose de tous les éléments qui permettent d’accéder au DIP, quelle que soit la granularité qui nous intéresse, ce qui semble être le principal atout de ce système. On peut lui brancher de façon modulaire n’importe quel système d’indexation et de visualisation, et en changer si nécessaire.

A première vue, je dirais que c’est un système qui doit bien marcher si vous archivez des choses qui sont déjà dans un format pérenne, qui ont une structure simple et identifiée, et qui ont déjà une URI ou un identifiant à chaque niveau de granularité. Les concepteurs mettent l’accent sur le côté fiable, dans une optique de préservation, du couple ARC/XMLtape, qui évite d’avoir à toucher aux fichiers : c’est très bien, sauf si on a besoin de toucher aux fichiers pour les conserver… une belle enveloppe ça ne sert à rien, si elle contient des trucs affreux.
Enfin, la flexibilité des conditions d’accès est quand même très séduisante.
Finalement, tout cela ressemble beaucoup aux infrastructures qu’on connaît pour l’archivage du Web, sauf qu’on y rajoute une couche de métadonnées de structure agrémentée d’OpenURL, pour en faire une architecture plus proche des besoins des bibliothèques numériques.

ADORe est un logiciel open source du Los Alamos National Laboratory.

NB : il est impossible d’y comprendre quoi que ce soit sans lire cet article. J’ai fait mon possible pour simplifier et synthétiser mais ce n’était pas très évident. Désolée.