owned this note   changed a year ago  
Published Linked with GitHub

Callisto & autres dans data journal shs, HNLab

tags: gt notebook,gt data journal shs,WIP
  • Contributeur.ices :
    • Sébastien Rey-Coreyhourcq
    • Nicolas Sauret
    • Hugues Pécout
    • 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

[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).

  1. 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 ?

  1. 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) :

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

3 - cr réunion du 25/05 du gt data paper journal shs

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

  • 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é.

  • 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

  • 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

- 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

7 - revues en HN de DigitHum

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

expérience Callisto - TGIR HumaNum

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

1 - Quarto académique

2 - plateforme de flux Onyxia

3 - évaluation(s)

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 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 ? 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.).

Select a repo