Ressources numériques en sciences humaines et sociales OpenEdition Nos plateformes OpenEdition Books OpenEdition Journals Hypothèses Calenda Bibliothèques OpenEdition Freemium Suivez-nous

Indices homériques, vérité et mensonge chez Lucien de Samosate

Introduction

Lucien de Samosate est un écrivain de la Seconde Sophistique, un courant culturel et littéraire qui s’est épanoui au deuxième siècle de notre ère. Les figures de ce mouvement, qui s’en revendiquent plus ou moins explicitement, ont pour point commun une culture littéraire approfondie et une maîtrise avancée de l’art rhétorique, fruits d’une éducation longue et exigeante. Ces hommes “formés et éduqués” (πεπαιδευμένοι) connaissent souvent par cœur l’Iliade, l’Odyssée et les grands classiques, et sont rompus aux exercices rhétoriques qui leur ont appris à faire parler dieux et héros, à présenter le pour et le contre de chaque cause, à réécrire des épisodes de mythes et de légendes. Par jeu autant que par habitude ou encore par volonté de montrer leur érudition, ces nouveaux sophistes émaillent leurs écrits de références à Homère.

Mon mémoire porte notamment sur la présence de l’univers homérique dans l’oeuvre de Lucien, entre allusions, citations, et jeu avec les notions de mythes, de vérité et de mensonge.

De nombreuses études ont recensé les vers homériques dans les écrits de Lucien. La plupart des éditions soulignent, au moyen de notes et de renvois, des termes manifestement homériques, utilisés exprès par Lucien, comme clins d’oeil, allusions, ou plus largement dans une démarche d’imitation (μίμησις) de l’oeuvre homérique. Toutefois, il n’y a pas, à ma connaissance, d’éditions numériques de tels recensements. La recherche exhaustive des termes liés aux notions de vérité, de mensonge, de réalité et de mythes, ou encore de vraisemblance, ne semble pas non plus disponible sur des plateformes publiques.

Le logiciel R semble tout indiqué pour une telle analyse textuelle, difficile à effectuer manuellement du fait de l’ampleur des œuvres de Lucien. Repérer des “indices homériques” prédéfinis, quantifier et présenter les résultats de manière organisée permettrait à la fois d’orienter mes recherches sur le mémoire et d’étayer des constats déjà établis à l’issue de mes lectures préparatoires.

Pour mener à bien ce travail, il est tout d’abord nécessaire d’identifier et préparer le corpus et les outils de recherche. Au terme de cette préparation, une triple détection sera effectuée: 1. vers ou hémistiches homériques, 2. autres “indices homériques” (éléments de phonétique, de morphologie, de syntaxe et de vocabulaire propre à Homère), 3. champ lexical de la réalité/vérité, du mensonge et du mythe.

1. Travail préparatoire

Il serait possible d’effectuer l’analyse sur l’intégralité du corpus de Lucien, qui comporte environ soixante-dix œuvres (selon les éditions, et notamment selon l’exclusion d’oeuvres jugées apocryphes). Une sélection semble utile au regard du thème du mémoire, qui se focalise davantage sur les rapports de confiance et de méfiance vis-à-vis de l’oeuvre homérique, via les notions de mensonge, de vérité, de réalité, de mythes, etc. On se concentre donc sur quelques dialogues comico-philosophiques, des récits et quelques pièces diatribiques où ces thèmes semblent davantage abordés. Une telle sélection est bien sûr arbitraire et on pourrait étendre l’analyse à tous les textes attribués à Lucien, disponibles en ligne.

La sélection porte sur les pièces suivantes: Alexandre ou le faux ProphèteLa Double accusation ou les JugementsCharon ou les ContemplateursSur les sacrificesDialogues des dieuxDialogues des mortsDiscussion avec HésiodeHistoires vraiesIcaroménippe ou le Voyage aérienJupiter confonduJupiter tragiqueMénippe ou la NécyomancieNigrinus ou le Portrait d’un philosophePhilopseudès ou l’IncréduleComment il faut écrire l’histoire.

Ces discours sont disponibles en ligne sur le site Perseus/Scaife notamment, en format txt ou xml. Il est plus facile de télécharger les textes bruts, mais la numérotation est perdue; or celle-ci s’avérera nécessaire pour le traitement des résultats de recherche. Il semble donc indispensable d’utiliser les fichiers en format xml qui, eux, ont une architecture détaillée (par sections, sous-sections, paragraphes, lignes, etc.).

La première étape consiste à télécharger les fichiers xml, à les enregistrer sur son dossier de travail et à préparer leur utilisation sur R (extraction et traitement des racines). La deuxième étape consiste à parcourir chaque fichier xml pour copier son contenu, afficher le titre en majuscule, extraire le contenu de chaque paragraphe, l’épurer des caractères latins (commentaires d’éditeur dans les fichiers xml), les doubles espaces résiduels, les doubles sauts de lignes, les signes de ponctuation, pour éviter de perturber les opérations ultérieures de recherche. Par “paragraphes”, on entend en réalité “sections de référence” des oeuvres de Lucien: il existe une numérotation conventionnelle, chaque section pouvant comprendre plusieurs “paragraphes” au sens où nous l’entendons de sections de texte délimitées par des retours à la ligne. Ces sections sont repérables aux balises “< div >< / div >” dans les fichiers xml.

2. Recherche des citations homériques (hémistiches)

2.1. Création de la liste des hémistiches de l’Iliade et de l’Odyssée

Il est tout d’abord nécessaire de télécharger les 24 chants de l’Iliade, puis ceux de l’Odyssée, en format xml sur le site de Perseus/Scaife. En raison de l’ampleur de ces fichiers, il faut procéder par groupes de chants (le site ne pouvant supporter des requêtes trop importantes). Ces fichiers sont ensuite fusionnés en un seul fichier xml. La même chose est faite pour l’Odyssée.

Après nettoyage des textes de l’Iliade et de l’Odyssée, il faut maintenant générer la liste des hémistiches. Il aurait été possible de créer la liste des vers entiers, mais il semble plus intéressant d’avoir à disposition la liste des hémistiches, pour deux raisons: la première est que toute recherche d’hémistiches aboutira a minima aux mêmes résultats que la recherche de vers homériques; la deuxième raison tient au fait que les hémistiches homériques présentent souvent une unité sémantique qui justifie leur citation indépendamment de leurs correspondants.

Cette étape est la plus délicate. Il est en effet très difficile d’établir des règles automatiques pour la détection des hémistiches homériques, puisque leur détermination repose sur la prosodie grecque, indétectable en tant que telle dans le texte brut. Il est possible de découper chaque vers en deux, en arrondissant au nombre supérieur de mots, afin d’éviter un découpage au milieu des mots. Il faut néanmoins avoir conscience du caractère approximatif de cette démarche, qui fonctionnera uniquement lorsque la césure homérique véritable correspond au découpage ainsi paramétré. La même chose est faite pour l’Odyssée.

Une méthode plus précise (mais toujours imparfaite) consiste à retranscrire dans un script R les règles paramétrables de la métrique grecque afin de constituer un compteur qui attribue un temps à chaque caractère et permet de scinder chaque vers. La logique est la suivante: concernant le premier caractère, soit il s’agit d’un espace, d’une apostrophe ou d’une consonne, et le compteur métrique n’est pas incrémenté, soit il s’agit, avec le caractère suivant, d’une diphtongue, en quel cas le compteur est incrémenté de 2 et le rang de 2 également (pour passer au caractère après la diphtongue et éviter ainsi de passer de nouveau en revue la deuxième lettre), soit il s’agit d’une voyelle qui est nécessairement longue (compteur +2, rang +1). Pour les caractères suivants, la boucle est un peu plus complexe, puisque les diphtongues peuvent être longues ou courtes (si certaines sont situées en fin de mot) et que les voyelles brèves peuvent être longues si elles sont suivies d’une double consonne ou de deux consonnes.
A chaque fois qu’un caractère est traité, le rang a été incrémenté d’un ou de deux unités, et on passe ainsi à l’examen du caractère suivant ou de celui d’après. Le résultat est une matrice contenant le caractère, son rang et le compteur métrique associé. 

La quantité des voyelles n’obéit pas entièrement à des règles (absolues ou liées à la métrique): il est parfois nécessaire de consulter un dictionnaire. Typiquement, un “α” final peut être long ou court: long dans “μῆνιν ἄειδε θε Πηληϊάδεω Ἀχιλῆος”, court dans “αἰδεῖσθαί θʼ ἱερῆα καὶ ἀγλαὰ δέχθαι ἄποινα”. De plus, comme les vers se divisent rarement en deux groupes égaux de mots correspondant à la fois à deux groupements métriques équilibrés et à deux unités de sens, il est nécessaire d’effectuer un choix: soit le mot contenant la lettre à laquelle le compteur est arrivé à sa moitié doit être rattaché au premier hémistiche, soit il doit l’être au second. Aucune de ces deux règles ne convenant à tous les vers, il semble préférable de conserver les deux options et de créer deux paires d’hémistiches possibles. Il devient alors extrêmement probable qu’une des deux paires correspondent au bon découpage. 

2.2. Détection des hémistiches

Afin de détecter les hémistiches homériques dans les oeuvres sélectionnées de Lucien et d’organiser les résultats de manière organisée, il faut que le script parcoure, pour chaque hémistiche (première boucle), chacune des oeuvres sélectionnées (deuxième boucle), et, en cas de correspondance, mémorise le titre de l’oeuvre et l’hémistiche concerné, pour enfin restituer les résultats sous forme d’un tableau.

Cette opération représente un nombre très élevé de calculs (au moins cinquante cinq mille hémistiches recherchés dans les chaînes de caractère d’une quinzaine d’oeuvres de plusieurs milliers de caractères chacune).

2.3. Conclusion

Une centaine d’hémistiches de l’Iliade et de l’Odyssée est détectée dans le corpus de recherche. Une analyse de ces résultats permettra de distinguer les “véritables” emprunts homériques de possibles coïncidences: par exemple, “δὲ καὶ ἄλλα” n’est sans doute ni un véritable hémistiche homérique (trop court) ni une particularité homérique (la combinaison de ces trois est très courante); à l’inverse “τε καὶ ἀνέρες ἱπποκορυσταὶ” est très probablement une citation homérique. Il sera également intéressant de vérifier si ces citations sont relevées par les éditions de référence, ou si certains hémistiches détectés par le script ne sont pas signalés.

extrait des résultats obtenus dans les écrits Alexandre, La Double Accusation et Les Observateurs.

3. Détection des “indices homériques”

3.1. Définition des “indices homériques”

La langue homérique présente de nombreuses particularités, tant phonétiques que morphologiques, syntaxiques, sémantiques et stylistiques. Ces particularités sont dues à l’ancienneté de ces chants, ainsi qu’à la diversité des dialectes dont est issu le texte homérique canonique. La langue ayant évolué depuis les temps archaïques jusqu’à la période de la Seconde Sophistique, la présence de ces particularités ou “indices” homériques dans les oeuvres de Lucien ne peut normalement résulter d’une coïncidence, mais bien illustrer une allusion homérique de l’écrivain.

Nous distinguons deux catégories d’indices.

La première regroupe des particularités phonétiques, morphologiques, syntaxiques et sémantiques énumérées sur le site Hypothèses et qui peuvent faire l’objet d’un codage univoque. Par exemple, la recherche “\b\wῃσι\b” est bien univoque, dans le sens où elle cherche tous les mots s’achevant par les caractères ”ῃσι”, une désinence de datif archaïque que l’on retrouve dans l’Iliade et l’Odyssée mais pas en prose attique classique.
A l’inverse, la recherche”\b\w*θι\b” est équivoque, puisque si elle vise à repérer les adverbes archaïques en “θι”, elle aboutira également à la détection de toutes les formes d’impératifs en “θι” qui relèvent de l’attique classique.

La deuxième catégorie regroupe un certain nombre d’épithètes dites “traditionnelles” ou “homériques”, qui servent à caractériser certains dieux ou héros (source: Wikipedia par exemple).

3.2. Détection et restitution

Les deux recherches sont effectuées de manière séquentielle. Pour chacune, le script parcourt chaque terme. Pour chacun d’eux, il balaie toutes les lignes du tableau de données créé précédemment à partir des fichiers txt, et, à chaque fois qu’un terme est détecté dans une ligne, le script extrait le mot correspondant. La liste des paragraphes ainsi que le nombre total de correspondances est ensuite mis à jour, avant de poursuivre la recherche.

matching_paragraphs <- list()
total_matches <- 0

# boucle correspondant à la 1ere recherche
for (term in search_terms_homerismes) {
  for (i in 1:nrow(combined_df)) {
    paragraph <- combined_df$paragraph[i]
    if (grepl(term, paragraph)) {
      words_found <- grep(term, unlist(strsplit(paragraph, "\\s+")), value = TRUE)
      for (word in words_found) {
        matching_paragraphs[[length(matching_paragraphs) + 1]] <- data.frame(
          source = combined_df$source[i],
          paragraph = paragraph,
          search_type = "homerismes",
          word_found = word,
          stringsAsFactors = FALSE
        )
      }
      total_matches <- total_matches + length(words_found)
    }
  }
}

# boucle correspondant à la 2e recherche
for (term in search_terms_epithetes) {
  for (i in 1:nrow(combined_df)) {
    paragraph <- combined_df$paragraph[i]
    if (grepl(term, paragraph)) {
      words_found <- grep(term, unlist(strsplit(paragraph, "\\s+")), value = TRUE)
      for (word in words_found) {
        matching_paragraphs[[length(matching_paragraphs) + 1]] <- data.frame(
          source = combined_df$source[i],
          paragraph = paragraph,
          search_type = "epithetes",
          word_found = word,
          stringsAsFactors = FALSE
        )
      }
      total_matches <- total_matches + length(words_found)
    }
  }
}

df <- do.call(rbind, matching_paragraphs)

output_file <- "XXX/resultats/indices_homeriques_lucien.xlsx"
write.xlsx(df, output_file)
print(df[, c("source", "word_found", "search_type")])
##                     source   word_found search_type
## 1            alexander.txt       ἔσσεαι  homerismes
## 2            alexander.txt       Δίζεαι  homerismes
## 3             nigrinus.txt       γένηαι  homerismes
## 4            alexander.txt      πελάζεο  homerismes
## 5            alexander.txt           φι  homerismes
## 6      historiae_verae.txt    μακάρεσσι  homerismes
## 7     quomodo_historia.txt      Πέρσῃσι  homerismes
## 8            alexander.txt   τεκμαίροιο  homerismes
## 9            alexander.txt      Πόντοιο  homerismes
## 10           alexander.txt      βιότοιο  homerismes
## 11           alexander.txt      νούσοιο  homerismes
## 12           alexander.txt   Ἀμφιλόχοιο  homerismes
## 13           alexander.txt      Ἴστροιο  homerismes
## 14       contemplantes.txt     ἠϋκόμοιο  homerismes
## 15   dialogi_mortuorum.txt       γένοιο  homerismes
## 16       icaromenippus.txt    αἰγιόχοιο  homerismes
## 17  iuppiter_tragoedus.txt     καθέζοιο  homerismes
## 18            nigrinus.txt      ἠελίοιο  homerismes
## 19           alexander.txt          μιν  homerismes
## 20    quomodo_historia.txt          μιν  homerismes
## 21     historiae_verae.txt      εἴδομεν  homerismes
## 22     historiae_verae.txt      εἴδομεν  homerismes
## 23     historiae_verae.txt      εἴδομεν  homerismes
## 24     historiae_verae.txt      εἴδομεν  homerismes
## 25     historiae_verae.txt      εἴδομεν  homerismes
## 26  iuppiter_tragoedus.txt      εἴδομεν  homerismes
## 27           alexander.txt     Τιέμεναι  homerismes
## 28           alexander.txt    πλωέμεναι  homerismes
## 29     historiae_verae.txt   προϊέμεναι  homerismes
## 30 iuppiter_confutatus.txt          κεν  homerismes
## 31  iuppiter_tragoedus.txt          κεν  homerismes
## 32    quomodo_historia.txt          κεν  homerismes
## 33           alexander.txt         δῶμα  homerismes
## 34  iuppiter_tragoedus.txt        μῆτις  homerismes
## 35      dialogi_deorum.txt          ἰδέ  homerismes
## 36           alexander.txt    ἀλεξίκακε   epithetes
## 37    quomodo_historia.txt   ἀλεξίκακος   epithetes
## 38      de_sacrificiis.txt  κυανοχαίτην   epithetes
## 39           alexander.txt       Φοῖβος   epithetes
## 40      de_sacrificiis.txt    γλαυκῶπιν   epithetes
## 41      dialogi_deorum.txt    γλαυκῶπις   epithetes
## 42  iuppiter_tragoedus.txt    γλαυκῶπις   epithetes
## 43  iuppiter_tragoedus.txt  τριτογένεια   epithetes
## 44      dialogi_deorum.txt ῥοδοδάκτυλος   epithetes
## 45   dialogi_mortuorum.txt  καλλίσφυρον   epithetes

