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

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 des structures de réseau dans le projet Sunoikisis Digital Classics

Introduction

Le projet Sunoikisis Digital Classics a pour but de proposer des séminaires thématiques à un public international. Ce projet, commencé en 2015, a été initié par les départements d’études classiques des universités de Leipzig (Allemagne) et de l’université Harvard (États-Unis) et par l’Institute of Classical Studies de Londres (Royaume-Uni). La liste des collaborateurs s’est développée au fil du temps de telle sorte qu’elle contient aujourd’hui des participants de plus de 120 institutions à travers le monde. Si Sunoikisis prenait au départ pour champ de recherche les études classiques comme la philologie, l’histoire et l’archéologie, son champ d’investigation s’est progressivement diversifié avec un intérêt pour les sciences dites « auxiliaires de l’histoire » dans l’étude des mondes anciens telles que l’épigraphie, la paléographie, la papyrologie et la prosopographie. L’objectif initial était de diffuser la maîtrise des humanités numériques. Au vu du nombre de participants, de leur diversité et de leur étendue géographique, cet objectif semble atteint.

Notre travail repose sur un fichier CSV regroupant l’ensemble des séances du projet Sunoikisis Digital Classics à partir de l’année universitaire 2014-2015. Notre première tâche a été de mettre à jour ce tableau, d’en corriger les erreurs et d’ajouter les données oubliées. Ce travail a été poursuivi tout au long du semestre. En effet, il fallait s’assurer d’avoir les informations les plus précises possibles afin d’obtenir des résultats exacts.

Notre but était de nous intéresser aux contributeurs des séances. Au cours de nos recherches, nous avons remarqué une différence entre les participants. Nous avons pu établir une distinction entre hosts (animateurs) et guests (invités). En effet, en nous appuyant sur les vidéos des séances, nous nous sommes aperçus que, bien souvent, une personne préside la séance : non seulement elle présente le sujet, les différents invités et le thème de leurs travaux de recherche mais au cours de l’exposé elle assure aussi le rôle d’animateur. Inversement, les guests sont des invités qui interviennent pour faire part de leurs recherches et de leurs connaissances sur une thématique précise. Ainsi, si l’on observe une certaine récurrence parmi les hosts, les guests sont, quant à eux, très variés.

Toutefois, dans le tableau dont nous disposions, ces données étaient assez éparses. Par exemple, les hosts n’étaient pas toujours notés et la distinction avec les guests n’existait pas. Nous avons donc dû corriger tout cela en nous appuyant sur les données vidéos. Ainsi, les premières recherches que nous avons effectuées apparaissent comme erronées puisque nous ne disposions pas des informations exactes. Le travail de nettoyage des données a été une procédure à la fois individuelle et collaborative : nous avons fait le choix de répartir entre nous la correction et la mise à jour des données.

Observations générales

Un seul coup d’œil sur l’ensemble des données permet d’emblée de remarquer la prédominance des hosts, les plus souvent présents dans les diverses séances en leur qualité d’animateurs. On pense notamment à Gabriel Bodard, Valeria Vitale et Monica Berti. Les guests, quant à eux, font des apparitions plus spontanées, en fonction de leur thème de prédilection.

Puisque le travail était collaboratif, il convenait de s’accorder sur une cohérence globale en ce qui concerne le traitement des données, autant dans leur mise à jour et dans leur présentation. La question des auditeurs s’est également posée. En effet, dans certaines vidéos nous pouvons remarquer qu’en plus des hosts et des guests, il y a parfois également des auditeurs, qui n’interviennent pas, ou peu, simplement pour demander une information ou préciser un détail. La question s’est ainsi posée de savoir comment traiter ces personnes dans nos données. Nous avons fait le choix de ne pas les inclure dans le traitement des données puisqu’il ne s’agit pas d’intervenants majeurs au sein des vidéos.

Les logiciels utilisés : De Github à Gephi, en passant par Visual Studio Code

Github

