D’où nous viennent nos projets de recherche ?

« D’où nous viennent nos idées ? » se demandait en 2010 Éric Méchoulan, dans un ouvrage où il démontrait que loin d’être abstraites et immatérielles, les idées sont le résultat de conditions matérielles précises et déterminées. Les techniques et les supports de transmission, les aléas de l’histoire produisent autant d’idées qu’un prétendu sujet cartésien (2010). Cette question, d’où nous viennent nos idées ?, apparaît tout aussi essentielle dans le cadre de la recherche universitaire : d’où viennent les hypothèses de recherche, les méthodologies, les modèles épistémologiques, les solutions brillantes (ou moins brillantes) à des problèmes complexes ? Et plus fondamentalement, d’où nous viennent nos projets de recherche ? Comment adviennent-ils et comment évoluent-ils, plus en particulier, dans le contexte spécifique de ce que l’on appelle les « humanités numériques » ? La thèse que nous souhaitons défendre ici s’appuie sur les mêmes conclusions que celles formulées par Éric Méchoulan : loin d’être le fruit d’un·e seul·e chercheur·e, la pensée est le fruit d’un ensemble complexe de conjonctures médiatrices (Larrue et Vitali-Rosati 2019) qui comprennent un ensemble de forces hétérogènes dont émergent ensuite des personnes, des techniques, des textes, des plateformes, des méthodes, des collectifs…

Le domaine des humanités numériques avec ses approches et ses méthodologies a toujours été caractérisé par la conscience du fait que la pensée n’est pas la production d’un individu, mais plutôt le résultat de conjonctures dynamiques et complexes où sont en jeu des forces diverses. Dans cet article, nous avons l’intention d’illustrer cette émergence de la pensée dans le cadre d’un projet particulier portant sur l’Anthologie grecque. Recherche collective fortement outillée – disséminée pourrait-on dire, dans le sens où il est très difficile de délimiter strictement les acteurs qui y ont participé –, ce projet nous semble rendre compte de façon convaincante des conjonctures médiatrices d’émergence de la pensée.

Depuis 2014, la Chaire de recherche du Canada sur les écritures numériques (la CRCEN) dirigée par Marcello Vitali-Rosati travaille à la réalisation d’un projet de recherche consacré à l’édition collaborative et l’enrichissement de l’Anthologie grecque¹. Cette recherche a été initiée avec la collaboration d’Elsa Bouchard, professeure au Département de philosophie de l’Université de Montréal et la collaboration de Chistian Raschle, professeur au Département d’histoire de l’Université de Montréal. Plusieurs contributeurs et contributrices ont eu un impact important dans l’histoire du projet : notamment les étudiant·e·s du lycée classique d’État « Samuele Cagnazzi » d’Altamura en Italie, sous la supervision de la professeure Annalisa di Vincenzo, et du lycée classique d’État « Ettore Majorana - Elena Corner », sous la supervision de la professeure Karine Baldan. Dans cet article, nous souhaitons revenir sur les origines du projet et ses récents développements pour formuler et explorer les problématiques théoriques et techniques rencontrées.

Il était une fois un projet

Notre problématique initiale n’était pas tant philologique qu’herméneutique : comment proposer un modèle éditorial numérique capable d’incarner un corpus² littéraire tel que l’Anthologie grecque et, plus généralement, la logique même du modèle anthologique ? Ce projet pilote visait également à proposer la première édition complète de l’Anthologie intégrant les scholies (leur transcription et traduction) et retraçant la richesse anthologique de ce corpus, notamment ses différentes compilations.

En effet, si les compilations de l’Anthologie sont multiples et viennent complexifier son histoire génétique, elles résultent de choix propres aux compilateurs, parfois accordés aux modes et mœurs de leurs époques – par exemple Maxime Planude dans sa propre anthologie a écarté plusieurs épigrammes dont notamment les épigrammes pédérastiques qui occupent le livre XII de l’Anthologie palatine (Beta 2019). Le principe d’une anthologie repose sur le rassemblement de fragments épars et représentatifs d’une culture selon un réseau de sens et d’imaginaire qui fait appel à la récurrence de thématiques (ce que l’on appelle les topoï). Ce principe est en réalité très proche des caractéristiques de structuration et de circulation des contenus sur le Web (Doueihi 2011, 163). Le projet pilote a donc exploré les possibilités d’édition d’un tel corpus dans un environnement numérique afin de mettre en lumière la multiplicité des lectures, le réseau des topoï et l’enrichissement des épigrammes par un ensemble de métadonnées.

