---
title: notebook et data journal shs
date: 2023-09-11
tags: gt notebook, gt data paper journal shs
theme: blue
header-includes: |
<style>
div.info {color: #31708f; background-color: #d9edf7; border-color: #bce8f1; border: 1px solid ; padding: 0.7em 1em; margin-bottom: 0.5em;}
body {font-family: mono;}
div.content {padding: 1em; max-width: 700px;}
</style>
---

# Callisto & autres dans data journal shs, HNLab
###### tags: `gt notebook`,`gt data journal shs`,`WIP`

:::info

- Contributeur.ices :
- [x] Sébastien Rey-Coreyhourcq
- [x] Nicolas Sauret
- [x] Hugues Pécout
- [x] Raphaëlle Krummeich
- Dernière màj : 14/09/2023
- quelques annotations hypothesis
- ajout des échanges avec HNLab
:::

## préalables

### 1 - dossier RSFIC 2022 Kembellec, Le Deuff
Data Paper : émergence d’une nouvelle donne scientifique
[https://journals.openedition.org/rfsic/12219](https://journals.openedition.org/rfsic/12219)

#### [Revue de lecture, WIP]
Outre une entamme en poésie... je cite : _il en va du data paper comme de la poésie_,
> une non-confusion entre
> - poïétique/éthique - ποιεῖν (créer/fabriquer en grec) de la technique,
> - et poétique - poïesis (création, voir Palimpsestes, Genette, 1982) où le geste technique est invisibilisé (méprisé) par la geste littéraire, comédienne et rhétorique.

parmi les apports de cet appel à communication / dossier RFSIC, il y a les faits
- de visibiliser les champs disciplinaires ou métiers venant en appui aux EC, l'enjeu étant _dans la possibilité de créer du lien_.
- de tenter de définir ce qu'est un _data paper_ dans une discipline fondée sur la question de l'information et de la communication, avec notamment deux focus : celui de la notion de documentation (Le Deuff, cf. Paul Otlet & la documentalité) et celui des métadonnées (Kembellec, cf. Foucault & l'archéologie du savoir).

Ainsi, une définition initiale du _data paper_, doté de _règles, normes et formes_, est une _représentation d'une réalité "différante" (Derrida , 1967), celles d'une mise en données qui facilite l'analyse du réel ainsi recomposé._ Il est la fois _objet rédactionnel_, _percolation méthodologique_ ou moyen de _sortie de crise de la reproductibilité_ et un _moyen de pointer le "travail invisible des données"_.

Par comparaison avec l'habitus du champ de la santé où le _data paper_ n'est pas _un espace de posture épistémique (...) (mais) principalement une démonstration de métrologie_, les auteurs définissent le _data paper_ en sciences humaines (sic!) _comme étant avant tout un écrit d'accompagnement_. Celui-ci reprend _les codes du data paper en STM, tout en respectant la tradition littéraire_. Ils lui attribuent _une vision auctoriale et éditoriale d'un jeu de données (...) (où) la question méthodologique n'est pas moins importante_.

La principale différence du _data paper_ entre STM et humanités réside dans les données qui _ne sont pas de simples mesures, mais de véritables productions d'observations ou d'analyses de corpus **subjectivées**_ (souligné par les auteurs citant Johanna Drucker) : entre data (données métrologiques), capta (données _co-dependently constituted_) voire sublata (données obtenues ou construites, citant Latour).

La notion de notebook apparaît dans l'_organologie (sic!) du data paper_ ou sa _matérialité_. Celui-ci peut être _adjoint_ au _data paper_ qui implique des _techniques numériques_. Une définition du notebook est un _document exécutable_ (cf. "bloc-code" d'Arthur) _qui hybride écriture et automatisation informatisée_.

#### [Possibles apports critiques]

1. Est-il possible d'appréhender les enjeux du data paper en sciences humaines (et dans les pratiques scientifiques en général) sans interroger le syntagme anglophone _data paper_ ?

Dans l'article, les données sont dites générées, récoltées, filtrées, massifiées, inférées, essentialisées, recherchées, mesurées, collectées, produites, construites, obtenues et réutilisées ou reproduites, regroupées en jeux ou corpus. Dans "Qu'est-ce que l'informatique", Varenne F. (2009, éd. Vrin) dit qu'elles sont relations. Cela va dans le sens de JD, je cite
> the abandonment of interpretation in favor of a naïve approach to statistical certainly skews the game from the outset in favor of a belief that data is intrinsically quantitative — self-evident, value neutral, and observer-independent. This belief excludes the possibilities of conceiving data as qualitative, co-dependently constituted — in other words, of recognizing that all data is capta [(Drucker, 2011)](http://digitalhumanities.org/dhq/vol/5/1/000091/000091.html).

2. La question du _paper_ qui est celle des supports d'inscriptions mais aussi celles de l'évaluation, car il s'agit d'un _scientific paper_, un article scientifique

Cette "logistique" - pour faire vite, interroge aussi le prisme disciplinaire du _data paper_, _une construction écrite posée également dans les canons de la disciplines_, selon les auteurs. Cependant, la question des méthodes est le plus souvent interrogée sous une acception "transdisciplinaire" de techniques souvent invisibilisées (jusqu'à présent). Cette dernière permet-elle de faire l'hypothèse que le _data paper_ serait aussi un objet ouvert à des processus interdisciplinaires, y compris en terme d'évaluation scientifique ?

3. Le notebook irréductible à la méthode quantilienne (QQOPQCC) ?

Selon les auteurs, il est à la fois automate informatique et outil, méthodologie et code. Il _offre (...) la possibilité de suivres les opérations effectuées (...) facilitant la vérification du processus (...)_ et l'ouverture de _pistes de réutilisation de tout ou partie de la méthodologie déloyée_.
Il s'agirait donc d'un moyen de reproduction de processus décrits attachés actuellement aux données, mais non réductibles à celles-ci. Ici se pose des questions éthiques relatives aux _prodiges et vertiges de l'analogie_ (Bouveresse, 1999) au sein des pratiques scientifiques.

### 2 - JE au printemps 2023 (msh lorraine) :

[<img src=https://www.misha.fr/websites/_processed_/4/1/csm_affiche-data_891939de67.png width="25%">](https://www.misha.fr/agenda/evenement/un-data-journal-interdisciplinaire-pour-les-sciences-humaines-et-sociales-enjeux-scientifiques-et-mise-en-oeuvre-pratique)

avec notamment openedition, mais aussi Nicolas Larousse sur l'articulation avec nakala (métadonnées) & Dominique Roux de l'IR métopes (édition), dans le cadre du programme/equipex COMMONS

[<img src=https://hackmd.io/_uploads/r1Ttd9nA3.png width="50%">](https://www.youtube.com/watch?v=YEdOVZmEQTo)

### 3 - [cr réunion du 25/05 du gt data paper journal shs](https://mypads2.framapad.org/mypads/?/mypads/group##/data-journal-shs-vo3r9c96l/pad/view/cr-reunions-data-journal-shs-jx3rac95v)

### 4 - extrait du cr réunion du 17/07 des réf. sous-GT (plateforme resana)
> GT « Articles exécutables/notebook »
La question du choix de la plateforme est sous-jacente aux questions sur l’intégration de notebooks dans le projet. Il faudra également voir sur cette question des notebooks ce qu’il est possible de faire avec Huma-Num.
Une des questions soulevées au sein de ce GT est celle de la finalité opérationnelle du notebook. En SHS, la donnée brute est souvent retravaillée. Veut-on rendre visible la chaîne de traitement de la donnée ? Importance de la partie « Méthodologie » qui doit détailler aussi précisément que possible les différents traitements opérés sur les données qui sont mises à disposition.
Remarque d’Aricia : il nous faut une plateforme éditoriale qui facilite les liens avec les forges et les divers entrepôts.
François-Claude évoque son expérience de publier en s’appuyant sur Lodel. Il suggère que lorsqu’on formate nous-même les articles en PDF, cela permet de faciliter le travail de mise en forme des articles ; sinon il faut vraiment un secrétaire éditorial. Julien précise qu’il pourra prendre en charge le rôle de secrétaire d’édition de la revue (si tant est que le rythme de publication de la revue est de deux numéros par an, comme nous le prévoyons initialement). A ce sujet, Aricia souligne également l’importance d’utiliser un format pivot (tel que le XML-TEI utilisé dans la chaîne Métopes).

### 5 - derniers échanges

- [name=Raphaëlle]

Il n'y a pas (encore) de définition pour "articles exécutables", ce qui s'entend compte-tenu de la complexité de l'objet. S'agit-il, pour le projet de revue, d'une "forme" spécifique d'article ? Est-ce un objet permettant d'exécuter/interpréter des cellules de code mobilisant les données, objets de la revue ? Est-il envisagé sous une forme de programmation lettrée ? S'agit-il d'autre chose ? L'article exécutable a-t'il pour fonction, par exemple, d'explicter la provenance des "données brutes" & leur traitement, et de rendre ainsi compte d'une "visibilité" de la méthodologie employée sur les données ? Voir, l'article exécutable engage-t'il à une reproductibilité du processus de collecte/traitement/représentation ? etc.
A ce stade, il y a plus de questions que de réponses...
Au sein du GT Notebook, notre réflexion dépasse la question d'une plateforme éditoriale de revue, même si lors du webinaire, nous avons déjà abordé le sujet. Peut-être, les questions/hypothèses posées par le GT data journal SHS à ce stade conduiraient à une définition dédiée de l'"article exécutable", à savoir (?) :
> un document computationnel - optionnel, doté d'un langage de programmation & de la description d'un environnement d'exécution/interprétation, ayant pour contenu, sous forme de cellules de code exécutable/interprétable (pas forcément sur la plateforme éditoriale de la revue), la chaîne de traitements des données mobilisées dans l'article données (ou autre) associé.

- [name=François-Claude Rey]

Je me demande aussi ce que nous entendrons par article exécutable, mais il me semble souhaitable, pour pouvoir le publier, de le définir en incluant peut-être :
- avec une forme pérenne téléchargeable ;
- exécutable en ligne sans avoir à le replacer dans un environnement-outil autre qu'un navigateur courant ;
- intégrant toutes les données nécessaires à son exécution, ou y faisant appel directement sans barrière d'accessibilité lors de son exécution si l'auteur.e les a hébergé dans un entrepôt;
- avec des limites "raisonnables" ou un avertissement dans la grosseur du fichier et dans l'intensité d'utilisation du CPU (sur les ordi hôtes qui l’exécuteront).

Je comprends que la forme de l'article sera probablement dans un notebook .ipynb sous Jupiter, c'est à dire finalement sous la forme d'une page web consultable et exécutable dans un navigateur :
- devrait-il être autosuffisant (sans fichiers annexes) ?
- Est-il souhaitable de ne pas se fermer à d'autres formats exécutables, par exemple certains PDF où du code peut être exécuté même dans le navigateur.

> [wip] François est notamment en charge du sous-gt chaîne éditoriale [https://annuel2.framapad.org/p/gt-chaine-editoriale-a1nl?lang=fr](https://annuel2.framapad.org/p/gt-chaine-editoriale-a1nl?lang=fr)

- [name=Julien Muller]

Si le format "article exécutable" pose beaucoup de questions, il me semble que la définition que tu en proposes est pertinente. Je suis bien sûr beaucoup moins avancé que vous sur la réflexion autour de ce format d'article, mais il est nécessaire effectivement, en vue de la création de la revue, de définir assez précisément ce que l'on entend par "article exécutable", ce qu'il doit contenir et comment son contenu est structuré. Sur la question de l'hébergement de l'article, il faudra y réfléchir en prenant en compte les résultats du GT plateforme (en fonction du choix qui sera fait pour la plateforme hébergeant la revue). Les résultats du GT enquête sur les besoins apporteront peut-être également des éléments sur ce que les chercheurs en SHS attendent de ce format.

### 6 - revues citées dans l'enquête MSH Lorraine | data papers
<details>
- Discourse Processe
- BMC Psychology
- L’Évolution Psychiatrique
- Développement Durable et Territoires
- Archives internationales d'histoire des sciences
- Artefact
- Histoire & mesure
- Bulletin de la Sabix
- Cortex
- RERU
- Annals of Public and Cooperative Economy
- RIPCO
- Travail et Emploi
- Économie et Société
- Proteus
</details>

### 7 - revues en HN de DigitHum

[https://digithum.huma-num.fr/ressources/revues/](https://digithum.huma-num.fr/ressources/revues/)

## [WIP] sous gt notebook / _articles exécutables_

### 1 - objectifs
- a) Lister les contraintes auxquelles doivent répondre les plateformes de diffusion pour permettre la publication d’articles exécutables (reproductibilité).
- b) Réaliser un benchmark des data journals qui proposent des articles exécutables et organiser des retours d’expérience de leur part.

### 2 - reproductibilité un point mort ? non, un réseau
- revue d'articles de l'été (to be continued)
- Computational reproducibility of Jupyter notebooks from biomedical publications : [https://arxiv.org/abs/2308.07333](https://arxiv.org/abs/2308.07333) / [https://arxiv.org/pdf/2209.04308.pdf](https://arxiv.org/pdf/2209.04308.pdf)
- Map Reproducibility in Geoscientific Publications: An Exploratory Study
[https://drops.dagstuhl.de/opus/volltexte/2023/18901/](https://drops.dagstuhl.de/opus/volltexte/2023/18901/)
- [réseau recherche reproductible](http://www.recherche-reproductible.fr/)
- [<img src="https://miti.cnrs.fr/wp-content/uploads/2023/04/geometric-glass-city-architecture-300x200.jpg" width="15%">](https://miti.cnrs.fr/evenement-scientifique/colloque-replicabilite-reproductibilite-recherche/)
**Réplicabilité/reproductibilité de la recherche : enjeux et propositions** (journée du 8/09 2023 CNRS-MITI)

## expérience Callisto - TGIR HumaNum

[](https://hnlab.huma-num.fr/blog/2021/05/26/callisto-un-demonstrateur-jupyter/)

## Quelles propositions du sous-GT notebook à gt data paper journal shs ?

### 1 - Quarto académique
- Notebooks Now details: [https://data.agu.org/notebooks-now/](https://data.agu.org/notebooks-now/)
- JJ Allaire's #bioC2023 talk: [https://jjallaire.quarto.pub/reproducible-manuscripts-with-quarto/#/title-slide](https://jjallaire.quarto.pub/reproducible-manuscripts-with-quarto/#/title-slide)
- Quarto manuscripts feature: [https://quarto.org/docs/manuscripts/](https://quarto.org/docs/manuscripts/)

### 2 - plateforme de flux Onyxia
[<img src=https://www.onyxia.sh/static/media/Dragoon.8d89504cc3a892bf56ee9e7412df7d43.svg width="20%">](https://www.onyxia.sh/)

### 3 - évaluation(s)

- voir l'intervention de Computo sur la web TV du gt notebook :
[https://gt-notebook.gitpages.huma-num.fr/site_quarto/posts/webinaire3.html](https://gt-notebook.gitpages.huma-num.fr/site_quarto/posts/webinaire3.html)
- ou l'exemple donné par Nicolas Rougier : [https://distill.pub/](https://distill.pub/) notamment [https://distill.pub/2021/distill-hiatus/](https://distill.pub/2021/distill-hiatus/)
- etc.

## Call avec Stéphane Pouyllau HNLab - 14 sept. 2023

_Raphaelle K., Sébastien RC., Nicolas S., Stéphane P._

Présentation par Raphaëlle :

- objectif du gt _data paper journal shs_ de répondre à l'appel FNSO pour une revue data paper
- articulation entre ce qu'on fait dans le GT notebook et la réflexion du _journal data paper shs_ à venir
- quelle position Huma-Num/HNLab pour en relater cet après midi lors de la réunion ?

Stéphane: _le HNlab n'a pas réussi à intéresser l'équipe Huma-Num aux notebooks/Callisto._ Huma-Num ne sera pas porteur sur ces questions. Ils sont plutôt en train de proposer une offre classique : entrepôt de données Nakala etc. avec des briques qui ne communiquent pas entre elles, et qui ne sont pas pensées pour le workflow éditorial.
- Le projet Callisto fonctionne sur une interaction et une complémentarité entre JupyterLab/Gitlab et une logique d'écriture markdown. Cela peut être expérimenté à grande échelle, mais doit être accompagné/appuyé par les communautés. Les dispotisitfs et technonologies sont mûres, ce qui ne veut pas dire que les infra du CNRS peuvent les exploiter, notamment du fait de cultures professionnelles : ces nouveaux outils se heurtent à l'incapacité des structures de recherche à comprendre comment ils fonctionnent et comment on les administre.
- le projet plus récent Vulcain est déployé sur 2 machines virutelles (VM) de la DSI du CNRS. Il est plus robuste que Callisto : les noyaux (_kernels_) sont mis à jour à la demande, avec un paramétrage par utilisateurices. Il est possible d'utiliser les langages Python et R. C'est mûr mais reste la problématique éditoriale et celle de l'orchestration (K8s). Autrement dit on a des technos mûres, qui marchent, mais on n'a pas les infrastructures. Au Canada, le côté K8s, cela ne leur fait pas peur, mais en France on en n'est pas du tout là, il y a un gap. On a besoin d'avoir des technos comme Quarto/Hugo, pour être stable. Reste la problématique de comment on fige un notebook jupyter python pour le rendre réexecutable (données intermédiaires, exécution partielle des cellules etc.).

Nicolas: il me semble qu'il y aura toujours un _delta entre les pratiques des chercheurs et chercheuses sur l'infrastructure de travail proposant des notebooks et les attendus et les contraintes des revues qui souhaitent publier des notebooks_: delta de contenus, de discours, etc. mais aussi delta technique puisque les problématiques de pérennité ne sont pas les mêmes pour la revue. Est-ce que c'est le rôle des infra. de recherche de se positionner sur la diffusion de revues ?

Stéphane : le temps long de la revue n'est pas celui du maintien d'une plateforme. Un article décrit de la méthodologie, explicite les traitements théoriques et pratiques et délivre les données et un résultat de traitement à un instant t : le HTML statique convient. La question de la (quasi)reproductibilité peut être posée en ces termes : ce qui compte, c'est la méthodologie, les data, et l'exemple, non l'infrastructure pour permettre tout rejouer à l'identique.

Sébastien défend une autre vision de la reproductibilité (Guix/Nix) (réflexion post visio). Il y a aujourd'hui des moyens de faire de la reproductibilité plus fine que des outils comme _docker_ et cie. C'est un horizon pour les SHS, mais cela est déjà en bonne voie du côté des sciences dites naturelles (bio, physique) notamment dans le monde du calcul de haute performance (HPC, voir par exemple https://hpc.guix.info/) à Grenoble ou Bordeaux. Et sur le plan de la review de code côté workflow éditorial, on a besoin de dire "l'article et la méthode fonctionne car cela s'exécute comme prévu et cela produit un résultat" à un instant. Je suis d'accord pour dire que les SHS n'en sont pas là, mais c'est aussi pour cela que l'on a créé la revue [RZine](https://rzine.fr/) par exemple, pour aller plus loin aussi sur cette question là, pour prototyper/explorer et montrer que "c'est possible" ! C'est un horizon de développement.

Stéphane : la demande du lecteur ou de la lectrice d'article de revue n'est probablement pas celle là. Il s'agit de lire et de comprendre "sans effort" (i.e. sans entrer dans la technicité de la méthode). Les dispositifs de dockerisation dans les infras SHS ne sont pas du tout pris en compte. Donc le chemin est encore long avant d'atteindre la reproductibilité telle que Sébastien la formule pour les SHS.

Sebastien (réflexion post visio): Oui je suis d'accord, l'infrastructure n'est pas encore là, et clairement on vit au crochet des physicien-nes depuis des années de ce côté là. Je pense qu'il faut continuer à exister et se faire entendre même si on est minoritaire dans ces réseaux, en tout cas c'est ce que l'on essaye de faire avec le HPC en géo, en réduisant tant que l'on peut (via des logiciels adaptés) la barrière d'accès à ces moyens de calculs. Je suis d'accord avec ce que tu dis sur une progression par jalon, avec des étapes concrètes, et sans aller trop loin, on observe déjà qu'il y a une barrière technique et méthodologique importante sur le workflow qui intègre git & plateforme git dans RZine. On expérimente sur un double plan, éditorial et technique, et sur ce dernier volet, je pense qu'avec des techno comme Guix pour la reproductibilité, on devrait pouvoir aller plus loin sans forcément ajouter de la contrainte au workflow éditorial.

A la lecture de Le Deuff, Kembellec 2022 dans RFSIC, l'idée des notebooks supports de data paper est de permettre de reprendre tout ou partie du code associé à une ou des méthodologies. Peut-être peut-on imaginer d'outiller quelques bouts de code, un peu comme le fait le W3C dans les tuto CSS ou HTML [tryityourself](https://www.w3schools.com/html/) ? La question se pose dès celle de l'évaluation de l'article lui-même : le paradigme du _litterate programming_ permettrait d'éviter de reproduire des opérations sans comprendre ce qui se passe.

Sebastien : peut-être pourrait-on tester des processus entre Vulcain et Rzine ?

Stéphane : l'initiative relative au notebook est sortie de l'infrastructure de recherche HumaNum pour aller vers une infra à l'état de l'art avec le CNRS. Ce qui a permis de réussir assez facilement à avoir les instruments nécessaires. Mais la question de l'article executable au sein d'une revue pose un réel problème : tout ce qui va s'exécuter dans un enivronnement Vulcain va se heurter aux infrastructures d'édition qui n'en sont pas là du tout. Soit les revues inventent leur propre modèle, soit elle tape à la porte des modèles existants et il y aura un mur technique (et peut-être aussi culturel, note Raphaëlle post-visio). C'est bien une question à se poser, car malgré les projets comme COMMONS qui porte ce type de problématique, cela ne sera pas réalisé à l'issue du premier programme...

Nicolas : il est important de distinguer
- la recherche en train de se faire (et qui peut être documentée et publiée),
- les initiatives pédagogiques (rzine, io, programming historian),
- les attentes éditoriales des revues.
Les pratiques de chercheurs et chercheuses sont solubles dans les attentes des revues. Entre les deux, il y a des objets intéressants, comme RZINE, les chercheurs et chercheuses font des efforts et il faudrait les accompagner. Il y a un delta à combler entre les deux attentes / voies.

Raphaëlle : On rencontre ces questions très concrètement dans la chaîne éditoriale de la revue Rzine, notamment la question de l'évaluation du code et de son écriture (et pas seulement celle du LP). Qu'est ce qu'on évalue ? Les méthodes déployées ? la technicité du code etc. ? En même temps, se pose aussi la question disciplinaire. Si une revue data paper journal shs se veut pluridisciplinaire, outre les questions de méthodes, on multiplie les difficultés en terme d'évaluation. Les notebooks, à travers les méthodes qui y sont transcrites, posent ces questions de frontières disciplinaires, au delà des shs voire de la communauté scientifique (voir les notebooks pédagogiques etc.).