Pour accomplir notre travail, nous avons principalement utilisé trois logiciels, à savoir GitHub, Open Refine et Gephi. Tout d’abord, GitHub, un service web, a grandement facilité notre collaboration. Il nous a permis de centraliser les données initiales utiles à l’étude et de regrouper, au fur et à mesure, les travaux de chaque étudiant. Il offre, par exemple, la possibilité de pratiquer « l’intégration continue », qui permet de détecter les problèmes se trouvant dans les données, ainsi que la « gestion de version », qui facilite la gestion des différentes versions et le travail collaboratif. Les erreurs de manipulation pouvant facilement s’y glisser, GitHub permet de garder une trace des différents états des fichiers au fil du temps et de repérer facilement toute anomalie dans les données. 

Ensuite, le traitement des données a été effectué à l’aide de l’éditeur de texte Visual Studio Code. Ce logiciel permet la manipulation de données, leur nettoyage et leur mise en forme. Enfin, c’est avec Gephi que nous avons pu donner un sens à nos données. Gephi permet en effet l’analyse et la visualisation graphique de réseaux. Ces représentations permettent une meilleure appréhension des données et la mise en relief d’éléments saillants.

Visual Studio Code

Il s’agissait en effet de sélectionner les données que nous allions conserver pour la réalisation des graphes mais aussi de les mettre en forme sous un format utilisable dans le logiciel Gephi, CSV.

Les données dont nous disposions au début rassemblent un grand nombre de métadonnées des séances Sunoikisis : date, semestre, participants (indifférenciés), thèmes, page GitHub associée… Comme notre projet avait pour objectif l’analyse des contributeurs, notre première tâche a été d’isoler les noms de ces contributeurs et de les rassembler dans un autre fichier CSV, mis en forme à l’aide de VS Code. Ce premier fichier était cependant inutilisable car les données de base n’incluent pas les hosts. Nous avons donc dû le compléter en ajoutant ces contributeurs et en distinguant les hosts et les guests. VS Code nous a permis de travailler localement pour mieux mettre en commun nos fichiers sur Github et de détecter des potentielles erreurs de code plus facilement.

Gephi

Observations avant analyse

Avant de mener à bien notre analyse, on a pu relever quelques problèmes liés au traitement des données. À travers divers tâtonnements, nous avons cherché à nous approprier le logiciel dans le but d’en obtenir les données les plus intéressantes à notre analyse.

En effet, on peut tout d’abord remarquer que la distinction entre les catégories hosts et guests n’est pas aussi claire que l’on aurait pu l’imaginer dans Gephi. Pour une raison assez obscure, le logiciel fait une distinction entre une catégorie “guests” et “; guests” dans l’attribut Type.

Par un recours au Laboratoire de données, une modification a pu être apportée à cette répartition. Le choix le plus pertinent, et qui a été conservé, est celui de ne conserver qu’une seule catégorie pour éviter des doublons.

Le résultat obtenu semble dès lors bien plus pertinent :

Dans certains cas, et pour certains membres de notre groupe d’analyse, Gephi ne semblait pas reconnaître certains signes orthographiques comme les accents ou les cédilles ce qui donnait des aberrations orthographiques et/ou des biais de catégorisation (voir l’exemple d’Aurélien Berra ci-dessous).

Dans le but de corriger ces données, il a été proposé de modifier le fichier CSV directement pour que les noms soient plus lisibles et que chacun n’appartienne qu’à une seule catégorie.

Préparation de l’analyse

Pour l’analyse, il semble obligatoire de réussir à obtenir le graphe le plus lisible possible. Or, même avec des jeux de couleurs, les graphes peuvent apparaître comme surchargés et l’analyse semble dès lors un peu difficile. Pour remédier à cela, plusieurs solutions étaient possibles, notamment celle de supprimer les prénoms des participants, ce qui permet de gagner en lisibilité en enlevant une moitié d’information.

La spatialisation Yifan Hu semble également être la plus pertinente en ce qui concerne l’analyse de réseaux car elle permet une meilleure lisibilité en offrant la possibilité de distinguer à l’œil nu trois groupes qui correspondent aux trois intervenants les plus fréquents : Monica Berti, Gabriel Bodard et Valeria Vitale.

Analyse générale

