I. De l'image à la transcription numérique

La majorité du corpus était accessible via des bibliothèques numériques telles que Gallica, les Harvard Digital Collections ou Numelyo. D'autres ont demandé une campagnes de photographies de travail, de qualité suffisante pour la reconnaissance de caractères. Pour d'autres encore, la transcription nous a été généreusement transmise par des chercheur·se·s associé·e·s.

Pour transcrire les premiers depuis les facsimiles numériques, nous avons eu recours au logiciel Transkribus. L'entraînement d'un modèle d'HTR (reconnaissance de caractères manuscrits) a été nécessaire, y compris pour les imprimés les plus récents, certaines variantes de lettres n'étant pas reconnues par l'OCR (reconnaissance optique des caractères) de base de Transkribus. L'utilisation de Transkribus nous a aussi permis le découpage des images en zones textuelles que nous avons alors typées afin de préparer le tri et l'organisation logique des informations, étape également suivie pour les témoins déjà transcrits mais dont nous possédions les images.

Notre souci était en effet tout autant de produire une ressource textuelle pour les études linguistiques et juridiques que de permettre la réutilisation des données pour d'autres projets. Les témoins re-synchronisés étant majoritairement des manuscrits, il nous semblait important de conserver le plus possible d'informations graphiques afin de pouvoir fournir une base de travail acceptable à d'autres champs d'étude tels que la philologie ou la codicologie.

L'encodage actuel des témoins du corpus peut ainsi constituer un matériau d'entraînement d'HTR à d'autres projets ou une base d'apprentissage paléographique pour les témoins les plus anciens. Il permet également de reconstituer la transcription d'une page, ligne par ligne, en convoquant les images directement depuis les serveurs des institutions pour les témoins disposant d'un manifeste IIIF, ou en utilisant des images locales pour les autres.

II. Harmonisation des structures hétérogènes

Face au défi de rendre compatibles entre elles des structures séparées par jusqu'à six cents ans d'évolution de l'objet livre, des attentes graphiques et des normes éditoriales, le parti a été pris de se baser sur une structure à trois niveaux typés en anglais (part > chapter > section), permettant de rendre les structures les plus détaillées comme les plus simples. Le niveau de base du texte était ainsi le plus profond (section). Quelques partis ont été pris dans l'organisation des témoins, toujours appuyée sur la matérialité et les points communs entre les témoins : s'il arrivait qu'un témoin, dans une même partie, rassemblait ses chapitres selon une organisation matérialisée en deux parties par un autre témoin, la partie a été divisée en deux lors de l'encodage, et l'intervention éditoriale signalée en attribut.

La distinction a bien sûr été faite entre matière liminaire, corps du texte et annexes, le cas échéant.

L'harmonisation a également nécessité une mise à plat des structures internes des sections. Si l'encodage commun des rubriques manuscrites et des titres des imprimés n'a posé aucun problème, la distinction entre texte principal et notes a demandé plus de réflexion.

Dans les premiers témoins du corpus (Très Ancien Coutumier et Grand Coutumier), ainsi que le voulaient les codes graphiques et stylistiques propres à leurs époques, texte législatif et commentaire n'étaient pas distingués et ils ont été considérés comme texte principal. À partir du 16e siècle, cependant, les auteurs matérialisaient visuellement la distinction. Le texte mis en valeur y correspond généralement au texte législatif et le reste à un commentaire auctorial. Nous avons toujours cherché à consider le texte original du témoin comme le texte principal. Le texte législatif est donc encodé comme citation dans les témoins imprimés. Les notes, quel que soit leur rôle interne, sont encodées à leur place. L'intégrité des unités de texte est donc restituée dans l'encodage, lorsque la mise-en-page originelle nécessitait de les scinder.

III. Un modèle d'encodage XML-TEI

Le choix du standard XML-TEI a été une évidence initiale : ce dernier étant mondialement utilisé pour encoder les données textuelles et permettant d'enrichir très finement tout type de texte, écrit ou oral, nous étions grâce à lui en mesure de proposer un corpus largement compréhensible et exploitable par la communauté scientifique et les institutions patrimoniales. Un schéma d'encodage était cependant nécessaire pour resserrer l'usage de la TEI à notre corpus particulier et garantir l'homogénéité des données. Il sera disponible dans le dépôt Git du corpus.

Les nécessités d'un corpus lemmatisé en diachronie longue rendaient difficile l'application d'un schéma d'encodage conçu pour d'autres données. Notre schéma s'appuie sur des éléments généraux de la TEI tels que les divisions de texte (div), paragraphes (p), notes (note), ainsi que des éléments spécialisés pour le détail des caractéristiques grammaticales et lexicales des unités textuelles telles le word token (w) tel que détaillé ci-dessous par Mathieu Goux (PhD).

