Les petites cases

Quand un éditeur s'intéresse à la conservation du document numérique...

Dans le cadre de l'édition électronique sur le Web, le support de l'ouvrage n'est pas multiplié par autant d'exemplaires, il n'existe qu'à un seul endroit sur un serveur. Oui, on parle de dématérialisation, mais elle a ses limites et il faut bien qu'à un moment donné, les informations soient stockées quelque part. C'est donc chez l'éditeur que se situe le support unique des informations et c'est donc sur lui que se reporte la responsabilité de garantir l'accès à long terme à ces données. Il me faut donc réfléchir à la question de la préservation du document numérique. L'idée m'amusait, étant éditeur à l'École des chartes, qui forme les futurs conservateurs et côtoyant très régulièrement une spécialiste de cette question ;-). Mais j'ai commencé à désenchanter quand j'ai pris conscience de la difficulté de la chose. Et plus je relisais les billets de Manue, plus les problématiques et les difficultés devenaient limpides.

Heureusement, des gentils conservateurs américains ont réfléchi à la question et ont inventé LOCKKS : Lots of Copies Keep Stuff Safe. Comme il est expliqué dans la page dédiée aux éditeurs, je ne suis pas seul et, surtout, c'est le rôle des bibliothèques de faire ce travail. Super !! Je vais pouvoir me décharger sur une bibliothèque sympa qui va accueillir mes données. Que nenni mon ami. Il faut plusieurs bibliothèques pour que le système devienne un tant soit peu crédible. En effet, LOCKKS est basé sur l'idée que plus on multiplie les points de stockage, moins on a de chances d'avoir des problèmes de conservation. Bon, donc, il faut que je trouve plusieurs bibliothèques sympas qui implémentent LOCKKS et accueillent mes données. Voilà un premier problème, même s'il n'est pas insurmontable (je suis sûr qu'il y a pleins de bibliothécaires gentils qui travaillent dans des bibliothèques sympas dans la salle). Je continue mon tour du propriétaire et là, stupeur, à aucun moment ou alors c'est une faute d'inattention, il n'est question de migration. Or, c'est une question fondamentale. Si on reprend le modèle OAIS, une archive doit être en mesure de faire migrer les données de façon transparente et surtout très simplement (c'est la partie AIP dans le modèle OAIS) !! J'ai pas l'impression que LOCKKS résoud ce problème. Donc, ce n'est pas la solution miracle, le couteau suisse qui m'enlève mon épine du pied.

Je me rabats donc sur ADORE dont Manue avait parlé il y a quelques temps. Je ne vous refais pas le détail de ce système qui est assez bien fait et dont une des problématiques de base : « comment s'abstraire d'un système de fichiers qui est lui-même soumis à l'évolution de l'informatique ? » est assez originale et donne à réfléchir. Donc, me voilà à regarder en détail ADORE. J'avais eu une bonne impression à la lecture du billet de Manue (et aux compléments d'information et d'explications que j'avais eu en live, oui, je sais, je suis un privilégié :-) ). Mon impression se confirme et malgré la complexité d'implémentation et le côté bricolage, ADORE a l'air de répondre à mes besoins. Mais, au moment où je commence à regarder en profondeur le système, je m'aperçois qu'il y a des impératifs de base :

  1. Il faut décrire les données dans un fichier utilisant un format spécialisé dans la gestion des « objets complexes » (METS, MPEG21 ou XFDU)

  2. Il faut que tous les fichiers soient accessibles et donc identifiables avec un identifiant pérenne et unique.

Ah ! tiens, les identifiants pérennes font leur apparition. On a donc besoin d'un système d'identifiants pérennes et c'est un préalable. Après mûres réflexions qui feront certainement l'objet d'un prochain billet, je comprends l'insistance de Manue sur cette question et toutes les briques se mettent dans le bon sens. Cette question réglée ou à peu près, la première question reste en suspens. Je dois décrire tous les fichiers qui compose chacun de mes ouvrages électroniques. Ouf ! Il y a METS dans la liste et ça tombe bien, je l'ai déjà utilisé pour un projet de numérisation, j'ai donc une petite expérience. En plus, il s'avère que METS me rend d'autres services : métadonnées descriptives de l'ouvrage, carte de structure, entre autres. Bref, cela correspond parfaitement, en plus, et même si je peste contre METS parfois, je dois gérer des fichiers et non des ressources dans ce cas précis, il n'est donc pas ici question de RDF.