Parce que cette première modélisation se fondait sur la pluralité et l’ouverture de l’œuvre ainsi que sur la notion d’intelligence collective (Lévy 1994), elle s’écartait des standards de l’édition savante numérique³ et nous a amenés à imaginer un nouveau modèle éditorial.

Le début du projet : penser un modèle théorique et technique

L’absence d’édition numérique de l’Anthologie (en dépit d’une abondante documentation secondaire sur le sujet) que nous avions constatée lors de la phase initiale du projet, avait motivé la mise en place une plateforme qui permette de rassembler, pour chaque épigramme, des traductions en plusieurs langues⁵, des commentaires, quelques mots-clefs et éventuellement des informations relatives au manuscrit. La première version était un simple site web généré avec le système de gestion de contenus Spip, mis en place par Marcello Vitali-Rosati⁶.

C’est ce premier modèle de données qui a servi à spécifier les besoins et surtout à définir le projet, ses problématiques de recherche, ses approches et ses méthodes. Ce premier constat est fondamental : la mise en place d’une stratégie éditoriale, la définition d’une conception singulière du texte, ainsi que celle d’un modèle épistémologique et herméneutique pour le lire et l’interpréter, passent par la mise en place d’outils et d’environnements de lecture et d’écriture. En soi, il n’y a pas de théorie du texte sans manipulation du texte.

En effet, le Spip originel a servi à définir la première API, conçue par Arthur Juchereau. Et successivement, cette API nous a permis de faire évoluer le modèle éditorial et de préciser notre interprétation du sens du texte pour développer d’autres environnements de lecture et d’écriture. Tout au long de ce processus, notre équipe a progressivement acquis des compétences techniques indispensables au suivi des développements du projet, mais aussi de ses enjeux épistémologiques et herméneutiques.

Arthur avait dû d’abord nous expliquer ce qu’est concrètement une API. Nous en avions auparavant une compréhension approximative. La possibilité d’interroger le texte de façon normalisée depuis plusieurs plateformes s’est avérée être un atout majeur : la conception du modèle de données fut effectuée de façon progressive, en ajoutant au fur et à mesure les champs qui se montraient nécessaires. Les étudiant·e·s de l’école Hetic en charge de la construction d’une plateforme de parcours de lecture furent sur ce point impliqué·e·s pour réaliser une première version de la base.

Au cours de cette progression, certains concepts s’étaient imposés :

1. L’objet central dans le modèle des données était ce qu’à l’époque nous avions nommé une entity : une épigramme non pas conçue en tant que texte mais en tant qu’entité abstraite.
2. Une entité pouvait avoir plusieurs versions. Ces versions sont des textes qui ont tous une même valeur : une édition du texte grec ou une traduction sont considérées au même titre comme des « manifestations textuelles » de l’entité. Cela correspondait au principe du projet : il ne s’agissait pas de rechercher la vérité du texte mais bien de mettre en valeur toutes les résonances des topoï anthologiques.
3. Tous les objets de la base devaient être multilingues : donc chaque objet (auteurs, mots-clefs, commentaires, etc.) a des versions.

Le backend de l’API était développé en se basant sur l’infrastructure logicielle (backend en anglais) Sail.js et l’interface d’utilisation avec la bibliothèque Javascript React. Son code est disponible sur un dépôt Git. L’API – encore en ligne – sert du Json.

À partir de ce premier prototype une série d’actions sont devenues possibles :