Il est intéressant de connaître la fréquence d’apparition des “homérismes” dans les œuvres de Lucien, leurs types, et ceux qui en sont absents. Pour cela, on crée un tableau avec deux colonnes: la première recense les différents termes recherchés, et l’autre recense le nombre de correspondances trouvées. Ces dernières sont déterminées au moyen d’une fonction “term” appliquée à chaque terme de recherche et qui renvoie des valeurs boléennes (1 pour chaque correspondance), qui sont ensuite sommées.

# calcul du nombre de correspondances pour chaque terme de recherche
results <- data.frame(
  search_term = c(search_terms_homerismes, search_terms_epithetes),
  matches = sapply(c(search_terms_homerismes, search_terms_epithetes), function(term) {
    sum(grepl(term, combined_df$paragraph))
  }),
  stringsAsFactors = FALSE
)

output_file_results <- "XXX/resultats/resultat_recherches_indices_homeriques_lucien.xlsx"
write.xlsx(results, output_file_results)

4. Détection du champ lexical de la vérité, du mensonge et du mythe

L’attitude des intellectuels (rhéteurs, philosophes, historiens notamment) vis-à-vis de l’oeuvre homérique et plus précisément des récits merveilleux ou “mythes” qu’elle contient, est complexe: beaucoup critiquent les “mensonges” d’Homère et n’y ajoutent pas foi, tout en professant non seulement un attachement profond au poète et à son oeuvre (qu’ils ont tous longuement étudiés pendant leur cursus scolaire), mais aussi la reconnaissance d’une “imitation” (μίμησις) réussie de la réalité, ainsi que la croyance dans le caractère historique des cadres de l’épopée (guerre de Troie, vie des héros).

L’analyse de ces rapports complexes est rendue plus difficile encore par les différences de vocabulaire entre le français et le grec ancien: il n’y a pas d’équivalent en grec ancien des mots, pourtant fondamentaux, de “vérité” et de “mensonge”, puisque ἀλήθεια et ψεῦδος signifient à la fois respectivement “réalité” et “vérité”, “mensonge” et “inadéquation avec la réalité”.

Lucien est un érudit: il connaît les reproches adressés à Homère et plus largement aux poètes, leur fondement intellectuel et philosophique (on pense notamment à la République de Platon), mais aussi la critique littéraire, de la Poétique d’Aristote aux études alexandrines. Dans ses oeuvres, il joue avec les notions employées par ces critiques, et l’on retrouve de nombreuses occurrences de termes liées à la réalité, au mensonge, à la tromperie, à la croyance, à la crédibilité ou la crédulité, et bien sûr aux mythes et à Homère lui-même.

4.1. Constitution de la liste des termes recherchés

Nous cherchons les champs lexicaux de la réalité/vérité (ἀλήθειαἔτυμος), du mensonge/inadéquation à la réalité (ψεῦδος), de la “forgerie” (πλάσμα), de la crédibilité (πιθανός) et de son contraire (παράδοξος), des apparitions (φαντασίατέρασμα), de la confiance (πίστις), du mythe (μῦθος, mais aussi ὡς φασι et ὡς φησι qui introduisent usuellement l’énoncé de récits mythologiques), ainsi que les mentions du poète Homère lui-même.

En raison des déclinaisons et de l’accentuation grecques, il est nécessaire de définir des chaînes de caractère sufisamment longues pour ne capturer que les notions désirées (ou du moins, minimiser les résultats non voulus), mais suffisamment courtes pour englober le maximum de formes fléchies.

Voici la liste de chaînes de caractères recherchées:

search_terms <- c(  "ἀλήθ", "ἀληθ", "ψεῦ", "ψευ", "ψεύ", "μῦθ", "μύθ", "μυθ", "ἔτυμ", "ἐτύμ", "ἐτυμ",  "πίθα", "πιθά", "πιθα", "πλάσμ", "πλασμ", "πλασά", "πλάττ", "πλαττ", "Ὅμηρ", "Ὁμήρ",  "Ὁμηρ", "τέρατ", "τεράτ", "τερατ",  "τέρασμ", "τεράσμ", "τερασμ", "τέραστ", "τεράστ",  "τεραστ", "ὡς φασι", "ὡς φησι",  "φάντασμ", "φαντάσμ", "φαντασμ", "πίστ", "πιστ",  "παράδοξ", "παραδόξ", "παραδοξ")

4.2. Détection et restitution

La première étape consiste simplement à appeler les fichiers à traiter, à définir les termes de la recherche et à initialiser le compteur.

Vient ensuite la recherche elle-même. Une boucle passe en revue chacun des textes du corpus. Une deuxième boucle interne passe en revue chacun des termes de la recherche, et la fonction grep détecte ces chaînes de caractères dans le texte, et renvoie la ligne correspondante. Une troisième boucle interne s’applique à chaque correspondance trouvée, détecte le mot contenant la chaîne de caractères en question (paste0("\\b\\w*", term, "\\w*\\b")). Une quatrième boucle crée, pour chaque mot détecté, une nouvelle entrée dans la liste “matching_paragraphs” avec le nom du fichier où le mot a été trouvé (“source”), la chaîne de caractères recherchée (“term”), le mot trouvé (“word”) et le texte du paragraphe où se situe de mot (“paragraph”).

A noter: malgré l’encodage UTF-8, une vérification manuelle montre qu’en de rares occasions, des termes ne sont pas trouvés. C’est notamment le cas, semble-t-il, de mots commençant par “ἀ”. Une recherche séparée est faite pour ces mots, avec des résultats mitigés (quelques mots détectés, mais “ἀπίθανον” de La double accusation n’est pas relevé).

La troisième étape consiste à restituer les résultats sous forme de deux fichiers Excel, afin de poursuivre mes recherches pour le mémoire. Le premier fichier Excel (“verites&mensonges_lucien.xlsx”) restitue les quatre informations décrites plus haut: fichier, chaîne recherchée, mot, paragraphe. Le deuxième (“resultats_recherches_verite&mensonge_lucien”) restitue le nombre de mots trouvés par chaîne de caractères recherchée.

4.3. Analyse de texte et visualisation

Le texte des paragraphes où se situent les mots trouvés en lien avec les notions de réalité, de vérité, de mensonge, de fiction, de croyance et de mythes a été sauvegardé au terme de ces recherches. Il peut être intéressant de détecter les mots les plus fréquents dans cette compilation de textes, afin de dégager, éventuellement, des nouveaux champs sémantiques.

Le première étape est de combiner les textes des mots et des paragraphes trouvés en un vecteur unique, de nettoyer le texte d’éventuelles scories (ex: caractères latins) et des signes de ponctuation, et d’éliminer les “stop words”, ces mots très fréquents sans valeur sémantique forte. Pour la détermination de cette liste de “stop words”, on repart de celle utilisée au premier semestre et on la complète de termes présents dans le corpus de Lucien. Cette liste est enregistrée dans le dossier “outils”. On crée ensuite un tableau, avant de classer les mots par fréquence décroissante. On garde en mémoire les cent mots les plus fréquents et on affiche les vingt mots les plus fréquents.

df_excel <- read_excel("XXX/resultats/verite&mensonges_lucien.xlsx")

paragraphs <- df_excel$paragraph
words <- df_excel$word
combined_text <- c(paragraphs, words)

stopwords_file <- "XXX/outils/stopwords_greek.txt"
stopwords <- readLines(stopwords_file, warn = FALSE)
combined_text <- gsub("[[:punct:]]", " ", combined_text)
combined_text <- gsub("[a-zA-Z]", " ", combined_text)
words <- unlist(strsplit(combined_text, "\\s+"))
words <- words[!tolower(words) %in% stopwords]

# création d'une liste de mots, conversion en tableau de fréquence et tri
word_freq <- table(words)
word_freq_df <- as.data.frame(word_freq)
word_freq_df <- word_freq_df[order(-word_freq_df$Freq), ]

# affichage
top_100_words <- head(word_freq_df, 100)
top_20_words <- head(word_freq_df, 20)
print(top_20_words)
##         words Freq
## 5649 Μένιππος   86
## 8486 Τυχιάδης   83
## 392     ἀληθῆ   81
## 3576    Ἑρμῆς   80
## 3927     Ζεύς   64
## 6259     ὅλως   63
## 399    ἀληθῶς   62
## 9164   ψεῦδος   59
## 6265   Ὅμηρος   58
## 9005    Χάρων   53
## 6365     ὁρᾷς   46
## 377  ἀληθείας   45
## 6264   Ὅμηρον   45
## 6175    οἶμαι   43
## 9058      χρὴ   43
## 6236   ὀλίγον   42
## 8485  Τυχιάδη   42
## 2303    δοκεῖ   39
## 8834 Φιλοκλῆς   39
## 2577    εἶδον   37

Vient ensuite l’étape de la visualisation. On choisit le graphique “cirrus” qui a l’avantage de présenter de manière esthétique les mots les plus fréquents en modulant leur taille.

set.seed(1234) 
wordcloud(words = top_100_words$words, freq = top_100_words$Freq, min.freq = 2, scale = c(3.5, 0.15),
          colors = colorRampPalette(brewer.pal(9, "Set1"))(100), random.order = FALSE, rot.per = 0.1, 
          use.r.layout = TRUE, fixed.asp = TRUE, max.words = 100)

Logiquement, ce graphique fait apparaître des mots correspondant aux chaînes de caractères recherchées. Cela est intéressant dans la mesure où l’on aperçoit la fréquence relative de ces termes, mais par définition, leur proportion est sur-représentée par rapport aux autres termes contenus dans les paragraphes, puisque ceux-ci n’ont pas fait l’objet d’une recherche explicite. Il semble donc nécessaire de renouveler l’opération, cette fois-ci en supprimant les mots de la colonne “word” du fichier Excel.

set.seed(1234) 
wordcloud(words = top_100_words$words, freq = top_100_words$Freq, min.freq = 2, scale = c(3.5, 0.15),
          colors = colorRampPalette(brewer.pal(9, "Set1"))(100), random.order = FALSE, rot.per = 0.1, 
          use.r.layout = TRUE, fixed.asp = TRUE, max.words = 100)

On remarque la présence de nouveaux mots liés à la vraisemblance, comme εἰκότως, à la vue et/ou au savoir (ὁρᾷςεἰδέναιοἶδʼοἶσθα), à l’opinion (οἴονταιδοκεῖ), aux hommes et aux dieux, à la parole (λόγων), également au plaisir (τερπνὸν). Une lecture plus approfondie de ces extraits et du corpus permettra de préciser s’il s’agit de coïncidences ou si ces constats peuvent mener à de nouvelles pistes de recherche.

Le De Inventoribus Rerum : une première OCR.

Le De Inventoribus Rerum, un ouvrage controversé pour un auteur hors-normes.

En 1499 paraît un ouvrage singulier : encyclopédique avant l’heure, couvrant mille sujets allant de l’origine des dieux ou celle des lois à l’apparition de l’argent, l’architecture, et même la prostitution, il s’intitule De Inventoribus Rerum, et comporte trois tomes.

Plus que le sujet lui-même, c’est l’auteur qui rend cet ouvrage si remarquable : trésorier du pape, évêque de Bath, évêque et archidiacre de Wells, il est aussi commandité par le roi Henri VIII d’Angleterre pour rédiger une histoire complète de son pays. Plus tard, enfermé par ce même roi, il sera libéré à l’insistance de nombre de ses amis et protecteurs, dont Catherine de Médicis, et le pape Léon X. Entièrement oublié aujourd’hui, Polydore Virgile était une des plus éminentes figures politiques de son temps.

C’est d’ailleurs peut-être pour cela qu’un travail, d’apparence tout d’abord inoffensive, sur l’origine de toutes choses, a été si vite condamné par les milieux catholiques bien-pensants pour de multiples hérésies. Il faut dire que, né dans la deuxième moitié du Quattrocento, et formé à Bologne, Polydore Virgile avait de la pensée et des institutions catholiques une opinion pour le moins contradictoire. Ardent défenseur du Saint-Siège, il n’en demeurait pas moins d’accord avec le fondement de certains arguments des intellectuels protestants tels que Jacques Lefebvre d’Étaples ou Luther, et exprimait plus ou moins subtilement cet accord dans ses pages.

Or, en guise de réponse à ces accusations, Polydore Virgile publie en 1521 une nouvelle version de son ouvrage, augmenté de cinq nouveaux volumes, concernant l’apparition et la formation des institutions chrétiennes. Ses positions quant aux dogmes et aux règles catholiques y sont encore plus explicites ; en revanche, il ne renie pas le Saint-Siège pour autant, se rangeant par conséquent plutôt aux côtés des évangélistes de Marguerite de Navarre que dans les rangs des protestants de Luther.

Cependant, ces révisions font interdire l’ouvrage, et il demeure à l’Index Librorum Prohibitorum jusqu’en 1576, après sa mort, année durant laquelle paraît un De Inventoribus Rerum expurgé par le pape Grégoire XIII.

Malgré ces périples éditoriaux, l’ouvrage de Polydore Virgile eut à son époque un succès retentissant. Originalement écrit en latin, il fut traduit en français en 1521, en allemand en 1537, en anglais en 1546, et en espagnol en 1551. Le De Inventoribus Rerum a d’ailleurs continué à influencer la pensée des lettrés jusqu’à tard, et il est même mentionné dans Don Quichotte.

Un ouvrage oublié.

Or, aujourd’hui, cet ouvrage est ignoré par le monde de la recherche, et les cinq derniers volumes, qui étaient les plus controversés, n’ont plus été traduits depuis les dates mentionnées ci-dessus. Le De Inventoribus Rerum n’est plus étudié, plus traduit, plus publié, et il n’est même plus mentionné dans l’univers de la recherche, à tel point qu’il n’existe même pas dans la plupart des banques de données numériques sur notre héritage culturel de langue latine. L’objectif de ce bref travail a donc été de préparer le chemin pour la mise en place d’une édition numérique adéquatement transcrite du cinquième des huit livres de cet ouvrage, afin de simplifier tout futur travail académique le concernant.

Première tentative d’OCR.

