January 8th meeting

Réunion TOFLIT 08/01/2015

Présents : Guillaume Daudin, Loïc Charles, Béatrice Dedinger, Paul Girard, Pierre Hollegien, Yannick Le Pen, Guillaume Plique, Sandrine Mesplé-Somps. La réunion a eu lieu de 10h à 12h.

Cette réunion a permis de revenir sur certains points évoqués lors de la réunion du 18 décembre, notamment Paul a donné quelques précisions sur le datascape. Nous avons donc également défini les prochaines étapes.

Précisions sur le datascape et la formalisation sous forme de réseaux

Manylines :

Outil pour l’exploration et le commentaire de réseaux (format des fichiers input : .gexf).

Questions sur les réseaux

Deux questions principales sont soulevées : Comment les réseaux sont-ils traités statistiquement, et quelle est la marge d’erreur ? Pour la spatialisation, le logiciel se base sur des algorithmes développés en physique, ce n’est malheureusement pas très fiable mathématiquement. Pour conserver toute l’information, il faudrait pouvoir projeter l’ensemble du réseau, ce qui nécessiterait un espace à n-1 dimensions, or Manylines projette le réseau en 2D. Il est difficile d’évaluer la quantité d’information perdue. Pour minimiser cette perte il faut choisir l’algorithme en fonction de ce que l’on traite (le médialab a son propre algorithme). Dans notre cas, on a un réseau naturel, la répartition des nœuds se fait donc au hasard.

Principe de modularité : le logiciel va détecter les différents clusters (familles de produits) en se basant sur la théorie probabiliste, le résultat dépend de l’aléatoire des conditions de départ. Il n’y a donc pas de déterminisme : en répétant plusieurs fois l’expérience, on obtiendra des résultats différents. Par conséquent la visualisation permet l’intuition mais ne peut pas être considérée comme une conclusion. En l’absence de mesure statistique de la significativité des résultats, le mieux est de répéter l’opération à plusieurs reprises pour identifier et isoler les clusters mêlés. Ces clusters mêlés peuvent parfois se séparer lorsqu’on renouvelle l’opération au niveau local.

Par la suite, Guillaume D. a fait part son expérience sur l’identification des marchés français au XVIIIe, et s’en est suivi une discussion autour de l’ouvrage de Thomas Le Roux et des problèmes méthodologiques identifiés. La méthode par réseau reste un outil limité.

Finalement si on opte pour cette méthode, il faudra se rapprocher d’un expert dans ce domaine, Mathieu Jacomy du Médialab.

Questions sur OpenRefine :

