Skip to content

Journée Afnor/BnF sur l’open data du 24 juin 2016 (5/5) : partager son EAD

11/07/2016

Dernier billet sur cette journée. Si vous ne l’avez pas lu, prenez le temps de lire l’intro du premier billet où j’explique que je ne fais pas un compte-rendu).

Je reviens à présent sur quelques propos de Gaël Chenard (très stimulant, comme toujours) au cours de la table ronde.

Il a présenté

  • la politique d’open data (et open content) de son service depuis 2014,
  • la constitution d’une base d’1,5 million d’images numérisées,
  • la numérisation de documents à la demande,
  • et sa frustration sur deux points.

En effet tout le monde dans son département des Hautes-Alpes est d’accord pour partager au maximum les métadonnées (IR, ou instruments de recherche, c’est-à-dire inventaires d’archives) et les données (documents numérisés).

Le problème est qu’il bute sur deux problèmes strictement techniques pour partager données et métadonnées :

  • Le protocole OAI, classiquement utilisé pour exposer ses données au moissonnage, n’est pas adapté aux inventaires en EAD :
    • en OAI, les notices sont toutes sur le même plan ;
    • en EAD toutes les infos sont imbriquées les unes dans les autres.
      Si bien que les métadonnées sont juridiquement ouvertes mais ne le sont pas techniquement, faute de format pivot pour leur exposition.
  • Proposer le téléchargement massif de la base d’images ferait tomber leur serveur s’il avait trop de demandes simultanées.

Je reviens sur chacun de ses deux points, dont je découvre en rédigeant ce billet qu’ils sont finalement assez liés.

EAD et OAI

J’ai déjà eu l’occasion d’exprimer mon opinion là-dessus (sans vraiment de réaction, accord ou désaccord, de la part des services producteurs d’instruments de recherche) : les instruments de recherche sont construits à tort, pour des raisons historiques, comme des livres composés de chapitres, sous-chapitres, rubriques et sous-rubriques.

En gros, quand internet est apparu, on a voulu remplacer les inventaires imprimés par des inventaires en ligne. La TEI (DTD massivement utilisée dans le monde de l’édition, notamment scientifique) ne permettant pas d’indiquer le sens des différents paragraphe, une DTD spécifique a été rédigée permettant de préciser que tel paragraphe n’était pas un paragraphe, mais de l’information sur les conditions d’accès aux boîtes (balise <accessrestrict/>) ou sur le support (matériau, format).

En réalité il faut concevoir un inventaire non pas comme un document à encoder d’une manière sémantisée (çàd avec des balises plus significatives que <p/> ou <div/>), mais comme l’imbrication de composants avec un système d’héritage de certaines propriétés.

Donc si on veut modéliser la description d’un fonds d’archives (si on veut chercher l’équivalent du FRBR pour les fonds d’archives), la question à résoudre n’est pas : quels éléments structure un fonds d’archives ? Quelles sont les propriétés d’un fonds d’archives ?

mais : quelles sont les propriétés d’un composant ? Qu’est-ce qui caractérise le composant d’un fonds d’archives ?

J’insiste : Le concept central pour décrire un fonds d’archives, c’est le composant, pas le fonds lui-même.

Si cela peut vous aider à comprendre ce que je veux dire, voyez l’ontologie Org permettant de décrire une organisation.

Schéma de l’ontologie Org – source https://www.w3.org/TR/vocab-org/

Une org:Organisation est composée d’org:Organisations (cf. les propriétés org:hasSubOrganization et org:subOrganizationOf).

Si on essaie d’imaginer un ead:Composant à la place du org:Organization, quelles sont les propriétés indispensables ?

Pour restituer la structure d’un fonds d’archives à partir de ses composants, chaque composant a besoin de 3 éléments essentiels :

  • l’identifiant du composant parent
  • l’ordre d’apparition au sein de cet élément parent
  • le type de composant qu’on est en train de décrire (lettre, registre d’état-civil, sous-série, fonds)

Avec ces 3 informations, il est possible d’exposer à plat ses métadonnées, permettant ainsi aux moissonneurs de reconstruire, et de réindexer correctement, les composants.