D’un point de vue macroscopique, avec l’outil modularité, qui crée des groupes au sein du réseau, on constate deux ensembles construits sur deux intervenants : Monica Berti (en rouge) et Gabriel Bodard (en bleu). Cependant, il faut mentionner aussi la présence de groupes disparates et d’un sous-groupe prédominant au sein du groupe Bodard, celui de Valeria Vitale.

Analyse sur la modularité

Lors de la collecte des données, il était déjà clair que certains noms, les noms des hosts les plus fréquents, allaient recouper davantage de connexions. Il s’agit, dans un premier temps, de confirmer cette hypothèse à l’aide d’une visualisation qui met en avant les connexions.

Pour cela on peut utiliser un classement des liens par leur poids. Nous pouvons lire dans ce classement quelles sont les connexions les plus fréquentes. Les liens les plus foncés sont ceux qui relient les hôtes les plus fréquents, à savoir Gabriel Bodard et Monica Berti, puis Valeria Vitale.

Spatialisation Force Atlas 2 présentant un classement des liens par poids et des labels par type 

La schématisation de la modularité peut se faire soit par partition, soit par classement. L’outil partition définit précisément des valeurs pour les hosts et les guests, mais n’autorise pas une visualisation claire de cette modularité. Nous avons donc opté pour un classement (et non une partition) des couleurs des labels par modularité. En choisissant trois couleurs bien distinctes pour le spectre de couleurs, des groupes se dessinent de façon plus flagrante.

Spatialisation Yifan Hu avec application de la modularité des labels

On observe trois grands groupes de couleurs : vert, marron et rose. Se distinguent également Rebecca Seifried dans un sous-ton de vert et un groupe de trois personnes en bleu : Alessio Sopracasa, Karsten Tolle et Lily Grozdanova. Lorsque l’on cherche à connaître les connexions des personnes en bleu, on observe que Tolle et Grozdanova sont exclusivement liées entre elles et à Monica Berti. Avec la mise en perspective du tableau de données, il semble que ces trois personnes aient assisté à la même séance, animée par Monica Berti. Il est curieux alors que ce choix de couleur ait été fait par Gephi, d’autant plus que le troisième protagoniste bleu, Alessio Sopracasa, a participé à une autre séance, avec d’autres invités. On retrouve une dynamique similaire avec Rebecca Seifried, qui est liée avec Sarah Murray et Piraye Haciguzeller.

Dans la visualisation Yifan Hu, les personnalités les plus importantes apparaissent par le grand nombre de liens qu’elles réunissent : c’est le cas de Gabriel Bodard, Valeria Vitale et Monica Berti. Ces personnes ont aussi pour caractéristique de se trouver au centre de cette spatialisation. En effet, plus les personnes sont éloignées dans le cercle, moins elles ont de connexions. Mais dans cette spatialisation ce critère est relativement confus, étant donné que des personnes avec tout aussi peu de connexions se retrouvent au centre, comme Federico Boschetti sur cette visualisation.

Spatialisation Force Atlas 2 avec application de la modularité pour les labels et poids pour les liens

Ainsi, grâce à la spatialisation Force Atlas 2, ce critère est davantage visible : les personnalités qui recoupent le plus de relations sont au centre et se distinguent clairement du reste. Mais on peut tout de même observer les sous-groupes avec l’application de la modularité sur la couleur des labels. Dans cette configuration, le poids des liens ne nous permet pas d’observer plus d’éléments signifiants que les couleurs ne faisaient déjà apparaître.

Peut-on analyser ces données avec un graphe dynamique?

Avec la fonctionnalité « dynamic », Gephi nous donne la possibilité d’associer chaque nœud à un moment dans le temps. On peut ainsi donner une dimension temporelle au graphe, à travers une animation prenant en compte les modifications, les changements en fonction d’un axe temporel. Cet outil semble intéressant pour analyser nos données, étant donné que chaque apparition des contributeurs est associée à une date de séance précise. On peut ainsi supposer que les « hosts » remplissent ce rôle sur plusieurs séances consécutives, souvent en fonction des saisons. Dans une moindre mesure, les « guests » pourraient également être présents sur plusieurs séances, notamment des séances doubles, portant sur la même thématique. Toutefois, il ne nous est pas possible de tester cette hypothèse puisque nos données n’ont pas été formatées pour être dynamiques. Mais même si cela était possible, l’intérêt d’un graphe dynamique resterait limité. L’évolution chronologique montrerait seulement les mêmes groupes d’intervenants que ceux qu’on retrouve dans nos graphes statiques. Malgré tout, cet outil serait très utile si nous avions choisi d’analyser nos données sous un autre angle.