Un rappel a été fait sur l’utilité d’OpenRefine. Cet outil permet de nettoyer les données (OpenRefine regroupe directement les groupes de mots proches, ou avec la même sonorité : cf. vidéo introductive 1/3 sur http://openrefine.org/), mais également de mieux visualiser les données récoltées. Par la suite, il est également possible d’aller directement tirer des informations des sites internet de manière automatisée (définitions dans le dictionnaire, recherche de latitude/longitude, etc… voir vidéo 2 et 3 du tutoriel OpenRefine)

Quels outils dans le datascape ?

OpenRefine ne sera pas directement intégré dans le datascape car ce serait trop complexe. Paul propose de définir des ponts entre le datascape et OpenRefine qui permettrait une utilisation plus rapide et plus simple. On peut également intégrer quelques fonctions d’OpenRefine dans le datascape. On peut envisager d’intégrer des logiciels pour l’analyse de réseau : Géphi et Sigma. Ou encore certaines mesures statistiques via l’intégration de R ou Sylab. Matlab et Stata ne sont à priori pas intégrables. De plus Paul préfère ne pas utiliser de logiciels privés pour ne pas se confronter à des problèmes de licence. L’idéal serait donc de permettre l’installation de plugins pour modifier la structure datascape ex post.

A faire dans le futur :

Le versionning :

Rappel : pour mieux comprendre les sources numériques. On veut pouvoir à chaque instant revenir en arrière pour comprendre les modifications qui ont été apporté à la base de données initiale.

Le logiciel GIT (http://blog.okfn.org/2013/07/02/git-and-github-for-data): Pour ce faire, Paul propose l’utilisation du logiciel GIT. Plusieurs avantages à ce logiciel :

  • Permet de voir ce qui a été modifié à chaque étape ($git status) à partir de l’instant t=0 où l’on a initialisé la base de données ($git init)
  • Permet d’ajouter des commentaires pour expliquer les modifications et les confirmer ($git comit « J’ai corrigé bug…. J’ai ajouté… »)
  • Permet de travailler ensemble sur la base. Github permet de mettre en ligne la version retravaillée ($git pull [ancienne version], puis $git push [nouvelle version]).
  • Evite les conflits : Si des conflits sont identifiés (car deux utilisateurs ont travaillé en même temps) alors Git résout lui-même le maximum de conflits puis demande validation à l’utilisateur.

    Problèmes identifiés :

  • Git repère les lignes modifiées sur le fichier csv. Donc il est impossible d’utiliser le tri car Git va considérer que la base a été entièrement modifiée. Il faut donc au plus vite trouver un agencement de la base de données initiale et ne plus y toucher.
  • Que faire des 20 versions csv déjà existantes ?
  • Cela marche avec des fichiers proches du texte (csv) mais ni excel ni stata

Finalement Guillaume D. et Loïc se sont mis d’accord sur la classification suivante : Lieu d’archive – Fonds – Côtes – Années

Concernant les différentes versions du versionning : trois étapes clés apparaissent :

  1. Source / transcription normées / source figée selon la hiérarchie établie ci-dessus.
  2. Unification des différents fichiers puis formalisation des sources (ex : si pluriel, majuscules, féminin…). A cette étape on s’éloigne de la version photo.
  3. Ajout des tags

En utilisant ce procédé, un problème se pose concernant les points virgules. Doit-on les supprimer dès l’étape 2 ou à l’étape 3 ? Doit-on les conserver ? En l’absence de réponse définitive, on se dirige vers la première solution, à savoir la suppression des points virgules dès l’étape 2.

Prochaines étapes :

Paul va commencer le versionning pour nous montrer une première version. Après vérification, le but sera de concaténer toutes les bases existantes puis les nouvelles (de manière automatisée si possible).

Les prochaines réunions :

  • Le 5 février, 10h
  • Le 12 mars, 10h
  • Le 2 avril, 10h
  • Le 7 mai, 10h
  • Le 5 juin, une journée complète de 10h-18h pour faire le point avant l’été.

December 18th meeting

Réunion TOFLIT18 du 18 décembre 2014.

Thème : datascape

Présents : Hugo Bruel, Loïc Charles, Ann Coenen, Béatrice Dedinger, Pierre Gervais, Paul Girard, Pierre Hollegien, Yannick Le Pen, Ivan Ledezma, Silvia Marzagali, et Guillaume Plique. La réunion a lieu de 10h à 16h30.

Merci à tous ceux d’entre vous qui ont pu se déplacer. Cette journée nous a permis de réfléchir aux outils que l’intégration de praticiens des humanités numériques met à disposition du projet. Mon espoir était de prendre des décisions sur la manière dont nous allons développer ces outils : nous nous sommes au moins donné un langage commun et une feuille de route pour y réfléchir.

La journée a été organisée par Paul Girard : je le remercie tout particulièrement.

Chaîne de transformation

Le topofil de Boa vista

Paul a commencé par nous présenter le concept de chaîne de transformation décrit par Bruno Latour à partir de son expérience du topofil de Boa Vista. Il s’agissait d’examiner le traitement du terrain de forêt équatorial par des chercheurs. BL a souligné l’existence d’un double cheminement réduction et amplification. On s’éloigne de la localité / particularité / matière / multiplicité / continuité pour aller vers la compatibilité / standardisations / texte / calculs / circulation / universalité relative.

chaines_de_transformation_topofil_boavista

L’important pour les outils que nous allons utiliser est qu’ils puissent nous permettre d’organiser la circulation dans la chaîne dans les deux sens. Par exemple, il nous faut pouvoir revenir en arrière de la base de donnée transformée pour l’exploration au plus proche de la source numérique.

Cela ressemble à un schéma de l’article «Understanding Comics» de Scott McCloud (1993) qui explique les différents niveaux de réalité des  Comics sur une échelle qui oppose Richesse et Lisibilité.

La même problématique se pose aussi pour le design de l’information. Il faut trouver le bon équilibre entre les connaissances («Richesse») et les données  («Lisibilité»). Plutôt que de vouloir déterminer quel est le bon niveau dans cette double chaîne, il est important de pouvoir s’y déplacer. Dans le cas de toflit, ce déplacement est depuis le bordereau papier dans l’archive jusqu’à l’agrégation des données dans des visualisations.

Déplacement et circulation sont au centre de la réflexion. Cela implique que celui qui fera la navigation, l’utilisateur, le soit aussi, car il doit pouvoir naviguer.

Concept de datascape

C’est à partir de la réalisation de l’importance de ce type d’outils pour les chercheurs que s’est développé le concept de datascape. Celui-ci est par exemple développé dans l’article «The Whole is always smaller than its parts – how digital Navigation May Modify smaller…» [(2012)] )

Il s’agit d’y permettre l’hybridation entre l’approche quantitative (au sens du calcul automatique des ordinateurs) et qualitatif (au sens du travail de lecture du chercheur). Pour cela, et pour permettre l’exploration fructueuse, il faut déconstruire les modèles spécifiques d’analyse a priori des données. Cela implique de faire quelque chose qui ne soit pas trop contraint, et qui puisse maintenir la complexité des données sans les formater dans un modèle théorique pré-éxistant.

medialab_information_design_pdf__page_17_de_24_

Le datascape a un rôle fondamentalement exploratoire. Pour confirmer les intuitions qu’il met à jour, l’étape suivante (qui est plus familière aux chercheurs de sciences sociales) est de créer des statistiques qui puissent être analysée.

Cela est rendu plus concret par la présentation du datascape fait autour du mouvement artistique EAT. Ce dernier, cependant a été fait en liaison avec un seul chercheur : Toflit18 rajoute une dimension collaborative.

De même, le datascape est au départ fait pour la communauté des chercheurs plutôt que le grand public. Celui-ci s’y intéresse : trouver une manière de le rendre accessible est encore une autre affaire. Le développement des interfaces d’exploration visuelle du datascape prépare cependant le travail pour un accès pus grand publique.

Navigation dans les datascape

 

Dans un datascape, la navigation entre les données et la connaissance s’effectuent suivant deux axes : le long des «sauts d’agrégation» (ce qui, je suppose, est notre méthode la plus habituelle); suivant le principe monadologique.

Celui-ci signifie que tout objet doit être vu comme étant une liste d’attributs, de liens vers d’autres objets. Chaque objet est une liste de liens vers d’autres objets. Chaque objet peut alors être pensé comme un point de vue particulier sur l’ensemble des données.

Dans toflit18, par exemple, la marchandise «Acier» n’est pas un objet en soi. Il n’y a pas d’acier dans les bordereaux. L’acier est ce qui lie 5 000 flux particuliers, chacun avec une géographie et une valeur mais partageant tous cet attribut « marchandise »: acier. De même, un pays peut être vue comme une distribution de marchandises et de valeurs, etc

Créer un datascape donne les moyens de se déplacer dans les multiples points de vues sur l’ensemble des données que propose chaque objet de la base. C’est ainsi que l’on peut saisir toute la complexité des données que l’on souhaite analyser.

L’expérience Ricardo

Présentation de Béatrice

Ricardo est un projet portant sur le commerce bilatéral entre 1800 et 1939. Il a été commencé en 2004 et réactivé en 2013 par Béatrice. En liaison avec elle, Paul a supervisé le développement d’un outil de visualisation. Il s’agit de données similaires de celles de Toflit18. Ce travail a donc servi, en quelque sorte, de galop d’essai — comme on a pu le voir par les nombreuses discussions à propos de Ricardo dans les réunions Toflit

Commentaires de Paul

Ces données sont différentes, puisqu’elles portent sur les statistiques de plusieurs pays sans précisions sur les biens.   Cependant Paul a beaucoup appris sur le domaine de l’histoire de l’économie et de l’étude des échanges commerciaux internationaux.

Ce qui a été fait n’est pas un datascape, puisqu’il y a eu une rupture de la chaîne de transformation. Il s’est agit de créer un outil de visualisation sans qu’il y soit possible de revenir sur la conception des données. Il s’agit d’un outil de publication et non pas d’exploration – même si, à l’usage, nous constatons que la visualisation est féconde pour mieux comprendre les données. Cela nous permet toutefois de ne pas oublier que nous avons aussi un objectif de publication de nos données.

Après ces réflexions générales, la réunion porte sur les problèmes spécifiques à Toflit18

Quelle serait la chaîne de transformation de Toflit18 ?

(marchands ->) bureaux des douanes -> documentation du bureau -> archivage |> bordereaux archivés

consultation archives -> photos -> discrétisation par OCR -> contrôle |> sources numériques

Les sources numériques représentent l’extrémité gauche de la chaîne de transformation

uniformisation -> nettoyage -> indexation |> une base de donnée

Les travaux actuels d’aggrégation ont servi à deux choses -> rapprochements de données externes -> exploration/visualisation

Cela nécessite de prendre des décisions sur un certain nombre d’enjeux

Gestion des sources

  • identification des bureaux de douanes / identités productrices
  • sourcing : bureaux,bordereaux,page
  • lien photo – sourcing
  • lien donnée – photos

Les sources numérisées

  • Quel contrôle ?
  • Déterminer la source numérique de référence
  • versionning des données (ce qui permet le contrôle et l’enrichissement) garder trace de chaque version du corpus
  • format des sources : uniforme ou à uniformiser ?

Création de la base

  • l’uniformisation ?
  •  le nettoyage: exemple marchandise au singulier/masculin, les accolades au sens strict ou création d’artefacts ?
  • Définition du modèle
  • Choix de la technologie

Une tentative d’exploration de la structure des marchandises normalisées

Ensuite, Paul nous a proposé une illustration de ce qu’il est possible de faire avec les outils potentiellement mobilisables pour le datascape (et notamment Open Refine et Gephi.

Il a travaillé sur les marchandises normalisées telles que présentes dans « bdd courante August 29th.csv ». Il a utilisé les « ; » qui représentent des accolades dans les documents d’origine (bon, ainsi qu’un certain nombre d’artefacts, comme nous en avons discuté durant la réunion), pour faire des liens entre les termes. Il a aussi codé la « profondeur» ou le niveau de la hiérarchie des accolades dans lequel chaque terme se place.

  • Les étapes dans OpenRefine sont : Copie de la colonne pour référence (chaines de transformation) / séparation de la hierarchie des noms de marchandises (split on 😉 / nettoyage simple : trim et lowercase / cluster and edit / join multivalued cell / sort / blank down / record/ ajouter la colonne Weight en comptant le nombre de row / conserver la chaine de transformation : l’historique
    • Un des avantages d’Open refine est que la chaîne de transformation faite dans l’interphase graphique est conservée (même toutes les étapes du clustering) et peux même servir à écrire un script
  • Puis il utilise un script python pour créer un réseaux à partir du document csv exporté depuis OpenRefine
  • Finalement, il utilise Gephi pour la visualisation de ce réseau. Chaque nœud représente un terme. La taille des nœuds représente le nombre d’occurences (c’est à dire le nombre de flux qui contiennent ce terme). Les liens représentent des présences conjointes dans le champs marchandises des flux. Les couleurs indiquent des groupes de marchandises suivant l’algorithme de clustering modularité (attention il faut analyser les résultats de cet algorithme avec précaution. Cet algorithme est empirique et ne fournit pas toujours les mêmes résultats. C’est essentiel vrai pour les noeuds qui sont difficiles à définir dans un cluster en particulier vues leurs positions entre clusters).

test_marhcandises_modularity_pdf__page_1_de_1_

Une présentation «narrative» du réseau se trouve ici. Il a été créé grâce à l’outil manylines.

Un telle approche permet d’envisager des catégories de marchandises en se basant sur les cooccurence et accolades des sources. Ce peut être une visualisation intéressante pour contextualiser le travail de classification des marchandises pour les chercheurs.

Datascape pour toflit

À partir de l’exemple d’EAT, nous discutons à nouveau de l’utilisation des tags et de l’importance de leur description.

Tags / axes d’analyse

Les axes d’analyse a priori sont :

  • catégorisation et hiérarchie des marchandises
  • le temps
  • la géographique (destination et origine)
  • la balance commerciale: import/export
  • les valeurs
  • les quantités

Au mieux, il faudrait créer une «couche toflit» de tags de manière collective qui permettrait à la fois de fournir une base de travail pour les utilisateurs futurs et d’avoir un rôle d’exemplarité. Cette couche pourrait être ignorées pour repartir directement des sources. Le terme de «tags multiples récursifs» est discuté. Ils peuvent être pensés comme des graphes. Il est important qu’ils aient une hiérarchie.

On imagine de permettre de créer des hiérarchies de tags. Chaque tag peut ensuite qualifier une ou plusieurs marchandises.

La qualification pourrait être dans certains cas limité à une période particulière voire à une zone géographique. Ça complexifie grandement le système. Il faudra rediscuter de la nécessité d’un tel système.

La réflexion porte ensuite sur les rapports entre les tags de Toflit18 et ceux utilisés pour catégoriser le web dans un autre projet du médialab. En effet le web peut être vu comme un graphe de pages webs échangeant des liens mais aussi comme une hierarchie d’adresses. Chaque page web à une adresse sous la forme d’une URL. Or ces URLs sont organisés sous la forme d’une hiérarchie. Le médialab a donc déjà développé des modèles de données dans lesquelles sont mêlés hierarchie et graphe.

Le futur

Il n’y aura pas d’outils manipulables avant l’été prochain. Ils devraient être disponibles au plus tard janvier 2016. Le travail avant l’été 2015 doit inclure :

  1. Mieux comprendre les sources numériques et mettre place le versioning (notamment mettre des identifiants pour les observations de flux).
  2. Avoir pris la décision de quel nettoyage on fait ou pas dans les données primaires.
  3. Question du modèle de données (cette question est différente de celle de la présentation en table ou en graphe, qui est du domaine de l’implémentation). A priori, Paul est en position de proposer quelque chose pour le modèle de données. Les discussions vont en effet dans le sens de ce qu’il maîtrise techniquement parlant. Paul fera une proposition qui s’accompagnera de questions. On mettra au point le modèle par des allers-retours successifs.
  4. Se mettre d’accord sur une liste de fonctionnalité du point de vue analytique/exploratoire qu’on veut mettre en place dans le datascape. Partir a priori de la wishlist des économistes. (wishlist des économistes) Nettoyage et tags : question de ce que toflit va produire en terme de classification et de nettoyage.

La prochaine réunion a lieu le 8 janvier à 9h30 au médialab. Nous ferons le debriefing de la réunion d’aujourd’hui, notamment en direction des économistes. Ceux-ci seront particulièrement mobilisés pour le point 4 de la liste qui vient d’être présentée. Ce serait donc bien s’ils venaient avec leurs questions sur les outils qui ont été discutés aujourd’hui.