Pour ce faire, il a fallu partir de scans propres des 35 pages du volume en question (libres de droits bien entendu, puisqu’il s’agissait d’une édition de 1528), et les placer dans un repository  GitHub (https://github.com/AlgernonNormanONyme/Numerisation_Polydore_Virgile) séparées en moitiés afin d’alléger le document. Il a ensuite été question d’en faire une OCR, ou Optical Character Recognition, une reconnaissance de caractères optiques réalisée par un programme destiné spécifiquement à ce genre de tâches. La difficulté de cette opération résidait notamment dans la nature du texte imprimé : les pages étaient jaunies par l’âge, certaines lettres étaient mal imprimées, ou partiellement effacées, et les conventions éditoriales de l’époque ont fait que de nombreux mots étaient abbréviés. Par exemple, un 9 en exposant à la fin d’un mot représentait la syllabe «-bus» ; un macron au-dessus d’une voyelle représentait un «n» ou un «m» situé à sa suite ; un «q» qui aurait l’air d’avoir un «B» majuscule attaché à sa barre tenait lieu du suffixe «-que» ; enfin, parmi d’autres singularités graphiques, il y avait aussi cet ancien «s» si semblable à un «f», «ſ». Tout autant d’éléments qui auraient pu rendre une OCR imprécise et fastidieuse. D’ailleurs, le premier programme qui y a été appliqué par le moyen de RStudio n’a su produire que des messages d’erreur concernant certains caractères qu’il était incapable de reconnaître.

 

 

 

La solution : Transkribus.

C’est le logiciel d’OCR mis en place par Transkribus qui a enfin servi pour ce travail. Ce site, spécialisé dans l’OCR, propose de nombreux modèles de reconnaissance selon la langue du document, l’époque ou la région où il a été écrit ou publié, et fonctionne à partir de reconnaissances précédentes. Le modèle particulier utilisé pour la reconnaissance du De Inventoribus Rerum s’appelle «Transkribus Print M1». Entraîné sur différents textes imprimés, il a fonctionné presque parfaitement. Malgré une moyenne d’une cinquantaine d’erreurs par page numérisée, ce nombre est négligeable par rapport aux erreurs potentielles : la capacité du programme à distinguer les «ſ» des «f» est étonnante, et il parvient à recomposer des lettres partiellement occultées par des taches, ou mal imprimées. Un autre avantage considérable de Transkribus est la division des espaces sur la page. En fait, le texte du De Inventoribus Rerum est doté d’un certain nombre de références en marge du texte principal, qui précisent la nature des citations bibliques faites par Polydore Virgile au cours de son exposé. Or le logiciel de Transkribus parvient à séparer automatiquement en deux «régions» le texte principal et les notes en marge. L’interface permet ensuite de corriger les erreurs directement sur Transkribus, puis de télécharger les versions TXT et Prima Page XML, une interprétation PDF de l’interface Transkribus, ainsi qu’une version du travail effectué codée entièrement selon les directives TEI, afin de pouvoir les exploiter par la suite. De cette façon, le système de Transkribus simplifie amplement le travail d’encodage. La version PDF notamment est tout à fait intéressante, puisqu’elle est presque identique au texte imprimé. Il y a une certaine déformation des notes en marge, mais elles sont bien placées face à la ligne de texte qui leur correspond, ce qui laisse présager que cette particularité est bien encodée dans le document XML TEI fourni par la plateforme.

 

Considérations finales.

La relative complexité d’une édition EVT a fait qu’elle ait malheureusement été laissée en dehors du spectre de ce travail, qui s’est contenté de paver le chemin pour une future édition numérique de cet ouvrage. Ainsi, on trouvera dans le repository suivant (https://github.com/AlgernonNormanONyme/Numerisation_Polydore_Virgile), tous les éléments mentionnés ci-dessus, prêts à l’usage.

Il est dommage qu’un texte d’une telle importance, écrit avec une telle verve, une telle érudition, et un esprit si étonnamment contemporain, ait été perdu dans les méandres de l’histoire. Mais la mémoire a trouvé dans le développement du monde numérique un précieux allié : si le texte original est retranscrit en un format aisément exploitable par un monde académique de plus en plus numérisé, et mis à la disposition de tous dans un espace facile d’accès, peut-être ce cinquième livre saura-t-il enfin attirer l’attention que mérite le De Inventoribus Rerum.

Synthèse de nos travaux sur le projet Sunoikisis DC

Ce semestre, étudiants en M1 avons inscrit notre projet dans la continuité des travaux précédents, en reprenant les données regroupées lors des années précédentes sur le programme Sunoikisis DC.

Ce projet, créé en 2015 à l’initiative de membres des universités d’Harvard, de Londres et de Leipzig, a pour objectif de favoriser les échanges à travers des séminaires portant sur toute discipline ayant trait aux Humanités Classiques entre les pays du monde entier. Ces séminaires se déroulent en visio-conférence, mais sont ensuite disponibles de manière asynchrone sur YouTube et GitHub. Les disciplines présentées sont nombreuses, et ne portent pas que sur la culture gréco-romaine : on y trouve des séances sur l’Égypte, la Mésopotamie, ou encore la Chine. Lors de la fondation du projet à Leipzig, le premier séminaire comptait 12 universités participantes ; de nos jours, on compte 135 institutions différentes qui ont participé au projet. En 10 ans, le programme s’est significativement développé, et on espère qu’il continuera à s’étendre et susciter l’intérêt du grand public pour le domaine des Humanités Classiques. 

Carte recensant les différentes institutions ayant participé au projet dans le monde, disponible via ce lien.

En regroupant les métadonnées de ces séminaires, notre objectif a été d’harmoniser et de mettre à jour les données des années passées, et ainsi créer des conditions d’analyse adéquates, de sorte que les années qui suivent, nos données soient complétées suivant le modèle fourni par notre fichier. 

 A la fois élèves en présentiel et en EAD nous sommes répartis diverses tâches visant à améliorer un fichier CSV créé par les précédents étudiants, qui se présente sous la forme d’un tableau regroupant ces données. L’essentiel de notre travail a été de le mettre à jour en ajoutant les données sur les séances récentes, mais également d’uniformiser les données. Pour cela, nous avons eu recours à divers outils. 

GitHub

Il s’agit d’un service d’hébergement basé sur le protocole Git, un outil de versionnage qui permet de conserver toutes les versions d’un fichier. Il facilite la collaboration entre les développeurs du monde entier, qui, par exemple dans le cadre de projets “open source”, y partagent des lignes de codes entières, ainsi accessibles à n’importe quel individu qui peut à son tour contribuer à l’élaboration du code. On peut y partager un fichier, que d’autres peuvent importer pour le modifier, puis l’exporter sur GitHub à leur tour pour partager leur version, sans pour autant créer de conflits, puisque le service permet d’enregistrer les versions de chaque machine. 

Le projet Sunoikisis DC regroupe les données sur les séminaires sur GitHub, de sorte que le monde entier puisse y avoir accès de manière asynchrone. Nous avons ainsi facilement pu regrouper ces données dans un fichier CSV. 

Nous disposons également d’un entrepôt GitHub exclusif, qui a facilité les échanges au sujet de l’élaboration du fichier CSV, notamment grâce à l’outil ‘Issues’ qui nous a permis de partager et de discuter de différents problèmes contenus dans notre fichier, et même d’assigner des personnes à une tâche donnée : par exemple, nous avons discuté de la mise en forme des conférences qui avaient été annulées. 

OpenRefine

Il s’agit d’un logiciel de nettoyage de données, parfait pour un fichier Excel ou CSV. Sous forme de tableau, il permet d’harmoniser nos données, en repérant rapidement des fautes de frappe ou des hétérogénéités dans notre fichier, mais également en filtrant les données, leur attribuer un type (date, heure, pays…) à des fins analytiques. Le logiciel consiste à effectuer des transformations sur un tableau, en utilisant le langage GREL. Grâce à celui-ci, nous avons rapidement pu traiter les données en utilisant diverses expressions, des commandes. Nous avons également pu enrichir le fichier en ajoutant des données à partir de Wikidata, comme les identifiants des différentes universités qui ont participé aux séminaires. Enfin, OpenRefine nous a aidé à visualiser et explorer les données du tableau, pour nous aider à la correction.

Visual Studio Code

Il s’agit d’un éditeur de code source, outil de développement indispensable destiné à l’écriture de différents langages de code. C’est avec ce logiciel que nous avons modifié notre fichier CSV, dont le format (Comma-Separated Values) consiste à regrouper sous la forme d’un tableau les données en les séparant par des virgules. Nous avons combiné ce format à une extension, Rainbow CSV, qui attribue une couleur différente à chaque colonne, de sorte que la lecture et la correction des données soit facilitée. 

Notre carnet de recherche

En visualisant les articles comprenant l’étiquette “Sunoikisis DC”, nous avons pu lire et analyser les travaux effectués par les classes précédentes, ce qui nous a permis de comprendre leurs réflexions et d’effectuer la synthèse des billets ci-dessous. 

Fichier CSV

Github est un service web d’hébergement et de gestion de développement de logiciels, utilisant le logiciel de gestion de versions Git. Par conséquent, dans un fichier réalisé en commun (projet collaboratif) ce service web avec la commande « Git » garde en mémoire chaque modification des données. Chaque fois qu’un caractère est modifié, faisant partie du logiciel, cela permet de savoir l’état du fichier avant la modification et après la modification apportée par chaque contributeur/contributrice inscrit dans un projet collaboratif. Dans un terme technique, Github pratique ce qu’on appelle  le « versionnage ».

On peut en dire que Github est une sorte d’entrepôt/dépôt qui permet de sauvegarder ce qui est partagé. Cela se réalise grâce à plusieurs fonctionnalités de Github qu’on étudiera. Par le biais  de « commits », de « pull requests » et d’« issues ».

Qu’est qu’un fichier CSV ?

Un fichier CSV (Comma-Separated Values) est un type de fichier qui organise les données sous forme de tableau séparées par des virgules et parfois des points virgules. C’est le cas de notre fichier quand on consulte la section «preview» (prévisualisation de la version finale du fichier) et juste à côté la section «code» (cela permet de visualiser le fichier à l’état brut).

Qu’est qu’un commit ?

Un commit, terme emprunté de l’anglais dans son sens informatique, représente une ou plusieurs modifications d’un ou d’une contributrice apportées à un dépôt/entrepôt chronologiquement (repository : espace de stockage). GitHub enregistre un commit qui est composé d’un titre et d’un message explicatif indiquant ce qu’un ou une contributrice a apporté comme modification à un fichier.

Sur Github, on peut avoir accès à l’historique des commits d’un fichier et on peut savoir à quel moment un commit a été réalisé. Pour trouver le lien pour accéder à l’historique des commits, c’est indiqué en haut à droite d’un fichier qu’on a sélectionné sur le site (History). On peut le voir dans l’image ci-dessous à en haut à droite.

Dans le cas du fichier Sunoikisis, voici le lien de l’historique des commits.

Combien y a-t-il de commits pour ce fichier CSV?

Ce fichier du projet collaboratif  compte 132 commits. Si l’on compte par sessions académiques :

  • 34 commits durant l’année 2020-2021 ;
  • 20 commits durant l’année 2021-2022 ;
  • 29 commits durant l’année 2022-2023 ;
  • 21 commits durant l’année 2023-2024 ;
  • 28 commits durant l’année 2024-2025.

Lorsque l’on accède à l’historique de ce fichier CSV, on apprend que ces commits ont été réalisés sur une période allant du 1er mars 2021 au 14 avril 2025.

Combien y a-t-il de contributeurs/contributrices ?

Au total, on compte 32 contributeurs/contributrices à ce projet collaboratif, les anciens laissant leurs places aux nouveaux contributeurs/contributrices chaque année depuis 2021 pour participer à la continuité de l’état du fichier CSV par des commits.

A titre d’exemple, durant l’année académique 2024-2025, on compte plus de 7 contributeurs/contributrices s’étant ajoutés à ce projet collaboratif.

Quels sont les types de commits du fichier CSV ?

On en trouve de diverses sortes, qui permettent de contribuer à l’état du fichier CSV final :

Le commit initial est réalisé par le contributeur propriétaire qui a permis d’ajouter les données du  fichier CSV. Voici une image ci-dessous qui l’illustre:

Les commits de correction : par exemple via ce lien on peut voir des citations ont été modifiées.

Les commits d’amélioration : harmonisation des institutions et des noms dans le fichier CSV, ou encore modification des noms de colonnes en anglais comme on peut le voir ci-dessous : 

Comment savoir qu’un commit a été réalisé ?

Via Github, des notifications sont indiquées avec le titre du commit. De plus, lorsqu’on clique sur le commit, chaque contributeur/contributrice indique en description ce qu’il a réalisé. On peut ajouter que Github donne des indications visuelles à chaque personne lisant le commit : en rouge la version avant le changement et en vert l’état après le changement d’un élément du fichier opéré par un contributeur/contributrice.

En voici un exemple:

On peut savoir lorsqu’un commit a été réalisé avec d’autres éléments à travers l’image ci-dessous :

  • L’identifiant du commit du contributeur ici est « cd3079c ». 
  • On peut voir la date de la contribution: « committed 3 weeks ago ». Dans certains commits on peut aussi voir en anglais : « authored + date».
  • Le titre et la description du commit que le contributeur a réalisés. Dans cet exemple, le titre et la description du commit sont identiques : « Harmonise institutions and names ».
  • Lorsque l’on clique sur le commit, on peut voir le message « 1 file changed », ainsi que les lignes de ces modifications:  “+68 – 68”.
  • Tout en bas de l’image on trouve le bouton de notification. Sur Github, on peut être averti d’un commit réalisé via l’historique des commits, mais aussi en s’étant abonné à une discussion spécifique ou d’un fil lié à un certain commit ou sujet, mais pas pour l’ensemble des commits d’un fichier.

Les commits sont non seulement visibles via le site de Github si le dépôt est public, mais aussi en local via le logiciel GitHub Desktop.

Voici l’interface de l’historique des commits du fichier CSV du projet Sunoikisis DC de GitHub Desktop ci-dessous : 

A gauche de l’écran, on peut voir l’historique des commits avec les informations associées à ceux-ci comme sur le site de GitHub.

GitHub Desktop est un logiciel associé au site de Github permettant de travailler en local sur des fichiers (ajouts, modifications ou suppressions) depuis son ordinateur sans passer directement par le site web. Cependant, pour que les modifications locales soient synchronisées avec le site GitHub, il est indispensable d’effectuer la commande « push ». Sans cette étape, les modifications restent uniquement sur l’ordinateur local, même si le dépôt est public.

Par exemple, dans le projet collaboratif, il y a des exemples montrant que GitHub Desktop a été pris en compte mais qui n’a  pas été synchronisé avec le site de GitHub en sélectionnant la commande « push ». Cela peut être volontaire, puisque l’on peut travailler sur un fichier via son ordinateur sans qu’il soit synchronisé avec le site de GitHub, ou involontaire. On peut le voir avec l’image ci-dessous :

Dans l’image ci-dessus, ces 8 commits réalisés par ces contributrices apparaissent entre le commit « harmonise institutions and names » et le dernier commit « update csv and archive » dans GitHub Desktop.

Mais ils n’apparaissent pas dans l’historique du fichier CSV sur le site de GitHub comme on peut le constater ci-dessous :

De plus, lorsqu’on se connecte régulièrement sur Github, on peut apercevoir en haut à droite (« Fetch origin ») une notification indiquant qu’un commit a été réalisé par un contributeur ou une contributrice. C’est un moyen efficace si on veut récupérer les changements des autres contributions. Cette commande permet aussi de rafraîchir la page comme on peut le constater ci-dessous :

Comment peut-on modifier le fichier CSV et réaliser un commit ?

Il y a plusieurs moyens de réaliser un commit.

Il est important de savoir que l’on peut directement modifier un fichier sur le site de GitHub pour ensuite effectuer un commit.

Tout d’abord, on sélectionne le fichier qu’on souhaite modifier. Dans notre cas, il s’agit du fichier CSV sur le projet Sunoikisis DC qui se trouve dans l’accueil du site de GitHub du contributeur/contributrice ou d’une personne externe au projet collaboratif consultant le fichier.

On peut le voir via l’image ci-dessous :

Ensuite, en haut à droite, il y a l’icône en forme de crayon que l’on sélectionne. Voici l’image ci-dessous :

En appuyant sur cet icône, on a la possibilité de modifier le fichier. Une fois cette étape réalisée, on sélectionne “commit changes” pour ainsi mettre en titre et en description, ce que le ou la contributrice a modifié. On peut le voir en haut à droit dans l’image ci-dessous :

Pour s’assurer que le commit soit vu par les autres, il suffit de cliquer sur la commande « push”, et les modifications réalisées se synchronisent avec le site de GitHub, et seront enregistrées dans l’historique du fichier CSV et sur GitHub Desktop.

On peut annuler une modification avant d’avoir appuyer sur « commit changes », en sélectionnant « cancel changes » qui se trouve juste à côté.

Cependant bien que cela reste une possibilité, cela peut entraîner des conflits avec le travail des autres contributeurs/contributrices. En effet, si plusieurs personnes effectuent des modifications dans un même fichier sans coordination, cela peut engendrer des conflits de fusion ou l’écrasement involontaire de modifications importantes.

Par conséquent, pour éviter ces éventuels conflits, il est possible de modifier le fichier et de réaliser des commits localement via Github Desktop avant de synchroniser ou non.

Dans l’image ci-dessus, on sélectionne le fichier sur le projet Sunoikisis qui est encadré en bleu. Puis on fait clic-droit et on sélectionne un logiciel d’éditeur de texte comme Visual Studio Code.

Via ce logiciel, on peut modifier directement le fichier comme on peut le voir dans l’image. Ensuite, dans la section « file » en haut à gauche, on sélectionne la commande « save » pour sauvegarder les modifications réalisées. L’extension CSV lint téléchargeable sur cet éditeur de texte permet de détecter les erreurs de formatage et renforcer les différents types de données avec des couleurs, en plus des virgules. Voici un image qui permet de l’illustrer ci-dessous :

GitHub Desktop affiche automatiquement les fichiers modifiés dans l’interface que l’on peut voir ci-dessous :

On peut effectuer ensuite un commit (en incluant un titre et une description) associé à la ou les modifications que l’on a réalisées via Visual  Studio Code. Voici une image ci-dessous :

La réalisation du commit s’effectue en bas à gauche. Lorsque l’on insère le titre et la description du commit, on sélectionne « commit to main ». Ainsi, le commit est affiché dans l’historique du fichier CSV sur Github Desktop, et s’il a été synchronisé avec le site GitHub, cela apparaît dans l’historique du fichier avec la commande « push ».

Attention, mettre un titre et une description du commit est nécessaire, car GitHub et GitHub Desktop enregistrent la ou les modifications. Néanmoins, le ou les commits vont s’afficher automatiquement en titre « update + le nom du fichier ». Cela indique qu’une mise à jour a été réalisée sur un fichier spécifique. Cela est observable via ces images ci-dessous :

Ci-dessus, ce sont des commits automatiques sur l’historique du fichier CSV sur le site de GitHub.

Ci-dessous, ce sont des commits automatiques sur l’historique du fichier CSV sur le logiciel GitHub Desktop : 

Y a-t-il une autre façon de modifier un fichier?

Pour modifier un fichier, on peut également se détacher de « la branche principale du code » c’est-à-dire de la version officielle (sous le nom de « main » ou « master ») du fichier via GitHub Desktop, en créant une nouvelle branche qu’on peut voir ci-dessous : 

Après avoir sélectionné le fichier, on va dans la section « branch » puis « new branch » pour ainsi faire les modifications nécessaires via Visual Studio Code par exemple et effectuer un commit comme dans la branche principale. Ensuite, on peut proposer les modifications qu’on a réalisées aux autres contributeurs/contributrices avec des « pull requests » dans GitHub Desktop (surligné en bleu).

Mais aussi sur le site de GitHub. Voici des images ci-dessus qui l’illustrent :

On peut constater via l’image ci-dessus, qu’aucun pull request n’a été ouvert car tous les autres ont été fermés lorsqu’ils ont été acceptés ou non. Dans le projet collaboratif, 22 pull requests ont été clos.

Ainsi, en cliquant dessus on peut accéder à l’historique des pull requests du fichier CSV que l’on peut voir ci-dessous et disponible ici

Ainsi le ou la contributrice dans une conversation (section « conversation ») propose sa modification avec son commit (section « commit »), et les autres contributeurs/contributrices peuvent en discuter. Si le fichier est accepté, ses modifications sont attachées à la branche principale du fichier, devenant la version officielle, dans la section « files changed ». Dans le cas du « pull request » de cette contributrice (voir ci-dessous), la proposition de modification a été acceptée et fermée (« Pull request successfully merged and closed »). 

Il est important de noter que le commit lié à ce « pull request » de cette contributrice n’apparaît pas dans l’historique du fichier CSV sur le site de Github. Cependant, il est bien considéré comme un commit mais dans un historique de « pull requests » bien spécifique et sur Github Desktop, sans être directement rattaché à l’historique des « commits » du fichier CSV. 

Cette contributrice a effectué des modifications en changeant les valeurs des colonnes du fichier CSV via un autre logiciel, en dehors de Visual Studio Code, qui s’intitule OpenRefine.

OpenRefine, est un logiciel libre de mise en forme et de nettoyage des données. Ainsi OpenRefine sous la forme d’un tableur va réorganiser les données. On a la possibilité d’ajouter des colonnes et de modifier des colonnes pour un format en CSV. Dans notre cas, le fichier collaboratif était déjà en CSV.

Voici la version finale du fichier CSV, sous la forme d’un tableur via OpenRefine. Cependant, pour faire une simulation, on appuie sur l’icône du copier-coller (« Raw this file ») surlignée en jaune pour télécharger le fichier afin de l’ouvrir dans OpenRefine.

Ensuite, on peut sélectionner des paramètres de OpenRefine concernant le fichier, comme on peut le voir ci-dessous : 

Quand on a réalisé les modifications nécessaires, on peut appuyer tout en haut à droite sur « Create projet » et exporter le fichier final avec plusieurs formats, dont le format CSV.

Qu’est qu’une issue ?

Une « issue » sur GitHub est une fonctionnalité qui permet de signaler un problème, de demander une amélioration ou encore de discuter d’une idée dans un projet collaboratif.

L’historique des issues du fichier CSV est consultable à ce lien.

On peut déléguer des tâches spécifiques à certains des contributeurs/contributrices.

Tout comme le « pull request », on peut ouvrir une issue et la fermer quand les contributeurs et les contributrices estiment que l’issue en question est résolue.

Dans les « issues », on a également la possibilité d’activer la fonctionnalité d’un ou de plusieurs « milestones ». D’une part, cela permet de regrouper les « issues » pour un projet bien précis. D’autre part, de pouvoir renforcer l’organisation et de fixer des dates limites pour la réalisation de tâches spécifiques d’un projet.

Dans le cas du fichier CSV, il n’ y a pas de « milestone » ouvert ou fermé, mais c’est une fonctionnalité qui reste utile.

Le « milestone » peut s’appliquer pour les issues, mais aussi pour les « pull requests ». A l’instar des issues, dans le cas du fichier CSV, il n’y a pas de « milestone » ouvert ou fermé dans les « pull requests ».

NOTRE FICHIER CSV

L’entrepôt GitHub offre une fenêtre sur l’histoire du projet et du fichier.

Consiste en transformation de données brutes, en l’espèce à la création d’un fichier à partir des métadonnées pour pouvoir créer des conditions d’analyse.

Ces données sont mises en forme pour rendre le projet dont elles sont issues lisible et intelligible.

Pour cela, les participants se sont appuyés sur la documentation produite par les membres du projet Sunoikisis DC, mise à disposition sur le wiki, lui-même créé pour l’occasion; il répertorie les différentes sessions à mesure qu’elles ont lieu, leurs programmes et intervenants.

Le projet s’est articulé pour les étudiants autour de la création d’un fichier au format .csv, format fondamental de logiciels de tableur comme Excel. Ce format permet d’offrir sous forme de tableau les métadonnées classées.

L’entrepôt lui-même a été ordonné de manière à ce que les travaux accomplis chaque année apparaissent de façon accessible et lisible pour les visiteurs-participants ; nous avons donc accès aux archives. Nous nous sommes principalement fondés sur le fichier résultant des travaux des années précédentes et mis au propre par notre enseignant.

Récapitulatif de l’histoire du fichier :

  • 2021: première année, 9 contributeurs (Zacharie, Maria, Olivier, Penda, Thierry, Chloé, Jérôme, Aurélia, Shubert), 189 lignes, 7 colonnes; les données prises en compte étaient l’étudiant.e contributeur.ice, le décompte total de sessions, l’année académique, la saison, la numérotation par session, le date, le titre, les contributeur-institution et thèmes.
  • 2022: à partir du travail réalisé par les étudiants de l’année précédente, ceux de cette année ont pu aborder les données de manière quantitative-analytique, notamment fréquence (institutions, contributeurs, mots-clés, thèmes associés) et représentation sous forme de pourcentages.

Le fichier csv a été divisé par blocs téléversés dans l’entrepôt pour ensuite produire un fichier final unifié comprenant les séances 189 à 220. Certaines parties du fichier précédent ont été reprises pour être corrigées et la catégorie des thèmes des séances, auxquels on dédie une colonne par thème, a été approfondie. Les contributeurs sont séparés de leur institution et cette catégorie a été étendue. Les fichiers préparatoires permettent d’avoir un aperçu des méthodes de travail (colonne suggestion-correction, réflexion autour des catégories, en vue, toujours, d’offrir un fichier de données lisible et synthétique).

  • 2023: Cette année-là, les données ont été abordées sous un angle géographique, à l’aide du format .kml, lisible dans Google Earth et Geojson, en vue de produire une représentation visuelle des pays d’origine des institutions concernées par les contributions (données géo-spatiales). Une colonne dédiée au lien menant vers la documentation de chaque session a été créée. Le fichier final semble ne pas apparaître ou alors celui disponible n’inclut pas la mention des pays.
  • 2024: Ajout jusqu’à la session 238/240; recours à Gephi, outil de visualisation graphique de données. Distinction host-guest, qui manifestement n’a pas été conservée cette année; focalisation sur les contributeurs, en vue de produire une représentation graphique de leurs liens et apparitions.
  • 2025: Le fichier tel que nous l’avons trouvé était dans un état proche de final. La numérotation a été interrogée et révisée, tant pour corriger d’éventuelles erreurs ou incohérences que pour œuvrer à l’harmonisation du fichier. Nous avons, notoirement, ajouté une catégorie intitulée status (sous forme de colonne, donc) . A l’occasion de cet apport, nous avons dans un premier temps envisagé un intitulé répondant à la question « la séance a-t-elle eu lieu ? ». OpenRefine nous aurait permis, dans une certaine mesure, d’automatiser le remplissage de cette colonne. Or il se trouve que la complétion de certaines séances n’était ni effective, ni annulée, mais reportée. Nous avons alors délaissé la forme interrogative « Occurred?» au profit du terme status. Nous avons également révisé la colonne des liens vers la documentation de chaque séance; nous avons ajouté et complété les séances manquantes (239 à 269); nous nous sommes également interrogés sur la pertinence du maintien d’une catégorie, face à un cas de concurrence en matière d’informations.

Nous travaillons à partir d’un fichier créé par les étudiants des années précédentes, avec pour objectifs de:

  • compléter-mettre à jour le fichier ;
  • harmoniser/raffiner le fichier ;
  • extraire informations pertinentes pour une analyse plus générale du projet ;
  • interroger un environnement de travail, en tentant de répondre à la question « que faire de ces données? Pourquoi?».

Méthode: comme pour les années précédentes, nous nous sommes réparti le travail en divisant le fichier par blocs de lignes. Ainsi avons-nous pu opérer, sur un champ plus réduit, des travaux d’inspection, vérification et modifications (ajouts comme suppressions, visibles dans l’historique des commits, donc).

Quand on compare les deux fichiers, on peut relever une première différence portant sur le décompte des séances par saison. Au départ, l’année 2019-2020 était en effet comptée comme un seul bloc, ce qui fait que les séances étaient numérotées de 1 à 32; dans ce cas-là, année académique et saison se confondent. Nous avons, dans un souci d’harmonisation, procédé à un re-découpage suivant les critères observés pour les années précédentes, figurant plus haut dans le fichier, donc, en limitant le décompte à chaque saison proprement dite au sein d’une année, à savoir Spring, Summer, Fall. A noter par ailleurs que chaque année débute en septembre et s’achève en juillet. Ce cas nous a invité à réfléchir sur le sens des catégories préexistantes, puisqu’alors ce « rangement » mettait en concurrence ou du moins affaiblissait celui adopté ailleurs.

De même, pour l’année suivante, les saisons (ou semestres) d’automne et de printemps allaient chacun de 1 à 9, mais celui d’été semblait reprendre le calcul à l’échelle de l’année, puisqu’il partait de la séance 19 (9+9+1, donc) et ce jusqu’à 32.

Pareil pour 2021-2022, qui proposait un décompte mutualisé des séances des semestres d’automne et de printemps (1 à 18) et dont le semestre d’été semblait chevaucher le début de l’année suivante.

L’année 2023-2024 était lacunaire quant à la numérotation générale et, pour la saison d’été, manquaient visiblement les séances 2, 4, 6, 8 et 10. 

Elle présentait une étrangeté, dans le sens où pas moins de 4 séances successives numérotées comme étant la cinquième.

Quant aux séances n’ayant pas eu lieu, soit elles ont été annulées, soit reportées: dans le fichier initial, lorsque ce cas se présentait, soit une mention en styles changeants « cancelled », soit, a priori, des lacunes. 

Le fichier présentait une erreur, il n’était pas mis en forme de manière « cherchable », comme nous l’indique l’encart de GitHub. 

Les données apparaissaient donc sous forme brute, séparées par des virgules.

Pour autant, par une simple fonction cmd+F/ctrl+F, nous avons pu opérer une recherche positive des occurrences sur la page. 

OpenRefine, en tant que « powerful tool to work with messy data » nous a permis de rendre la tâche plus aisée, logiciel fort utile pour opérer des remplacements lexicaux et autres corrections.

Ainsi avons-nous pu, par exemple, créer une nouvelle colonne, à l’endroit souhaité, dévolue à la question du statut des séances.

Le remplissage des cellules était donc automatisable, au moyen de la fonction « transform» pour les séances ayant eu lieu; restait à remplir manuellement celles ayant été annulées ou reportées.

Dans la mesure du possible, certaines séances n’en offrant pas, tous les liens vers la documentation utile ont été ajoutés.

Ainsi avons-nous pu compléter le fichier avec les séances les plus récentes et celles qui manquaient éventuellement, corriger certaines erreurs de syntaxe et œuvré à l’harmonisation du fichier, dans la continuité du travail de nos prédécesseurs.

Billets précédents

Les thèmes qui n’apparaissent que dans un billet

Les billets rédigés les années précédentes abordent plusieurs sujets. Nous allons donc nous attarder sur les sujets n’apparaissant que dans un seul billet. 

Dans le billet de 2023, le groupe a choisi d’utiliser le logiciel UMap pour créer une carte afin de visualiser leur recherche. Le but a été de mettre en évidence les pays des institutions et des centres de recherche qui participent au projet Sunoikisis DC. Les membres du groupe ont tout d’abord ajouté une colonne sur Github afin de classer les séances par pays. Pour certaines séances, ils ont rencontré des difficultés puisqu’il s’agissait d’une collaboration entre plusieurs universités du programme. Une fois cette étape terminée, ils ont pu transformer le fichier en fichier KML pour le transformer en carte grâce à UMap. Enfin, des observations ont pu mener à des explications ou des questionnements : l’absence des États-Unis malgré l’existence de nombreuses universités investies dans ce domaine ou la présence de l’Egypte du fait de ses importantes ressources paléographiques. La plupart des pays participant au projet Sunoikisis DC sont donc européens. 

Le travail autour des différents thèmes abordés dans le projet Sunoikisis DC est un thème récurrent dans les trois billets. Cependant, le point de vue utilisé pour travailler sur les thèmes abordés varie dans les billets. C’est donc dans cette optique que nous allons nous intéresser aux thèmes dans cette partie. 

Dans le billet de 2023, le travail s’est axé autour de trois thèmes uniquement. Cette décision a été prise afin de faciliter le travail, mais des problèmes se sont posés : une partie des thèmes abordés se retrouve manquante, savoir quel thème regrouper sous quel nom. Dans le billet de 2022, c’est un travail sur la répartition des différents thèmes abordés durant le programme. Un graphique a donc été fait pour permettre de visualiser la répartition des différents thèmes par année. Cependant, le graphique qui est présenté n’est pas très lisible. Nous ne pouvons pas correctement nous rendre compte de la réelle répartition. De plus, dans ce billet, le logiciel TaDiRah est utilisé pour les annotations des thèmes. Ce logiciel n’est pas présent dans les autres billets. 

En essayant de comprendre le travail mené sur l’analyse des données du Projet Sunoikisis DC jusqu’ici, on a procédé à une analyse des billets déjà publiés sur Hypotheses. On a trouvé quatre billets, dont un datant de 2016, qui ne concerne pas notre analyse vu qu’il présente une analyse des données liée à un corpus différent. Alors, notre synthèse concerne les billets des années 2022, 2023 et 2024 qui travaillent sur le corpus des séances du projet Sunoikisis DC. Dans ce corpus, on a observé l’existence des certains thèmes récurrents chaque année et certains thèmes apparus une seule fois.

Thèmes récurrents

CSV

Le format CSV apparaît de manière récurrente dans les billets de 2022 à 2024 comme un outil central dans le traitement des données liées au projet Sunoikisis DC. En 2022, son maniement est cité parmi les compétences pratiques acquises par les étudiants. Le billet de 2023 approfondit cette mention en définissant le format CSV (Comma Separated Values) et en soulignant son utilité pour organiser les données sous forme tabulaire. Ce fichier, contenant l’ensemble des séances du projet Sunoikisis DC depuis 2014-2015, sert de base pour l’annotation thématique, l’analyse des séances, et la cartographie des institutions participantes. Les étudiants créent même un nouveau fichier CSV à partir des données initiales, afin d’isoler les informations géographiques utiles au projet de cartographie. En 2024, l’utilisation du même fichier CSV est de nouveau un thème central, avec une attention particulière portée aux métadonnées (comme les noms des contributeurs), extraites puis transférées dans un fichier distinct pour faciliter leur traitement. Certaines modifications ont également été apportées dans le fichier original afin d’assurer une compatibilité avec les outils de visualisation comme Gephi. Ainsi, le CSV a été utilisé comme  un outil fondamental de structuration, de transformation et d’exportation des données dans l’ensemble du processus analytique.

Détail du fichier CSV.

GitHub

GitHub est régulièrement mentionné dans les billets de 2022 à 2024 comme un outil fondamental pour le travail collaboratif des étudiants autour du projet Sunoikisis DC. En 2022, il est évoqué comme un simple entrepôt de données, servant à centraliser les fichiers partagés du groupe. En 2023, son rôle s’élargit : les étudiants ont pour objectif de s’initier à son usage et de contribuer à l’enrichissement de cet espace commun. Le billet de 2024 consacre une attention particulière à GitHub, présenté non seulement comme un service web de stockage, mais surtout comme une plateforme de collaboration qui permet de centraliser les données initiales, de regrouper les productions individuelles et de gérer différentes versions d’un même fichier. Cette capacité à retracer les modifications facilite l’identification des erreurs éventuelles. Le lien entre GitHub et l’usage du format CSV est également souligné, montrant comment l’intégration des deux outils soutient efficacement le travail d’équipe et la gestion des données au fil du projet.

OpenRefine

OpenRefine est mentionné de façon constante dans les billets de 2022 à 2024 comme un outil clé dans le traitement des données du projet Sunoikisis DC. En 2022, il est cité pour ses fonctions de nettoyage, de traitement automatique et d’analyse interactive des données, mettant en valeur sa capacité à structurer efficacement les données brutes. En 2023, le logiciel est décrit comme un outil libre dédié au nettoyage et à la mise en forme, confirmant son rôle dans la préparation des données pour l’analyse. En 2024, OpenRefine est mis en avant comme l’un des trois logiciels principaux utilisés par les étudiants, aux côtés de GitHub et Gephi.

 Son usage est donc pleinement intégré au processus de travail, soulignant sa pertinence pour assurer la qualité, la cohérence et la structuration des données tout au long du projet.

Traitement et analyse des données

L’analyse et le traitement des données sont au cœur des trois billets consacrés au projet Sunoikisis DC, constituant le fil conducteur des travaux menés par les étudiants. 

En 2022, le traitement automatique des données est brièvement mentionné, soulignant une première approche technique de la manipulation des informations. En 2023, le traitement prend une place plus structurée avec l’usage du format CSV pour organiser les données tabulaires, accompagné d’une description des étapes du processus. Le billet de 2024 approfondit cette dynamique en insistant sur la nécessité d’assurer une cohérence dans le traitement, impliquant des choix méthodologiques de la part des étudiants. Ce dernier texte met également en lumière l’usage de plusieurs outils logiciels, tels que Visual Studio Code (déjà présent en 2023) et Gephi, pour affiner le traitement et faire face à des problématiques spécifiques liées à certaines données. Finalement, il montre comment l’articulation de ces outils a permis une analyse plus fine et structurée des données du projet.

 Au fil du temps, le traitement des données devient donc un processus de plus en plus réfléchi, rigoureux et intégré à une chaîne d’outils complémentaires.

Annotation

L’annotation des données apparaît comme une pratique stable, collaborative et essentielle à la structuration thématique des séances du projet Sunoikisis DC.

 Dès 2022, le billet souligne le travail collectif d’annotation thématique réalisé par les étudiants, en insistant sur son caractère manuel, donc potentiellement subjectif. Cette annotation sert à identifier et organiser les thèmes abordés dans chaque séance, et le terme lui-même est également utilisé comme mot-clé pour décrire le contenu des certaines séances.

Visualisation du traitement des donnés concernant l’annotation des thèmes des séances du Projet Sunoikisis comme publié au billet du 20.05.2022

 En 2023, cette pratique est intégrée explicitement aux objectifs pédagogiques du groupe : l’annotation collaborative y est à nouveau valorisée comme un moyen structurant de catégoriser les thèmes du projet. Le texte réitère aussi l’usage du mot annotation comme mot-clé dans la description des séances, montrant ainsi la continuité de cette démarche dans la construction d’une base de données thématique cohérente et partagée.

Thèmes

 Les trois billets présentent les travaux d’analyse des étudiants liés aux thèmes des séances du Projet Sunoikisis..

Question des données concernant les organisateurs (hosts)

Les billets de 2022 et de 2024 analysent la problématique créée par la présence des noms des organisateurs (hosts) dans le tableau CSV qui participent très souvent aux séances, mais la majorité de fois ils prennent la parole pour introduire et présenter les différents participants. La non-distinction entre eux et les invités participants (guests) crée un « bruit », posant question sur la fiabilité des résultats des analyses des données.

Visualisation des thèmes des séances du Projet Sunoikisis comme publié au billet du 23.04.2023.

Le groupe d’étudiants qui a travaillé sur le billet de 2022 a signalé ce problème et le groupe  de 2024 a fait la distinction dans le fichier CSV du projet Sunoikisis entre les hosts et les guests, et a corrigé les discontinuités existantes liées à ce sujet.

Capture d’écran concernant le travail mené en 2024 sur la distinction entre hosts et guests comme publié au billet du 03.05.2024.

Visualisation des données avec des graphes

Les billets de 2022 et de 2023 mentionnent le mot “visualisation” en faisant référence au mot-clé pour le thème de la visualisation que certaines séances du projet Sunoikisis portent.
Le billet de 2024 met en avant le processus de visualisation des données à partir du fichier CSV du projet Sunoikisis avec l’utilisation des logiciels comme Gephi.

Visualisation des données du Projet Sunoikisis avec le logiciel Gephi comme publié au billet du 03.05.2024.

On observe une montée en complexité et en réflexivité au fil des années : les outils ne sont plus seulement utilisés, ils sont analysés, articulés entre eux, et les étudiants développent des méthodologies critiques, en particulier sur la fiabilité et qualité des données (notamment sur les hosts).

Conclusion

Dans le cadre du projet collaboratif du Master 1 d’Humanités Classiques et Numériques, nous avons effectué des recherches sur les métadonnées des séances du projet Sunoikisis DC. Ayant accès au travail des trois dernières années, regroupé dans un fichier CSV et ainsi qu’aux billets correspondants, nous avons jugé pertinent de mener une approche analytique sur le travail mené, les outils traités, les aspects considérés, afin de proposer de nouveaux axes de recherche pour les années à venir.

Une constante en ce qui concerne les outils a été l’emploi du fichier CSV, des logiciels de traitement de texte VSCode et OpenRefine, ainsi que Github. En second plan et selon les besoins et les différentes cibles du groupe, Gephi, TaDiRaH et UMap ont été utilisés pour visualiser les données. Les outils offrent un large éventail de fonctionnalités requises pour le traitement des données, et cette année, ils se sont avérés utiles et indispensables. L’analyse des différents emplois de Github a mis en évidence les énormes possibilités offertes par cette plateforme aux projets collaboratifs, qu’il est possible d’explorer davantage.

Après avoir été regroupées dans le fichier, les données ont été nettoyées et mises à jour, puis examinées et interprétées. On y trouve des métadonnées importantes telles que le titre de la séance, les organisateurs, l’institution, le pays, les mots clés et les liens. Trois recherches très intéressantes ont déjà été réalisées : l’analyse des sujets abordés et de leur fréquence; l’identification des organisateurs, et la fréquence de leur activité ; la cartographie des institutions impliquées au projet. En se basant sur ces études, dans le cadre d’une requête plus complexe, il serait envisageable d’effectuer une analyse comparative de ces deux variantes, à savoir les institutions et les sujets traités. De plus, les caractéristiques académiques et sociales des hôtes, qui certes a été un sujet traité en 2022, pourrait être repris et enrichi en considérant différentes catégories telles que l’âge, le sexe et la capacité. Mais le fichier pourrait aussi être enrichi avec les ressources proposées à chaque séance, puisque l’on peut noter des séances plus riches qui comprennent exercices et listes bibliographiques, en parallèle de séances plus simples.

Analyse lexicale et thématique des hymnes du Peristephanon de Prudence

Le Peristephanon de Prudence, est un recueil d’hymnes en vers latins dédiés à la gloire des martyrs chrétiens. Il constitue un corpus poétique riche en images corporelles et en symboles liés à la matière. Ce projet vise à explorer les occurrences et cooccurrences lexicales relatives au corps et aux éléments, à partir d’une analyse automatique des textes encodés en XML selon le standard TEI. L’objectif est double : observer la présence récurrente de certains termes (comme le sang, la main, ou le feu), et en proposer une première interprétation.

L’intégralité des script R permettant ce travail ont été réunis sur le Rmarkdown hn4-rmarkdown.rmd disponible sur mon github public : https://github.com/JinaneRrguiti/HN4-etudes-et-analyses-sur-le-Peristephanon-Jinane-RRGUITI.

 

Constitution et traitement du corpus

Quatorze hymnes ont été récupérés depuis mon dépôt GitHub où les fichiers sont encodés en XML. Chaque fichier contient les strophes du poème balisées par des éléments tels que `<l>`, `<lg>`, `<head>`, etc. Une fonction d’extraction a permis de reconstituer, pour chaque hymne, le titre et le texte intégral.

Une phase de nettoyage du texte a ensuite été appliquée : mise en minuscules, suppression de la ponctuation et des chiffres, puis tokenisation, c’est-à-dire découpage en unités lexicales. L’output résultant de la tokenisation donne le tableau suivant qui permet de voir tous les tokens du corpus :

 

Des listes de mots vides (stopwords) latins ont permis d’éliminer les mots-outils les plus fréquents afin de conserver uniquement les termes significatifs pour l’analyse.

La lemmatisation et les annotations grammaticales

Afin de disposer d’une base linguistique fiable, les textes ont été lemmatisés à l’aide du modèle latin du logiciel UDPipe. Cette opération a permis d’associer à chaque mot sa forme canonique (lemme) ainsi que sa catégorie grammaticale (nom, verbe, etc.). Une première sélection a permis d’extraire tous les mots appartenant à un champ lexical ciblé : le corps humain (manus, caput, sanguis…) et les éléments naturels caractérisés par leur matérialité (igne, ferro, lapis…). 

Un tableau interactif listant tous les mots ainsi extraits a été généré, incluant le poème d’origine, la forme observée, le lemme, et la catégorie grammaticale. Cette table constitue la base des analyses suivantes :

Analyse quantitative : fréquences absolues

L’analyse des fréquences permet de mettre en évidence les lemmes les plus récurrents du corpus. Un diagramme en barres verticales a été généré, montrant les 10 lemmes les plus fréquents parmi les termes du corps et de la matière. On observe sur le corpus complet notamment une forte présence de mots comme christi, deus, manus, membra ou encore ore.

Ces fréquences absolues traduisent une insistance thématique sur le corps martyrisé, les éléments de torture, et la matière comme vecteur de transcendance.

J’ai analysé la fréquence par hymne dans un output graphique interactif.

Analyse contextuelle : KWIC et cooccurrences

Une analyse KWIC (Keyword in Context) a été menée pour dégager les contextes immédiats des mots clés. Pour chaque lemme, les deux mots précédents et suivants sont extraits et affichés dans un tableau. Cela permet d’identifier des motifs récurrents (« manus sancta », « igne flagrant »…) et de poser des hypothèses sur leur valeur symbolique.

Cette analyse est enrichie par un graphe de cooccurrences qui montre les liens lexicaux entre les mots-clés du corpus. Le réseau sémantique révèle des proximités entre sanguis et cruor, igne et lapis, ferro et corpus, suggérant des chaînes poétiques construites sur la souffrance et la matière sanctifiée.

Analyse thématique : modélisation LDA

Une analyse, fondée sur la Latent Dirichlet Allocation (LDA), a été appliquée au corpus lemmatisé. Elle permet d’identifier des thèmes latents sans supervision. Le modèle a détecté quatre topics dominants, chacun caractérisé par les 10 termes les plus significatifs.

On observe que certains topics gravitent autour de la figure divine (deus, dominus, gloria), d’autres autour du corps souffrant (cruor, ferro, manus), et d’autres encore autour de la matière et de l’espace (éléments, lieux, objets).

Cette segmentation thématique permet d’isoler des noyaux sémantiques cohérents et d’approcher une lecture structurée des hymnes sans passer par l’analyse littérale.

Analyse TF-IDF

Ce script applique une analyse TF-IDF (Term Frequency–Inverse Document Frequency) pour identifier les mots spécifiques à chaque hymne du corpus. Contrairement aux fréquences absolues, le score TF-IDF prend en compte l’occurrence d’un mot dans un poème par rapport à sa rareté dans l’ensemble du corpus. Plus un mot est fréquent dans un hymne et rare ailleurs, plus son score TF-IDF est élevé.

Le rapport généré liste les 5 mots les plus distinctifs par hymne, accompagnés de leurs scores et d’un court commentaire d’interprétation lexicale. Le poème sur le Baptistère, très différent des autres poèmes, se détache visiblement dans l’analyse TF-IDF.

J’ai procédé à une analyse TF-IDF en deux temps d’abord en tableau puis en barplot :

Conclusion

Ce travail montre l’intérêt des méthodes d’analyse textuelle appliquées à un corpus antique encodé en XML. L’association d’une lemmatisation morphologique précise (via UDPipe) même si ce n’est pas  le meilleur outil pour les textes en latin, de visualisations interactives (tableaux, diagrammes, réseaux) et de modélisation thématique (LDA) permet d’exhumer des récurrences lexicales et des structures symboliques que l’analyse littéraire pourra approfondir. Le champ sémantique du corps et de la matière, dans ce contexte martyrologique, se révèle comme un vecteur privilégié de la poétique de Prudence.

Etude comparative de deux œuvres portant sur l’empereur Claude

Introduction

La figure de l’empereur Claude a suscité de nombreux récits, tant dans l’Antiquité qu’à l’époque contemporaine. Ce projet se propose de comparer deux représentations textuelles majeures : celle de Suétone, historien latin du Ier siècle, et celle de Robert Graves, romancier britannique du XXe siècle, auteur de I, Claudius. À travers une analyse lexicale et lemmatisée des deux corpus, l’objectif était de comparer la différence de traitement d’un auteur antique et d’un auteur moderne sur un seul et même sujet, à savoir la figure de Claude. 

Outils utilisés

Cette étude comparative a mobilisé plusieurs outils numériques complémentaires, chacun jouant un rôle spécifique dans la constitution et le traitement des corpus. Parmi eux, RStudioDeucalion et VSCode ont constitué la base du travail méthodologique.

Rstudio

Rstudio, et le langage R plus spécifiquement, a été l’outil principal pour l’analyse des textes. Grâce à des bibliothèques spécialisées comme tidytext ou encore ggplot2, il a été possible de transformer les textes en corpus analysables, de nettoyer les données, de construire des tableaux de fréquence, et de générer des visualisations comme des graphes comparatifs. 

deucalion

Développé par l’École nationale des chartes, ce logiciel dispose d’un rôle crucial en ce qui concerne la lemmatisation des textes. Cela a donc permis  une comparaison lexicale plus pertinente et cohérente des textes par le recours aux lemmes. 

Visual studio code

Utilisé à la suite de Deucalion, VS code m’a notamment permis de gérer les données obtenus quant à la lemmatisation des textes et d’en faire un fichier TSV plus simple a utiliser ensuite.

Préparation des données textuelles

Suétone

Dans un premier temps, l’objectif a été de structurer le texte de La Vie de Claude de Suétone, à la fois dans sa version française et dans sa version originale en latin. Les deux textes sont lus ligne par ligne, puis nettoyés. Ce nettoyage inclut notamment la suppression des balises inutiles, l’élimination des espaces superflus et la fusion de toutes les lignes pour former un texte unique. Une expression régulière identifie les chiffres romains, qui correspondent aux différentes sections du texte dans l’édition choisie. Le texte est alors découpé en fonction de ces chiffres pour isoler chaque section.

Ensuite, à chaque section identifiée est associé un titre explicite, précédemment défini, stocké dans un vecteur nommé titles. Ce couplage a pour but de mieux contextualiser l’analyse ultérieure. Un tableau est ensuite créé, dans lequel chaque ligne contient le numéro de section, son titre, le texte en français et le texte en latin correspondant. La mise en parallèle des textes latin et français permet un rapport direct au texte original et à sa traduction en regard, facilitant le travail de recherche. 

Une fois le corpus structuré, une phase de nettoyage approfondie a dû être appliquée à chaque texte. En effet, mon but était d’obtenir les données les plus propres possibles pour faciliter mes analyses. Cette étape a ainsi veillé à supprimer la ponctuation superflue en début de texte, à enlever les parenthèses et leur contenu, ou encore à corriger certains caractères parasites dans le but d’obtenir un texte aussi propre et uniforme que possible pour éviter que des éléments de forme n’introduisent de biais dans l’analyse lexicale.

L’étape suivante est celle de la tokenisation, c’est-à-dire la découpe du texte en unités lexicales, ici en mots. Cette opération est réalisée indépendamment pour le texte français et pour le texte latin, sans prendre en compte les titres. Chaque mot devient une ligne dans une nouvelle table, ce qui permet ensuite de compter leur fréquence d’apparition dans le texte.

Les mots les plus fréquents sont comptés pour chaque langue. Cette analyse brute met en lumière les mots les plus utilisés dans le texte, mais elle peut être faussée par la présence de mots grammaticaux fréquents (articles, pronoms, etc.). Pour affiner l’analyse, une liste de stopwords est utilisée pour chaque langue, afin de supprimer ces mots sans intérêt analytique. Une nouvelle table de fréquence est alors produite avec uniquement les mots significatifs. Pour une meilleure lisibilité, on peut visualiser les mots les plus fréquents après suppression des stopwords sous forme de diagrammes en barres horizontales.

Afin de dépasser les limites d’une analyse basée uniquement sur les formes des mots, une lemmatisation est appliquée au texte latin. Cela signifie que les formes fléchies des mots sont ramenées à leur forme canonique, ou lemme. Par exemple, les mots amicumamici, et amicus sont tous ramenés au lemme amicus. Cette opération est rendue possible grâce à un fichier Lemma_Suetone.tsv généré grâce à Deucalion et VSCode.

 

Le tableau issu de Deucalion est à son tour nettoyé pour supprimer les chiffres, les doublons, et les mots vides. La fréquence des lemmes est ensuite calculée, ce qui permet une analyse sémantique plus robuste que l’analyse de surface. Enfin, les dix lemmes les plus fréquents sont extraits et affichés, offrant une synthèse claire du vocabulaire essentiel du texte latin.

Graves

Le processus pour le second texte, celui de Graves, a été assez similaire dans l’ensemble. Cependant, si je disposais d’un fichier avec le texte brut pour Suétone, ce n’était pas le cas ici. En effet, mon premier objectif et la première difficulté que j’ai rencontré ici, après avoir réussi à me procurer le texte, a été celle de lire et de nettoyer des fichiers HTML et XHTML contenant le texte de Robert Graves. Pour ce faire j’ai dû créer une fonction pour nettoyer et extraire le texte brut afin de créer un nouveau document avec le texte brut exclusivement. Comme pour Suétone, les chapitres du texte ont été associés à des titres prédéfinis.

Cependant, là encore il a fallu procéder à un nettoyage pour obtenir les données les plus propres possibles. Cependant puisque les différents chapitres venaient à l’origine de 3 livres différents avec des formats différents, le nettoyage s’est révélé plus difficile que prévu. En effet, si jusqu’au chapitre 33 j’ai pu me contenter de retirer tout ce qui se trouvait avant la première majuscule, pour les chapitres suivants j’ai dû définir des conditions plus précises et complexes. 

J’ai ensuite fait le choix, avant d’entamer l’analyse lexicale, de remplacer les apostrophes par des espaces dans le but de faciliter la tokenisation. Puis de même que pour Suétone, j’ai eu recours aux stopwords avant de passer à la lemmatisation du texte avec Deucalion. 

Mise en parallèle des textes et analyse

Comparaison des lemmes

J’ai tout d’abord choisi de commencer par analyser les lemmes les plus fréquents dans les textes de Suétone et de Graves en générant un graphique. Cette approche permet de voir d’un coup d’œil les termes les plus utilisés dans les deux œuvres. De plus, les graphiques sont placés côte à côte pour faciliter la comparaison entre les deux auteurs. Le graphique ci-dessous présente ainsi les 10 lemmes les plus fréquents chez chaque auteur, mais la comparaison peut évidemment porter sur plus ou moins de lemmes en fonction de la nécessité.

Cela m’a ainsi permis de voir les lemmes les plus fréquents chez chaque auteur et de les comparer. Ainsi, chez Graves on peut remarquer que les lemmes les plus fréquents semblent être en lien avec la politique et le pouvoir impérial mais surtout qu’il se concentre en grande partie sur les personnes ayant partagés la vie de Claude. Chez Suétone, l’accent est mis sur des aspects plus administratifs et institutionnels du pouvoir romain. De plus, si l’empereur Auguste semble majeur des deux côtés, la première différence notable est la mention d’Hérode chez Graves.

Etude des noms propres

J’ai ensuite choisi d’accès mon analyse sur les noms propres. pour ce faire j’ai procédé à l’extraction de ces derniers en commençant par filtrer les mots qui commencent par une majuscule puis en calculant la fréquence de chaque nom dans les deux corpus. Pour chaque texte les noms propres sont extraits et triés en fonction de leur fréquence d’apparition. Ces fréquences sont ensuite utilisées pour créer des graphiques qui comparent visuellement l’importance des noms propres dans chaque œuvre.

La différence de langue entre les deux textes ne me permettait cependant pas de les comparer de façon rapide et immédiate. J’ai ainsi réfléchi à un moyen de contourner ce problème en créant un dictionnaire de correspondance entre les noms latins et français. L’objectif est ainsi de rendre les noms cohérents entre les deux textes, en particulier lorsqu’un même nom peut être écrit différemment dans les deux œuvres. Le code utilise cette liste pour remplacer les noms latins par leurs équivalents français dans les deux corpus, afin de faciliter la comparaison. Il a malgré tout fallut manuellement vérifier les données à partir des lemmes et des possibilités d’erreurs qui y sont liées.

Une fois la normalisation effectuée, les données sur les noms propres sont fusionnées pour créer une comparaison directe entre les deux textes. Le code permet de comparer la fréquence de chaque nom dans les œuvres de Suétone et de Graves, en mettant en parallèle les résultats pour chaque texte. 

Suite à cela j’ai ainsi pu obtenir les noms les plus répandus chez l’un et l’autre auteurs, mais aussi ceux les plus répandus chez les deux auteurs en même temps. Ce qui permet une visualisation directe des différents personnages dans les deux textes.

Suite à cela, je me suis interrogée sur les noms uniques chez l’autre et l’autre auteurs comme cela semblait le cas pour Hérode.

La présence significative de Caligula et d’Hérode chez Graves et leur absence encore plus significative chez Suétone me donne ainsi des pistes de réflexion intéressante pour mon mémoire sur la réception moderne de l’empereur Claude. En effet, l’omission total d’Hérode par Suétone pousse à s’interroger sur son rôle dans la vie de l’empereur.

Fréquences relatives

La taille des deux corpus s’est avéré un autre problème puisqu’il semblait absurde de prendre en compte le nombre d’occurence étant donné la différence de taille entre les deux œuvres. J’ai ainsi décidé de procéder à une nouvelle normalisation sous forme de fréquence relative ce qui m’a permis de neutraliser l’effet de la différence de taille entre les textes. Ce graphique montre ainsi les fréquences relatives des noms propres pour chaque auteur, permettant une comparaison plus fine et plus logique des deux corpus. 

Visualisation de l’évolution lexicale

J’ai ensuite voulu pouvoir visualiser la distribution des noms propres au sein des différents chapitres des œuvres pour pouvoir m’y référer rapidement au besoin.

Pour ce faire, j’ai dû comme auparavant, séparer les textes en fonctions des chapitres, les tokeniser et les lemmatiser en fonction de leur chapitre tout en supprimant les données parasites vu précédemment.

J’ai ensuite crée une liste des noms à “surveiller” pour chaque œuvre qui contient des noms définis manuellement. J’obtiens ainsi par exemple ce graphique pour l’un et l’autre corpus ce qui me permet de repérer rapidement la répartition des personnages dans le texte et de pouvoir comparer des passages.

Conclusion

En résumé, ce code fournit une analyse détaillée des noms propres dans les textes de Suétone et de Graves, en commençant par une exploration des lemmes les plus fréquents et en allant jusqu’à une comparaison des noms propres normalisés. Chaque étape vise à extraire et à comparer les éléments clés de ces œuvres, tout en prenant en compte les variations de langue et la longueur des textes. Les graphiques générés tout au long de ce processus permettent de visualiser facilement les résultats et d’obtenir des insights sur les différences et similitudes entre les deux auteurs.

Achille, une reprise du personnage homérique par Platon

Version numérique 

Le personnage d’Achille, héros emblématique de l’Iliade, est repris par Platon dans plusieurs dialogues, où il devient tantôt un modèle, tantôt un contre-exemple philosophique. Ce projet numérique, en lien direct avec mon travail de recherche pour cette année universitaire, propose une analyse comparative de ce personnage dans l’épopée homérique et les dialogues de Platon. À travers l’étude de textes comme le Banquet, la République, l’Hippias mineur, l’Apologie et le Criton, et grâce à des outils d’analyse textuelle comme Voyant Tools, ce travail met en lumière les continuités et transformations du personnage, révélant les enjeux de sa réinterprétation platonicienne.

Orientation du projet 

Le but de mon projet était d’explorer mon corpus à l’aide d’outils numériques tout en restant dans la continuité de mon mémoire. Pour cela, j’ai constitué un corpus de textes récupérés sur la plateforme Perseus, comprenant des dialogues de Platon (La République, Le Banquet, L’Apologie, L’Hippias mineur et Le Criton), ainsi que les extraits de l’Iliade qu’il y cite. J’ai également ajouté mes propres traductions des passages platoniciens sélectionnés ainsi que les traductions françaises des extraits homériques. Ce travail m’a permis d’établir une base textuelle cohérente pour analyser la manière dont Achille est repris et transformé par Platon.

Outils et méthodes

Pour mener à bien mon projet, j’ai utilisé plusieurs outils numériques. J’ai d’abord exploré Voyant Tools afin d’analyser l’Iliade dans son intégralité. Cependant, la plateforme fragmentant automatiquement le texte sans respecter la division en chants, il m’a été difficile d’obtenir une analyse fluide. J’ai donc choisi de basculer sur Obsidian, où j’ai pu organiser mon corpus en fichiers Markdown interconnectés, facilitant ainsi le suivi de mon travail textuel. Une fois mon corpus prêt, j’ai testé les possibilités d’analyse sur Obsidian, mais celles-ci se limitaient à la recherche du terme Achille en français ou en grec, sans classement de colocations. Pour affiner mon étude, je suis finalement retournée sur Voyant Tools, qui permet ce type de traitement. J’ai ainsi pu relever les termes pertinents et établir deux listes distinctes selon le corpus analysé. 

Sur la capture d’écran ci-dessous, on peut voir la structure de mon projet dans l’application Obsidian. À gauche, la barre de recherche, accessible via l’icône en forme de loupe, permet d’effectuer des requêtes textuelles. Cependant, cette fonctionnalité reste basique et similaire à celle que l’on trouve dans d’autres applications, ce qui ne m’a pas apporté l’analyse approfondie que je recherchais.

 

 

J’ai donc poursuivis mes recherches et voici ce que mes recherches sur Voyant Tools ont donné : 

Ci-dessous, capture d’écran du traitement de texte Voyant Tools sur le corpus de Platon :

Ci-dessus, capture d’écran du traitement de texte Voyant Tools sur le corpus d’Homère. 

 

Résultats obtenus

Grâce à l’outil “collocations” de Voyant Tools, j’ai pu établir d’abord deux listes des termes en lien avec le physique et le caractère d’Achille dans l’Iliade et chez Platon :

Dans l’Iliade

  • la nature d’Achille
    –> est le meilleur, “aux pieds rapides”
    –> beau
    –> fils de Pélée et d’une déesse, Thétis
    –> sensible à la musique
  • Achille et Patrocle
    –> Patrocle est son ainé
    –> est décrit comme au dessus de Patrocle (par le père de ce dernier)
  • la querelle
    –> Achille et le changement qu’il peut avoir selon son interlocuteur
  • Achille et la mort
    –> peu soucieux de son destin et du danger
    –> se montre pieu à la mort de Patrocle (les funérailles)

Chez Platon : 

  •  sincère
  • simple
  • le meilleur
  • menteur 

 

Enfin, toujours à partir de l’outil “collocations”,  j’ai pu établir deux listes sur les émotions d’Achille dans l’Iliade et dans les dialogues de Platon : 

Chez Homère : 

– le chagrin 
–> pleure 
–> sanglote 
–> ressent la douleur 
– la colère 
–> s’irrite 
–> est humilié
– le cœur (lié à la façon dont il ressent ses émotions, lui viennent du cœur)
– le regret (de sa vie humaine dans l’Odyssée)

Chez Platon, le seul ajout à cette liste est qu’il affirme clairement dans Le Banquet que Patrocle est l’amant d’Achille.  

Conclusion 

Étudier un corpus et réaliser des comparaisons intertextuelles sur un même personnage dans deux œuvres différentes, comme l’Achille de l’Iliade et des dialogues de Platon, nécessite une organisation rigoureuse et une approche méthodique. Ce projet m’a permis de découvrir qu’une analyse comparative efficace repose sur la capacité à naviguer entre les textes, à repérer les récurrences et les variations. L’application Obsidian s’est révélée précieuse pour organiser mon corpus et établir un réseau de fichiers, facilitant ainsi la gestion de mon travail. Toutefois, pour des analyses plus détaillées sur les termes et colocations, j’ai dû revenir à Voyant Tools, qui m’a permis de réaliser des analyses plus fines. Cette combinaison d’outils m’a permis d’établir une base solide pour ma réflexion sur la manière dont Platon reprend et transforme la figure d’Achille en fonction de sa pensée et ses objectifs philosophiques.

 

Une édition numérique des fragments d’Archestrate de Géla

Mon mémoire de master, en humanités classiques et humanités numériques, a pour objectif d’éditer les fragments d’Archestrate, un poète grec du IVe siècle avant notre ère, originaire de Géla, une ville située au sud de la Sicile, qui appartenait alors à la Grande Grèce. Nous possédons aujourd’hui 339 vers du poème d’Archestrate, soit soixante-deux fragments. C’est un poème gastronomique qui traite des plaisirs de la table et de la préparation du pain, de quelques viandes, mais surtout de celle des poissons, mollusques et crustacés – des mets de luxe ! Les aliments évoqués sont associés à un lieu de la Méditerranée, là où ils sont les meilleurs à trouver à un moment précis de l’année. À travers ces recettes, se dessine ainsi un véritable voyage culinaire. Ce poème hexamétrique est à la fois une œuvre didactique parce qu’il cherche à transmettre la façon de trouver et de préparer un grand nombre de produits de la mer, mais c’est aussi un pastiche parce qu’il imite les grands poèmes épiques. Poète, gastronome et voyageur : voici une esquisse d’Archestrate de Géla.

Malheureusement, ce poème ne nous est pas parvenu dans son entièreté, et de plus, il nous est arrivé indirectement, cité dans une autre oeuvre : les Deipnosophistes (Δειπνοσοφισταί, Le Banquet des sophistes) d’Athénée de Naucratis. Et, en même temps, quelle aubaine pour Archestrate, qui a survécu au naufrage de la littérature antique ! Les Deipnosophistes, composés de quinze livres, ont été écrits vers l’an 200 de notre ère et rapportent des propos de tables, tenus à Rome, par une vingtaine d’érudits, sur toutes sortes de sujets : politique, philosophie, médecine, mais aussi gastronomie, boissons, poissons, etc. C’est dans ces circonstances qu’un nombre considérable d’œuvres antiques, en vers mais aussi en prose, sont citées de mémoire par les convives.

Présentation des manuscrits

Nous possédons trois manuscrits des Deipnosophistes, que j’ai longuement parcourus afin de repérer les fragments d’Archestrate : 

Le manuscrit A, gr. Z. 447 qui se trouve à la bibliothèque Marciana de Venise, datant du Xe siècle, a été copié par Jean Le Calligraphe à Constantinople. Il est rédigé en minuscule. Pour retrouver le manuscrit sur le site de la Marciana, cliquez ici.

Image 1 – Fragment 54 (Ath. 7. 326b) tel qu’il se trouve dans le manuscrit A.
Image 1 – Fragment 54 du manuscrit A

καὶ νεαροῦ μεγάλου τ’ αὐλωπία ἐν θέρει ὠνοῦ
κρανίον, ἂν Φαέτων πυμάτην ἁψῖδα διφρεύῃ.
καὶ παράθες θερμὸν ταχέως καὶ τρῖμμα μετ’ αὐτοῦ.
ὄπτα δ’ ἀμφ’ ὀβελίσκον ἑλὼν ὑπογάστριον αὐτοῦ.

Et, quant au jeune et grand aulopias, achète, en été,
La tête, lorsque Phaéton conduit son char à l’extrémité de la voûte,
Et, sers-le chaud, sur le champ, et la sauce qui va avec.
Fais-le griller à la broche, après avoir pris son ventre.

Le manuscrit C, supplément grec 841, appartenant à la Bibliothèque Nationale de France, a été rédigé par Demitrios Damilas entre 1476 et 1506, en écriture humaniste. La numérisation de ce manuscrit est disponible sur le site de la BNF (ici).

Image 2 – Fragment 54 du manuscrit C

Enfin, le manuscrit E, Pluteus 60.02, qui se trouve à la Bibliothèque Laurentienne de Florence, a été transcrit, lui aussi, en écriture humaniste par Jacob Questenberg, vers 1490. La numérisation est visible en cliquant ici

Image 3 – Fragment 54 du manuscrit E

Après avoir trouvé les fragments d’Archestrate de Géla dans les manuscrits A, C et E, je les ai transcrits un à un, puis je suis passée à leur traduction. Au terme de ce travail, l’idée d’une édition numérique a émergé. En effet, un site compagnon qui hébergerait mon travail faisait sens dans la mesure où il permettrait l’accès direct aux manuscrits – ce qui n’est pas le cas dans les éditions imprimées comme les Belles Lettres, par exemple. Cela faciliterait aussi la comparaison entre les trois manuscrits et donnerait ainsi tout son sens à l’apparat critique. Ce site compagnon serait enfin enrichi d’un index nominum et d’un index locorum.

Langage XML et TEI

Pour cela, j’ai utilisé le logiciel Oxygen pour encoder le texte d’Archestrate de Géla en langage XML, ou « extensible markup language », tout en suivant les recommandations de la TEI, « text encoding initiative », un format de balisage international que les universitaires et les chercheurs utilisent dans le champs des humanités numériques pour l’encodage de ressources. La TEI est un ensemble normalisé de balises que l’on applique aux textes littéraires afin de ne pas porter atteinte à leur intégrité.

Après la déclaration XML qui permet de spécifier la version de XML et le type d’encodage du document, il faut préparer le <teiHeader> : un en-tête qui rassemble toutes les métadonnées du texte que l’on encode. Plusieurs balises sont alors utilisées pour préciser :

– le titre <title> </title> ;

– le nom de la personne responsable de l’édition <respStmt><resp></resp><name></name></ respStmt> ;

– les sources utilisées (titre et auteur) : <sourceDesc><bibl><title></title><author></author></bibl></sourceDesc>

– les manuscrits : <listWit></listWit>

– l’index nominum : <listPers></listPers>

– l’index locorum : <listPlace></listPlace>

Après la préparation du <teiHeader>, il faut encoder le poème avec des balises, qui structurent le texte, comme l’élément <div> qui m’a permis de diviser le texte en fragments, la balise <head> qui indique le titre de chaque fragment et, enfin, l’élément <l> qui répartit le texte en vers.

Enfin, les variantes textuelles peuvent être spécifiées, grâce à des balises propres à créer l’apparat critique. Cela permet de reconstruire l’histoire des versions d’un même texte et de fournir de façon détaillée ses différentes leçons. On documente ainsi les différences textuelles entre les manuscrits. L’élément <app> est l’élément racine où l’on regroupe les différentes variantes d’un texte, l’élément <lem> indique la lecture principale ou reconstituée d’un passage. Quant à l’élément <rdg>, il indique les autres versions du texte, qui diffèrent de la lecture principale.

 

Image 4 – Fragment 54 encodé. On y voit les différentes balises : <div>, <head>, <l>, <app>, <lem>, <rdg>

Pour l’édition numérique des fragments d’Archestrate de Géla, j’ai utilisé des balises assez courantes. Cliquez ici pour avoir une vision plus détaillée des TEI Guidelines.

Le fichier XML a ensuite été transféré sur GitHub, une plate-forme open source qui aide les développeurs à stocker et à gérer leurs données, leurs codes mais aussi à suivre et à contrôler les modifications faites sur leurs fichiers par d’autres utilisateurs. J’ai créé un repository ou dépôt que j’ai appelé : classnum/evt-1.3_archestratus. Ce dépôt m’a permis de regrouper mon fichier XML, les captures d’écran des fragments prises dans les manuscrits A, C et E, au format .png. Monsieur Berra a été désigné administrateur de ce dépôt afin de m’aider à gérer les problèmes au fur et à mesure.

Github et EVT

Le transfert sur GitHub était indispensable afin de terminer la préparation des données et de les déployer sur EVT (Edition Vizualisation technology), une plateforme créée par l’université de Pise, pour l’édition, la visualisation et la publication numérique. L’utilisation de GitHub Desktop me permettait de modifier mon fichier sur Github : en effet, en encodant directement sur Visual Studio Code, je pouvais ensuite envoyer, grâce à la fonction Push, les modifications sur mon fichier en ligne. La fonction Pull, quant à elle, me permettait de recevoir les corrections et les recommandations de Monsieur Berra. Mais, malgré les ressources que possède EVT, la version 1 n’est pas réellement prévue pour publier des éditions critiques. J’ai dû m’accommoder des possibilités du système pour l’encodage de l’apparat critique avec les balises suivantes : <choice></choice>, <corr></corr> (apparat), <sic></sic> (leçon retenue). C’est alors que j’ai dû réviser mon code afin qu’il soit compatible avec EVT.  Enfin, j’ai eu recours à une connexion Python, qui, grâce un http server, permet de transférer mes données de GitHub sur EVT. Un problème s’est alors posé pour les captures d’image des manuscrits. Parfois, un fragment se trouvait sur deux pages de manuscrit et j’ai dû faire deux captures d’écran. Malheureusement, sur EVT, il n’était possible de ne mettre qu’une image par page. On a essayé de trouver des solutions. C’est ainsi que Monsieur Barra m’a proposé de lier deux images d’un même fragment ensemble, au sein d’un même fichier, mais cela demandait une manipulation délicate. C’est alors que l’on a choisi une option plus simple, celle de mettre l’image qui contenait le plus de texte en ligne.

L’édition numérique et son mode d’emploi

Image 5 – Capture d’écran de la page d’accueil de l’édition numérique

Cliquez ici pour accéder à l’édition numérique.

Voici quelques conseils pour consulter cette édition en ligne :

  • Passer tout d’abord sur l’interface francophone. Pour cela, cliquer sur les trois petites lignes en haut à droite de votre écran.

  • Consulter ensuite l’édition “interprétative” soit avec les images, soit avec la transcription ou la traduction.

  • Cliquer sur le petit triangle en haut, à gauche ou à droite de l’écran, pour n’avoir que l’image ou la transcription ou la traduction.

  • Sélectionner le numéro du fragment en déroulant l’ascenseur.

  • Survoler les mots en rouge de la transcription pour voir les notes éditoriales.

  • Cliquer sur la fenêtre ‘informations’ en haut à droite de l’écran pour trouver l’introduction et le commentaire.

  • Enfin, consulter les index nominum et locorum en cliquant sur “listes” en bas de l’écran.

    AVANCEES et Perspectives

    En cette année de master 2, et au terme d’une révision de ma transcription et de ma traduction, mon objectif est d’améliorer cette édition numérique. Je souhaiterais, en effet, la rendre plus interactive. Cela est devenu possible grâce à la version 3 d’EVT, qui permet une meilleure lisibilité de l’apparat critique. Cette version semble aussi plus souple à utiliser qu’EVT1 grâce aux fichiers .json, un format de données utilisé en alternative au langage xml, pour échanger des données entre un serveur et une application web.

    Pour cette nouvelle édition, un nouveau repo a été créé : classnum/evt-3.0_archestratus. Pour faire des modifications sur le fichier .xml, le principe est toujours le même : j’ai travaillé sur Visual Studio Code, avec les fonctions Push et Pull, pour modifier mon fichier sur GitHub.

    Si l’apparat critique est beaucoup plus lisible, la traduction, quant à elle, n’a pas d’emplacement prédéfini. Les développeurs, en effet, n’ont pas encore prévu un affichage pour la mettre en valeur. Une solution pourrait être la suivante : placer en-dessous de chaque transcription sa traduction. Des tests sont en cours. Cela est rendu possible grâce à l’installation du plugin Live Server, qui permet de visualiser, à partir de Visual Studio Code, l’éditeur de textes et de voir les modifications, que l’on effectue, en local.

    De son côté, monsieur Berra a construit tout le framework, c’est-à-dire tout le squelette du programme. Je le remercie vivement. Je lui suis aussi reconnaissante d’avoir lever plusieurs obstacles : la publication ne peut se faire que dansSafari ou Chrome et les images ne peuvent apparaître qu’au format .png.

    Cette édition numérique est un outil de travail personnel très précieux. Elle permet, en effet, de regrouper tout mon travail et de le mettre à jour au fur et à mesure de mes avancées. C’est un work in progress, qui s’enrichira, au cours des prochains mois, d’un index des aliments cités par Archestrate et, notamment, des animaux aquatiques, très nombreux. La présentation des images sera aussi améliorée, en liant deux captures d’écran, lorsque c’est le cas, grâce à un logiciel spécialement conçu pour cela.

    Si Archestrate de Géla est un poète méconnu, l’édition numérique de ses fragments, par son accessibilité, contribuera, je l’espère, à sa diffusion et à sa connaissance. À terme, il serait fructueux de faire une édition des poètes gastronomes de Sicile : Mithaicos, Héraclide, Dionysios et Agis. Cela permettrait de comparer leur style d’écriture, les aliments qu’ils mettent en avant et la façon dont ils les apprêtent, mais aussi ceux dont ils ne parlent pas. Ainsi, l’édition numérique pourrait faciliter la comparaison avec d’autres textes similaires et, peut-être, d’apercevoir leur filiation. Cliquez ici pour la consultation en ligne.

    Image 6 – Capture d’écran du fragment 54 avec sa transcription et son apparat critique que l’on obtient en cliquant sur le mot surligné en bleu pâle.

Grâce à l’édition des fragments d’Archestrate, j’ai pu parcourir toute l’histoire du livre : du papyrus aux technologies les plus récentes. Une histoire passionnante.

Lemmatisation, analyse et tentative d’interprétation d’une déclamation latine par des outils informatiques

Introduction

   Dans ce billet, nous essaierons de montrer les possibilités ainsi que les difficultés que l’on peut rencontrer lors de l’étude d’un long texte ou d’un corpus de textes, au moyen d’outils numériques. Le but est d’extraire d’un texte, ici d’un poème, le plus d’informations possibles, plus que ce que l’œil humain, même après plusieurs lectures, peut obtenir devant la quantité de vers et de mots qui le composent. Pour cela, sont nécessaires trois étapes: la préparation des données, le codage, et l’interprétation. C’est donc ce plan que nous suivrons dans cet exposé.

   Il apparait nécessaire maintenant de faire une brève présentation du poème que nous allons analyser et qui fait partie du corpus de déclamations que j’étudie dans le cadre de mon mémoire. Il s’agit d’une controverse datant du Ve-VIe après J.C couramment intitulée “Le pêcheur sacrilège” ou AL 21 Riese. Cette pièce poétique est aussi un plaidoyer contre un pêcheur ayant volé l’or contenu dans le temple de Neptune et l’ayant ensuite ramené sous la forme d’un poison doré avec l’inscription “De tuo tibi Neptune”. Le déclamateur cherche à prouver sa culpabilité.

   Le travail réalisé va être présenté et commenté ci-dessous. Mais la version Pdf à la fin du billet permet d’avoir un aperçu plus détaillé des lignes de codes qui seront abordées plus loin.

Préparation des données

Accéder au texte

   Notre travail reposant sur un texte, il nous donc commencer en premier lieu par entrer en possession de ce matériau fondamental. Il y a, selon moi, trois manières de procéder, sachant que notre étude sera d’autant plus aisée que nous aurons un texte débarrassé des caractères non alphanumériques. La méthode la plus simple est de l’exporter, au format souhaité, directement depuis un des nombreux entrepôts de textes en ligne comme Perseus Digital Library. La deuxième, la plus fastidieuse, est de recopier l’intégralité du texte. La troisième, celle que nous suivrons, consiste à simplement à réaliser un copier-coller à partir d’un site qui donne accès à notre poème. 

   Il convient de préciser que la pièce 21 de l’Anthologie Latine est très tardive et, par conséquent, ne se retrouve pas facilement sur internet et sur les sites spécialisés dont nous venons de parler. C’est pourquoi, nous choisissons cette option. Dans tous les cas, pour tout projet de ce genre, la préparation des données est très souvent impérative et relativement aisée grâce aux outils que l’on verra plus tard. Quoiqu’il en soit, c’est sur le site Musisque Deoque, répertoriant tout particulièrement des œuvres poétiques latines, que nous retrouvons notre texte. 

Nettoyer le texte

   Pour cela, on peut soit passer par VS Code, soit directement par RStudio, le but étant de ne conserver que les mots d’AL 21 séparés par un seul espace pour pouvoir l’exploiter par la suite. Dans RStudio, les fonctions stringr sont les plus utiles pour cela. Mais, étant donné le procédé auquel nous avons recouru et l’état particulièrement dégradé des éléments copiés, il convient davantage de travailler avec VS Code et sa fonction Replace. Le fichier ainsi nettoyé se nomme AL_21.txt.

   J’en profite ici, mais nous y reviendrons plus loin, pour mentionner l’outil OpenRefine et son utilité dans le traitement des fichier csv et tsv. En effet, son rôle est salutaire et parfois mieux adapté que RStudio lorsqu’il s’agit de trier des informations contenues dans un tableau de données. Grâce à la fonction fwrite, il est ainsi possible de demander à R d’exporter un tableau au format voulu et de l’exploiter ensuite avec OpenRefine. 

Le codage dans R

La distribution des principaux termes

   Notre travail s’articule en deux parties : une étude de la distribution des mots les plus fréquents d’Al 21 ainsi qu’une étude grammaticale et syntaxique de l’œuvre. Nous aborderons d’abord la distribution avec le fichier R AL_21_distribution_termes. Notre démarche ici obéit à deux objectifs : obtenir les dix mots les plus fréquents et observer la manière dont ils se répartissent dans notre déclamation.

Un texte non lemmatisé

   Après avoir installé le package pacman, nous insérons notre fichier AL_21.txt dans R qui en fait une liste unlist(). Notre texte étant nettoyé, il n’est pas utile de recourir aux stringr. Puis, la suite de mots doit être mise dans un tableau tibble et en faire des tokens pour qu’ils puissent par la suite être dénombrés avec la fonction count. On se rend compte que la plupart des occurrences obtenues ne sont pas intéressantes pour l’interprétation à venir, car il s’agit de termes courants et que l’on peut retrouver dans la majorité des écrits latins.

   Il nous faut donc être plus précis dans notre recherche. Dans notre cas de figure, une solution peut être d’insérer une liste préétablie de termes parmi les plus fréquents (stopwords_latin_v2_6) et de la faire fusionner avec nos résultats (fonction anti_join) afin de ne faire apparaitre que les termes les plus représentatifs de notre déclamation. 

   Le graphique construit à partir de la fonction ggplot nous donne des résultats bien plus spécifiques que plus haut. Les dimensions religieuse et criminelle semblent les plus caractéristiques. Cependant, remarquons que le texte n’est pas lemmatisé et que notre liste comprend plusieurs termes pour un même lemme (aurum /auro).  Notre représentation n’est donc pas optimale. Pour résoudre ce problème il nous faudrait un texte qui soit lemmatisé au préalable.

Lemmatisation d’AL 21

   Les contraintes rencontrées nous obligent à aborder cette étape nécessaire dans la distribution mais dont notre étude grammaticale et syntaxique bénéficiera également. Pour cela, nous utilisons le service de lemmatisation Deucalion. Le procédé est relativement simple, il suffit de coller notre texte dans un espace dédié et le site sort une page où les données, séparées par des tabulations, peut être copié. 

   Il ne reste plus qu’à sélectionner les données ou plutôt la ou les colonnes qui nous intéressent. La suite de l’étude de la distribution ne requiert que la colonne “lemme”. Donc, nous ne conservons que celle-là avec OpenRefine et nous l’exportons dans R. 

Un texte lemmatisé

   Maintenant, nous pouvons reprendre les étapes déjà mentionnées et observer la nouvelle représentation graphique.

   Cette fois-ci, les différentes formes d’un même mot sont regroupées et viennent grossir le nombre d’occurrences de termes déjà présent sur le graphe précédent. Cependant, de nouvelles entrées ont été ajoutées comme rapio, donum ou furtum. Nous verrons comment interpréter cela plus tard. 

Répartition des principaux termes

   Une fois que nous connaissons les lemmes les plus caractéristiques de ce texte, nous pouvons maintenant nous intéresser à la répartition d’un terme donné au sein de la déclamation. Nous ne nous concentrerons que sur un exemple précis, celui d’aurum, le lemme le plus fréquent et le plus représentatif des potentialités de la distribution dans R

   Il faut commencer par indexer (fonction seq) le texte lemmatisé mais non fusionné à la liste de stopwords, car la distribution serait alors biaisée, des lemmes ayant été retirés. Ensuite, la fonction which intègre le lemme choisi. Et, on attribue le résultat NA à toutes les occurrences autres que aurum et la valeur 1 sinon. La fonction plot, enfin, nous permet de visualiser ceci.

Interprétation de la distribution des principaux termes

   Il convient maintenant d’exploiter nos recherches en commençant par la liste des dix mots les plus fréquents. Comme nous l’avons déjà dit, les aspects criminel (scelus, crimen, facinus) et sacré (templum) dominent dans la déclamation. Mais, les autres résultats semblent montrer que le déclamateur insiste et intensifie la portée du crime. Le terme aurum (or) revient le plus. Il s’agit en effet de l’objet volé mais, la qualité de l’objet ainsi accentuée, fait apparaitre par synecdoque le vol du métal précieux comme plus important que le vol lui-même. De plus, la répétition de magnus (grand) et ars (art) par hyperbole aggrave le forfait du pêcheur. De même que les antithétiques donum (don) et furtum (vol) tendent à exciter le sentiment d’injustice de l’auditoire. La distribution spécifique du lemme aurum tend à confirmer cette interprétation. En effet, le déclamateur rappelle fréquemment que l’or a disparu du temple, mais c’est surtout vers la fin du texte, peu avant le 1500e mot que ce terme est comme martelé. Or, cela correspond à peu près aux parties “preuve” et “réfutation”, parties venant avant l’épilogue, comme si l’auteur de ce procès à charge souhaitait que ses auditeurs aient davantage en tête la valeur considérable du larcin, avant la fin de son discours.

L’étude grammaticale et syntaxique

Présentation de la méthode

   Cette partie s’appuie largement sur les fonctionnalités du package Tidyr, car nos recherches nous amènent à extraire du tableau généré par Deucalion des données bien précises. Contrairement à l’étude précédente, nous ne traitons plus de lemmes mais de classes grammaticales et de syntaxe. Pourtant, le procédé est assez similaire, sauf que nous ne donnons à R non pas la colonne des lemmes mais celles qui contribuent à leurs caractérisations comme le temps pour les verbes ou les cas pour les formes déclinables. Cela nous donne accès à des données chiffrées portant sur la langue.

Limites de Deucalion

   Le rôle de Deucalion, comme on a pu le voir, est important dans notre étude. Cependant, afin d’en exploiter tout son potentiel, il convient d’avoir à l’esprit ces trois inconvénients, plus ou moins problématiques, qu’il est préférable de résoudre. D’une part, bien que Deucalion parvienne très souvent à une lemmatisation complète, certaines lignes demeurent incomplètes. Outre le fait qu’il faut en tenir compte pour l’interprétation, cela entraine des décalages dans les colonnes, créant des colonnes hétérogènes avec des informations propres aux colonnes voisines venant s’y insérer. D’autre part, Deucalion sort dans la colonne “Dis”, dans une même cellule, un ensemble de caractéristiques relatives au lemme comme le genre pour le nom ou le mode pour le verbe. Le problème est que, selon que ce soit un nom ou un verbe, ces marques non seulement ne viennent pas dans le même ordre, mais encore diffèrent à cause de la nature propre de l’élément lemmatisé (un nom ne peut pas avoir de temps ou de personne). Enfin, d’un point de vu formel, certaines cases présentent une forme un peu lourde du type telle caractéristique est égale à telle chose.

   A cela, nous pouvons apporter deux solutions. La première est la plus fastidieuse. Elle consiste vérifier et à corriger les lignes et les colonnes une par une. La deuxième a l’avantage d’être plus rapide car automatisée par R, mais elle ne permet pas de tout modifier ou, du moins, de le faire de manière plus aisée que manuellement. Dans notre cas, il parait nécessaire de combiner ces deux approches, car notre travail n’implique pas d’étudier toutes les propriétés des lemmes, mais seulement leur nature et leur fonction (répertorier tous les mots masculins ou tous les pluriels sort du cadre de notre étude). Or, on peut constater que pour toutes les catégories, hormis les verbes, la lemmatisation de la nature et du cas est correcte. Donc, ceux-là peuvent être directement traités dans R. Pour les verbes, au contraire, il faut passer par VS Code et OpenRefine afin de corriger au cas par cas en ajoutant des NA là où la lemmatisation a échoué.

Etude de la nature des lemmes

   Comme mentionné précédemment, on fait lire notre tableau csv à R et on utilise les fonctionnalités de Tidyr pour y rechercher des informations précises. Les fonctions group_by et arrange permettent d’organiser la colonne “nature”. Puis, la fonction count dénombre le tout. On s’aperçoit alors que Deucalion a procédé à une sous-catégorisation des natures, distinguant par exemple les noms propres (NOMpro) des noms communs (NOMcom). Ce degré de précision étant superflu ici, nous utilisons, pour chaque nature, un filtre filter afin de regrouper chaque classe grammaticale. Nous unifions ces catégories en une seule avec mutate. Cela fait, il ne reste plus qu’à compter (count) séparément chaque nature et à former un tableau (tibble). Ce dernier doit être “retourné” avec pivot_longer afin de le visualiser correctement avec ggplot

   Le graphe obtenu montre assez clairement la répartition à laquelle nous souhaitions aboutir. Néanmoins, le nombre d’occurrences demeure relativement flou pour l’interprétation. Il est alors conseillé de l’échanger pour des fréquences. Le procédé est plutôt rapide. Il faut dégroupé ungroup les éléments, comptabiliser le nombre total d’occurrences avec summarise et sum, joindre cross_join le résultat au tableau et ne sélectionner select que les colonnes nature et fréquence. 

Les traits grammaticaux (verbes)

   Nous reviendrons sur l’interprétation de ces résultats. Passons maintenant à l’étude plus spécifique des verbes et de leurs traits grammaticaux. Contrairement aux autres classes grammaticales, comme on l’a vu plus haut, leur analyse requiert un nettoyage préalable et distinct selon leur mode (un participe est déclinable, un verbe conjugué non). Nous allons donc recourir de nombreuses fois à la fonction separate_wider_delim et ne sélectionner (select) que les colonnes d’intérêt, afin de clarifier la présentation des résultats. Il faut également transférer nos données à VS Code pour combler et replacer correctement les valeurs dans leur colonne propre. La fonction filter nous permet de trier et ainsi de choisir les modes, que nous aborderons d’abord. Une fois purifiées, les données sont dénombrées (count), puis placées dans un tableau et enfin réorganisées. Nous présenterons ici les résultats sous forme de fréquences, pour la même raison que plus haut. 

   Pour l’étude de la répartition des temps et des voix, nous procédons d’une manière différente car nous avons maintenant une colonne fixe “mode”. Il suffit de sélectionner (select) les colonnes mode et temps ou mode et voix et de les rassembler dans un même tableau avec full_join. Une fois dénombrés (count) et réorganisés reorder selon un ordre décroissant decreasing, on obtient les graphes suivants : 

   Concernant l’étude des personnes du verbe, une étape doit précéder le processus que l’on a suivi pour le temps et la voix. En effet, les colonnes “personne” et “nombre” sont séparées dans notre tableau. La fonction unite permet de les faire fusionner, nous employons comme séparateur sep la formule “ème du ” pour rendre la fusion plus esthétique. Il est à noter que le participe et l’infinitif étant des modes non personnels, il ne seront ici pas pris en compte.

L’étude syntaxique

   Nous aborderons dans cette partie la répartition des cas des mots déclinables. Il est évident que certaines catégories grammaticales, n’admettant pas de déclinaisons, seront mises de côté lors de notre tri préalable (select(cas)). De déclinables et identifiés comme tels par Deucalion nous trouvons les noms, les adjectifs et les participes. Le fait que les participes fassent partie de cette catégorie explique pourquoi nous nous intéressons aux cas en dernier. En effet, il nous fallait d’abord les purifier avant de pouvoir les étudier. Pour le reste, nous suivons le même procédé que précédemment. 

Interprétation

   La forte proportion de noms est à mettre en relation avec l’écrasante majorité de nominatifs dans le texte. Le fait d’avoir une quantité si élevée de noms au nominatif, ou plutôt de noms sujets et de noms attributs du sujet traduit une volonté manifeste de catégorisation du sujet. En effet, le déclamateur insiste davantage sur l’état du sujet que sur l’objet d’une action, puisqu’il y a environ deux nominatifs pour un accusatif, complément naturel et régulier du verbe transitif. En outre, rappelons que l’occurrence qui arrive en tête dans le texte non lemmatisé est le verbe être (est, 46 occurrences). Cela implique que l’auteur de la déclamation livre un véritable procès à charge contre l’accusé, appuyant moins sur les circonstances du crime que sur leur auteur lui-même (la troisième personne du singulier, c’est-à-dire le pêcheur, est sept à huit fois plus usitée que les autres). D’ailleurs, la lecture du texte nous le confirme, les attaques ad personam et ad hominem font légion. De même, les autres documents vont dans ce sens. L’indicatif, cinq fois plus important que le subjonctif, place le discours dans le domaine du factuel et non dans de l’hypothèse. Fait ou plutôt méfait qui poursuit le pêcheur même dans le présent (trois fois que le passé) et pour lequel il est directement responsable (quatre fois plus de verbes actifs que le passifs). 

Conclusion

   Pour finir, grâce à des processus automatisés, nous sommes parvenus à caractériser un texte latin de manière plutôt intéressante. Cela a été rendu possible par le formidable outil qu’est Deucalion et qui nous permet d’analyser autant des termes que leur nature, leurs traits grammaticaux ou leur syntaxe. Le nettoyage des données, rendu possible par VS Code et OpenRefine, est, néanmoins, souvent nécessaire. Les multiples fonctionnalités de R et du package Tidyr ont contribué à l’exploitation des informations fournies par Deucalion. Notre déclamateur a une propension à l’exagération du crime de l’inculpé (prédominance d’aurum). Il s’inscrit dans une stratégie rhétorique de l’attaque personnelle, visant à expliquer le forfait par la prédisposition (ars) du pêcheur au larcin (furtum).

   Sources
Fichiers partagés