Une première version du corpus est disponible dans '///Projets/Textométrie/SpUV/Projet BHE' :
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) :
342 OCTOBRE 1850.
OCTOBRE 1850. 341
OCTOBRE 1850. 341
341 OCTOBRE 1850.
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.
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 ...
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]
Les paramètres supplémentaires suivants de l'import XML/w+CSV ont été utilisés (import.properties) :
ignoredelements=note|teiHeader editionpage=pb
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 :
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 :
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 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).
La version 2 a été déposée dans le répertoire partagé.
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