1. Remplir la base avec les épigrammes. Un script permettait d’importer le texte grec dans l’édition de Paton depuis Perseus. Ensuite les éditeur·ice·s ajoutaient des traductions –  en anglais, en français et en italien, originales ou issues d’éditions existantes.
2. Mettre en place des collaborations avec des groupes d’élèves. En particulier, deux lycées classiques italiens ont mis en place des ateliers d’édition collaborative. Un intérêt pédagogique émergeait alors de notre projet : en Italie, le grec est étudié pendant cinq ans au lycée classique. Dans un moment où l’école tend de plus en plus vers la formation professionnalisante et met de côté sa fonction de former des citoyens par le développement d’un esprit critique et d’une culture générale, l’étude du grec est parfois perçue comme une perte de temps. Notre réflexion permettait à la fois de donner une dimension appliquée à la pratique de la langue et d’insérer le travail d’étude dans un projet de recherche. Le message que nous voulions transmettre devenait le suivant : la connaissance du grec est précieuse pour contribuer à la compréhension de nos cultures et de nos imaginaires actuels comme passés. Grâce à des professeurs particulièrement engagés, l’expérience s’est révélée être un succès. Les élèves ont produit des contenus de qualité – en particulier pour le livre IV et V – en proposant des traductions, des commentaires et des alignements des textes avec les traductions. Le succès a été par ailleurs souligné par le Prix pour l’école numérique remporté par le lycée d’Altamura. La dimension pédagogique du projet est également investie grâce au programme Mitacs des stages de recherche Globalink (SRG) qui met en place le jumellage entre les membres du corps professoral du Canada et les étudiant·e·s internationaux·ales du premier cycle dans le cadre de projets de recherche. En 2021, trois étudiant·e·s ont participé au développement du projet dans le cadre de ce programme et sont ainsi formé·e·s aux enjeux d’édition numérique savante de corpus classiques fragmentaires.
3. Aligner des textes avec les traductions. L’alignement des textes est une des activités présentant un fort intérêt pédagogique. En utilisant une simple interface, il est possible d’associer les mots du texte grec avec les mots correspondant dans une traduction. Cela permet évidemment une prise de conscience fine du travail de traduction. Ces alignements ont été réalisés grâce à un éditeur conçu en Javascript, développé ad hoc par Arthur Juchereau. La possibilité d’utiliser un éditeur déjà existant, comme Alpheios, avait été prise en compte puis écartée à cause de la relative lourdeur de l’environnement technique demandé. Ce choix aura ensuite des répercussions sur la compatibilité de nos données – dont il sera question plus tard.
4. Aligner des textes avec le manuscrit. Le manuscrit est disponible en version numérique (images non océrisées⁷) sur le site de la bibliothèque de Heidelberg. Les derniers feuillets – qui se trouvent à la Bibliothèque nationale de France – sont disponibles sur la plateforme Gallica. Dans un premier temps, nous n’avions pas de solution d’annotation bien structurée. Nous nous limitions à découper manuellement le manuscrit en produisant des images au format JPG qui étaient ensuite liées aux épigrammes correspondantes. Cette solution posait une série de problèmes dont le premier était l’impossibilité de lier de façon explicite la partie du manuscrit avec sa transcription. C’est dans ce cadre que les discussions avec la bibliothèque de Heidelberg et en particulier avec Gustavo Fernandez Riva ont été très productives. La bibliothèque était en train de développer une application Javascript pour annoter le manuscrit, le segmenter et produire automatiquement des images avec le protocole IIIF (International Image Interoperability Framework) pour chaque segment. Les annotations sont ensuite exposées avec une API. Suite aux discussions avec ce nouveau partenaire, nous sommes parvenus à établir un protocole pour rédiger des annotations bien structurées. Il a été alors décidé que chaque annotation aurait un titre régulier pour permettre d’identifier l’épigramme et un lien vers l’URN (Uniform Resource Name pour l’identification des ressources sur le Web) de la dîte épigramme sur la plateforme de notre projet. Cela a nécessité la création d’une deuxième plateforme de visualisation de nos données, plateforme qui respecterait les nouvelles règles des URNs – il en sera question plus bas.
5. Suite aux subventions du programme Développement Savoir du CRSH (2017-2018) et du programme Savoir (2020-2025) du CRSH, nous avons été en mesure de recruter plusieurs étudiant·e·s de l’Université de Montréal qui ont contribué à l’édition. Il s’agit pour la plupart d’étudiant·e·s qui suivent une formation de grec sous la direction d’Elsa Bouchard. L’idée de fond était au début de permettre aux étudiant·e·s de se concentrer sur les tâches éditoriales qui les interessaient le plus. À la suite de cette édition initiale, nous avons pu affiner la demande et orienter les étudiant·e·s vers des tâches plus précises. De nouveau, les contours théoriques du projet ont été rédéfinis grâce à l’activité concrête d’édition et au travail effectué sur la plateforme.
6. L’API nous a amenés à expérimenter certaines manipulations des données. En premier lieu, il a été possible de diffuser plus largement les résultats de notre travail. L’équipe s’est progressivement formée à l’usage de l’API pour manipuler les données. Après quelques expérimentations en Javascript – et la réalisation d’un site de visualisation de l’Anthologie sous la forme de parcours de lecture, la POP conçue par Louis-Olivier Brassard, étudiant à l’Université de Montréal – nous avons commencé à utiliser le langage de programmation Python pour travailler avec les données. L’usage de Python se révélait plus simple fondamentalement parce que les fonctions sont exécutées de facon linéaire, ce qui évitait d’avoir à gérer l’imbrication des fonctions synchrones et asynchrones typiques du Javascript. La première application réalisée était un bot twitter qui relayait chaque jour une épigramme. Cela a permis une familiarisation avec l’usage de l’API et de bibliothèques Python comme json et requests. Lorsque le besoin d’une visualisation avec des URNs plus stables s’est presenté – suite au travail effectué sur le manuscrit – nous avons pu développer une application avec le framework Flask qui produisait un nouveau site web en affichant toutes les informations nécessaires pour chaque épigramme. Cette activité de programmation a eu plusieurs effets : a) une montée en compétences informatiques ; b) une meilleure compréhension du modèle et de ses limites ; c) une meilleure connaissance des données que nous avions produites et d) une analyse plus fine des besoins qui auraient été à la base du développement d’un nouveau modèle de données et d’une nouvelle plateforme.