Conclusion

Grâce à l’analyse de réseau des animateurs et intervenants, nous avons mis en évidence les pivots du réseau qui entretiennent le projet Sunoikisis Digital Classics. La concentration des interactions entre certains sujets a permis de distinguer des groupes d’échanges qui témoignent autant de l’importance du regroupement effectué par les animateurs que de la diversité des sujets traités. La combinaison des logiciels de traitement et de partage des données a rendu possible l’expérimentation d’une mise en abyme intéressante à travers une analyse de réseau.

Billet rédigé par Hugo Caverivière, Inès Le Guillou, Frédéric Mellet, Léa Morel, Axelle Penture et Evie Roussel.

Projet collaboratif : Sunoikisis Digital Classics

Une partie du cours « Humanités numériques 2. Projet collaboratif » est consacrée au programme Sunoikisis Digital Classics. Ces séances ont pour objectif d’explorer ce programme collaboratif international, ses thèmes, ses ressources et le réseau auquel nous participons ainsi. Ce billet reprend les synthèses préparées par les deux groupes de ce semestre.

Annotation et étude des thèmes

Nicolas Corre, Frédérique Maréchal et Beniamino Motton (EAD)

Objectifs

  • Découverte du programme Sunoikisis Digital Classics, programme collaboratif de Digital Classics
  • Initiation à GitHub et contribution à notre entrepôt de données
  • Usage du format CSV (comma-separated values) pour le traitement de données tabulaires
  • Initiation à Open Refine, logiciel libre de nettoyage et de mise en forme de données
  • Annotation collaborative
  • Analyse de données

Situation de départ

Le fichier CSV sur lequel reposait notre travail présentait toutes les séances de Sunoikisis Digital Classics à partir de l’année universitaire 2014-2015. Pendant le semestre, notre groupe s’est occupé d’analyser la partie concernant les thèmes de chaque séance pour proposer ensuite une meilleure organisation du tableau et donc une meilleure lecture. Le fichier d’origine avait six colonnes pour les thèmes et nous avons pu constater dès le début que ces colonnes n’étaient pas remplies systématiquement. De plus, un travail de toilettage s’imposait, car des liens de sites Internet se trouvaient dans les colonnes dédiées aux thèmes. L’impression était donc d’un tableau de lecture difficile, qui voulait être précis dans la définition des séances en proposant un large éventail de thèmes, mais qui finalement n’était pas efficace.

Processus de traitement des données

Nous avons fait le choix de nous limiter à trois thèmes, par souci d’efficacité et de commodité. Dans les deux premières colonnes devaient apparaître les mots les plus pertinents, en lien notamment avec le titre de la session. La troisième colonne, quand cela était possible, devait correspondre par contre à la discipline traitée lors de la séance. Au premier abord, certaines décisions semblaient s’imposer d’elles-mêmes. Par exemple, entre text encoding et encoding, il nous est apparu pertinent de garder uniquement encoding ; ou alors faire un seul thème pour digital edition et digitalisation. Pour être efficace, la sélection de mots-clés devait éliminer des redondances, prendre en compte les synonymes ou les expressions associées. Cela nous obligeait notamment à repérer les associations régulières de mots-clés, d’une séance à l’autre, ou la fréquence d’emploi de certaines expressions. Cela peut paraître simple, mais cela nous a obligé cependant à faire des choix parfois draconiens. Certaines logiques se sont affrontées. Fallait-il choisir des mots-clés spécifiques comme XLM-TEI ou choisir des thèmes plus généraux comme code ? Il nous fallait choisir une stratégie d’indexation adaptée aux objectifs de recherche des utilisateurs potentiels de ce fichier. En effet, il peut être parfois judicieux d’utiliser des mots-clés généraux pour élargir le champ de recherche. Cependant, cela peut également donner lieu à des résultats trop nombreux et peu pertinents qui peuvent décourager le chercheur. Aussi, nous avons fait le choix de garder de préférence les mots-clés spécifiques pour aider à mieux cibler les requêtes des utilisateurs. Par exemple, cela imposait de mettre en avant, quand cela était possible, des acronymes comme NLP, qui désigne le Natural Language Processing (ou « traitement des langues naturelles »), ou des noms de systèmes d’encodage, comme XLM-TEI justement.