Je signale que concernant l’héritage de l’indexation, l’EAD en fait pas forcément mieux et tout dépend du moteur de recherche. Ainsi, la base Archives et Manuscrits de la BnF, qui tourne actuellement sous Pleade, ne permet pas de retrouver un composant à partir d’un mot se trouvant au sein d’un composant supérieur. Ce sera résolu avec la nouvelle plateforme en cours de production, sans que les données en entrée soient modifiées : toujours de l’EAD. Donc c’est bien le paramétrage du moteur de recherche qui permet de faire hériter l’indexation à des sous-composants, et non la structure du fichier lui-même.
Au moment de l’exposition des données en OAI, il faudrait évidemment documenter la manière dont on a affecté ces 3 propriétés (id du <c/> parent, ordre, type de <c/>), c’est-à-dire quelles sont les balises (DC ou autres) utilisées pour les fournir.

  • La notion de « sous-composant de » n’est pas spécifique aux archives, il existe déjà certainemrent plein d’ontologies qui le prévoient
    dcterms:isPartOf pourrait déjà faire l’affaire dans un premier temps
  • Pour le type, dcterms:type, évidemment
  • Pour le rang, je ne sais pas s’il peut être induit de la cote, par exemple. Mais je sais qu’en EAD on peut se retrouver avec des composants qui ont un <unititle/> et pas de cote spécifique. Donc il faudrait trouver ou créer un xxx:rank pour résoudre ce problème.

Cela dit, pour l’exposition de ses données, un point particulier doit être retravaillé : l’identifiant du composant (du <c/> parent, mais aussi du <c/> exposé). En effet cela implique :

  1. que chaque composant ait un identifiant, ce qui n’est pas forcément le cas dans les inventaires actuels
  2. que cet identifiant soit pérenne (et ne soit pas juste le numéro d’ordre au sein de l’inventaire)
  3. que cet identifiant soit exprimé sous forme d’URI : en effet une fois décontextualisé, si un <c/> renvoie vers son <c/> parent dont celui-ci est « AD05-23.362 », on se demande ce qu’on peut bien en faire : pas seulement dans le cadre du web de données (je n’ai même pas évoqué la RDFisation des inventaires, là), mais au sein d’un moteur de recherche qui aurait moissonné (et reconstitué) plusieurs centaines d’inventaires récupérés dans plusieurs dizaines de serveurs OAI : il faut bien que chaque ID soit unique. Et pour cela, rien de mieux qu’une URI.

Mettre à plat ses métadonnées EAD au sein d’un serveur OAI permettrait aussi de les percevoir un peu plus comme une base de données (liées entre elles) et moins comme un texte linéaire et arborescent.

Exposer ses images à tout venant

Le second problème technique est très intéressant aussi : comment exposer son 1,5 million d’images sans exploser son serveur au bout de la 2e requête.

Une solution serait d’autoriser à 1 téléchargement du dump par jour. Après tout, WorldCat limite le nombre de requêtes sur son API à 50.000 par jour ; l’IGN autorise 100 téléchargements par jour de cartes Minecraft ; et les utilisateurs intéressés par 1,5 millions d’images ne doivent pas être si nombreux !

D’ailleurs, qui sont-ils, ces utilisateurs qui aimeraient pouvoir télécharger 1,5 millions d’images ? En quoi les avoir sur leur (gros) PC ou sur leur serveur leur semblerait plus avantageux que d’en disposer en ligne ?

Je manque peut-être d’imagination, mais je vois seulement deux raisons pour opérer un tel téléchargement :

  • quelqu’un qui veut mettre en place une plateforme en agrégeant des contenus de toutes parts (l’histoire des Hautes-Alpes, l’état-civil français, etc.).
    Ces personnes là (sociétés, administrations, associations) doivent être suffisamment peu nombreuses pour qu’on puisse passer convention (même orale) avec elles et leur fournir un dump complet à la demande.
  • Quelqu’un qui voudrait récupérer un corpus d’images, pour lequel les critères disponibles sur l’interface de recherche ne permettent pas :
    • soit de récupérer d’un clic les quelques centaines ou milliers de résultats obtenus
    • soit d’interroger correctement la base, parce que le formulaire de recherche n’est pas adapté

En gros, la vraie question devient alors : quel service je rends à l’internaute qui souhaite constituer un corpus d’images ?

  • Comment peut-il constituer son lot ?
  • Comment peut-il le récupérer ?
  • Comment peut-il récupérer les métadonnées qui vont avec ?