Développer un nouveau modèle et une nouvelle plateforme : le projet se rédéfinit

L’appropriation de l’API et l’émergence de nouvelles pratiques de manipulation des données au sein de notre équipe ont été à l’origine de la réorientation du projet et de sa redéfinition. Notre pensée s’est déroulée dans le cadre de pratiques concrètes de manipulation du texte. Ce sont ces pratiques qui ont été le fondement de l’évolution de notre compréhension et interprétation de l’Anthologie.

Progressivement, il est devenu évident que l’objectif principal du projet ne devait pas tellement être de produire de nouvelles connaissances scientifiques sur l’Anthologie, mais plutôt de fonctionner comme un véritable hub qui permette de donner accès de façon structurée et normalisée à une série de ressources déjà existantes : le manuscrit, les transcriptions, les traductions, les commentaires, la littérature secondaire, etc.

Nous devions trouver un équilibre entre un travail érudit mené dans le cadre de l’étude du manuscrit, de la transcription des scholies et des commentaires, et un travail plus compilatif de rassemblement de ressources existantes, disséminées et donc difficilement accessibles. Le partenariat avec la bibliothèque de Heidelberg a renouvelé l’importance du travail de transcription – en particulier la transcription des scholies – et d’alignement avec le manuscrit. Mais au sein de notre équipe, nous manquions de compétences philologiques pour réaliser un tel travail. Par ailleurs, l’édition de Stadmüller présente la transcription critique de tous les scholies des livres I à IX. Il s’agit d’une édition ancienne, avec un appareil critique très complexe, rédigé en latin. Nos étudiant·e·s ont été formé·e·s à extraire les informations pertinentes de cet appareil critique pour les reporter dans notre base de données.

L’analyse du modèle et des données, rendue possible lors du développement de l’application Flask, a permis d’identifier les plus grandes limites du modèle initial et de commencer à concevoir un nouveau modèle. C’est à ce moment que les discussions avec Perseids, et en particulier avec Zachary Fletcher, développeur, se sont révélées fondamentales. Perseids souhaitait développer une plateforme qui permette de réaliser des éditions de matériel fragmentaire, en particulier dans le cadre du projet Digital Miliet. Nous avons donc décidé de développer cette plateforme – fortement apifiée – en collaboration avec Perseids. Cela demandait de concevoir un modèle de données partagé, ce qui présentait aussi l’avantage de présenter ensuite des données compatibles et interopérables.

Nous avons donc, en premier lieu, identifié les limites de notre modèle. Nous pouvons les résumer comme suit :

1. Faible structuration des informations de langue et d’édition ;
2. Manque de relation entre certains objets : mots-clefs et villes par exemple ;
3. Manque de certaines informations comme des descriptions génériques pour chaque épigramme ;
4. Manque d’identifiants uniques pour des objets comme les auteurs et les villes et manque par conséquent d’une approche web sémantique.