Dès le départ, le travail de sélection a été collaboratif. Sur le forum de discussion, nous avons pu échanger régulièrement nos impressions, nos doutes sur le choix de tel ou ou tel thème. Chacun a pu défendre ses préférences, ou se résoudre à se soumettre à la majorité. Devait-on supprimer les vagues et tristes annotation ou standards ? Si on précisait la discipline archaeology, la mention d’objects and artefacts était-elle nécessaire ? Les combats ont parfois été rudes. À la surprise générale, l’obscur named entities, initialement rejeté, a finalement été gardé. L’enseignant a pu parfois jouer le rôle de conciliateur, et plus sûrement celui d’arbitre, afin de rappeler les critères de sélection. L’objectif était de toujours être logique et régulier. Pour être plus précis, le travail de toilettage s’est fait à la fois de manière personnelle et collaborative. Il y avait 226 lignes dans notre tableau, aussi nous l’avons découpé en trois fois 76 lignes. Chacun d’entre nous pouvait ainsi procéder dans son coin au toilettage des lignes qui lui étaient affectées. Mais cela nous obligeait ensuite à confronter nos choix à celui des autres, il fallait avoir le souci de la cohérence entre chacune des trois parties, et, le cas échéant, mettre en exergue certains choix délicats, ou à l’inverse revenir sur les sélections qui n’étaient pas suffisamment étayées. Ces échanges réguliers et toujours très cordiaux nous ont obligés à développer une véritable pratique réflexive, des compétences qui devraient nous être utiles par la suite.

Ce que nous avons observé

Une fois le recensement de nos thèmes effectué sur trois colonnes, nous avons pu observer que nous avions une vision à la fois précise et globale de chaque séance, mais aussi de chaque session et que cela simplifierait l’utilisation de ce tableau pour quiconque s’intéresserait au programme SunoikisisDC.

En parcourant le tableau, nous nous rendons compte que de nombreux thèmes reviennent à chaque session : annotation, encoding, named entities, epigraphy, translation, visualisation ou encore treebank et text mining. On constate ainsi une forte cohérence dans le choix des sujets abordés. À l’inverse, certains thèmes sont peu évoqués comme ethics, linguistics, computational linguistics, semantic web ou encore digital humanities history et topic modeling. Cela manifeste la volonté de diversifier les thèmes et d’ouvrir le champ de recherche à certains sujets peu explorés jusque-là.

Cette impression d’ouverture est confirmée par les thèmes qui sont mis à l’honneur au cours des dernières sessions comme GLAM (« galleries, libraries, archives, museums ») ou copyright license and open access. La présence de ces nouveaux thèmes est le fruit de la réflexion engagée depuis 2014 par l’équipe de SunoikisisDC en faisant émerger de nouvelles problématiques : une réflexion collective qui a permis le déploiement d’un grand nombre de réponses à des questions scientifiques très pointues. Un work in progress qui a encore de beaux jours devant lui.

Un problème subsiste malgré tout. Comme nous avons parfois réduit à trois thèmes chaque séance, il se pourrait que nous ayons – même en voulant faire pour le mieux – oublié des thèmes. L’observation de nos résultats, sans être le fruit du hasard, comporte une marge d’erreur.

Voyant Tools : nuage de mots comprenant les thèmes du projet Sunoikisis Digital Classics. (Par défaut, les thèmes comportant un nom composé sont considérés par la plateforme comme deux mots et non comme un seul.)

Cartographie

Paraskevi Dimitra et Thibault Legois

L’idée de créer une carte des pays des institutions et des centres de recherche participant au projet Sunoikisis Digital Classics depuis sa création est le fruit d’un travail collaboratif. Notre objectif était de créer une carte avec les pays participant au projet par rapport à leur sujet de recherche. Mais ce projet était difficile à réaliser sur une carte à travers l’outil de cartographie choisi, uMap. Le choix qu’on avait à notre disposition était la création d’une carte avec un seul critère, celui des pays d’origine des institutions.

