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 :
- Source / transcription normées / source figée selon la hiérarchie établie ci-dessus.
- 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.
- 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é.