À partir de ces constats, nous avons développé un nouveau modèle⁸. L’emploi de la syntaxe GraphQL a été très utile dans ce cadre. Elle nous a permis de définir de façon simple le modèle et l’ensemble des relations.

Le fait d’avoir un modèle nativement multilingue a complexifié la tâche. Nous nous sommes rapidement heurtés aux limites du modèle relationnel : la quantité des relations rendait la compréhension du modèle et sa manipulation particulièrement complexe – un problème, encore actuel, dont nous allons ensuite parler de façon plus approfondie. Le modèle que nous avons défini devait être assez générique pour pouvoir être partagé avec d’autres projets. Cela a impliqué certains choix, négociés avec Perseids et discutés avec Zachary Fletcher. La généralisation demandait parfois un modèle encore plus complexe. La question de l’implémentation du modèle s’est ensuite posée. Suite aux discussions avec Perseids, nous avons décidé que l’utilisation de Django était un bon choix car il s’agit d’un framework Python largement utilisé, maintenu et documenté. Le travail de développement a donc commencé dans cet environnement. Le schéma a été défini en Django et implémenté dans une base PostgreSQL. L’étape suivante a consisté à créer un script d’importation de nos données de l’ancien modèle au nouveau modèle. C’est un travail commencé par Louis Van Beurden et terminé par Timothée Guicherd.

Les péripéties de la plateforme

La conception de la nouvelle plateforme nous a confrontés à une question fondamentale : comment produire une documentation assez claire de l’ancien et du nouveau modèle pour donner la possibilité aux informaticiens de manipuler les données ? Dans cette question, plusieurs problèmes sous-jacents sont apparus :

1. Les informaticiens, Timothée Guicherd (pour l’infrastructure) et David Larlet (pour l’interface web) n’avaient pas une connaissance assez précise des enjeux éditoriaux et de recherche – qu’est-ce qu’une épigramme ? Qu’est-ce qu’un manuscrit ? Qu’est-ce qu’un scholie ? Quelle est la différence entre un auteur et un éditeur ? Mais aussi entre un scholie, qui est finalement un commentaire, et un commentaire contemporain ? Par ailleurs, du côté de l’équipe, le modèle éditorial et les enjeux épistémologiques ne pouvaient se préciser qu’en travaillant à l’implémentation technique. L’implémentation technique nous permettait de peaufiner notre modèle abstrait et l’expertise des informaticiens nous amenait à mieux définir les modèles en cours de réalisation. Nous nous sommes donc rendu compte que le projet n’était possible qu’à deux conditions : d’une part que l’équipe éditoriale travaille à produire une modélisation bien définie des enjeux éditoriaux en s’appuyant sur les questions et l’expertise des informaticiens ; de l’autre que les informaticiens montent en compétences éditoriales et scientifiques – c’est-à-dire qu’ils apprennent ce qu’est une épigramme et quelles sont les questions épistémologiques et scientifiques au cœur de notre réflexion – pour être en mesure de faire le pont entre un modèle éditorial de type représentatif et un modèle fonctionnel. Une nouvelle fois, nous avons constaté que la pensée théorique et scientifique ne se fait pas sans son implémentation technique.
2. L’ensemble des données éditées au cours des premiers temps du projet se composait d’informations établies par différentes personnes, selon différentes pratiques éditoriales, au fil des évolutions épistémologiques comme techniques. Nous étions ainsi face à un corpus qui manquait de cohérence et d’uniformité (des champs étaient mal remplis, de nombreuses exceptions étaient à signaler). Un nettoyage de nos données était donc nécessaire : l’inconsistance de notre corpus rendait en effet impossible la définition de tests unitaires pour produire un script d’import de la base qui soit stable.

Ces difficultés nous ont amenés à expérimenter une nouvelle approche : utiliser des Jupyter Notebooks pour documenter le mapping des données. Voici un exemple d’espace de prototypage ou d’expérimentation : https://framagit.org/anthologie-palatine/anthologyontology/-/blob/juppiter/ap2ap.ipynb

Cela nous permettait de tester notre mapping théorique, de visualiser les exceptions et de chercher des solutions pour leur traitement. Les Jupyter Notebooks représentent bien cette fusion entre théorie et technique : ils permettent d’associer un langage discursif avec du code qui est exécuté directement et dont les outputs – les résultats – sont conservés en cache. On combine ainsi dans le même espace un raisonnement en langue naturelle et un raisonnement algorithmique qui permet de vérifier en direct la qualité de la modélisation du premier raisonnement. Cette approche permet en plus de spécifier les besoins aux informaticiens de manière moins ambiguë.