Je reprends la documentation de METS, mon éditeur XML préféré et je commence à encoder le fichier d'un de mes ouvrages en cours. Mais, je m'aperçois que je ne suis pas encore sauvé. En effet, METS, c'est beau, c'est grand, c'est fort et tout et tout. Mais, pour décrire concrètement un fichier, son format, la version du format... Il faut utiliser un autre schéma, METS ne mettant qu'une enveloppe à disposition (techMD).

Mais, vous allez me dire : « A quoi sert ces informations ? ». Élémentaire, mon cher Watson. Prenons un exemple : actuellement, j'utilise la version dite P4 de la TEI, la version P5 est en développement. Si je veux garder un ensemble de fichiers XML un tant soit peu homogène, je suis obligé de faire migrer mes fichiers de P4 à P5. Il faut donc que je sache quels fichiers je dois migrer et pas question d'aller voir tous les fichiers, mon système doit pouvoir me les retrouver en une petite requête. Bon, vous me suivez toujours ? Donc, il me faut une grammaire XML pour ce genre de métadonnées. Je fait donc appel à ma personne ressource (qui, ça tombe bien, avait aussi une question à se poser, elle est pas belle la vie ;-) ). « la solution à ton problème, c'est PREMIS » me dit-elle ; moi : « Ah ! d'accord, merci. ». Me voilà, donc parti à la découverte d'un nouveau schéma : PREMIS pour Preservation Metadata : implementation Strategies. Gage de sérieux, l'OCLC, RLG et la library of congress sont dans le coup. Mais, le rapport final fait la bagatelle de 237 pages et le dictionnaire de données une bonne centaine de pages.

Tout ou presque y passe. Mon correspondant permanent dans ce domaine m'indique qu'il manque des choses. Je veux bien la croire, moi, j'ai l'impression que même la marque de café du développeur de l'application est encodée... Tout ça, c'est bien joli, mais j'ai toujours pas de système optimal pour gérer la conservation et la pérennisation du document numérique. ADORE a l'air bien, mais je ne dispose pas des moyens humains pour l'implémenter. Réflexion faite, j'ai pris un semblant de décision... Si on reprend à nouveau le modèle OAIS, il existe trois étapes ou plutôt trois types de paquets :

  1. les paquets de versement, dit SIP ;

  2. les paquets d'archivage, dit AIP ;

  3. les paquets de diffusion, dit DIP.

Actuellement, on est capable de gérer les paquets de diffusion. En revanche, on est incapable de gérer les paquets d'archivage avec tout ce qui va avec : migration, émulation, vérification des trains de bits et autres joyeusetés de ce genre. On va donc préparer le terrain, faire de jolis paquets de versement avec toutes les métadonnées utiles à la conservation et la pérennisation en utilisant METS et PREMIS, chaque fichier possédera un identifiant pérenne et le jour où on bascule nos données dans une archive qui nous gère nos AIP (chez nous ou chez un prestataire public ou privé), on change simplement les localisations physiques des fichiers dans notre résolveur d'identifiants pérennes. Il me reste donc (doux euphémisme) à déterminer les métadonnées utiles pour nos paquets de versement avec METS et PREMIS. Plutôt que de faire le travail dans mon coin et comme j'ai besoin d'un pense-bête, je vous propose donc la liste des métadonnées qui me semblent utiles et leurs explications dans les prochains billets. Ça permettra de défricher le terrain et je me sentirai moins seul.

Enfin, franchement, comme dirait Géronte dans les Fourberies de Scapin : « Que diable allait-il faire dans cette galère ? » et je me pose vraiment la question ;-)

Causeries Conservation Édition électronique Numérisation TEI —