Oui, parce que récupérer 1,5 millions ou 6000 images, si c’est juste autant de fichiers déposés tels quels dans un répertoire de ma machine, je ne vois pas ce que je peux en faire ?

Bref, il me faut impérativement les métadonnées associées (ou un minimum de métadonnées associées).

Et donc il me semble que, plutôt que de chercher à fournir un dump des 1,5 millions d’images, le vrai service consiste à fournir la liste des URL des 1,5 millions d’images, et quelques métadonnées + API ou RDF pour en récupérer davantage si besoin.

En gros, une sitemap listant les « ressources » (qui sont les URI des <c/> de tout à l’heure) avec un lien (propriété rdarelationships:electronicReproduction par exemple) vers l’image.

En bonus : l’URI de la ressource renvoie à l’inventaire EAD en ligne, lequel expose pour chaque composant quelques métadonnées en RDFa (dont les 3 propriétés évoquées tout à l’heure).

Et comme on n’a généralement pas une seule image par <c/> (puisqu’un registre d’état-civil, c’est un composant mais des dizaines d’images) : rien n’empêche qu’un même <c/> ait plusieurs propriétés « reproduction électronique ».

Toutes ces réflexions n’ont que quelques jours, voire quelques heures. Je ne prétends donc pas que j’ai la solution à tous ces problèmes, loin s’en faut.

Et vous identifierez très certainement plein de problèmes conceptuels, structurels, logistiques, qui font que ma proposition ne marche pas. Je serai ravi que vous me démontriez mes erreurs : ça éviterait qu’elles restent en ligne et que d’autres s’en inspirent et se plantent à cause de moi (et donc à cause de vous, qui n’aurez rien fait).