Pour exemplifier le très grand nombre de petits problèmes rencontrés au sujet de la consistance des données, nous pouvons citer deux exemples :

1. Dans l’ancien modèle, les épigrammes étaient identifiées seulement par un identifiant unique et un titre. Le titre était structuré de manière régulière : Greek Anthology livre.epigramme. Par exemple : Greek Anthology 5.1 est le titre de l’épigramme 1 du livre V. Dans le nouveau modèle, chaque épigramme appartient à un work (Anthologia Graeca), un book (le numéro du livre) et un fragment (le numéro de l’épigramme). Évidemment une regex ou expression régulière résout ce problème et permet d’injecter les données dans le bon modèle. Cependant nous avons découvert plusieurs exceptions : tout particulièrement les épigrammes qui ont une numérotation spéciale incluant des lettres : par exemple, Greek Anthology 7.2b. Ce type de détail peut sembler mineur, mais il implique en réalité de repenser les modèles de données : le fragment ne suffisait plus pour identifier l’épigramme, il nous fallait aussi un subfragment. La structuration de ces informations devenait par ailleurs fondamentale en vue du maintien des URNs pour identifier les épigrammes et les scholies.
2. Le premier modèle de données n’incluait pas la notion d’édition d’un texte. Il était donc impossible de déclarer qu’un texte était la traduction d’une épigramme par Paton ou de déclarer qu’une traduction de l’épigramme était une traduction originale. Nous avons pallier cette lacune – très grave pour la consistance de nos données – en utilisant les langues pour exprimer l’édition : pour ce faire, nous avons créé de nouvelles langues pour caractériser des éditions particulières. Ensuite la notion d’édition a été ajoutée, uniquement en tant que champ texte – ce qui a généré de nombreux doublons. Il a fallu donc réaliser un mapping des différentes solutions pour exprimer les éditions dans l’ancienne base et expliquer comment les relier au nouveau modèle de données (qui dispose évidemment d’une table édition avec plusieurs champs).

Ce type de problèmes et leurs extensions nous ont systématiquement renvoyés à des réflexions de fond : comment identifier une épigramme de façon non ambiguë ? Comment faire en sorte que notre nommage soit facile à aligner avec celui des éditions existantes ? Comment spécifier une édition d’un texte et comment différencier une traduction originale de la simple correction d’une traduction existante ?

La réflexion éditoriale et épistémologique s’est développée à l’intérieur de la réflexion technique. Les Jupyter Notebooks ont donc été utilisés à des fins de recherche : ils permettaient d’afficher avec précision les données, de comprendre les structures et les relations de notre modèle et de soulever des questions épistémologiques et méthodologiques majeures, parfois à partir d’une donnée qui faisait exception.

Le besoin de désambiguïser certaines données nous a amenés, par ailleurs, à utiliser des Jupyter Notebooks pour explorer d’autres bases de données et essayer ainsi d’aligner nos objets avec des identifiants uniques. C’est le travail que nous avons fait sur les auteurs : nous avons d’abord récupéré les identifiants TLG⁹ des auteurs sur la version XML de Perseus. À partir de l’identifiant TLG, nous avons pu rechercher les identifiants Wikidata correspondants (lorsque Wikidata présentait l’identifiant TLG et lorsque l’auteur existait dans la base Wikidata). Nous avons ensuite aligné les auteurs présents dans notre base avec les TLG et les identifiants Wikidata. Le travail a été en partie réalisé à l’aide d’algorithmes et ensuite vérifié à la main.

Ce chantier est actuellement en cours pour les noms de villes et pour certaines catégories de mots-clefs.

Le travail de recherche et la réflexion sur les données ont fait évoluer progressivement le modèle de données. Pour ne donner qu’un exemple : s’agissant d’une édition collaborative, il est nécessaire de pouvoir garder trace de l’utilisateur à l’origine d’une modification. Cette exigence avait été exprimée, évidemment, dès le début, mais de façon trop imprécise.

