Aller au contenu principal

L’EAD, c’est pour l’import-export

07/10/2013

J’ai vu passer en février dernier ce billet de blog : L’art d’élaborer des instruments de recherche XML-EAD gratuitement.

En gros : si on a besoin de créer un inventaire d’archives en EAD (c’est du XML pour décrire des inventaires d’archives), quel outil de saisie utiliser ?

Le début du billet m’a fait assez peur, en évoquant les différents éditeurs XML existants. Le billet se termine heureusement sur une chute plus heureuse : utiliser ICA-Atom, logiciel de description d’archives, utiliser les champs de saisie du logiciel puis exporter l’inventaire en EAD, puisque ce format d’export existe.

Pour ma part, j’aurais commencé par ça : il est interdit d’écrire de l’EAD à la main. L’EAD est un très bon format d’échange entre deux bases d’archives, pour partager un inventaire. Mais ça ne sert à rien d’en faire un format natif.

Pour faire une comparaison plus compréhensible aux bibliothécaires (enfin, aux bibliothécaires qui lisent ce blog) : c’est un peu comme si on demandait à un catalogueur d’écrire ses notices en iso2709 ou en MarcXML.

Il vaut mieux consacrer du temps à savoir produire automatiquement de l’EAD à partir d’un autre format, que de le passer à taper les balises et attributs à la main. La saisie manuelle, même avec toute l’aide à la frappe d’un bon logiciel payant comme XMetaL, est rentable pour un inventaire — et encore — pas pour 2.

D’ailleurs, en juin, le même auteur évoquait la mécanique SOSIE, qui va dans le sens que j’aime ! (dommage pour les problèmes de mises à jour logicielles qu’il signale).

Cas d’école et retour d’expérience

Je viens d’être confronté à un outil d’inventaire d’archives qui n’exporte pas en EAD. Tout ce qu’il connaît, c’est l’export CSV : une ligne par cote, avec répétition systématique des informations à chaque ligne.

export CSV

C’est simplement l’export standard d’une base de données relationnelle.

Sauf que pour l’injecter dans un autre site — comme le portail européen des archives — ce CSV est indigeste, et c’est là qu’il est pratique de pouvoir dire : "fournissez-moi de l’EAD". Au moins, on sait ce que c’est (si on est archiviste). L’EAD devient en quelque sorte un format d’échange entre deux plates-formes, l’une capable de l’exporter, l’autre de l’importer.

Ici, le principe fonctionne à moitié puisque à la source il n’y a pas d’EAD…

Le passage du CSV à l’EAD ne pose aucune difficulté autre que scientifique : il faut faire des choix sur l’encodage. Le reste, c’est de l’informatique — et les informaticiens, ça se trouve (à condition de pouvoir leur donner des consignes qu’ils sachent comprendre).

Bref, pour la conversion j’ai utilisé des techniques déjà évoquées :

  1. publipostage Excel –> Word pour obtenir un fichier XML moche, où chaque ligne est un noeud, avec la même répétition des infos (pas de regroupement par série, sous-série, fonds, etc., comme le réclament l’ISAD(G) et l’EAD)
    xml brut
    Si vous ignorez tout du publipostage, voici un petit tuto (de quelqu’un d’autre) en vidéo.
    Le fichier Word qui appelle les valeurs des cellules Excel encadre les valeurs dans des balises XML
    publipostage
  2. Feuille XSL qui regroupe les infos, selon la méthode Muenchian déjà évoquée sur un autre blog dans une autre vie.
    Voici la feuille de style utilisée

Une fois la machine rodée, le plus long est le travail "scientifique" (qui doit être assez intuitif en réalité pour un archiviste) consistant à traiter les spécificités : dans le fichier en entrée, qu’est-ce qui est un fonds, une sous-série, etc. Il faut ensuite ajuster la feuille de style à chaque source de données, selon les variations (certaines sources ont besoin d’une arborescence à 3 niveaux, d’autres seulement 1).

PS : le publipostage marche aussi très bien sous LibreOffice (Outils > Assistants Mailing)