6 commentaires
  1. B. Majour permalink
    12/07/2016 11:35

    Proposer le téléchargement massif de la base d’images ferait tomber leur serveur s’il avait trop de demandes simultanées.

    Oui et non.

    La BNF utilise un système de « mise en cache » lorsqu’on veut télécharger les fichiers PDF des documents Gallica, avec un lien ensuite pour le téléchargement. Ce qui permet de temporiser la charge pour le serveur, voire peut-être de la confier à un autre serveur plus rapide. Enfin, il me semble.

    Un serveur pour la consultation, un serveur pour le téléchargement.

    On peut aussi limiter fortement les demandes simultanées en ayant une mauvaise présentation ou un système de panier. Quand il faut cocher ou tourner des dizaines de pages pour atteindre sa cible, les demandes sont moins nombreuses.

    Après, oui, télécharger des milliers d’images, ça ne peut intéresser que des grosses sociétés (type Google)… ou alors des gens qui ont un projet de mise en valeur du patrimoine. Mais dans leur cas, pas sur la totalité ? Sauf peut-être pour une sauvegarde.

    Tu me diras aussi : tout dépend du contenu et de son intérêt. ^-^

    Ce qui ramène toujours à la notion : pour qui je crée cette base de données de millions de documents ? De quoi mes prospects ont-ils vraiment besoin ?

    Quand je vois la complexité des formats de données que tu présentes (waow), je sais ce que je ferai :
    – extraction des colonnes les plus intéressantes pour mes cibles,
    en me limitant à quelques critères simples : qui quoi où quand

    Et ensuite, j’ouvrirai un échantillon de la base pour consultation (5-10 000 docs), afin de voir ce dont mes cibles ont vraiment besoin, comment ils s’en emparent.

    Puis ouverture progressive à la présentation d’autres documents suivant l’intérêt des cibles.

    Car l’erreur fréquente est de dire : mes prospects ont besoin de tout.
    Or les gens n’ont pas besoin de tout, ils ont besoin d’une certaine sélection.
    Une sélection présentée de manière harmonieuse et conviviale. (Cf. les collections de musée, ou les menus des restaurants)

    Pour les chercheurs ?
    Ils feront l’effort d’utiliser les outils qui gèrent la base de données complète. Parce que c’est dans leur intérêt. Ou alors, ils feront une demande ciblée. Autre moyen de temporiser un téléchargement massif.

    Le choix des documents présentés peut être effectué de manière automatique par un algorithme, ou alors il peut être effectué par un humain qui repère des photos particulières, ou des documents intéressants pour lui => qu’il aura envie de faire connaître.

    D’ailleurs, c’est ce que vont permettre les chercheurs : faire connaître, partager leurs découvertes. Leurs découvertes, pas la totalité des documents qu’ils auront regardés.

    10 000 documents, c’est déjà conséquent, et suffisant pour ne pas surcharger un serveur.
    La partie émergée de l’iceberg suffit, et la vraie solution est là. ^_^
    B. Majour

  2. 13/07/2016 08:08

    Bonjour,
    Merci pour ce billet très intéressant.
    Quelques remarques, à la volée…
    – L’héritage dans les IR, ne concerne pas seulement l’indexation, certains éléments du parent sont indispensables à la compréhension d’autres éléments des <c> enfants.
    – comme vous l'avez souligné avec l'ex. de la BnF, pour de l'EAD directement dans des records dans l’OAI soit opérant, il faut avoir des outils métiers capables d’une part de digérer cet EAD, de le restituer (soyons franc, l’affichage arbo est toujours demandé par le services d’archives) et d’avoir un moteur permettant de l’exploiter.
    – On voit maintenant pas mal d’IR, qui ont en attribut id du <c>, l’URL ark du noeud mais cela pose parfois de gros soucis dans la mise à jour des données car de nombreux ouils métiers recréent systématiquement des id à la volée… Les <c> peuvent être numérotés de style c01, c02 pouvant ainsi être utile pour l’ordre d’apparition mais cela n’est pas recommandée par le SIAF et risque de confirmer la crainte de’avoir un n° d’ordre rattaché à l’IR.
    – La notion de sous-composant est effectivement essentielle et l’utilisation de isPartOf de dcterms est une piste que l’ontologie spécifique aux archives intitulée RiC-O (pour Records in Context – Ontology) poursuit me semble-t-il. Présentation à l’ICA à Séoul en septembre 2016.
    – Pour les images, l’intégration de IIIF dans les visualiseurs de fonds d’archives pourrait également être une piste car avec ce système, permettant comme actuellement dans GALLICA, de récupérer en tache de fonds de gros volumes de la presse numérisée (après, la méthode est un peu geek, il faut l’avouer mais possible).

  3. louiscolombani permalink
    23/07/2016 15:24

    Bonjour,

    Comme souvent, « Bibliothèques » soulève d’excellentes questions… à propos d’archives.

    Le format XML-EAD en cause ?
    Le format XML-EAD et les problèmes qu’il pose reviennent régulièrement dans plusieurs de vos textes, depuis au moins 2013, et je les cite bien volontiers : « L’EAD, c’est pour l’import-export »(1) ; « Calames IT ? »(2) ; « Le XML pour écrire du texte, l’EAD pour produire des données (avec du A. Swartz dedans) »(3). Et ces textes ont suscité des commentaires très intéressants et des renvois sur d’autres blogs, comme « Les petites cases »(4) de Gautier Poupeau qui a abordé ces sujets dès 2009.
    Les questions soulevées dans ces différents posts concernent très directement les archivistes. En tant qu’éditeur de logiciel pour les archives, elles me semblent essentielles.

    EAD pour quoi faire ?
    Dans un commentaire à l’article « Le XML pour écrire du texte, l’EAD pour produire des données », vous notez : « l’objectif de l’EAD (produire des données) ». Est-ce bien sûr ? À l’origine et même plus tard, qu’ont fait les archivistes américains, et en particulier les auteurs de la DTD EAD, avec les fichiers encodés ? Ils les ont seulement transformés en HTML (j’ai eu l’occasion, de participer au congrès des archivistes américain en 2008 à Chicago et de suivre un atelier animé par Kris Kiesling et Michael J. Fox : « Stylesheets for EAD: Delivering Your Finding Aids on the Web »(5) où on nous apprenait à utiliser XSLT).
    Ce qui s’est passé, c’est plutôt que, comme on nous a « vendu » EAD comme format standard, unique et pérenne, nous avons décidé de « faire avec » et de construire des moteurs de recherche archivistiques nous appuyant sur ce format. En France, nous avons d’ailleurs été pionniers dans ce domaine et, après quelques tentatives peu réussies, Pleade et été le premier et très longtemps le seul moteur à bien traiter le format EAD. (Petite parenthèse à ce sujet : quand vous écrivez « la base Archives et Manuscrits de la BnF, qui tourne actuellement sous Pleade, ne permet pas de retrouver un composant à partir d’un mot se trouvant au sein d’un composant supérieur », ce n’est pas un problème lié à Pleade, mais seulement à la façon dont on a su le paramétrer.)

    Là où vous avez parfaitement raison, et mille fois raison, c’est que le XML-EAD est un format d’échange, un format de restitution, mais ne doit surtout pas être un format de stockage ni un format de traitement des données. Il faut, à ce propos, relire et relire ce qu’a écrit Bruno Bachimont et que je citais dans un commentaire (mon second) à votre texte « L’EAD, c’est pour l’import-export »(1).
    Le fait d’avoir décrit des fonds d’archives dans un éditeur XML ou encore, pour certains éditeurs de progiciels pour archives, d’avoir choisi de stocker les descriptions sous forme de fichiers XML a terriblement hypothéqué l’avenir ainsi que les évolutions en cours qui, comme vous le soulignez avec d’autres, correspondent à un glissement du mode document vers le mode données (et métadonnées descriptives).

    EAD et open data ?
    Ce qui est en cause, c’est moins le protocole OAI-PMH que le format qu’on lui fournit. Faire de l’open data avec un format pleinement orienté document ne peut en effet que présenter des difficultés.

    Partir des données descriptives et non d’un document EAD
    Ma société édite des logiciels pour les archivistes dont un outil pour la description, un moteur de recherche et un service d’entrepôt OAI-PMH. Tout cela peut fonctionner de manière cohérente à partir du moment où les descriptions sont stockées dans une base de données et non sous forme de fichiers XML. Car il est alors possible, comme le conseille Bruno Bachimont, de restituer ces descriptions aux formats voulus qui peuvent être en mode document ou en mode données en fonction des utilisations que l’on doit en faire.
    Pour être concret, nous produisons – pour des utilisateurs dans le domaine des sciences humaines et sociales qui publient leurs descriptions dans Isidore – des restitutions au format Dublin Core. Donc, avec une mise à plat complète. Comme vous le soulignez, il faut faire hériter l’indexation, mais pas seulement comme le note justement Antoine Courtin (certains logiciels pour archivistes leur imposent de faire de l’indexation redondante aux niveaux les plus bas !) ; il faut prendre en compte le contexte, ce qui est aussi une forme d’héritage (un composant pouvant avoir, pour intitulé, un simple numéro, une seule lettre, une année – ce qui est parfaitement incompréhensible en soi) ; il faut, bien sûr, un identifiant pour chaque description ; il faut, et on peut le faire, préciser les rangs relatifs – leur ordre d’apparition – des différents composants (la cote ne le permet pas : non seulement parce qu’elle peut, quelquefois, être absente, mais aussi parce qu’on a des instruments de recherche « méthodiques », c’est-à-dire que les descriptions sont dans un ordre logique et non dans l’ordre des cotes).
    Nous restituons aussi les descriptions suivant un format qui respecte le modèle RDF, alors beaucoup plus riche que le Dublin Core, avec tous les éléments de description qui seraient présents dans un fichier EAD et plus car on n’est pas limité par les contraintes de la syntaxe EAD.

    Allons-nous vers l’abandon du format EAD ? Peut-être. Dans tous les cas, comme vous l’avez déjà écrit à plusieurs reprises, il n’aurait jamais dû être un format de stockage des descriptions. Je crois qu’il faudra que je développe ces questions sur blog Anaphore.

    1) https://bibliotheques.wordpress.com/2013/10/07/lead-cest-pour-limport-export/
    2) https://bibliotheques.wordpress.com/2014/07/21/calames-it/
    3) https://bibliotheques.wordpress.com/2014/11/04/xml-pour-texte-ead-pour-donnees/
    4) http://www.lespetitescases.net/
    5) https://www.libraries.psu.edu/psul/saaworkshops/2008/eadstyle.html

Trackbacks

  1. Journée Afnor/BnF sur l’open data ...
  2. Journée Afnor/BnF sur l’open data ...
  3. Journée Afnor/BnF sur l’open data ...

Les commentaires sont fermés.

%d blogueurs aiment cette page :