À partir d’une base de données relationnelle, il est possible de garder trace du créateur d’un objet dans la base car chaque objet a un champ user. Cependant, il n’est pas possible de garder trace de l’auteur d’une création ou d’une suppression d’une relation entre deux objets. Par exemple : je peux savoir que l’usager A a créé l’épigramme Y mais je ne peux pas savoir qui a ajouté à l’épigramme Y le mot-clef X, à moins de complexifier le modèle et de créer des tables intermédiaires. Ici l’implémentation oblige à spécifier le modèle éditorial qui demeurait auparavant ambigu. Le travail de Timothée et David pour comprendre nos besoins a été indispensable et a ensuite aidé à mieux les identifier et les spécifier.

Le travail de développement de la plateforme s’est révélé être simultanément un espace privilégié d’apprentissage et d’acquisition de litéracie numérique pour l’ensemble de l’équipe. Timothée a assuré un mentorat à une partie de l’équipe éditoriale pour lui permettre de mieux comprendre les enjeux liés à la modélisation et à l’implémentation ainsi que de devenir relativement autonomes dans la manipulation des données.

Épilogue(s)

Quel bilan tirer de ce projet près de huit ans après la traduction des premiers épigrammes et la première modélisation du corpus anthologique ? L’histoire est loin d’être terminée. Les compétences informatiques acquises par l’équipe auront permis d’ouvrir à des perspectives nouvelles. En particulier, l’aisance relative acquise par l’équipe à travailler avec l’API nous a permis d’entreprendre le travail d’alignement avec différents référentiels que nous avons déjà mentionnés. Nous avons ainsi entrepris d’aligner nos données au TLG, à Wikidata et à Pleiades. À terme, c’est l’ensemble des mots-clefs qui devrait être aligné –  à Wikidata.

Le partenariat avec Perseids nous encourage à nous poser la question de la maintenance de fichiers d’autorités qui permettent à d’autres projets de bénéficier du travail réalisé.

Par ailleurs, le projet fait désormais partie de LINCS (Linked Infrastructure for Networked Cultural Scholarship), un consortium réunissant des projets de données liées, visant à conserver des modèles de données pour donner à voir des cultures différentes (Simpson et Brown 2021). L’équipe de LINCS a ainsi accès à la base de données afin de comprendre sa modélisation, pour identifier un schéma de données et le comparer à d’autres initiatives. La spécificité du projet de l’Anthologie grecque réside aussi dans la structuration des informations, et dans l’articulation complexe entre livres, épigrammes, scholies, auteurs·trices, éditeurs·trices, commentaires, ressources externes, etc. Les perspectives de comparaisons et de connexions avec d’autres projets sont à la fois une étape nécessaire afin de disposer d’un regard extérieur sur les choix de modélisation et un moyen de rendre nos données plus visibles et plus lisibles via le développement d’API pour le projet LINCS.

Un développement ultérieur du projet se destine à expérimenter certaines approches algorithmiques sur notre corpus pour tester l’apport des outils numériques pour la recherche sur l’Anthologie grecque. Nous sommes notamment en train d’expérimenter des approches de topic modeling (LDA) pour déterminer s’il est possible d’identifier algorithmiquement certaines relations entre les épigrammes. Mais nous souhaitons aussi expérimenter l’approche inverse en concevant, à partir de connaissances déjà établies sur notre corpus, des algorithmes capables de les répérer. En d’autres termes, il s’agirait de produire des modèles formels pour définir des concepts littéraires et de tester ces modèles sur notre corpus pour définir s’ils sont capables de produire les résultats attendus. Par exemple, on sait que l’épigramme 6.13, attribuée à Léonidas de Tarente, a « inspiré » (Waltz 1960. p.31) plusieurs autres épigrammes du livre VI : les épigrammes 11 à 16 et 179 à 187. Il y a donc 14 épigrammes qui sont « inspirées » de l’épigramme originale de Léonidas. Que signifie ici le terme « inspiré » ? Peut-on en donner une définition formelle qui pourrait ensuite être implémentée dans un algorithme ?

Si on observe certains de ces textes, on peut déjà constater que plus que d’une vague « inspiration », il s’agit là d’une véritable « reprise » ou d’une variation. Voici l’épigramme 6.13 :

