Module 25
March 21, 2024
Diffusion des documents
Tous les documents présentés lors de cette formation sont destinés à être distribués et sont disponibles sur https://documents.migale.inrae.fr
Un problème vieux comme la bioinformatique :
La réplication indépendante d’expériences est à la base de la méthode scientifique.
En complément de réplication indépendante ( expérimentation, échantillonnage, analyse, …), la reproduction d’analyse est indispensable à l’évaluation et à la compréhension de la démarche employée.
Chacun peut déjà, par la mise en place de pratiques simples et l’utilisation d’outils conviviaux, améliorer la reproductibilité de ses travaux
Source : [2]
Avoir accès :
Mais aussi :
[3]
[4]
Aller de façon pragmatique vers une documentation accrue de ce que l’on fait (comment, pourquoi) et des données que l’on utilise et produit.
Décomplexifier les problème, se décomplexifier sur ses pratiques , désacraliser la reproductibilité !
Vous fournir des outils, des pistes pour rendre vos projets :
Bref, plus ouverts et reproductibles.
[5]
Séparer :
git clone
: cloner un dépot distantgit init
: initialiser le versionning sur un dépôt localgit commit
: enregistrer l’état d’un dépôtgit status
: afficher l’état des documents du dépôtgit diff
: comparer l’état actuel au dernier commit, ou deux commits entre eux ou deux branchesgit pull
: récupérer les commits distantsgit push
: envoyer les commits locauxet bien d’autres encore (blame
, revert
,…)
# Titre H1
## Sous-titre H2
### Sous-titre H3
*italique*, **gras** et `code`
> Citations
```
bloc de code
```
* liste
* item
* item
[lien](https://fr.wikipedia.org)
![](https://migale.inrae.fr/sites/default/files/migale.png)
#lien vers une image en ligne ou dans l'espace de travail
Gardez ce mémo à porté de main !
<ul>
<li>item1</li>
<li>item2</li>
</ul>
- item1
- item2
Regrouper dans un unique document: les informations, le code, calculs et les résultats ; pour assurer leur cohérence et améliorer la traçabilité. Tout en étant exportable (ex : html) pour une meilleure portabilité et lisibilité.
Encore un joli mémo pour R markdown.
]
Une alternative open-source pour la publication de documents scientifiques et techniques !
Python
, R
, Julia
, et Observable
Ce document est versionné, dans un format texte dont la lisibilité est assurée au cours du temps, exportable en HTML et accessible via les GitHub Pages.
→ Expliciter pour trouver les erreurs et de les éliminer
- Inspecter pour justifier et comprendre
- Refaire pour vérifier, corriger et réutiliser
La science ouverte est la diffusion sans entrave des publications et des données de la recherche.
Elle s’appuie sur l’opportunité que représente la mutation numérique pour développer l’accès ouvert aux publications et –autant que possible– aux données de la recherche.
Un document collaboratif qui définit la façon dont les données seront gérées pendant et après le projet.
Penser à toutes les étapes du cycle de vie de la donnée
Le modèle vous aide à anticiper l’ensemble des questions et des problèmes qui peuvent se poser par le biais d’une série de questions.
Document évolutif. Au moins 3 versions :
l’ensemble des partenaires. PGD = pour générer du dialogue.
On planifie , on anticipe
On gère, on améliore et on commence par ne plus perdre de données.
Quelles sont les données critiques généres ou utilisées dans le projet ?
Pour vous et vos collaborateurs :
Pour la communauté scientifique, publiez le DMP pour indiquer :
Différents modèles (ANR, Horizon Europe) - Un seul document avec 6 sections, 2 à 4 questions par section. - DMP OPIDoR pour organiser l’écriture collaborative
Informations générales sur le projet
Selon l’OCDE, les données scientifiques (research data) sont « des enregistrements factuels (chiffres, textes, images et sons), qui sont utilisés comme sources principales pour la recherche scientifique et sont généralement reconnus par la communauté scientifique comme nécessaires pour valider des résultats de recherche. »
Explorons un exemple de DMP
env.yml
et le versionnerconda env export > environment.yml
[7]
Snakemake ou Nextflow pour définir de façon “simple” et modulaire des workflows d’analyse :
Snakefile
for sample in `ls *.fastq.gz` do
fastqc ${sample}
done
SAMPLES = glob_wildcards("./{sample}.fastq.gz")
rule final:
input:expand("fastqc/{sample}/{sample}_fastqc.zip", sample=SAMPLES)
rule fastqc:
input: "{sample}.fastq.gz"
output: "fastqc/{sample}/{sample}_fastqc.zip"
conda: "fastqc.yaml"
message: """Quality check"""
shell: """fastqc {input} --outdir fastqc/{wildcards.sample}"""
Au final, toujours se poser la question du rapport coût / bénéfice.
Module 25
Comment mettre en forme et structurer simplement un document texte ?
→ avec un balisage faible tel que Markdown