Le détail des métadonnées du corpus, en premier élément (teiHeader), comprend bien sûr toutes les personnes et institutions ayant contribué à l'établissement du fichier, une introduction éditoriale aux principes appliqués pour l'établissement du fichier (editorialDecl), en français et en anglais, ainsi que la description des sources matérielles (sourceDesc) et références identifiées dans le texte, tel que détaillé ci-dessous par Prune Decoux (PhD).

Un exemple de structure générale peut être simplifié ainsi :

• <TEI>
  • <teiHeader/>
  • <text xml:id="identifiant-temoin">
    • <front>
      • <titlePage xml:id="identifiant-temoin-frontMatter-1-titlePage"/>
      • <div type="dedication" xml:id="identifiant-temoin-frontMatter-2-dedication>
        • <head>À Monsieur de ...</head>
        • <p/>
        </div>
      </front>
    • <body>
      • <div type="part" xml:id="identifiant-temoin-01>
        • <head> Titre de partie</head>
        • <div type="chapter" xml:id="identifiant-temoin-01-01>
          • <head> Titre de chapitre</head>
          • <div type="section" xml:id="identifiant-temoin-01-01-01>
            • <head>Titre de section</head>
            • <quote>
              • <p>Texte législatif
                • <note>Clarification d'un terme.</note>
                </p>
              </quote>
            • <p>Commentaire général de l'auteur sur la section.
              • <note>Note sur le commentaire</note>
              </p>
            </div>
          </div>
        </div>
      </body>
    • <back/>
    </text>
• </TEI>

IV. Gestion des caractères anciens et abréviations

Le processus d’HTRisation se base sur le caractère. La machine devant considérer un caractère comme une seule unité, qu’il s’agisse ou non d’une abréviation, cela signifie de pouvoir donner au modèle un caractère unique pour représenter cette unité. Toutes les abréviations sont déclarées comme caractères Unicode, bien que la plupart des polices d’écriture ne les connaisse pas et ne puisse donc pas les afficher. Nous utilisons pour cela Junicode. Puisque la transcription automatique par HTR nous donnait les abréviations, graphies et caractères anciens, nous avons fait le choix de les garder aux côtés de leurs résolutions/régularisations respectives.

Le modèle XML-TEI nous permet en effet d’utiliser l’élément <choice> permettant de stocker deux alternatives pour un caractère, ici avec le couple <orig>/<reg>  pour les graphies anciennes:

con<choice><orig>ſ</orig><reg>s</reg></choice>titué

L’élément <choice> peut également accueillir d’autres couples d’éléments comme <am> et <expan> , permettant d’encoder ensemble une abréviation et sa résolution :

autrem<choice><am>ē</am><expan>en</expan></choice>t

Nous utilisons les <choice> au caractère car un même mot peut ainsi donner à la fois archaïsmes et abréviations, comme :

empe <choice><orig>ſ</orig><reg>s</reg></choice> ch <choice><abbr>ā</abbr><expan>an</expan></choice> t

Lorsque plusieurs du même type se suivent, nous avons cependant rejoint les deux afin d’alléger les fichiers déjà très lourds (la version lighter du Basnage, ne contenant ni informations graphiques ni élément <choice> car entièrement modernisée, pèse à elle seule 68 Mo !) :

<choice><orig>ſegnoꝛ</orig><reg>segnor</reg></choice>

I. Tokenisation

La tokenisation des témoins du corpus (soit, la délimitation des unités minimales d’analyse en « mots »), a répondu à plusieurs règles distinctes, selon l’origine temporelle et matérielle du témoin, avant et après l’invention de l’imprimerie. Nous avons globalement suivi les principes établis par l’ANR-DFG Presto, que nous résumons ici:

• Pour les imprimés, nous avons respecté autant que faire se pouvait les segmentations typographiques opérées par les auteurs et imprimeurs du temps, à la condition qu’elles ne rentraient pas en contradiction avec les découpes observées dans les états modernes de la langue. Pour les manuscrits, nous avons tranché certaines ambiguïtés en nous appuyant sur les référentiels de lemmatisation de français médiéval et du moyen-français. Notamment, nous avons repris les entrées du DMF comme faisant autorité, ou les graphies les plus fréquemment trouvées en cas de litige.
• Nous avons cependant généralisé ce principe, là où PRESTO opérait occasionnellement des fusions (par exemple, dans le cas des déterminants partitifs du type de la). Nous avons toujours considéré ici qu’il s’agissait de deux tokens distincts, la catégorisation morpho-syntaxique permettant, ensuite, de les identifier sans mal. Nous avons ainsi tâché, autant que faire se pouvait, de respecter la matérialité des témoins, y compris en termes de ponctuation, afin de conserver l’originalité de ces textes juridiques.
• En ce sens, les amalgames et enclises relevés régulièrement ont été étiquetés par l’intermédiaire de l’opérateur « + » ( est ainsi étiqueté « DE+LE » pour le lemme, « S+Da » pour l’étiquette PoS). En revanche, des erreurs de segmentation sporadiques (p.ex. ceregard relevé une fois dans un seul texte) ont été traitées comme deux tokens séparés.