Pour créer notre carte, nous avons commencé par ajouter sur notre fichier CSV, qui contenait la liste des séances du projet, trois colonnes avec les pays d’origine des institutions. Cette procédure était parfois compliquée, du fait que le siège de certaines institutions était difficiles à localiser exactement (par exemple, collaboration de deux ou trois universités dans un programme).

Ensuite, nous avons crée un fichier CSV contenant la liste des pays. L’étape suivante était la création d’un fichier au format KML à importer sur uMap. Pour la création de ce fichier nous avons travaillé dans Visual Studio Code. Étant donné qu’un fichier KML est en réalité une liste des pays, on ne pouvait pas en présenter deux « côte à côte », par exemple Germany/Italy (ces doublets ayant été provisoirement admis lorsqu’un intervenant relevait de plusieurs institutions de pays différents). Pour cette raison, on a présenté chaque pays séparément. À travers le site opendatasoft (choix World Administrative Boundaries – Countries and Territories), on avait la possibilité de trouver le fichier KML de chaque pays, en le téléchargeant et en faisant un copier coller de leur source dans notre fichier.

Notre dernière étape était la création d’un compte sur uMap et d’une carte. Nous avons importé le fichier KML avec tous les pays en cliquant sur « importer des données » et notre carte a été créée ! Par la suite, on avait la possibilité de nommer notre carte, de changer le fond sur notre écran, d’ajouter des informations ou des images en cliquant sur chaque pays et de sauvegarder la carte dans notre compte uMap pour l’utiliser à n’importe quel moment.

La carte réalisée à l’avantage de rendre compte visuellement (c’est-à-dire mieux qu’un fichier CSV) des pays et continents accueillant les universités et institutions membres du projet, et d’ainsi nous fournir quelques informations sur la culture et la dynamique du projet. En effet, nous constatons que l’Europe de l’ouest et du nord concentre la majorité des pays concernés. En effet, deux états d’Amérique (le Canada pour le nord, le Brésil pour le sud), deux états d’Afrique (l’Égypte et l’Afrique du sud) et deux états d’Asie mineure (la Turquie et l’Iran) viennent s’ajouter. On note à l’inverse l’absence des États-Unis, dont les universités sont pourtant investies dans la recherche paléographique et numérique, de l’Afrique du Nord, disposant d’importants vestiges archéologiques en lien avec la Grèce et Rome, et de la Russie, culturellement proche de la Grèce. Cette carte révèle donc que les intervenants sont majoritairement issus de pays dont l’étude des cultures gréco-latines constitue une tradition scolaire ancienne (Europe de l’ouest ou du nord), ou disposant d’importantes ressources paléographiques (Égypte), ou ayant eu un rôle dans l’histoire grecque, notamment hellénistique (Turquie et Iran). La présence des pays restants (Canada, Brésil, Afrique du sud) témoigne de l’ouverture du projet aux initiatives des professeurs qui souhaitent le rejoindre. En les comparant aux pays absents de notre carte (comme la Russie, l’Afrique centrale, l’Asie…), nous pouvons nous demander si leur implication dans le projet n’est pas liée au fait que la culture européenne (et donc antique) est constitutive de la leur, profondément implantée et répandue, notamment en raison de l’existence d’une population européenne et de structures scolaires partageant toujours l’intérêt pour les cultures anciennes (à l’inverse de la majeure partie de l’Asie par exemple).

Enfin, l’outil uMap réserve encore un fort potentiel pour mettre en relation les pays et les institutions. Par exemple, quelques informations ajoutées pour la ville de Nauplie où se trouve le Centre d’études helléniques en Grèce de Ηarvard (site internet du Centre et quelques informations de base comme le titre du centre en français et en anglais, région, continent) permettent de rendre ces informations visibles sur la carte, et de donner accès au site internet du Centre. On pourrait aussi ajouter sur la description pour chaque ville les thèmes principaux des séances du projet (par exemple, annotation, digital papyrology, etc.). Donc, cet outil est parfait si on veut stocker quelques informations de base par rapport à notre recherche et avoir un accès interactif à travers une carte sur son contenu. De plus, les nombreuses options de mise en forme qui nous sont données, telles que la modification du fond, des couleurs et des bordures, nous permettent de personnaliser notre carte en fonction de notre esthétique personnelle.