About these ads
6 Commentaires
  1. 07/10/2013 10:09

    Tout à fait d’accord : XML-EAD format natif est une hérésie. Surtout, il hypothèque sérieusement l’avenir avec les évolutions prévisibles vers les données liées : on ne va pas pouvoir transformer directement l’EAD en triplets RDF suffisamment riches et pertinents.
    Contrairement aux espoirs initiaux, l’adoption de l’EAD a entraîné un grand formalisme (la priorité au respect d’une syntaxe) parfois au détriment de la qualité des contenus.
    De plus, il y a trop d’informations implicites et manquantes dans l’EAD. Le projet de schéma EAD vient beaucoup trop tard et restera un compromis entre lecture humaine et exploitation par les machines (pas assez sémantique).
    La nécessité de modèle conceptuel pour les archives (comme FRBR, FRAD… pour les bibliothèques) et d’une grande urgence.
    Les archivistes ou du moins les "e-archivistes" doivent également réfléchir aux notions de données versus documents (cf. les travaux de "Pédauque"-Salaün, Bachimont, Crozat…) pour leurs instruments de recherche.

  2. 07/10/2013 10:52

    @Louis : merci de recentrer correctement le débat. Je ne m’étais préoccupé que de l’aspect technique de la chaîne de traitement.
    En soi, l’EAD a été conçu pour la mise en ligne d’inventaires non conçus comme devant être en ligne, ce qui pose évidemment la question de sa pertinence "en soi". Et cette mise en ligne d’inventaires est une des manières possibles possibles de publier les données qu’ils contiennent.
    Il me semble que le CIDOC-CRM doit évoluer vers un modèle commun archives/bib/musées, donc l’état d’avancement n’est pas tout à fait nul.
    A voir ensuite comment la profession s’en empare (il y a des problèmes d’appropriation sur le modèle FRBR en bibliothèque, entre ceux qui l’ignorent ou ne savent pas quoi en faire, et ceux qui veulent en faire un modèle de navigation à absolutiser).

  3. 07/10/2013 11:38

    Merci pour ce billet qui fait réfléchir mais pour lequel je ne peux être à 100% d’accord ou du moins pour lequel je souhaite apporter quelques nuances et remarques.
    - je distinguerais le fait d’écrire un fichier directement en XML-EAD en tant que tel et celui de savoir écrire un IR en XML-EAD ou du moins comprendre la syntaxe afin d’avoir un regard critique sur les fichiers XML réalisés.
    - La question de l’import-export est selon moi très épineuse si on ne connait pas parfaitement toute la chaîne de traitement d’un fichier XML et les choix d’export versus nativement XML.
    - l’EAD dans la forme actuelle est extrêmement permissif – ce qui lui donne l’avantage d’être souple – mais pose le problème de l’import-export dans des environnements différents. Après, il est vrai que cette question se pose également pour les IR "à la main". Mais d’un logiciel métier à un autre, l’encodage varie. On revient selon moi, à ma seconde remarque, connaître la chaîne de traitement.
    - Pour le projet APEnet, pour être précis, ils demandent de l’EAD dans les via le protocole d’échanges OAI-PMH plutôt que traditionnellement du DC ou du OLAC, afin de respecter la contextualisation archivistique.
    - Ensuite l’EAD peut-être utiliser de X manières avec des spécificités selon l’objet d’écrit : recommandation Calames pour les manuscrits, pour les cartes par le centre de documentation Regards, etc, ce qui selon moi, complique et multiplie les "post-traitements".

    Après, il faut également avoir en tête la question de "pourquoi je réalise un IR en EAD". Tout ne peux pas être si catégorique, surtout quand je lis "il est interdit d’écrire de l’EAD à la main".
    Par exemple, personnellement, je souhaitais faire une sortie papier (sic) très "poussée", je n’avais qu’une seule solution, celle d’écrire directement un EAD très riche en contenu pour ensuite utiliser une feuille de transformation où je pouvais aller également assez loin. Certes, c’est assez spécifique et impensable en "production" à l’échelle d’une institution et je me fais un peu l’avocat du diable, mais je pense qu’il faut penser d’abord et toujours se poser les questions suivantes : "pour qui, pour quoi, sur quelle plateforme, dans quels buts"

    Je vous rejoins à 100% concernant le tournant sémantique que l’EAD ne prend malheureusement pas avec son nouveau schéma.
    On peut néanmoins noter des intiatives comme le thésaurus W en format SKOS et le projet HADOC du ministère.
    Je me permets de signaler deux documents que vous connaissez déjà probablement à ce sujet : http://goo.gl/a8Rw2 + http://goo.gl/ZTkCI

    Encore merci pour le blog.
    Antoine

  4. 07/10/2013 15:27

    Ce débat est essentiel.
    La phrase d’Étienne, bien que pas parfaitement claire, est très importante : "En soi, l’EAD a été conçu pour la mise en ligne d’inventaires non conçus comme devant être en ligne," Or, pas mal de services d’archives consacrent de l’énergie et des moyens à faire mettre en syntaxe EAD des instruments de recherche imprimés ou autres plutôt qu’à produire de nouveaux instruments de recherche.

    Il faut lire absolument Bruno Bachimont, par exemple son ouvrage "Ingénierie des connaissances et des contenus : le numérique entre ontologies et documents" (Lavoisier, 2007).

    Ci-dessous des extraits de ce qu’il écrit à propos des formats.
    Il insiste sur les contraintes liées aux formats.
    « Mais, ces formats sont en eux-mêmes structurants et contraignants : leur choix préconfigure le projet documentaire en imposant une manière de structurer les contenus et de penser leur accès et leur manipulation. La dérive, que l’on constate aujourd’hui, se déduit immédiatement : on conçoit un projet documentaire pour le rendre compatible avec les formats et standards, au lieu d’utiliser ces derniers pour réaliser le projet.
    La vogue, justifiée, de XML en fait un détour obligé de tout projet. Peu importent les documents, pourvu qu’ils soient en XML et échangeables suivant ce type de structure. Cependant, si le projet nécessite de prendre en compte des informations non prévues par le format, de mettre en œuvre un type de validation non prévu par le standard, il en résulte un écart nécessaire entre le choix du standard d’une part et l’élaboration des outils pour le projet d’autre part. »

    Et l’auteur rappelle la distinction, que nous avons tendance à oublier, entre formats d’échange et formats de travail.
    « Les formats d’échange qui permettent de rendre lisibles par différentes applications les mêmes données.
    Les formats de travail qui permettent à une application d’effectuer tous les traitements nécessaires et de créer les structures à cet effet. »

    L’auteur montre que les vocations des ces deux types de formats sont contradictoires, les formats de travail constituant une solution locale quand les formats d’échange visent à une certaine universalité. Il en conclue : « Par conséquent, vouloir choisir le format d’échange pour mener les traitements internes de l’application est souvent un choix maladroit et introduit des contraintes et difficultés inutiles à l’élaboration du projet, alors qu’il suffit d’avoir un moyen de traduire les structures du format interne dans le format d’échange pour exploiter de manière large les informations manipulées et produites par l’application. ».
    Cette confusion entre format d’échange et formats de travail est exactement celle qui a souvent été faite dans les archives avec le format XML-EAD, avec les conséquences que l’on peut prévoir, d’autant plus, comme on peut l’imaginer, que ce format n’est probablement pas destiné à une grande pérennité.

    Ma société ayant participé activement à la diffusion du format EAD lors de son arrivée, je me crois autorisé, avec le recul, à émettre ces réflexions et surtout mises en garde.
    C’est un très très vaste sujet, seulement effleuré ici.

  5. 08/10/2013 09:53

    Sur ce point précis, je partage à 100% (si ce n’est plus) votre avis !
    C’est effectivement un problème lors des grands chantiers de rétroconversion d’IR : ne pas penser à l’objectif final, à savoir la mise en ligne pour de la recherche (via un moteur mais sans oublier le mode "exploratoire par plan de classement) et prendre en compte la lecture à l’écran. Au-déll de la question de l’enregistrement des données, se pose ainsi la question de la médiation de ces données.
    Selon moi, l’utilisation abusive du dans certaines rétroconversions est symptomatique de ce débat.

Rétroliens

  1. L’EAD, c’est pour l’import-ex...

Les commentaires sont fermés.

Suivre

Recevez les nouvelles publications par mail.

Joignez-vous à 97 followers

%d bloggers like this: