Outils pour utilisateurs

Outils du site


public:umr_larhra_projet_bhe:import_baip

Import du corpus BAIP dans TXM

Livraison de la version 1 - compte-rendu du premier import

Une première version du corpus est disponible dans '///Projets/Textométrie/SpUV/Projet BHE' :

  • baip-bin.txm : le corpus binaire à charger
  • baip-src.zip : les sources à importer avec XML/w+CSV

fichiers sources XML-TEI

Les sources contiennent des césures non résolues : j'ai remplacé tous les '¬ ' par rien (~30 000).

Les pages ont en général un titre courant codé comme paragraphe du corps du texte. On peut distinguer 5 types de pattern de titre courant immédiatement après un '<pb/>' (c'est sur plusieurs lignes dans la source XML) :

  1. 342
    OCTOBRE 1850.
  2. OCTOBRE 1850.
    341
  3. OCTOBRE 1850. 341
  4. 341 OCTOBRE 1850.
  5. OCTOBRE 1850.

Comme le XML encode déjà ces informations et qu'il n'est a priori pas très intéressant de laisser cela dans le corps du texte (au pire on peut le re-synthétiser à partir de l'encodage XML), je les ai supprimées des sources.

Pour cela, j'ai appliqué 5 chercher/remplacer de regexp multilignes suivantes par $1

(<tei:pb [^>]+>\n)   <tei:p>[0-9]+</tei:p>\n   <tei:p>[^ ]+ 18[5-6][0-9]\.</tei:p>\n
(<tei:pb [^>]+>\n)   <tei:p>[^ ]+ 18[5-6][0-9]\.</tei:p>\n   <tei:p>[0-9]+</tei:p>\n
(<tei:pb [^>]+>\n)   <tei:p>[^ ]+ 18[5-6][0-9]\. [0-9]+</tei:p>\n
(<tei:pb [^>]+>\n)   <tei:p>[0-9]+ [^ ]+ 18[5-6][0-9]\.</tei:p>\n
(<tei:pb [^>]+>\n)   <tei:p>[^ ]+ 18[5-6][0-9]\.</tei:p>\n

Pour pouvoir faire ces C/R multilignes par script (sur tous les fichiers sources), j'ai écrit la nouvelle macro 'MultiLineSearchReplaceInDirectoryMacro.groovy'.

Pour régler les regexp, j'ai développé une nouvelle macro pour chercher des regexp multilignes 'FindMultiLineRegExpMacro.groovy'.

Remarque : ce traitement n'a résolu que quelques cas de titres courants. En particulier il n'a pas traité les cas où l'OCR a produit des résultats incorrects. Les cas traités sont listés dans le journal de recherche de regexp de titres courants.

Métadonnées

J'ai produit un tableau de métadonnées à partir des informations se trouvant dans les entêtes teiHeader des sources.

Pour cela j'ai utilisé la nouvelle macro prototype 'XMLText2MetadataCSVMacro.groovy'.

Cette macro s'est appuyée sur les déclarations de métadonnées suivantes :

titre=tei:TEI/tei:teiHeader/tei:fileDesc/tei:titleStmt/tei:title[@type='main']/text()
volume=tei:TEI/tei:teiHeader/tei:fileDesc/tei:sourceDesc/tei:biblStruct/tei:monogr/tei:imprint/tei:biblScope[@type='volume']/text()
numero=tei:TEI/tei:teiHeader/tei:fileDesc/tei:sourceDesc/tei:biblStruct/tei:monogr/tei:imprint/tei:biblScope[@type='issue']/text()
pages=tei:TEI/tei:teiHeader/tei:fileDesc/tei:sourceDesc/tei:biblStruct/tei:monogr/tei:imprint/tei:biblScope[@type='pages']/text()
annee=tei:TEI/tei:teiHeader/tei:fileDesc/tei:sourceDesc/tei:biblStruct/tei:monogr/tei:imprint/tei:date/text()

Pour régler les XPaths ci-dessus, j'ai développé une nouvelle macro 'GetXPathMacro.groovy'.

Le fichier 'metadata.csv' résultant a la structure suivante (après édition de métadonnées supplémentaires) :

id,titre,mois,annee,titrelong,numero,moisparannee,moisnum,volume,pages
article_baip_1254-0714_1850_num_1_1_970_tei,N° 1,Janvier,1850,N° 1 — Janvier 1850,01,1850-01,1,1,1-26
article_baip_1254-0714_1850_num_1_2_971_tei,N° 2,Février,1850,N° 2 — Février 1850,02,1850-02,2,1,29-47
...
  • id : nom fichier
  • titre : le titre extrait de teiHeader simplifié
  • mois : mois alphabétique
  • annee : année numérique
  • titrelong : le titre extrait de teiHeader
  • numero : numéro numérique pouvant être trié alphabétiquement
  • moisparannee : numéros numériques de mois et d'années concaténés
  • moisnum : mois numérique
  • volume : volume numérique
  • pages : pages de début et de fin dans le volume

Les métadonnées extraites automatiquement sont : mois, annee, titrelong, moisnum, volume, pages.

J'ai respecté la datation et l'ordre des tables chronologiques et alphabétiques de fin d'année, en différenciant leur numérotation de celle du bulletin (numero) pour pouvoir facilement faire un sous-corpus sans ces tables ainsi que l'avis (unique). [l'AFC montre clairement trois paquets : bulletins, tables chrono, tables alpha]

Paramètres d'import additionnels

Les paramètres supplémentaires suivants de l'import XML/w+CSV ont été utilisés (import.properties) :

ignoredelements=note|teiHeader
editionpage=pb
  • ignoredelements : les notes et les teiHeader sont ignorés des sources
  • pb est la balise de pagination (le nombre de mots pas page par défaut n'a pas été changé → certaines pages sont sur-paginées par rapport à l'édition d'origine (à améliorer dans la version 2)

Livraison de la version 2 - compte-rendu de recette de l'import 1

Retours de BP sur la v1

Point A

J'ai observé que les textes étaient dans l'ordre chronologique au niveau des années, mais pour les mois à l'intérieur des années il y a qq inversions pour 1850 et 1858 (ce sont les années qui comportent les numéros 10 et 100, le tri sur les noms de fichiers est sur la chaîne de caractères et le pb est que le numéro n'est pas codé avec une longueur constante sur 3 caractères avec des zéros initiaux).

Initialement, j'ai créé la métadonnée 'moisparannee' pour encoder l'ordre des textes. Or je me suis aperçu que les commandes Progression et Édition (texte suivant) n'avaient pas le même avis sur cet ordre (créé par le module d'import XML/w+CSV ici). Du coup je me suis retranché sur les noms de fichiers de textes, pour que tous les outils offrent une même relation d'ordre sur la séquence de textes, en y recodant les préfixes des numéros à deux chiffres : j'avais oublié qu'il pouvait y avoir 3 chiffres.

Après discussion avec MD, il est confirmé que le paramètre d'import 'sortmetadata' n'est pas pris en compte pour créer l'ordre des éditions de textes (dans le module d'import XML/w+CSV) [ticket TBX ?]. Du coup :

  1. j'ai recodé les noms de fichiers en tenant compte des 3 chiffres (le script de renommage est documenté ici) : j'espère que c'est la bonne cette fois ;
  2. il faut INTERDIRE l'utilisation du paramètre 'sortmetadata' tant que les différentes commandes n'auront pas un avis homogène sur cet ordre [ticket DOC ?].

Point B

Si j'ai bien compris, Persée se prépare à coder les articles au sein de chaque numéro, mais de façon éclatée (autant de fichiers), et cette unité de travail plus précise semble intéresser les historiens (Francesco, Emmanuelle). Est-ce que cela pourrait être pertinent de discuter avec Persée d'un codage plutôt de type div (qu'ils ont évoqué aussi comme une de leurs pratiques me semble-t-il), avec malgré tout les informations correspondantes ? (portées donc plutôt par un attribut plutôt que dans un entête, par ex. pagination)

On peut demander à Persée une version 2 où un bulletin est encodé par un fichier, avec des div pour marquer des limites internes. Mais :

  • je n'ai pas souvenir qu'ils proposent cela (je m'apprétais à construire cette représentation mono-fichier nous-mêmes)
  • ce sera un corpus expérimental incomplet jusqu'à l'été. Qui en seraient les destinataires ? Quelle serait la fréquence de mise à jour ?

En fait je me demande s'il ne serait pas plus intéressant de thématiser les délimitations de sections internes du côté d'annotations faites par nous, plutôt que du côté de Persée (ce qui supposerait que notre environnement d'annotation soit disponible pour le vacataire préssenti).

Point supplémentaire

Point C

J'ai profité de cette nouvelle version pour affiner la pagination des éditions : désormais, les sauts de page correspondent exactement aux <pb/> des sources TEI de Persée (il n'y a plus de sur-pagination pour limiter le nombre de mots par page). On est donc prêts pour l'édition synoptique avec les facsimilés (dans une prochaine étape).

Nouvelle version : v2

La version 2 a été déposée dans le répertoire partagé.

Nouvelle version : v3

Les sources sont disponibles à \\ensldfs\espaces_metiers\BHE

Remarque sur leur structure :

les tous premiers exports correspondaient à un tome ou une journée.
C'était avant que le découpage en unité documentaire ne soit réalisé.
Nous n'avons pas d'outil pour générer une TEI globale une fois que les documents sont isolés.
Il reste à faire une XSLT qui crée un tei:corpus à partir du METS du numéro
public/umr_larhra_projet_bhe/import_baip.txt · Dernière modification: 2017/04/07 16:27 par slh@ens-lyon.fr