Réunion 2023-11-07

[emchateau]

• Sara a poursuivi les transcriptions.
• Josselin a fait la demande CREMMA.
• pour avancer, il est nécessaire d’arrêter les règles de transcription adoptées
• Josselin a travaillé sur le schéma du modèle expert (en ODD)

Organisation du travail

Travaillent une semaine sur deux sur le projets, mais en décalé. Autant que possible, essayer de travailler en parallèle sur le projet.

Schéma

Il est préférable d’exprimer les règles en pure ODD plutôt qu’en RNG. Schematron ne fait pas partie de la TEI, faut-il l’implémenter alors que nous n’en aurons pas réellement besoin.

Par exemple :

• Dans la partie métadonnées, on cite la source et le carton. Faut-il une règle schematron pour valider qu’un seul item est impératif ?
• Type et valeur dans l’élément.
• Framework, procédure de l’expertise

L’étape suivante consistera à saisir les définitions dans la documentation du schéma. Il n’est sans doute pas nécessaire de traduire.

Faut-il en faire un pour les IAD ? les réceptions ?

Pour les fiches prosopographique, on ne diverge pas du schema version 2. On utilise l’ontologie pour les relations. Il y a un problème avec les # dans les cibles.

Décisions à prendre:

• implémenter les règles du schéma en pure ODD plutôt que RNG
• faire un essai pour les règles schematron (et limiter à 4 cas de figure importants)
• réintégrer la documentation au schéma
• faut-il traduire la documentation (plutôt non)
• faut-il faire un schéma pour les IAD et les réceptions (plutôt non)
• appliquer le schéma pour vérifier que les documents EAC-CPF sont valides
• documenter dans le README l’organisation propre du répertoire
• pour le moment, ne pas produire un odd EAC-CPF version 2

Transcriptions

Sara a fait des essais de transcription sur toutes les mains pour faire des essais. Maintenant elle travaille principalement sur Vilain. Parfois, c’est difficile. Frustrant quand n’arrive pas à lire. Pour le moment, utilisation de balises TEI <gap> et de <unclear> avec un attribut de dimension (nombre de mots).

Les essais de transcription ont permis d’identifier différents problèmes qui ont été notés dans le journal. Par exemple: les pointillés pour les comptes.

i en forme de j. Quel point de vue adopter alors que le logiciel raisonne sur la forme des lettres plutôt que les mots. Actuellement choix du i.

Nombreux mots aglutinés avec une majuscule.

• utiliser <gap> et de <unclear> avec un attribut de dimension (nombre de mots)
• utiliser <add> avec place
• utiliser <orig>

Un tableau comparatif a été établi pour les règles de transcription. Il est parfois difficile d’avoir des règles générales applicables pour tout le corpus. Cela varie beaucoup selon les mains, en même temps on a besoin d’avoir des règles stables qui documentent nos pratiques.

Question des mains. Il y a souvent des changements de mains. Certains ajouts sont peut-être de la main de l’expert (cf. signatures).

Il ne me semble pas que nous devions entraîner un modèle pour lire le texte raturé (même si en soit cela pourrait être intéressant). Par contre, nous avons besoin de marquer les passages raturés pour ne pas entraîner fautivement la machine. Utiliser un <del>.

Je suis d’accord avec le fait que notre cas d’usage est assez proche de celui de Nouvelles France numérique qui a déjà réfléchi à ces questions. Mais partir de nos besoins avant de choisir me semble la bonne démarche.

Pour les mots agglutinés, il y a clairement une difficulté.

Il pourrait être intéressant de pouvoir documenter visuellement les phénomènes identifiés. Pour cela, essayer d’utiliser un outil d’annotation comme les images du corpus sont en IIIF.

https://annotorious.github.io

Voir discussion https://github.com/orgs/anrExperts/discussions/21