οἱ τρισσοί τοι ταῦτα τὰ δίκτυα θῆκαν ὅμαιμοι, ἀγρότα Πάν, ἄλλης ἄλλος ἀπ᾽ ἀγρεσίης: ὧν ἀπὸ μὲν πτηνῶν Πίγρης τάδε, ταῦτα δὲ Δᾶμις τετραπόδων, Κλείτωρ δ᾽ ὁ τρίτος εἰναλίων. ἀνθ᾽ ὧν τῷ μὲν πέμπε δι᾽ ἠέρος εὔστοχον ἄγρην, τῷ δὲ διὰ δρυμῶν, τῷ δὲ δι᾽ ἠϊόνων.

Ces trois frères t’ont dédié ces filets, Pan chasseur, chacun issu d’une chasse différente. Pigres celles-ci, d’oiseaux, Damis celle-ci, de bêtes féroces, Cléitor, le troisième, d’animaux marins. En échange donne une bonne chasse au premier dans l’air, au deuxième dans les bois et au troisième sur les rivages.

et deux exemples de reprises, l’épigramme 6.14 :

Πανὶ τάδ᾽ αὔθαιμοι τρισσοὶ θέσαν ἄρμενα τέχνας: Δᾶμις μὲν θηρῶν ἄρκυν ὀρειονόμων, Κλείτωρ δὲ πλωτῶν τάδε δίκτυα, τὰν δὲ πετηνῶν ἄρρηκτον Πίγρης τάνδε δεραιοπέδαν: τὸν μὲν γὰρ ξυλόχων, τὸν δ᾽ ἠέρος, ὃν δ᾽ ἀπὸ λίμνας οὔ ποτε σὺν κενεοῖς οἶκος ἔδεκτο λίνοις.

À Pan, trois frères ont consacré ces instruments de leur profession : Damis un panneau pour les bêtes des montagnes, Cleitor ces filets à poissons, Pigrès cet infrangible collet à prendre les oiseaux. Car jamais de leur chasse l’un dans les bois, l’autre dans les airs, l’autre sur les eaux, leur logis ne les a vus revenir les rets vides.

et l’épigramme 6.184 :

τρισσὰ τάδε τρισσοὶ θηραγρέται, ἄλλος ἀπ᾽ ἄλλης τέχνης, πρὸς νηῷ Πανὸς ἔθεντο λίνα: Πίγρης μὲν πτανοῖσιν ἐφεὶς βόλον, ἐν δ᾽ ἁλίοισιν Κλείτωρ, ἐν θηρσὶν Δᾶμις ἐρημονόμοις. τοὔνεκα, Πάν, τὸν μέν γε δι᾽ αἰθέρος, ὃν δ᾽ ἀπὸ λόχμης, τὸν δὲ δι᾽ αἰγιαλῶν θὲς πολυαγρότερον.

Voici la triple offrande de trois chasseurs : dans le sanctuaire de Pan ils ont consacré ses filets dont ils se servaient chacun pour exercer son métier particulier et qu’ils tendaient Pigrès aux oiseaux, Cleitor aux poissons, Damis aux bêtes qui habitent les lieux solitaires. En retour, Pan, fais-leur trouver dans l’air, dans les bois ou sur les flots un butin encore plus abondant.

À la lecture, il paraît évident que ces épigrammes sont liées. Il est très probable également qu’il y ait une source à partir de laquelle les autres ont été écrites. Mais pourquoi est-ce si évident ? L’usage de noms identiques, d’une même thématique, d’un même sens. Est-ce possible de modéliser cela de façon formelle ? Que signifie avoir le même sens ?

Pour faire qu’un algorithme soit capable de trouver des relations de ce type, il nous faudra désambiguïser la relation. Ces questionnements s’inscrivent dans la poursuite du projet actuel et ouvrent la recherche à d’autres expertises, d’autres approches et de nouvelles collaborations. La technique est la pensée, la pensée est toujours technique.

Ce qui émerge de cette expérience de recherche, au-delà de l’importance de définir un modèle éditorial précis en amont de la réalisation, c’est qu’une série de dimensions – techniques, collaboratives, infrastructurelles… – établissent et redéfinissent constamment les intentions du projet.

D’où nous viennent donc nos idées ? D’où viennent nos projets de recherche ? Le projet est un ensemble de conjonctures médiatrices faites d’acteurs et de forces multiples et hétérogènes : des savoirs faires, des protocoles, des rencontres, des textes, des circulations, des reprises, des environnements techniques qui entrent en résonnance et qui font émerger des idées, des pensées, des corpus.