Comme promis dans mes précédents billets, je vais partager avec vous mon utilisation des formats METS et PREMIS pour constituer les SIP (Submission information package, n'en déplaise aux esprits mal placés...), les paquets de versements dans notre entrepôt numérique de données suivant le modèle OAIS. Je vous propose de commencer par le format pivot de notre système : METS, schéma XML maintenu par la library of congress.

Je vais rentrer dans les détails du format, donc si vous voulez avoir une vue d'ensemble et un résumé avant la lecture de ce document, je vous conseille de faire un petit tour chez blogokat qui propose un petit résumé très éclairant.

METS sert à gérer des objets numériques complexes et présente l'avantage de rassembler au sein du même fichier les trois types de métadonnées :

1. Métadonnées descriptives ;

2. Métadonnées administratives ;

3. Métadonnées de structure.

Il répond donc potentiellement à l'ensemble des besoins en terme de métadonnées. Ce format n'est pas le seul qui rend ce type de services, il en existe trois autres :

1. XFDU, mis au point par les initiateurs du modèle OAIS : la NASA. Ce format reprend donc scrupuleusement l'ensemble des informations qu'un bon SIP doit contenir

2. MPEG21-DIDL. Si j'ai compris de ma lecture rapide, il s'agit de la description XML de l'objet numérique encodé dans le fichier au format MPEG21.

3. Et mon envoyé spécial du domaine me souffle aussi : SCORM qui, visiblement, est plus dédié au E-learning et qui m'a l'air très corporate.

Le choix de METS est vite fait. Je connais le format puisqu'on l'a utilisé pour le projet des cartulaires numérisés, d'autres projets de numérisation ont fait ce choix en France dont PERSEE et c'est un format ouvert et libre.

Commençons par dresser la liste de nos besoins par rapport aux possibilités de METS. Il y a 7 parties dans un fichier METS :

1. METS header (metsHdr) permet d'indiquer les références du fichier METS (les métadonnées du fichier de métadonnées...), en particulier le producteur du fichier ;

2. Description Metadata Section (dmdsec) permet de renseigner les métadonnées descriptives de l'objet principal décrit par le fichier METS et éventuellement des objets le composant. Exemple : un fichier METS décrit un fonds d'estampes, vous pouvez à la fois décrire le fond dans une section de métadonnées descriptives et chaque estampe dans autant de sections qu'il y a d'estampes ;

3. Administrative Metadata Section (amdSec) permet de renseigner l'ensemble des métadonnées administratives de l'objet principal et éventuellement des objets le composant, c'est à dire les métadonnées techniques, les métadonnées juridiques, les métadonnées sur la source des fichiers, les métadonnées décrivant le processus de numérisation et les migrations (au sens large : passage des données de l'analogique au numérique, donc y compris l'encodage par exemple)

4. File Section (fileSec) permet de décrire l'emplacement physique de chaque fichier ; rassemblé par groupe de même nature et il est aussi possible d'inclure à cet endroit le contenu du fichier ;

5. Structural Map (structMap) permet d'organiser selon une structure hiérarchique les objets composant l'objet principal décrit dans les parties dmdSec, amdSec et/ou fileSec. Il est possible de décrire plusieurs cartes de structure ;

6. Structural Map Linking (structLink) permet de décrire les liens éventuels entre des divisions appartenant à des cartes de structure différentes ;

7. Behaviour section (behaviourSec) permet d'indiquer des comportements entre différents objets décrits dans le fichier METS.

La grande force de METS est de séparer les différents types de métadonnées ce qui permet d'organiser et de relier les objets décrits dans les différentes sections (que vous pouvez multiplier selon vos besoins) comme on le souhaite et non selon une seule structure hiérarchique. Les différentes sections correspondant à un même objet sont reliées par un système d'identifiants et de références aux identifiants (id/idref pour les intimes...). Pour reprendre l'analogie de l'arbre, ici les branches (ou les feuilles comme vous voulez) peuvent être raccrochées à plusieurs troncs.

Le deuxième avantage de METS réside dans le principe des enveloppes (mdWrap). Ces enveloppes permettent de renseigner les métadonnées descriptives ou techniques dans le format XML qui paraît le plus adapté ou même de mettre directement le contenu d'un fichier encodé en binaire selon une base 64. Ainsi, grâce aux espaces de noms XML, vous pouvez décrire l'objet principal ou les objets le composant en Dublin core, en EAD, en MODS, en LOM ou en ONIX (Soyons fous !!) par exempe pour les métadonnées descriptives ou utiliser PREMIS, MIX (métadonnées pour décrire les images), METSrights ou encore creative commons pour les métadonnées administratives. Cela laisse une très grande souplesse dans les choix précis de métadonnées en fonction des besoins. Mais, cela impose aussi d'utiliser d'autres schémas de métadonnées, d'où mon intérêt pour PREMIS, mais on y reviendra.

Maintenant que les possibilités de METS sont listées, voyons mes besoins. Il faut avant tout déterminer l'objet principal décrit dans le fichier METS. Dans notre cas, c'est assez simple. Nous avons organisé nos éditions électroniques dans une collection selon un système équivalent au monde de l'édition papier. Chaque numéro dans la collection constitue en quelque sorte un « ouvrage » et c'est cet objet que va décrire notre fichier METS. Nous aurons donc un fichier METS par « ouvrage » et un fichier METS général pour la collection. Pour des commodités, je vais désigner l'ouvrage par le terme « corpus ». A l'intérieur du fichier METS, j'ai besoin des informations suivantes :

1. les métadonnées descriptives du corpus, pour les récupérer dans les métadonnées des pages Web générées et pour alimenter notre entrepôt OAI dont les enregistrements se font à ce niveau

2. les métadonnées techniques reprenant les caractéristiques des fichiers composant le corpus. Ces informations sont essentielles dans le cadre de la conservation à long terme des fichiers numériques.

3. les métadonnées juridiques peuvent avoir leur utilité dans le cas où nous utilisons des images numérisées d'une institution de conservation avec qui nous avons signé une convention. La plupart du temps dans ce cas, l'institution conserve le droit sur les images numérisées. Cette mention est importante à indiquer dans les pages Web incluant les images numérisées, mais aussi dans la mémoire du système si une demande de reproduction nous est adressée.
   De plus, il nous faut pouvoir indiquer dans le cas d'une numérisation d'ouvrages, que le texte est libre de droit, mais cela va pratiquement de soi (est-ce bien utile finalement ?)
   Au niveau des droits sur la production de l'Ecole, il n'existe pas de licences particulières d'utilisation à l'heure actuelle. Elle est donc régie par le code de la propriété intellectuelle. Et si nous venions à en utiliser une, elle serait commune à l'ensemble de nos corpus, donc l'indication n'a pas ici d'importance, me semble-t-il ?.

4. les métadonnées de provenance de la numérisation peuvent être renseignées pour la mémoire du système, mais aussi pour indiquer les principes d'encodage et le noms du ou des encodeurs. Mon envoyé spécial du domaine m'indique gentiment (Merci !) que cette partie permet aussi de documenter les migrations. Elle est donc essentielle.

5. Lister l'ensemble des fichiers utilisés dans mon corpus rassemblés par groupes de fichiers avec l'indication par un identifiant pérenne de l'emplacement physique de chaque fichier. Normalement, pour un corpus, je dispose d'un ou plusieurs fichiers XML contenant le texte structuré, des feuilles de style XSL, de la feuille de style CSS, les images pour le graphisme du site, les images venant en appui du texte voire les images de l'original numérisé. Chaque groupe de fichier devra être relié avec la section correspondante dans les métadonnées techniques. Cette partie est essentielle pour la fourniture des paquets de diffusion (DIP) et donc la génération des pages Web. Elle l'est aussi pour la conservation, car il faudra bien retrouver l'emplacement des fichiers le jour où il faudra effectuer une migration ou recomposer le SIP.

6. La carte de structure permet de lister l'ensemble des « unités structurelles » composant le site Web. En fait, il s'agit de lister l'ensemble des pages Web qui seront générées. A chaque division correspondent un fichier XML et un fichier XSL. Exemple dans le cas du formulaire d'Odart Morchesne, je vais avoir 7 divisions correspondant aux 7 types de pages générées à partir du fichier XML : la page d'accueil, la page pour le texte d'introduction, la page listant les formules d'un chapitre, la page pour afficher une formule, la page listant l'ensemble des chapitres et des formules, la page pour le formulaire de recherche en texte intégral et la page pour les résultats de la recherche en texte intégral. Ces indications doivent permettre à mon système de savoir quelle feuille de style il doit utiliser selon le paramètre passé en argument. La division principale de ma carte de structure doit être reliée à la section correspondante dans les métadonnées descriptives. A-priori, les sous-divisions ne font pas l'objet de descriptions précises.

Les sections structLink et behaviourSec ne m'intéressent par pour l'instant. Pour la structLink, mes besoins pour relier deux divisions d'une carte de structure dépasseront le corpus, donc il faudrait que je fasse référence à un autre fichier METS. Il me faut donc utiliser un autre fichier avec un format spécifique. Mais, j'y reviendrai dans les prochains mois.

Donc si je résume, j'ai :

1. Une section de métadonnées descriptives en Dublin Core pour décrire mon corpus/ouvrage

2. Autant de sections de métadonnées techniques que de type de fichiers en PREMIS pour décrire précisément le type de fichier, leur caractéristiques (Grammaire XML utilisée, version de la grammaire...) ou en MIX pour les images (format, niveau d'encodage, particularités de l'image...)

3. Eventuellement une ou plusieurs sections de métadonnées juridiques pour indiquer le droit sur les images si on a la numérisation de l'original OU les droits sur le texte dans le cas d'une numérisation en mode texte. Le choix du schéma de métadonnées est encore à déterminer.

4. Eventuellement une section de métadonnées pour indiquer le processus de numérisation, renseigner les pratiques d'encodage ou documenter les éventuelles migrations subies par les fichiers

5. une section de fichiers avec un groupe par type de fichiers rassemblant la liste de tous les fichiers utilisés par mon corpus. Chaque groupe de fichiers doit faire référence à la section correspondante dans la section des métadonnées techniques avec l'attribut ADMID.

6. une carte de structure listant l'ensemble des pages Web générées et faisant référence au fichier XML et XSL. Les divisions doivent faire référence à la section de métadonnées descriptives correspondante avec l'attribut DMDID. Dans le cas où le corpus serait composé de plusieurs fichiers XML (cas du Cartulaire Blanc de l'abbaye de Saint-Denis), il faut créer une sous-division par fichier XML, puisqu'elle représente une division logique supplémentaire du corpus.

Pour être plus concret, vous pouvez visualiser le fichier METS à peu près terminé (sauf les métadonnées PREMIS) de l'édition du formulaire d'Odart Morchesne qui suit les spécifications exposées ci-dessus. Prochaine étape : les métadonnées techniques avec PREMIS.