II. Lemmatisation

La lemmatisation s’appuie sur les règles développées et suivies par le projet PRESTO, ainsi que par d’autres bases de données telles FRANTEXT. Les grands principes sont les suivants :

• Les lemmes sont en capitales, et suivent les conventions des dictionnaires d’usage: la forme singulier est retenue pour les substantifs, le masculin singulier pour les adjectifs, l’infinitif pour les verbes, et ainsi de suite. Nous avons conservé les lemmes IL(S) / ELLE(S) pour les pronoms personnels de rang 3 et 6, ainsi que certaines formes féminines des substantifs pour les titres et statuts.
• Si un token a survécu jusqu’à aujourd’hui, c’est la graphie contemporaine qui est choisie. Le token « honestes » est lemmatisé comme « HONNÊTE ». Cela est valable également pour les toponymes : « Roüen » a été lemmatisé comme « ROUEN ».
• Pour les mots disparus, les dictionnaires de l’ATILF et du CNRTL font référence.
• Les mots d’origine étrangère ont un lemme correspondant à leur token. « solvit » (lat.) est lemmatisé comme « SOLVIT ».
• Pour les nombres, les chiffres romains et les chiffres arabes ont été lemmatisés respectivement avec des chiffres romains et des chiffres arabes. Les chiffres écrits en lettres ont été traités « comme des mots ».
• Les abréviations ont été lemmatisés comme le mot qu’ils abrégeaient (« M » a été lemmatisé comme « MONSIEUR »).
• Enfin, et pour les hapax, noms propres, etc. le lemme correspond au token, sauf si le nom propre, pour les auteurs antiques par exemple, est mieux connu sous sa forme moderne.

III. Étiquetage PoS (« Part of Speech » / Parties du discours)

Le jeu d’étiquettes a été repris, tel quel, du jeu Presto_min : nous renvoyons donc à la documentation du projet pour avoir les détails de l’étiquetage. Nous avons choisi ce jeu car il était pensé pour la diachronie longue du français et compatible avec la base de données FRANTEXT.

Chaque étiquette PoS est déterminée par deux caractères, trois pour les verbes : la première, majuscule, donne la catégorie grammaticale générale du token (Nom, Verbe, Conjonction…) ; la seconde, une sous-catégorie (possessif, démonstratif, commun, propre…) et la troisième, uniquement pour les verbes, son statut morphologique (mode fini ou infinitif). Cet étiquetage ne précise pas d’autres indications morphologiques : il faut pour ce faire s’appuyer sur le co(n)texte ou la morphologie du token en lui-même pour affiner la recherche d’occurrences.

Lorsque le mot-forme correspondait à la forme du participe passé/présent, le token a été traité comme un participe. Dans tous les autres cas il a été considéré comme un nom commun. L’approche formelle a donc été choisie au détriment de l’approche fonctionnelle, pour éviter les ambiguïtés liées à la valeur nominale/valeur du participe, les tokens étaient trop nombreux pour l’analyse au cas par cas. Par exemple, fait/faite et atteint/atteinte a toujours été étiquetté comme un participe passé, alors que renvoi, apprenti est toujours nom commun.

IV. Attribut @cert

L'attribut @cert a été ajouté dans la balise pour l'anodine minorité des tokens dont l'étiquetage était potentiellement erroné. Il est destiné à permettre de repérer aisément les erreurs potentielles, dans le cas où un agent aurait l'occasion de perfectionner l'étiquetage du corpus une fois le projet terminé.

La valeur "low" a été assignée aux tokens qui n'ont pas pu faire l'objet d'une révision à la suite de la lemmatisation et l'annotation automatiques. Pour ces tokens, les valeurs des attributs @lemma et/ou @pos sont inconnues ou multiples.