Carte mise en ligne à l’adresse https://umap.openstreetmap.fr/el/map/carte-des-pays_899985#2/37.7/22.9

Projet collaboratif : Sunoikisis Digital Classics

Une partie du cours « Humanités numériques 2. Projet collaboratif » est consacrée au programme Sunoikisis Digital Classics. Ces séances ont pour objectif d’explorer ce programme collaboratif international, ses thèmes, ses ressources et le réseau auquel nous participons ainsi. Pour ce faire, les étudiantes et étudiants acquièrent des compétences pratiques en matière de préparation de données et de collaboration : Web scraping élémentaire, maniement du CSV comme format pivot pour le traitement automatique, nettoyage et analyse interactive dans un éditeur de texte et avec OpenRefine, définition de catégories d’analyse et annotation collaborative, contribution à des fichiers partagés en ligne et à notre entrepôt de données sur GitHub.

Cette année, le groupe a mis à jour les données de notre panorama des séances organisées depuis la création de Sunoikisis Digital Classics en 2015 et mené une annotation thématique systématique (sur la base de la taxonomie TaDiRAH, Taxonomy of Digital Research Activities in the Humanities, et des catégories de l’Index of Digital Humanities Conferences), puis s’est intéressé aux axes d’exploration suivants : fréquences et genres des intervenants ; fréquences et distribution chronologique des institutions ; fréquences, co-occurrences et distribution chronologique des thèmes.

Les analyses seront poursuivies avec d’autres moyens dans le cours de master 2. Néanmoins, plusieurs observations faites par le groupe semblent d’ores et déjà intéressantes. Nous les résumons ici.

Le renouvellement des intervenants et des institutions est remarquable : 90 % des participants interviennent 5 fois ou moins et 60 % interviennent seulement une fois, tandis que la moitié des institutions n’apparaît qu’une seule fois. L’équilibre entre hommes et femmes semble parfait, avec 50,8 % d’hommes et 49,2 % de femmes. Le « bruit » créé par la présence dominante des principaux organisateurs, qui sont ne sont généralement mentionnés que lorsqu’ils assurent une partie de la séance, mais il faudrait contrôler les données afin de savoir si elles sont fiables pour les trois personnes mentionnées plus de 20 fois. On note par ailleurs que 20 % des institutions ne semblent pas être des universités.

L’étude des thèmes repose sur une annotation manuelle et comporte donc une part d’arbitraire liée à la subjectivité des annotateurs, même si deux personnes au moins ont validé les thèmes. Cela étant, quelques thèmes sont saillants : l’annotation (un tiers des séances), la visualisation (27 %) et l’open data (19 %). De fait, les graphiques montrent bien que les notions d’encodage, d’annotation et de visualisation sont fondamentales dans le programme. Au contraire, des thèmes assez spécifiques sont évoqués dans moins de 1 % des séances, comme « sentiment analysis », « topic modelling » ou « virtual and augmented reality ». Certains thèmes sont présents tous les ans ou presque : « visualisation », « translation », « text mining », « objects and artefacts », « epigraphy », « geography », « annotation », « treebank », « encoding », « linked open data ». Cependant, malgré ces constantes – qui constituent la colonne vertébrale des saisons –, on observe une diversification des thèmes depuis les débuts de Sunoikisis Digital Classics, avec l’introduction de thèmes nouveaux jusqu’à cette année (comme les GLAM) ; le nombre de thèmes traités est passé de 17 thèmes différents en 2014-2015 à 25 en 2021-2022. De plus, pour chaque thème, on observe une grande variété d’intervenants et d’institutions, ce qui signifie que la parole est donnée à plusieurs spécialistes, avec un souci de varier leur lieu de provenance et donc d’élargir la communauté.

Ce travail sera repris et précisé. Nous partageons pour finir certains des graphiques produits à la fin du projet collaboratif.