Comment établir et maintenir un ensemble de données de recherche animale multimodal à l'aide de DataLad

Jul 08, 2023

Données scientifiques volume 10, Numéro d'article : 357 (2023) Citer cet article

1 Altmétrique

Détails des métriques

Le partage des données, des outils de traitement et des flux de travail nécessite des services d'hébergement de données ouvertes et des outils de gestion. Malgré les directives FAIR et la demande croissante des agences de financement et des éditeurs, seules quelques études animales partagent toutes les données expérimentales et les outils de traitement. Nous présentons un protocole étape par étape pour effectuer le contrôle de version et la collaboration à distance pour les grands ensembles de données multimodaux. Un plan de gestion des données a été introduit pour assurer la sécurité des données en plus d'une structure homogène de fichiers et de dossiers. Les modifications apportées aux données ont été automatiquement suivies à l'aide de DataLad et toutes les données ont été partagées sur la plateforme de données de recherche GIN. Ce workflow simple et économique facilite l'adoption des workflows de logistique et de traitement des données FAIR en mettant à disposition les données brutes et traitées et en fournissant l'infrastructure technique permettant de reproduire indépendamment les étapes de traitement des données. Il permet à la communauté de collecter des ensembles de données acquis et stockés de manière hétérogène non limités à une catégorie spécifique de données et sert de modèle d'infrastructure technique avec un riche potentiel pour améliorer le traitement des données sur d'autres sites et s'étendre à d'autres domaines de recherche.

La gestion et le partage des données nécessitent les meilleures pratiques telles que récemment introduites pour l'IRM humaine1,2. D'après notre expérience, la plupart des laboratoires s'appuient sur un stockage de données non standardisé sur des disques durs locaux ou des lecteurs réseau avec une gestion des utilisateurs et une capacité de sauvegarde insuffisantes. Malgré le fait que seule une minorité d'études IRM utilisent de petits animaux, il est alarmant de constater que sur OpenNeuro, une plateforme de partage de données de neuroimagerie largement utilisée3, seuls 3 % des ensembles de données contiennent des données provenant de souris ou de rats. De même, sur une autre plate-forme de partage de données populaire, non spécifique à la neuroimagerie, Zenodo4, seuls 30 % environ des ensembles de données IRM proviennent de souris ou de rats. De plus, il est surprenant et contraire aux principes FAIR5, si dans la majorité de ces jeux de données de neuroimagerie, seules les données d'imagerie sont fournies. Cela exclut une grande partie des données d'accompagnement, par exemple, les fichiers de microscopie utilisés pour la validation croisée in vivo. Nous avons également identifié un manque évident de guides étape par étape ou de routines automatisées nécessaires pour reproduire les données traitées. Ces exemples soulignent les rapports précédents6 que le partage de données sur les petits animaux est loin d'être courant et qu'il n'y a pas de normalisation en termes d'acquisition, de stockage et de partage des données. Si les données ne sont pas partagées et donc pas disponibles pour être réutilisées comme c'est le cas pour 93% des publications biomédicales en libre accès7, cela contraste également fortement avec le principe des 3 R de minimiser le nombre d'expérimentations animales8. Il reste donc très difficile de comparer des études entre différents laboratoires, ce qui contribue à la crise de reproductibilité9, et les études sur le petit animal (neuroimagerie) ne font pas exception10.

Nous envisageons une évolution vers les conditions de bonnes pratiques scientifiques et les principes de FAIR - Findable, Accessible, Interoperable, Reusable5 et Open Science2 pour améliorer la fiabilité et la reconnaissance des études animales. Notre objectif était de créer une approche facilement applicable pour la mise en place d'un jeu de données multimodal qui donne accès aux données brutes et traitées, aux méthodes, aux résultats et à leur provenance. Une bonne gestion des données de recherche (GDR), telle qu'elle est également de plus en plus exigée par les organismes de financement et les éditeurs, est essentielle pour respecter ces normes2,11,12.