La valeur "medium" concerne les tokens mal interprétés lors de la lemmatisation et l'annotation automatiques qui ont pu être analysés manuellement ou semi-automatiquement, mais pour lesquels, en raison de l'importance de leur fréquence, les erreurs sont probables (p.ex., le mot-forme que et ses variantes graphiques, connaissant une fréquence considérable dans tous les textes du corpus, pour lequel l'annotateur automatique proposait systématiquement plusieurs valeurs potentielles : conjonction de subordination, pronom relatif etc.)

V. Structure générale

Chaque token est encapsulé dans une balise <w>, possédant trois attributs :

• @lemma : le lemme
• @n : le numéro du token dans la linéarité du texte. Cet attribut n’est utile que pour l’affichage des témoins, et n’est pas convoqué dans les recherches linguistiques.
• @pos : la catégorie grammaticale (« Part Of Speech »)
• un quatrième attribut @cert vient compléter les balises des tokens potentiellement erronnés

L’ordre des attributs n’est pas signifiant dans la balise concernée.

---

L’objectif est d’identifier les références doctrinales, normatives ou jurisprudentielles que les auteurs utilisent pour étayer leur discours ou leur raisonnement juridique, afin d'enrichir la base de données du projet ConDÉ. Les références trouvées sont compilées, pour chaque témoin, au sein de tableurs Excel récapitulatifs.

À partir de ces données, trois grandes catégories sont susceptibles d’encodage : les acteurs (I), les œuvres (II) et les arrêts (III).

I. Acteurs

Tous les noms de personnes ont été relevée, pourvu qu’elles aient un rapport direct avec la matière juridique (rédaction ou analyse de texte juridique). Sont ainsi exclus les noms des parties à un procès, celui de leur avocat ou encore les marqueurs temporels, de type « sous le règne de Philippe le Bel ».

Cette catégorie est encodée dans le <sourceDesc/> et comporte des <listPerson/>, dotées d’attributs différents permettant d’affiner les classements. Ainsi, à ce jour, six types différents d’acteurs ont été identifiés:

• <listPerson type="lawyer"/> : juristes, praticiens, magistrats...
• <listPerson type="churchman"/> : ecclésiastiques (pape), spécialistes de droit canon
• <listPerson type="philosopher"/> : philosophes
• <listPerson type="historian"/> : historiens
• <listPerson type="king"/> : souverains, roi, empereurs
• <listPerson type="others"/> : autres (inconnus, divers).

Au sein de chacune des <listPerson/>, les auteurs disposent d'une fiche qui comporte leur identifiant unique @xml:id, un lien vers une notice d'autorité quand elle existe dans un @sameAs, et la mention la plus exhaustive possible de leur nom. Les fiches les plus renseignées indiquent le nom et le prénom, version française et version latine/internationale.

• <listPerson type="lawyer">
  • <person xml:id="aimoin" sameAs="https://catalogue.bnf.fr/ark:/12148/cb125156680">
    • <persName xml:lang="la">
      • <surname> Floriacensis </surname>
      • <forename> Aimoinus </forename>
    • </persName>
    • <persName xml:lang="fr">
      • <surname> Fleury (de) </surname>
      • <forename> Aimon </forename>
    </persName>
  • </person>
• </listperson>

Au sein de l'œuvre, les noms de ces acteurs sont encadrés de l'élément <ref/>, assortie d'un attribut @corresp et d'un pointeur vers leur identifiant.

Dans son ouvrage Historiae Francorum, <ref corresp="#aimoin>Aimon de Fleury analyse le droit canon</ref> qui est repris dans l'arrêt rendu en la Grand-Chambre du 16 janvier 1667.

II.Œuvres

Un travail identique de compilation des œuvres citéesa été mené ;la liste des ouvrages va être encodée dans le <sourceDesc/> et ils seront dotés d'un identifiant unique et d'une notice d'autorité.

• <bibl type="reference" xml:id="hist-francorum" sameAs="https//blablaba">
  • Historiae Francorum
• </bibl>

Au sein des textes, les références à ces travaux sont encadrées de l'élément <ref/>, assortie de l'attribut @corresp et d'un pointeur vers leur identifiant.

Ex:

Dans son ouvrage <ref corresp="#hist-francorum">Historiae Francorum</ref>,<ref corresp="#aimoin">Aimon de Fleury analyse le droit canon</ref>qui est repris dans l'arrêt rendu en la Grand-Chambre du 16 janvier 1667.

III. Arrets

Les arrêts mobilisés vont, eux, être encodés dans le corps du texte. Les termes seront encadrés par l'élément <decision>.

Ex:

Dans son ouvrage <ref corresp="#hist-francorum">Historiae Francorum</ref>, <ref corresp="#aimoin">Aimon de Fleury analyse le droit canon</ref>qui est repris dans l'<decision>arrêt rendu en la Grand-Chambre du 16 janvier 1667</decision>.