Nous décrivons ici notre stratégie d'organisation des données, de collecte de métadonnées et de suivi des données/analyses à l'aide de trois outils établis : notre base de données relationnelle13, la plateforme de données GIN (G-Node Infrastructure services, https://gin.g-node.org) et le logiciel de gestion des données de recherche DataLad14. La base de données est utilisée pour collecter toutes les métadonnées expérimentales sur la chronologie complète des expériences animales longitudinales et multimodales, y compris l'IRM, l'histologie, l'électrophysiologie et le comportement. GIN et DataLad sont tous deux basés sur Git, un système de contrôle de version populaire, et git-annex, qui étend les capacités de Git, notamment en ce qui concerne la gestion de fichiers volumineux. GIN est un service de gestion de données open source basé sur le Web avec diverses fonctionnalités pour la gestion collaborative des données, par exemple, la gestion des versions intégrée, l'accès sécurisé, les identificateurs de données persistants pour la publication (DOI), l'indexation automatique et la validation des données. DataLad est un logiciel de gestion de données conçu pour accompagner les différentes étapes de développement des objets numériques. Il est important de noter que DataLad peut être considéré comme une superposition au-dessus des structures et des services de données existants : le suivi des fichiers ne modifie pas les fichiers eux-mêmes ni l'emplacement à partir duquel ils peuvent être récupérés par les outils de traitement des données.

Au cours des 5 dernières années, nous avons établi une stratégie pour 1) la planification du projet, 2) la documentation, 3) l'acquisition et le stockage des données, et 4) le partage des données (Fig. 1). La planification du projet et les détails expérimentaux sont enregistrés dans une base de données relationnelle interne basée sur le cloud13. Un élément clé pour la base de données et le stockage des données est l'identifiant, l'ID d'étude pour chaque animal, utilisé dans une structure de nom de fichier standardisée pour rendre les données trouvables. La structure du répertoire pour les données brutes suit le permis d'effectuer des expériences sur les animaux. Les données d'un projet spécifique sont organisées selon les principes YODA (https://handbook.datalad.org/en/latest/basics/101-127-yoda.html), qui sont compatibles avec les normes existantes, par exemple la structure BIDS15 (Fig. 2A). Une routine de sauvegarde incrémentielle automatique a été installée, qui transfère les données d'un poste de disque externe relié au poste de travail d'analyse principal vers un lecteur réseau géré de manière centralisée. En préparation de la publication et pour faciliter la reproductibilité des données, les données expérimentales brutes et traitées sont rendues publiques sur GIN, et les détails et les pipelines de post-traitement sont spécifiés - soit dans la publication, soit sur une page GitHub (https://github.com/aswendtlab/Project_C3a_peri-infarct).

Flèches vertes : flux de travail pour la planification du projet, l'acquisition, le traitement, le stockage des données ; flèches grises : plan de sauvegarde sur les stockages locaux et réseau ; flèches orange : intégration de DataLad pour le contrôle de version ; flèches bleues : processus de publication utilisant GIN comme service d'hébergement en ligne. Figurine créée avec Biorender.com.

(A) Structure du répertoire YODA et intégration de DataLad. Le répertoire racine du système d'exploitation (OS), la liste des projets et le contenu lié au projet (dossiers + types de fichiers). Les connexions séparées par des tirets et des "//" indiquent qu'il peut y avoir des niveaux supplémentaires, par exemple, le temps des mesures. Lors de la conversion du dossier Project1 en un jeu de données DataLad, les fichiers DataLad correspondants (cases grises) sont créés en tant qu'informations supplémentaires dans le dossier, sans affecter le reste des données. Les dossiers "raw_data" et tous les dossiers dans "code" sont des sous-ensembles de données indépendants dans le contexte de l'imbrication et de l'établissement de la décentralisation, le "code" étant situé dans Github au lieu de GIN. (B) Le guide étape par étape pour la création du jeu de données DataLad est composé de 4 étapes ultérieures obligatoires et encadrées par une phase de préparation initiale et un scénario d'utilisation tiers facultatif (les cercles rouges mettent en évidence les étapes récurrentes). (C) Structure de dossiers basée sur le permis d'effectuer des expériences sur des animaux sans DataLad (TVA = Tierversuchsantrag (allemand : protocole animal). Il s'agit de l'ancienne structure avant la mise en œuvre de la structure YODA, tout le traitement a également été effectué au sein de cette structure, en utilisant les pipelines parallèlement à partir d'un autre stockage séparé de cette structure. Les données brutes d'origine sont toujours conservées dans cette structure en tant qu'archives de données brutes, mais le reste est aboli.

DataLad est utilisé comme outil central de gestion des données (Fig. 1) et pour le contrôle de version : il garde une trace des fichiers qui ont été modifiés, quand et par qui, et offre la possibilité de restaurer les états précédents. À cette fin, DataLad est indépendant du type de données et fournit une interface unifiée pour gérer les fichiers de code et de données (généralement gérés respectivement par Git et git-annex).

Dans les ensembles de données DataLad, il est possible d'imbriquer (un nombre illimité) d'autres ensembles de données DataLad, chaque sous-ensemble de données restant un composant autonome avec son propre historique et ses frères et sœurs. Pour obtenir cette structure, les étapes suivantes 1 à 4 peuvent être effectuées indépendamment dans un ensemble de données établi. De cette manière, l'utilisateur peut subdiviser le projet, par exemple par publication, type de données ou emplacement de stockage. Pour clarifier cela, il est possible de placer un ensemble de données de niveau supérieur avec les sous-ensembles de données dans le service de référentiel en ligne. Ici, les données suivies directement par un ensemble de données sont stockées comme d'habitude, mais les sous-ensembles de données ne sont disponibles que sous forme de liens vers leur propre référentiel, qui peut, mais ne doit pas être hébergé par le même fournisseur de référentiel en ligne. Dans notre cas, tout le code du projet est stocké et maintenu dans les référentiels GitHub (https://github.com), et installé en tant que plusieurs sous-ensembles de données dans l'ensemble de données principal Project1 sur GIN (Fig. 2A). La structure introduite par les principes Yoda rend l'ensemble du projet autonome. Aucun élément supplémentaire en dehors du projet n'est nécessaire pour passer des intrants aux résultats. En revanche, aucune auto-confinement n'est possible pour la structure de la figure 2C.

INFO : Si un jeu de données ou un sous-jeu de données doit être implémenté pour un dossier qui ne contient que des scripts de codage, les étapes 1 à 4 doivent être légèrement optimisées. En bref, git est bien mieux adapté au contrôle de version des scripts contenant du code. Lorsque l'étape 1.2 est exécutée, tout est géré par git-annex par défaut, l'alternative est d'utiliser datalad create --force -c text2git. La configuration supplémentaire place git en charge du contenu des jeux de données.

Sur la base de notre développement de flux de travail (Fig. 1), cette description de cas d'utilisation fournit un guide étape par étape pour les utilisateurs non experts sur la façon de gérer de grands ensembles de données expérimentales contenant des fichiers complexes et multimodaux, c'est-à-dire les données brutes et traitées ainsi que les fichiers de code et de sortie.

Pour les exigences matérielles et logicielles et les routines d'installation, voir la section Méthodes et le matériel supplémentaire. Le flux de travail se compose de 4 étapes obligatoires (Fig. 2B) : 1. Initialiser un jeu de données DataLad, 2. Contrôler la version, 3. Initialiser le référentiel distant (en ligne) et 4. Télécharger vers le référentiel distant. Nous décrivons également un scénario de cas d'utilisation facultatif pour une utilisation par des tiers, c'est-à-dire la collaboration sur le même ensemble de données avec d'autres chercheurs et la publication de l'ensemble de données.

Afin de créer la structure de données, commencez par le dossier principal du projet et triez les données brutes dans le dossier d'entrée associé (Fig. 2A).

Lors de la conversion du dossier Project en un jeu de données DataLad, les fichiers DataLad correspondants sont créés automatiquement sans modifier les fichiers et la structure. Les fichiers DataLad contiennent la version et l'historique de tous les fichiers du dossier du projet. Project1 sert de super-ensemble de données avec les dossiers raw_data et proc_data associés en tant que sous-ensembles de données avec leurs propres référentiels sur les services de référentiel GIN et GitHub, respectivement. Avec cette structure, DataLad peut enregistrer des actions telles que le traitement de raw_data à partir d'un pipeline spécifique dans le code et stocker la sortie du pipeline dans proc_data. Ces actions sont enregistrées dans les informations d'historique du super jeu de données Project1.

Dans notre cas, les données de plusieurs dossiers de protocoles d'animaux sont copiées dans le dossier du projet et les données brutes d'origine (dans l'archive) restent intactes. Ce processus peut être suivi si Datalad est déjà effectif pour tous les stockages. Dans le cas d'autres structures de données, par exemple en utilisant le serveur PACS, le transfert des données dans le dossier principal du projet serait similaire. L'idée est d'avoir toutes les données pertinentes pour le projet disponibles pour analyse et partage ultérieur. Chaque sous-dossier d'entrée est nommé en fonction de la méthodologie (par exemple, IRM, comportement, histologie, etc.) et peut contenir différents types de fichiers (tableau 2). Les autres dossiers incluent le code, les résultats et la documentation. Dans cet exemple, le code contient les outils d'analyse de données d'imagerie basés sur Atlas AIDAqc et AIDAmri16 pour le contrôle de qualité automatisé, le traitement de l'IRM multimodale16 et l'enregistrement auprès de l'Allen Mouse Brain Atlas17. Le dossier docs contient toutes les informations (métadonnées) et la documentation nécessaires pour reproduire l'ensemble de données IRM (par exemple, quel ID d'étude appartient à quel groupe expérimental, points temporels, type d'examen IRM, etc.).

Les étapes suivantes sont exécutées pour démarrer la conversion du dossier Project1 en un jeu de données DataLad (Fig. 2B). Un guide vidéo est disponible (https://gin.g-node.org/Aswendt_Lab/Example_Dataset_Kalantari_Paper/src/master/doc).

1.1 Pour commencer, ouvrez le terminal et changez le répertoire dans le dossier cible. Dans cet exemple, il s'agit de Projet1.

»cd Projet1

1.2 Une fois dans le dossier cible, exécutez la commande suivante pour créer les dossiers et fichiers spécifiques à l'ensemble de données DataLad dans le dossier Project1 (Fig. 2A).

» datalad créer–force

INFO : DataLad fournit de nombreuses commandes et chaque commande a des options différentes. Vous pouvez créer un dossier de jeu de données DataLad vide en datalad create nom_dossier. Ici, à l'étape 2, la commande create a été utilisée pour initialiser un jeu de données DataLad dans le répertoire de travail actuel, et l'option --force a permis la création d'un jeu de données dans un dossier contenant déjà des données. Pour plus d'informations sur les autres options que vous pouvez utiliser--help.

2.1 Après l'étape d'initialisation 1, passez à l'étape suivante. Notez que cette étape peut prendre un certain temps en fonction du matériel1.

(1Fait référence à des fonctionnalités telles que des lecteurs de stockage connectés en interne ou en externe, des lecteurs réseau, des types de stockage tels que des disques durs (HDD) ou des disques SSD).

» état datalad »datalad save -m "message utilisateur"

Une fois le jeu de données créé, les étapes qui modifient son contenu sont enregistrées en exécutant la commande datalad save. L'étape 2 montre la première utilisation pratique des ensembles de données DataLad : enregistrer les modifications. Dans notre cas, le dossier raw_data contient, par exemple, des données brutes IRM. Après traitement à l'aide d'AIDAmri16, les résultats sont stockés dans le dossier proc_data (Fig. 2A).

INFO : La commande d'état de datalad peut être considérée comme un outil d'inspection qui imprime l'état actuel de chaque fichier, qu'il soit suivi ou non suivi par DataLad, supprimé ou modifié. Après l'initialisation à l'étape 2.1, toutes les impressions d'état afficheraient "non suivi". Tous les fichiers nouvellement ajoutés ne seront pas suivis jusqu'à ce que datalad save soit explicitement exécuté. Une fois qu'un fichier a été enregistré et que son contenu a été modifié par la suite, l'état sera imprimé différemment. En général, le statut datalad est utilisé à des fins d'information uniquement et peut être utile pour identifier les modifications récentes (non enregistrées).

La commande datalad save, quant à elle, enregistre les nouvelles modifications dans le dossier .git. La commande save a également plusieurs options, où -m associe la sauvegarde à un message utilisateur qui peut décrire le but de la modification. Ces messages peuvent être utiles à l'utilisateur pour trouver une version particulière ou pour rappeler plus facilement les modifications apportées à l'ensemble de données. Si vous êtes intéressé par plus d'options pour une commande, utilisez l'option --help. Par exemple, datalad save --help affiche toutes les options disponibles pour la commande save.

2.2 (Facultatif) Si les modifications sont effectuées par programme (par exemple en exécutant un script personnalisé), cela peut être fait avec une commande comme celle-ci :

» datalad run -m "message utilisateur" -–input … python < code.py >

La commande run enregistre des informations sur les données d'entrée et de sortie du code exécuté (ici un script Python) et les enregistre dans les informations d'historique de l'ensemble de données. La commande datalad save est automatiquement exécutée lors de l'utilisation de datalad run, mais en plus du message fourni par l'utilisateur, un enregistrement d'exécution réexécutable est également stocké pour capturer la provenance.

Il est important de souligner que l'étape 2 est une étape répétitive (Fig. 2B), c'est-à-dire qu'elle peut être répétée pour enregistrer des changements consécutifs ou de nouveaux états. Au fil du temps, ce processus crée un journal de bord, dans lequel toutes les actions qu'un utilisateur a effectuées sur le projet au fil du temps sont enregistrées. L'accès et l'utilisation de ce journal de bord sont expliqués à l'étape suivante.

2.3 Toutes les informations enregistrées sur les modifications enregistrées sont accessibles par :

» journal git

Cela affichera toutes les modifications apportées depuis le début du contrôle de version. Eventuellement en tapant :

» git log -2

Seuls les deux derniers changements ou commits seront imprimés (Fig. 3).

Exemple de sortie de journal git d'un ensemble de données affichant des informations sur l'auteur, la date, les modifications et l'identifiant de validation correspondant, également appelé "sha".

INFO : Un commit est un instantané de l'état actuel du projet. La différence entre deux validations dans un jeu de données datalad signifie les changements qui se sont produits entre ces deux états du projet. Certaines données peuvent être produites, modifiées, déplacées ou supprimées. Il existe d'autres moyens d'accéder à l'historique tels que tig (https://jonas.github.io/tig/) ou certains avec leur propre interface utilisateur graphique (GUI) comme gitgui, gitk, etc. (https://git-scm.com/downloads/guis).

Dans ce scénario, nous utilisons la plateforme de données GIN (d'autres options sont disponibles, voir le tableau 1). Une condition préalable pour les étapes suivantes est un compte GIN opérationnel (https://gin.g-node.org/user/sign_up) avec une paire de clés ssh associée (http://handbook.datalad.org/en/latest/basics/101-139-gin.html) entre le compte GIN et le compte sur l'ordinateur local. Remarque : Cette étape peut prendre un certain temps en fonction de la vitesse du réseau.

Créez un référentiel avec un nom d'ensemble de données spécifique au projet sous le compte GIN et copiez le lien ssh spécifique au projet généré par GIN.

Exécutez la commande suivante avec vos propres informations d'identification dans le dossier Project1.

datalad siblings add–dataset.–name gin–url [email protected]:/username/dataset-name.git

INFO : les frères et sœurs datalad sont utilisés pour toutes les actions qui affectent d'autres copies de l'ensemble de données. Ici, l'option d'ajout est utilisée pour lier l'ensemble de données à un nouvel emplacement où les frères et sœurs ou la copie de l'ensemble de données doivent aller. Ensuite, --dataset définit le chemin de l'ensemble de données en cours de configuration, ici il est défini par le ".", signifiant l'emplacement du dossier actuel. --name est le nom du frère qui peut être défini par l'utilisateur. Cependant, il est logique de le nommer en fonction du service de référentiel en ligne pour en faciliter l'utilisation et éviter toute confusion. Ici, nous utilisons du gin. L'option --url est pour le lien disponible sur la page du projet acquis à l'étape 3.1, qui est généré explicitement pour le projet qui y est créé. Pour certains référentiels, comme GIN, des commandes dédiées sont fournies pour automatiser la création et l'enregistrement de frères et sœurs distants en une seule étape. Pour GIN, cette commande est create-sibling-gin.

Une fois que le référentiel distant est configuré et qu'une connexion entre les deux est établie, le projet peut être téléchargé (poussé) sur GIN.

4.1. Commencez par taper la commande suivante dans le terminal :

datalad push --to gin

Tout comme l'étape 2, cette étape peut être répétitive (Fig. 2B). Au fur et à mesure qu'un jeu de données et ses informations d'historique progressent, de nouveaux commits sont ajoutés et les mises à jour peuvent être transmises au référentiel distant. Ceci est fait efficacement, ce qui signifie que seuls les fichiers modifiés sont transférés. La gestion des versions rend l'état de l'ensemble de données téléchargé unique. De plus, GIN est entièrement compatible avec git et git-annex, et son interface web peut, par exemple, afficher l'historique des changements et les messages de commit associés.

Selon la taille du projet et la qualité de la connexion Internet, l'exécution de cette étape peut prendre un certain temps. Par conséquent, il peut être judicieux de ne pas essayer de pousser toutes les données en un seul lot, c'est-à-dire de les diviser et de faire le processus de push en plusieurs lots. Ceci est possible en ajoutant le chemin d'une petite partie spécifiée du projet à la commande :

4.2 (Facultatif) datalad push --to gin

Toute personne intéressée par le projet peut désormais accéder et télécharger non seulement les données mais aussi l'historique du projet tel qu'il a évolué dans le temps, grâce à ce qu'on appelle le "clonage". Du point de vue d'un tiers, la première étape consiste à visiter le référentiel respectif sur le site Web de GIN, où se trouvent respectivement le lien SSH ou le lien HTTPS, selon que l'ensemble de données doit être modifié ou uniquement téléchargé.

INFO : Sur la page des projets d'un compte GIN, il y a trois liens pour accéder au référentiel, SSH, HTTPS et GIN. En termes simples, SSH et HTTPS sont différents moyens de communication entre le système d'exploitation de l'utilisateur et le service de référentiel en ligne. La principale différence dans notre cas d'utilisation est qu'une connexion SSH est requise si nous voulons télécharger ou "pousser" les données vers le référentiel distant. Pour télécharger ou "cloner" les données, une connexion HTTPS suffit. Comme brièvement mentionné à l'étape 3, la mise en place d'un lien SSH nécessite des étapes supplémentaires, mais les liens HTTPS peuvent être utilisés sans autre souci.

Copiez le lien SSH/HTTPS de la page Web du projet GIN.

Ouvrez le terminal et accédez à un dossier où le contenu du projet doit être situé et exécutez la commande suivante, en remplaçant l'exemple d'URL par le lien copié.

Pour les liens SSH :

clone de l'ensemble de données [email protected] :/username/dataset-name.git

Pour les liens HTTPS :

clone de l'ensemble de données https://gin.g-node.org/username/dataset-name

Si le lien HTTPS est choisi, notez que le lien n'a pas d'extension .git.

INFO : Une fonctionnalité utile de la commande datalad clone est qu'elle ne télécharge pas l'intégralité de l'ensemble de données en une seule fois. Il télécharge uniquement la structure des dossiers, les petits fichiers et les noms de fichiers des fichiers volumineux, c'est-à-dire les fichiers gérés par git-annex. La commande datalad get peut ensuite être utilisée pour télécharger de manière sélective le contenu de fichiers volumineux afin que l'intégralité du contenu devienne disponible localement. Cela peut être utile de deux points de vue : premièrement, si l'ensemble de données est très volumineux et que seules certaines parties présentent un intérêt, seules ces parties peuvent être téléchargées de manière sélective. Deuxièmement, si seuls la structure du projet et le nom du fichier sont intéressants, dans ce cas, datalad get ne serait pas appelé du tout.

Si vous souhaitez télécharger l'intégralité du projet, continuez avec la commande suivante dans le dossier du jeu de données DataLad créé après la dernière étape.

Tapez ce qui suit :

chèvre informatisée

La commande peut être limitée à un chemin spécifique (répertoire ou fichier) pour récupérer sélectivement le contenu.

Comme présenté dans la section précédente, l'imbrication des ensembles de données peut être très utile du point de vue d'un tiers. Dans notre exemple, l'ensemble de données de niveau supérieur Project1 contient plusieurs ensembles de données pour les dossiers "raw_data" et différents pipelines de code (Fig. 2A). L'intention de cette configuration était, premièrement, de rendre les données brutes et les codes disponibles séparément pour des tiers sans avoir à télécharger toutes les structures de projet périphériques, et deuxièmement, de préserver la possibilité de mise à jour des différents pipelines dans le dossier de code, c'est-à-dire que les pipelines sont mis à jour au fil du temps, le clonage de l'ensemble de données de niveau supérieur lui associe automatiquement les pipelines les plus à jour.

Étant donné que notre ensemble de données est destiné à être publié et réutilisé, il est essentiel de l'annoter avec des informations pertinentes. Lors de la création, les référentiels GIN sont par défaut privés, c'est-à-dire à accès restreint, mais peuvent être définis comme publics via une case à cocher dans le menu des paramètres. Les ensembles de données publics sur GIN peuvent recevoir un identifiant d'objet numérique persistant (DOI) unique, ce qui les rend citables. À côté des métadonnées de publication, nous incluons de la documentation sur l'ensemble de données, comme les groupes expérimentaux et les points temporels, ainsi que des informations spécifiques à la modalité, par exemple, sur les séquences IRM, qui sont extraites de notre base de données relationnelle.

Ici, nous fournissons un guide étape par étape pour les utilisateurs non experts pour mettre en œuvre un flux de travail de données FAIR applicable aux données sur les petits animaux. Dans ce flux de travail, nous utilisons un schéma de sauvegarde local simple mais efficace et une structure de données standardisée en combinaison avec GIN comme solution pour la disponibilité des données publiques. DataLad a été utilisé comme outil de gestion des données pour fournir une base pour une collaboration transparente et fiable entre les chercheurs, avec l'intention d'encapsuler tous les éléments d'un projet, tels que les données d'entrée, les codes et les résultats, ainsi que des informations sur la façon dont ils sont connectés18.

Notre motivation pour mettre en œuvre ce flux de travail était d'assurer la préservation des données, une collaboration efficace, le partage des données et une reproductibilité accrue. Ces besoins pratiques liés à la gestion des données de recherche sont répandus dans le domaine et jusqu'à présent, seules des solutions uniques ont été proposées (Kuhn Cuellar et al.19). Une enquête récente sur la gestion et le partage des données en neuroimagerie (humaine) montre les défis importants associés à la gestion et au partage appropriés des données de neuroimagerie, les plus grandes limites étant le temps et le manque de meilleures pratiques20. Les chercheurs se considèrent moins matures dans le partage des données que dans les pratiques d'analyse et de collecte des données. Pour surmonter cette limitation, nous nous sommes concentrés sur un flux de travail facile à mettre en œuvre qui utilise uniquement des logiciels librement disponibles et ne nécessite aucune connaissance préalable particulière.

Un identificateur de sujet et une structure de fichiers/dossiers normalisés (voir la section Méthodes) sont à la base d'une gestion efficace des données de recherche. L'identifiant créé pour chaque animal et la dénomination standardisée des fichiers permettent de rendre les données traçables même en l'absence d'autres métadonnées. Dans notre cas, le protocole animal détermine quelle méthode peut être appliquée et à quelle fréquence. Afin d'assurer une transparence totale selon les lignes directrices des bonnes pratiques scientifiques utilisant des animaux21 et de simplifier la documentation pour les audits par les autorités locales, nous collectons toutes les données expérimentales dans une base de données relationnelle électronique13 et stockons les données brutes dans la structure prédéfinie par le protocole animalier. Ce répertoire de données brutes sert plus tard d'archive, qui reste intacte. Pour le traitement lié au projet/à la publication, toutes les données brutes - qui peuvent provenir de différentes licences animales - sont copiées dans le dossier d'entrée pour laisser les données brutes intactes pour des raisons de sécurité tout en offrant une flexibilité maximale pour travailler avec les données. La structure YODA contient non seulement le dossier d'entrée, mais également la sortie, les documents et le code. Ici, notre approche diffère des structures de dossiers suggérées précédemment avec une hiérarchie à 3 niveaux, c'est-à-dire le niveau du laboratoire (organisation détenant plusieurs projets), le niveau des projets et le niveau expérimental subséquent22. Pour publication ou collaboration, toute la structure YODA est téléchargée sur le service d'hébergement de données en ligne, dans notre cas GIN. Surtout, DataLad est flexible quant à l'endroit où les données sont stockées. Si les utilisateurs disposent de leurs données complètes dans des solutions de stockage alternatives telles que sur le serveur XNAT ou PACS pour les données radiologiques23 ou OMERO24 comme pour les données de microscopie, il existe des extensions DataLad dédiées (https://docs.datalad.org/), ou des extensions supplémentaires peuvent être développées avec un minimum d'effort pour prendre en charge des services supplémentaires. Notre flux de travail n'exclut pas d'autres services d'hébergement de logiciels et de données, par exemple, CKAN (https://ckan.org), Harvard Dataverse (https://dataverse.harvard.edu) et Barcelonaβeta Brain25, avec leur propre stratégie pour gérer des données de recherche multimodales complexes. En revanche, il fournit un RDM polyvalent et interopérable, avec la flexibilité et la simplicité nécessaires pour s'adapter aux paradigmes expérimentaux locaux et aux infrastructures informatiques existantes des petits laboratoires aux grands consortiums multisites12,18.

Les métadonnées sont un ingrédient très important dans les pratiques de recherche actuelles, en particulier lorsqu'il s'agit d'une collaboration transparente entre les chercheurs selon FAIR et les directives spécifiques à la communauté de neuroimagerie5,26. Pour l'IRM enregistrée au format de fichier DICOM ou NiFTI, plusieurs tentatives ont été faites pour rendre le fichier d'en-tête plus riche en métadonnées, la norme BIDS étant l'option la plus avancée et la plus largement utilisée pour structurer les fichiers selon les séquences IRM et inclure des métadonnées normalisées15. Notre flux de travail est entièrement compatible avec le format BIDS (voir exemple dans https://doi.org/10.12751/g-node.3yl5qi27) mais nous avons décidé de ne faire de BIDS aucune obligation d'utiliser le flux de travail comme c'est par exemple le cas pour la plateforme de données OpenNeuro, afin de maximiser la flexibilité pour les chercheurs travaillant avec différents formats de fichiers. Bien que nous soutenions pleinement les efforts visant à maximiser la normalisation au niveau des métadonnées, dans notre propre expérience de travail avec des données multimodales (issues de l'IRM, du comportement, de l'électrophysiologie et de la microscopie), il est nécessaire, comme étape intermédiaire, de prioriser l'existence d'autant de métadonnées que possible dans des fichiers lisibles par machine (txt, csv, json), qui ne doivent pas nécessairement être la structure communautaire actuelle. Nous recommandons donc d'utiliser le workflow en combinaison avec une base de données relationnelle telle que notre propre développement13, REDcap28, ou autres, qui permet la génération de tels fichiers lisibles par machine. Avec une expertise de programmation de base, il sera facile pour les utilisateurs tiers de rechercher et de filtrer les données partagées en fonction de ces fichiers.

Si le traitement nécessite plusieurs étapes ou outils de traitement, nous suggérons en outre d'inclure un guide étape par étape plus détaillé (par exemple https://github.com/aswendtlab/ Project_C3a_peri-infarct), qui va au-delà des exigences de déclaration des métadonnées dans les normes existantes, c'est-à-dire BIDS. De tels guides étape par étape peuvent être nécessaires pour la réplication des données dans le cas où les routines automatisées, c'est-à-dire l'exécution de datalad, ne peuvent pas être utilisées.

Il convient de mentionner que DataLad nécessite un investissement initial en temps et en ressources, mais les gains d'efficacité, de qualité et de fiabilité sur toute la ligne rendent ces investissements intéressants d'après notre expérience.

L'incapacité à reproduire les résultats d'une étude particulière n'est pas propre à la neuroimagerie chez les petits animaux. Cela est principalement dû au manque de transparence et de détails méthodologiques, comme un protocole étape par étape dans les articles scientifiques. La reproduction d'une étude nécessite l'accès à une variété d'autres documents, tels que les paramètres de numérisation, les procédures de pré- et post-traitement et les caractéristiques individuelles des sujets. À cette fin, en plus du flux de travail présenté ici, nous adoptons une approche pragmatique, c'est-à-dire que nous rendons publiques les données brutes et traitées sur GIN et spécifions les détails du post-traitement sur une page GitHub spécifique au projet.

La conversion des dossiers de données en un ensemble de données DataLad offre non seulement les avantages décrits ci-dessus, c'est-à-dire le suivi des modifications, le partage facile des ensembles de données en les publiant aux frères et sœurs et la gestion efficace des fichiers volumineux en réduisant les besoins de transport et de stockage. Comme indiqué précédemment, DataLad ouvre vos ensembles de données pour une utilisation beaucoup plus large et permet une réutilisation facile des ensembles de données publiés dans d'autres ensembles de données DataLad via le mécanisme de sous-ensemble de données DataLad. DataLad propose également un suivi de provenance (annotation ré-exécutable des modifications) et une gestion des métadonnées. Avec la commande run et la commande rerun de DataLad, qui permettent une "exécution suivie" des opérations sur un ensemble de données, DataLad permet une recherche réellement reproductible29.

Le partage de données ouvertes intégré dans un protocole RDM approprié ne résoudra pas les lacunes dans la conception de l'étude ou la stratégie d'analyse, mais surtout, il permet à d'autres chercheurs d'identifier les lacunes potentielles et de les résoudre dans les travaux futurs, ce qui empêche la répétition des erreurs20. Nos efforts servent de modèle pour d'autres domaines de l'imagerie préclinique ayant un impact élevé sur la pratique de la recherche dans la communauté de la neuroimagerie animale et au-delà. Conformément au principe des 3 R visant à réduire le nombre d'animaux, ce flux de travail permet à la communauté de collecter des ensembles de données acquis et stockés de manière hétérogène pour favoriser les expériences de simulation de cerveau de souris et mettre en œuvre une approche de modélisation inter-espèces. De plus, l'étroite collaboration avec les efforts de normalisation des données et des métadonnées, le suivi de la provenance et la gestion du flux de travail, l'intégration dans un écosystème de plate-forme de données de recherche interopérable et la spécification du modèle informatique à l'aide de moyens normalisés contribueront à renforcer l'interaction de tous les participants et amélioreront l'écart translationnel actuel entre les chercheurs fondamentaux et cliniques.

Dans cette section, nous décrivons les détails du matériel nécessaire pour reproduire le flux de travail.

Le flux de travail décrit ici (Fig. 1A) a été développé à l'aide d'un Mac Pro (fin 2013) comme poste de travail principal exécuté en mode serveur. De cette façon, plusieurs utilisateurs peuvent accéder au Mac via l'écran intégré ou le partage de fichiers (protocoles VNC/SMB) et récupérer des données et exécuter des programmes en parallèle. Une méthode de travail similaire est possible avec des postes de travail exécutant des installations Linux ou Windows 10/11 via des connexions de bureau à distance. La stratégie de stockage des données a été élaborée selon les meilleures pratiques30, y compris un plan de sauvegarde, différents emplacements de sauvegarde, des contrôles de validité des sauvegardes et la possibilité d'étendre le stockage des données. Le stockage local principal - directement connecté au poste de travail - est un disque LaCie Thunderbolt de 20 To fonctionnant en mode Raid-5 (un disque dur peut être endommagé alors que le système de fichiers reste intact). Toutes les données sont d'abord copiées manuellement dans ce stockage local par l'expérimentateur responsable. Le chemin vers les données brutes est documenté dans la base de données électronique13. Des sauvegardes automatisées et incrémentielles sont effectuées à l'aide de Carbon Copy Cloner (Bombich Software, Inc., États-Unis) chaque semaine du stockage local au stockage réseau (géré par le service informatique de l'hôpital universitaire).

Le flux de travail (Fig. 1A) s'appuie sur des logiciels gratuits et open source : Python (https://www.python.org/, RRID:SCR_008394), GIN (https://gin.g-node.org, RRID:SCR_015864) et DataLad (https://www.datalad.org, RRID:SCR_003931). D'autres options d'hébergement de données existent (tableau 1), qui peuvent être facilement intégrées dans le flux de travail fourni. Des guides d'installation représentatifs sont fournis dans le matériel supplémentaire. Pour obtenir les instructions d'installation les plus récentes, consultez les sites Web connexes.

DataLad est utilisé pour le contrôle de version distribué : création, synchronisation et suivi des copies d'ensembles de données liés (appelées frères et sœurs). Un jeu de données DataLad peut avoir un ou plusieurs frères et sœurs, stockés soit localement (lecteurs de sauvegarde, serveurs locaux, différents postes de travail) soit en ligne (par exemple GIN). Les modifications apportées à une copie d'un jeu de données peuvent être synchronisées avec d'autres copies, et la synchronisation est toujours explicite (il est facile de savoir si les versions divergent ou non). La disponibilité du contenu des fichiers est suivie et le contenu disponible à distance peut être récupéré à la demande pour économiser de l'espace localement. Cela signifie également que l'échange de fichiers, la sauvegarde et la publication sont tous effectués via la même interface logicielle, même si les emplacements sont différents.

Référentiel : dossier avec des fichiers et des sous-dossiers en tant qu'unité structurelle pour la gestion du code ou des données ; peut être n'importe quel ensemble ou combinaison de fichiers avec différentes structures de dossiers et différents types de données, parfois il peut même être vide et ne contenir aucun fichier.

Jeu de données DataLad : référentiel sur lequel DataLad est exécuté et le contrôle de version est en cours d'exécution.

Initialisation d'un jeu de données DataLad : pour créer un jeu de données vide soumis au contrôle de version de DataLad. Si des fichiers sont ajoutés à cet ensemble de données après cela, ils seront suivis par DataLad.

Initialisation de DataLad dans un référentiel déjà existant : la transition d'un ensemble de données dans une structure de fichiers/dossiers vers un ensemble de données géré par DataLad.

Suivi/contrôle de version : si un fichier change parce qu'il a été remplacé ou modifié par un utilisateur, DataLad enregistre ces modifications au fil du temps en conséquence.

Un frère/clone DataLad : peut être défini comme une copie de l'ensemble de données. Cela ne signifie pas nécessairement qu'il s'agit d'une copie exacte ou que toutes les données sont entièrement disponibles. Un espace réservé est un fichier portant le même nom que le fichier d'origine mais sans son contenu.

Git : un système de contrôle de version gratuit et open-source utilisé pour gérer efficacement les petits et très grands projets

Git-annex : git-annex est un système distribué de synchronisation de fichiers qui vise à résoudre le problème du partage et de la synchronisation de collections de fichiers volumineux.

Imbrication des ensembles de données : les ensembles de données peuvent contenir d'autres ensembles de données (sous-ensemble de données), qui peuvent à leur tour contenir des sous-ensembles de données, et ainsi de suite. Chaque ensemble de données qui contient un autre sous-ensemble de données peut être appelé un super ensemble de données. Le jeu de données de niveau supérieur est le super jeu de données qui a le niveau le plus élevé dans la hiérarchie des jeux de données.

Les fournisseurs d'hébergement de données en ligne offrent aux chercheurs l'infrastructure nécessaire pour télécharger leurs données et les partager avec d'autres. Ces services diffèrent par leur objectif principal : stockage en nuage (stockage de fichiers et partage limité, pas d'indexation des métadonnées), services d'hébergement de données simples (hébergement à long terme, indexation automatisée des métadonnées) et plateformes de données de recherche (hébergement à long terme, partage, collaboration et gestion des données) (tableau 1).

Les services et les plateformes qui fournissent des identifiants persistants (DOI) sont essentiels pour adopter des pratiques de FAIR et de science ouverte conformes aux aspects de reproductibilité et de réutilisation des données. Cependant, seule une minorité d'études partagent leurs données, ce qui pourrait changer avec la demande croissante des éditeurs et des institutions de financement. Nous avons choisi la plateforme de données de recherche GIN (https://gin.g-node.org/G-Node/Info/wiki/), soutenue par le gouvernement allemand (BMBF Grant 01GQ1302) et LMU Munich, et développée en open source par le German Neuroinformatics Node (G-Node). GIN est une ressource enregistrée (https://doi.org/10.17616/R3SX9N) et remplit les critères de référentiels et de passerelles scientifiques approuvés par l'INCF31.

Pour rendre un ensemble de données éligible au service GIN-DOI, des métadonnées spécifiques, y compris un fichier spécifique au GIN appelé "datacite.yml", doivent être créées, qui contiennent des informations sur les auteurs, le titre, la description, les mots-clés et la licence selon le schéma DataCite (https://schema.datacite.org/) doivent être fournis. Sur GIN, ces métadonnées doivent se trouver dans un fichier appelé "datacite.yml" à la racine du référentiel. Une licence doit être choisie (par exemple, https://creativecommons.org/choose/) pour spécifier l'attribution, les dérivés et les exigences de partage, avec le texte de la licence à inclure dans un fichier texte appelé LICENCE. Le service GIN DOI assure un accès permanent au jeu de données à l'aide d'un identifiant persistant (https://gin.g-node.org/G-Node/Info/wiki/DOI).

INFO : Le choix d'un service d'hébergement de données doit être fait avec soin, car divers facteurs jouent un rôle, par exemple la disponibilité, le cryptage de l'anonymat, le groupe cible général d'utilisateurs externes ou internes, l'étendue des données, la fréquence d'utilisation, etc. Il est important de noter que DataLad fonctionnera avec tous les services répertoriés. Le contrôle de version DataLad est appliqué quel que soit l'endroit où les données résident, c'est-à-dire localement ou dans un magasin de données en ligne. Néanmoins, une sauvegarde adéquate est nécessaire afin de ne pas perdre l'accès aux données, aux enregistrements DataLad et à l'historique associé. Par conséquent, il est courant de stocker une réplique de l'ensemble de données et de son historique sous contrôle de version ailleurs avec un espace de stockage suffisant.

Nous travaillons avec deux structures de données, l'une dans laquelle les données (brutes) sont stockées selon les expériences décrites dans le protocole animal approuvé (Fig. 2C), et la seconde dans laquelle les données spécifiques au projet sont stockées (Fig. 2A). Tout d'abord, nous collectons toutes les données brutes dans une structure de dossiers uniforme en fonction des principaux projets et sous-projets de nos licences d'expérimentation animale et tel qu'approuvé par les autorités locales. ) et un code spécifique au matériel d'IRM (Bruker) (c'est-à-dire le numéro d'étude, le numéro de reconstruction, la date au format AAAA-MM-JJ et l'heure au format hh-mm-ss). Nous vous recommandons d'enregistrer les données brutes dans la structure de dossiers liés au protocole animal, ce qui simplifie la documentation pour les autorités. Dans un deuxième temps, avant d'initialiser DataLad, les données brutes sont copiées depuis un ou plusieurs dossiers de données brutes dans la structure YODA pour chaque projet/publication. La structure YODA regroupe les données d'entrée, de sortie, de documentation et de code dans une structure spécifique au projet (Fig. 2A).

Afin de garder une trace du grand nombre d'expériences, nous avons créé des identifiants uniques pour chaque souris/scan (Fig. 1). L'identifiant (Study ID) combine des éléments du protocole animal, du (sous)projet, de la cage et du nombre d'animaux par cage. Par exemple, SPs1c4m1 se rapporte au projet SPasticity, sous-projet 1, cage 4, souris 1. En principe, d'autres informations, telles que le sexe et le génotype peuvent être ajoutées selon la nomenclature commune, par exemple, SPs1c4m1mRbp4, concernant une souris mâle (m) Tg(Rbp4-cre)KL100Gsat (short Rbp4). Fait important pour les études translationnelles, les identifiants d'étude ne doivent pas être modifiés pour révéler le groupe expérimental à l'utilisateur, c'est-à-dire que l'utilisateur reste aveuglé pendant la collecte et l'analyse des données. Dans tous les cas, les principales fonctions de l'identifiant doivent être préservées, c'est-à-dire anonymiser le sujet (en termes de détails expérimentaux) et rester identifiable par des termes de recherche/tri de type mot-clé.

INFO : Les identifiants font référence au protocole animal et sont stockés dans une structure de dossiers fixe similaire à celle utilisée dans le format BIDS. Notre convention de fichier pour nommer et structurer les fichiers a été spécifiée avant que BIDS ne devienne populaire pour les données IRM animales. Par conséquent, nous avons des ensembles de données avec des traits de soulignement et des traits d'union comme séparateurs, par exemple TP_T1_4_1. Si les utilisateurs prévoient d'utiliser le format BIDS, le flux de travail peut toujours être appliqué car DataLad est compatible BIDS. Cependant, étant donné que BIDS est sensible à des caractères spécifiques, par exemple des traits d'union et des traits de soulignement, les identifiants ne doivent contenir que des chiffres et des lettres. Une alternative possible pour SP_T1_4_1 serait SPsT1c4m1, qui remplace les traits de soulignement par les lettres initiales du sous-projet (s), de la cage (c) et de la souris (m). Remarque : si des caractères spéciaux étaient inclus dans les ID d'étude dans le passé, rendre les fichiers compatibles BIDS nécessite beaucoup plus d'attention, par exemple écrire les informations correctes également dans l'en-tête NIfTy et dans tous les fichiers de métadonnées associés.

Dans la mesure du possible, les éléments des noms de fichiers sont soit générés automatiquement, soit attribués selon un schéma normalisé, qui comprend l'ID d'étude, le test/l'expérience et le point temporel (le cas échéant). De cette façon, le nom du fichier sera unique et contiendra déjà des métadonnées essentielles. Par exemple, SPs1c4m1CytD4 concernerait le test du cylindre (Cyt), un test de comportement de la souris, qui a été effectué le jour 4 (J4) avec l'ID d'étude SPs1c4m1. Les chemins de fichiers/dossiers sont stockés dans la base de données électronique13 avec d'importantes informations de métadonnées sur l'expérience. Dans le cas de l'IRM, cela inclut le protocole d'anesthésie (y compris le moment et le dosage exacts), les détails de la configuration (par exemple bobine, gradient) et la liste des examens IRM.

Selon les règles de base du stockage des données30, les formats de données ouverts sont utilisés chaque fois que possible. Nos ensembles de données contiennent un large éventail de fichiers, allant des petits fichiers texte aux fichiers IRM plus volumineux et aux enregistrements vidéo. Il n'y a aucune restriction générale dans le format de fichier pour être compatible avec le flux de travail (tableau 2).

INFO : Pour tout format de fichier texte (par exemple, txt, csv, json), DataLad suit les modifications apportées au fichier ligne par ligne (holistique). Par conséquent, chaque ligne, par exemple dans le code Python, peut être attribuée à un commit (et à un auteur) qui l'a modifiée en dernier (à l'aide de la fonctionnalité Git). Pour tous les autres formats de données, DataLad suit la différence fichier par fichier à l'aide de sommes de contrôle de fichier, c'est-à-dire que des informations sur le moment et la personne qui a modifié le document sont stockées, mais pas sur la partie du fichier modifiée. En termes de science ouverte et d'utilisabilité à long terme, il est recommandé d'utiliser des types de fichiers ligne par ligne (lisibles par machine, par exemple csv) dans la mesure du possible.

Nous recommandons d'utiliser le jeu de données de test27 (https://doi.org/10.12751/g-node.3yl5qi). Il contient une structure yoda de base (Fig. 2A) et est suffisamment petit pour permettre un traitement rapide.

DataLad et GIN sont disponibles gratuitement. Le manuscrit contient tout le code pour reproduire le flux de travail.

Nichols, TE et al. Meilleures pratiques en matière d'analyse et de partage de données en neuroimagerie à l'aide de l'IRM. Nature Neuroscience 20(3), 299–303 (2017).

Article CAS PubMed PubMed Central Google Scholar

Niso, G. et al. Neuroimagerie ouverte et reproductible : du début de l'étude à la publication. https://doi.org/10.31219/osf.io/pu5vb (2022).

Markiewicz, CJ et al. La ressource OpenNeuro pour le partage de données en neurosciences. eLife 10 (octobre). https://doi.org/10.7554/eLife.71774 (2021).

Organisation européenne pour la recherche nucléaire et OpenAIRE. Zénodo. CERN. https://doi.org/10.25495/7GXK-RD71 (2013).

Wilkinson, MD et al. Les principes directeurs FAIR pour la gestion et l'intendance des données scientifiques. Données scientifiques 3 (mars), 160018 (2016).

Article PubMed PubMed Central Google Scholar

Mandino, F. et al. Imagerie par résonance magnétique fonctionnelle animale : tendances et voie vers la normalisation. Frontières en neuroinformatique 13, 78 (2019).

Article PubMed Google Scholar

Gabelica, M., Bojčić, R. & Puljak, L. De nombreux chercheurs n'étaient pas conformes à leur déclaration de partage de données publiée : une étude à méthodes mixtes. Journal of Clinical Epidemiology 150 (octobre), 33–41 (2022).

Article PubMed Google Scholar

Les principes de la technique expérimentale humaine. Le Journal médical d'Australie 1(13), 500–500 (1960).

Begley, CG & Ioannidis, JPA Reproductibilité en science : améliorer la norme pour la recherche fondamentale et préclinique. Recherche sur la circulation 116(1), 116–26 (2015).

Article CAS PubMed Google Scholar

Poldrack, RA et al. Balayage De L'horizon: Vers Une Recherche En Neuroimagerie Transparente Et Reproductible Nature Reviews. Neurosciences 18(2), 115–26. (2017).

Article CAS PubMed PubMed Central Google Scholar

Couture, JL, Blake, RE, McDonald, G. & Ward, CL Une exigence de publication de données imposée par le bailleur de fonds a rarement inspiré le partage de données. PloS One 13(7), e0199789 (2018).

Article PubMed PubMed Central Google Scholar

Hanke, M. et al. À la défense de la gestion décentralisée des données de recherche. Neuroforum 0 (0). https://doi.org/10.1515/nf-2020-0037 (2021).

Pallast, N., Wieters, F., Nill, M., Fink, GR & Aswendt, M. 2018. Base de données relationnelle basée sur le cloud pour les données animales multimodales. Base de données : The Journal of Biological Databases and Curation https://doi.org/10.1093/database/bay124 (janvier 2018).

Halchenko, Y. et al. DataLad : système distribué pour la gestion conjointe du code, des données et de leur relation. Journal of Open Source Software 6(63), 3262 (2021).

Annonces d'article Google Scholar

Gorgolewski, KJ et al. La structure de données d'imagerie cérébrale, un format pour organiser et décrire les résultats des expériences de neuroimagerie. Données scientifiques 3 (juin), 160044 (2016).

Article PubMed PubMed Central Google Scholar

Pallast, N. et al. Pipeline De Traitement Pour L'analyse De Données D'imagerie Basée Sur L'atlas De L'IRM Structurelle Et Fonctionnelle Du Cerveau De Souris (AIDAmri). Frontières en neuroinformatique 13 (juin), 42 (2019).

Article PubMed PubMed Central Google Scholar

Wang, Q. et al. Le cadre de coordonnées communes du cerveau de la souris Allen : un atlas de référence 3D. Cellule 181(4), 936–53.e20 (2020).

Article CAS PubMed PubMed Central Google Scholar

Wachtler, T. et al. NFDI-Neuro : Construire une communauté pour la gestion des données de recherche en neurosciences en Allemagne. Neuroforum 0 (0). https://doi.org/10.1515/nf-2020-0036 (2021).

Kuhn, L. et al. Une infrastructure de gestion de données pour l'intégration de données d'imagerie et d'omiques dans les sciences de la vie. BMC Bioinformatique 23(1), 61 (2022).

Article Google Scholar

Borghi, JA & Van Gulick, AE Gestion et partage des données en neuroimagerie : pratiques et perceptions des chercheurs en IRM. PloS One 13(7), e0200562 (2018).

Article PubMed PubMed Central Google Scholar

Percie du Sert, N. et al. Les lignes directrices ARRIVE 2.0 : Lignes directrices mises à jour pour la déclaration de la recherche animale. Journal du flux sanguin cérébral et du métabolisme : Journal officiel de la Société internationale du flux sanguin cérébral et du métabolisme 40 (9), 1769–77. (2020).

Article PubMed Google Scholar

Colomb, J., Arendt, T. & Sehara, K. L'équipe Gin-Tonic. Vers une structure standardisée des dossiers de recherche. https://doi.org/10.25815/WCY6-M233 (2021).

Article Google Scholar

Marcus, DS et al. La boîte à outils d'archivage de neuroimagerie extensible : une plate-forme informatique pour la gestion, l'exploration et le partage de données de neuroimagerie. Neuroinformatique 5(1), 11–34 (2007).

Article PubMed Google Scholar

Swedlow, JR 2007. L'environnement de microscopie ouvert : un projet collaboratif de modélisation de données et de développement de logiciels pour l'informatique d'images biologiques. Dans Imaging Cellular and Molecular Biological Functions, 71–92. Berlin, Heidelberg : Springer Berlin Heidelberg.

Huguet, J. et al. Gestion et contrôle de la qualité de grands ensembles de données de neuroimagerie : développements du Barcelonaβeta Brain Research Center. Frontiers in Neuroscience 15 (avril), 633438 (2021).

Article PubMed PubMed Central Google Scholar

Poline, JB et al. Partage de données dans la recherche en neuroimagerie. Frontières en neuroinformatique 6 (avril), 9 (2012).

PubMed PubMed Central Google Scholar

Aswendt, M. & Kalantari, A. Un ensemble de données DataLad pour une structure exemplaire d'un référentiel de données animales multimodal, G-Node, https://doi.org/10.12751/g-node.3yl5qi (2023).

Harris, PA et al. Capture électronique de données de recherche (REDCap) - une méthodologie et un processus de flux de travail axés sur les métadonnées pour fournir un soutien informatique à la recherche translationnelle. Tourillon d'informatique biomédicale 42(2), 377–81 (2009).

Article PubMed Google Scholar

Wagner, AS et al. FAIRly Big : Un cadre pour le traitement reproductible par calcul de données à grande échelle. Données scientifiques 9(1), 80 (2022).

Article PubMed PubMed Central Google Scholar

Hart, EM et al. Dix règles simples pour le stockage de données numériques. PLoS Computational Biology 12(10), e1005097 (2016).

Article PubMed PubMed Central Google Scholar

Sandstrom, M. et al. Recommandations pour les référentiels et les passerelles scientifiques du point de vue des neurosciences. Données scientifiques 9(1), 212 (2022).

Article PubMed PubMed Central Google Scholar

Télécharger les références

Ce travail a été financé par la Fondation Friebe (T0498/28960/16) et la Deutsche Forschungsgemeinschaft (DFG, Fondation allemande pour la recherche) - ID de projet 431549029 - SFB 1451. Nous reconnaissons le soutien de la charge de traitement d'article de la DFG (Fondation allemande pour la recherche, 491454339).

Financement Open Access activé et organisé par Projekt DEAL.

Université de Cologne, Faculté de médecine et Hôpital universitaire de Cologne, Département de neurologie, Cologne, Allemagne

Aref Kalantari et Markus Aswendt

Laboratoire de psychoinformatique, Institut des neurosciences et de la médecine, du cerveau et du comportement (INM-7), Centre de recherche Jülich, Jülich, Allemagne

Michal Szczepanik, Stephan Heunis, Christian Mönch & Michael Hanke

Institut des neurosciences systémiques, Faculté de médecine, Université Heinrich Heine, Düsseldorf, Allemagne

Michel Hanke

Faculté de biologie, Université Ludwig-Maximilians de Munich, Planegg-Martinsried, Munich, Allemagne

Thomas Wachtler

Neurosciences cognitives, Institut des neurosciences et de la médecine (INM-3), Centre de recherche Jülich, Jülich, Allemagne

Markus Aswendt

Vous pouvez également rechercher cet auteur dans PubMed Google Scholar

Vous pouvez également rechercher cet auteur dans PubMed Google Scholar

Vous pouvez également rechercher cet auteur dans PubMed Google Scholar

Vous pouvez également rechercher cet auteur dans PubMed Google Scholar

Vous pouvez également rechercher cet auteur dans PubMed Google Scholar

Vous pouvez également rechercher cet auteur dans PubMed Google Scholar

Vous pouvez également rechercher cet auteur dans PubMed Google Scholar

Conceptualisation : AK, MA, MS, Conservation des données : AK, Analyse formelle : AK, MA, Acquisition de financement : MA, MH, Enquête : AK, MA, Méthodologie : AK, MS, TW, MH, MA, Administration de projet : MA, Ressources : MA, Logiciel : AK, MA, Supervision : MA, MH, Visualisation : MA, AK, Rédaction – version originale : MA, AK, MS, SH, TW, Rédaction – révision et édition : MA, AK, CM, SH, MH , TW,Tous les auteurs ont lu, édité et approuvé le manuscrit final.

Correspondance à Markus Aswendt.

MS, SH, CM et MH sont les développeurs du logiciel libre et open source DataLad. TW est impliqué dans le développement du logiciel libre et open source GIN et dans la fourniture de la plate-forme GIN. Les autres auteurs ne signalent aucun intérêt concurrent.

Note de l'éditeur Springer Nature reste neutre en ce qui concerne les revendications juridictionnelles dans les cartes publiées et les affiliations institutionnelles.

Libre accès Cet article est sous licence Creative Commons Attribution 4.0 International License, qui permet l'utilisation, le partage, l'adaptation, la distribution et la reproduction sur n'importe quel support ou format, tant que vous donnez le crédit approprié à l'auteur ou aux auteurs originaux et à la source, fournissez un lien vers la licence Creative Commons et indiquez si des modifications ont été apportées. Les images ou tout autre matériel tiers dans cet article sont inclus dans la licence Creative Commons de l'article, sauf indication contraire dans une ligne de crédit au matériel. Si le matériel n'est pas inclus dans la licence Creative Commons de l'article et que votre utilisation prévue n'est pas autorisée par la réglementation légale ou dépasse l'utilisation autorisée, vous devrez obtenir l'autorisation directement du détenteur des droits d'auteur. Pour voir une copie de cette licence, visitez http://creativecommons.org/licenses/by/4.0/.

Réimpressions et autorisations

Kalantari, A., Szczepanik, M., Heunis, S. et al. Comment établir et maintenir un ensemble de données de recherche animale multimodal à l'aide de DataLad. Sci Data 10, 357 (2023). https://doi.org/10.1038/s41597-023-02242-8

Télécharger la citation

Reçu : 19 décembre 2022

Accepté : 15 mai 2023

Publié: 05 juin 2023

DOI : https://doi.org/10.1038/s41597-023-02242-8

Toute personne avec qui vous partagez le lien suivant pourra lire ce contenu :

Désolé, aucun lien partageable n'est actuellement disponible pour cet article.

Fourni par l'initiative de partage de contenu Springer Nature SharedIt