Cómo establecer y mantener un conjunto de datos de investigación animal multimodal usando DataLad

Jul 08, 2023

Scientific Data volumen 10, Número de artículo: 357 (2023) Citar este artículo

1 Altmetric

Detalles de métricas

El intercambio de datos, herramientas de procesamiento y flujos de trabajo requiere herramientas de gestión y servicios de alojamiento de datos abiertos. A pesar de las pautas FAIR y la creciente demanda de las agencias de financiación y los editores, solo unos pocos estudios con animales comparten todos los datos experimentales y las herramientas de procesamiento. Presentamos un protocolo paso a paso para realizar control de versiones y colaboración remota para grandes conjuntos de datos multimodales. Se introdujo un plan de gestión de datos para garantizar la seguridad de los datos además de una estructura homogénea de archivos y carpetas. Los cambios en los datos se rastrearon automáticamente utilizando DataLad y todos los datos se compartieron en la plataforma de datos de investigación GIN. Este flujo de trabajo simple y rentable facilita la adopción de flujos de trabajo de procesamiento y logística de datos FAIR al hacer que los datos sin procesar y procesados ​​estén disponibles y al proporcionar la infraestructura técnica para reproducir de forma independiente los pasos de procesamiento de datos. Permite a la comunidad recopilar conjuntos de datos adquiridos y almacenados de forma heterogénea que no se limitan a una categoría específica de datos y sirve como modelo de infraestructura técnica con un gran potencial para mejorar el manejo de datos en otros sitios y extenderse a otras áreas de investigación.

La gestión y el intercambio de datos requieren las mejores prácticas, tal como se introdujeron recientemente para la resonancia magnética humana1,2. Según nuestra experiencia, la mayoría de los laboratorios confían en el almacenamiento de datos no estandarizados en discos duros locales o unidades de red con capacidad de copia de seguridad y administración de usuarios insuficiente. A pesar de que solo una minoría de los estudios de resonancia magnética utilizan animales pequeños, es alarmante que en OpenNeuro, una plataforma de intercambio de datos de neuroimagen ampliamente utilizada3, solo el 3% de los conjuntos de datos contienen datos de ratones o ratas. De manera similar, en otra popular plataforma de intercambio de datos, no específica para neuroimágenes, Zenodo4, solo alrededor del 30% de los conjuntos de datos de resonancia magnética provienen de ratones o ratas. Además, es sorprendente y contrario a los principios FAIR5, si en la mayoría de estos conjuntos de datos de neuroimagen solo se proporcionan los datos de imagen. Esto excluye una gran parte de los datos adjuntos, por ejemplo, los archivos de microscopía utilizados para la validación cruzada in vivo. También identificamos una clara falta de guías paso a paso o rutinas automatizadas requeridas para reproducir los datos procesados. Estos ejemplos subrayan informes anteriores6 que el intercambio de datos de animales pequeños está lejos de ser común y que no existe una estandarización en términos de adquisición, almacenamiento e intercambio de datos. Si los datos no se comparten y, por lo tanto, no están disponibles para su reutilización, como es el caso del 93 % de las publicaciones biomédicas de acceso abierto7, esto también contrasta fuertemente con el principio de las 3 R de minimizar el número de experimentos con animales8. Por lo tanto, sigue siendo muy difícil comparar estudios entre diferentes laboratorios, lo que contribuye a la crisis de reproducibilidad9, y los estudios de animales pequeños (neuroimagen) no son una excepción10.

Visualizamos un cambio hacia las condiciones de buenas prácticas científicas y los principios de FAIR - Findable, Accessible, Interoperable, Reusable5 y Open Science2 para mejorar la confiabilidad y el reconocimiento de los estudios con animales. Nuestro objetivo era crear un enfoque de fácil aplicación para configurar un conjunto de datos multimodal que proporcione acceso a datos, métodos, resultados y su procedencia sin procesar y procesados. La gestión adecuada de los datos de investigación (RDM), ya que las agencias de financiación y los editores también la exigen cada vez más, es clave para cumplir con estos estándares2,11,12.

Aquí, describimos nuestra estrategia para la organización de datos, la recopilación de metadatos y el seguimiento de datos/análisis utilizando tres herramientas establecidas: nuestra base de datos relacional13, la plataforma de datos GIN (G-Node Infrastructure services, https://gin.g-node.org) y el software de gestión de datos de investigación DataLad14. La base de datos se utiliza para recopilar todos los metadatos experimentales sobre la línea de tiempo completa de los experimentos con animales longitudinales y multimodales, incluidos MRI, histología, electrofisiología y comportamiento. GIN y DataLad se basan en Git, un popular sistema de control de versiones, y git-annex, que amplía las capacidades de Git, especialmente con respecto a la gestión de archivos de gran tamaño. GIN es un servicio de administración de datos basado en web y de código abierto con varias características para el manejo colaborativo de datos, por ejemplo, control de versiones incorporado, acceso seguro, identificadores de datos persistentes para publicación (DOI), indexación automática y validación de datos. DataLad es un software de gestión de datos diseñado para soportar las diversas etapas del desarrollo de objetos digitales. Es importante destacar que DataLad se puede ver como una superposición sobre las estructuras y los servicios de datos existentes: el seguimiento de los archivos no cambia los archivos en sí ni la ubicación desde la que las herramientas de procesamiento de datos pueden recuperarlos.

En los últimos 5 años, hemos establecido una estrategia para 1) planificación de proyectos, 2) documentación, 3) adquisición y almacenamiento de datos y 4) intercambio de datos (Fig. 1). La planificación del proyecto y los detalles experimentales se registran en una base de datos relacional interna basada en la nube13. Un elemento clave tanto para la base de datos como para el almacenamiento de datos es el identificador, la identificación del estudio para cada animal, que se utiliza en una estructura de nombre de archivo estandarizada para que los datos se puedan encontrar. La estructura del directorio para los datos sin procesar sigue el permiso de realizar experimentos con animales. Los datos para un proyecto específico se organizan siguiendo los principios de YODA (https://handbook.datalad.org/en/latest/basics/101-127-yoda.html), que es compatible con los estándares existentes, por ejemplo, la estructura BIDS15 (Fig. 2A). Se instaló una rutina de copia de seguridad incremental automática, que transfiere los datos desde una estación de disco externa vinculada a la estación de trabajo de análisis principal a una unidad de red administrada centralmente. En preparación para la publicación y para facilitar la reproducibilidad de los datos, los datos crudos y procesados ​​experimentales se ponen a disposición del público en GIN, y se especifican los detalles y las canalizaciones posteriores al procesamiento, ya sea en la publicación o en una página de GitHub (https://github.com). /aswendtlab/Project_C3a_peri-infarct).

Flechas verdes: flujo de trabajo para la planificación de proyectos, adquisición de datos, procesamiento, almacenamiento; flechas grises: plan de copia de seguridad en almacenamientos locales y de red; flechas naranjas: integración de DataLad para control de versiones; flechas azules: proceso de publicación utilizando GIN como servicio de hospedaje en línea. Figura creada con Biorender.com.

(A) Estructura de directorios de YODA e integración de DataLad. El directorio raíz del sistema operativo (SO), la lista de proyectos y el contenido relacionado con el proyecto (carpetas + tipos de archivos). Las conexiones separadas por guiones y "//" indican que puede haber niveles adicionales, por ejemplo, el tiempo de las mediciones. Durante la conversión de la carpeta Project1 en un conjunto de datos DataLad, los archivos DataLad correspondientes (cuadros grises) se crean como información adicional en la carpeta, sin afectar el resto de los datos. Las carpetas "raw_data" y todas las carpetas en "code" son subconjuntos de datos independientes en el contexto de anidamiento y establecimiento de descentralización con "code" ubicado en Github en lugar de GIN. (B) La guía paso a paso para crear el conjunto de datos de DataLad se compone de 4 etapas posteriores obligatorias y está enmarcada por una fase de preparación inicial y un escenario de uso de terceros opcional (los círculos rojos resaltan las etapas recurrentes). (C) Estructura de carpetas basada en el permiso para realizar experimentos con animales sin DataLad (TVA = Tierversuchsantrag (alemán: protocolo animal). Esta es la estructura anterior antes de que se implementara la estructura YODA, todo el procesamiento también se realizó dentro de esta estructura, utilizando las canalizaciones paralelamente desde otro almacenamiento separado de esta estructura.Los datos sin procesar originales todavía se mantienen en esta estructura como un archivo de datos sin procesar, pero el resto se elimina.

DataLad se utiliza como la herramienta central de administración de datos (Fig. 1) y para el control de versiones: realiza un seguimiento de qué archivos se modificaron, cuándo y por quién, y brinda la capacidad de restaurar estados anteriores. Con este fin, DataLad es independiente del tipo de datos y proporciona una interfaz unificada para administrar archivos de código y datos (generalmente manejados por Git y git-annex, respectivamente).

Dentro de los conjuntos de datos de DataLad, es posible anidar (un número ilimitado de) otros conjuntos de datos de DataLad, cada subconjunto de datos permanece como un componente independiente con su propia historia y hermanos. Para lograr esta estructura, las siguientes etapas 1 a 4 se pueden realizar de forma independiente dentro de un conjunto de datos establecido. De esta forma, el usuario puede subdividir el proyecto, por ejemplo, por publicación, tipo de datos o ubicación de almacenamiento. Para aclarar esto, es posible colocar un conjunto de datos de nivel superior junto con los subconjuntos de datos en el servicio de repositorio en línea. Aquí, los datos rastreados por un conjunto de datos directamente se almacenan como de costumbre, pero los subconjuntos de datos están disponibles solo como enlaces a su propio repositorio, que puede, pero no tiene que ser alojado por el mismo proveedor de repositorio en línea. En nuestro caso, todo el código del proyecto se almacena y mantiene en los repositorios de GitHub (https://github.com) y se instala como múltiples subconjuntos de datos dentro del conjunto de datos de nivel superior Project1 principal en GIN (Fig. 2A). La estructura introducida por los principios de Yoda hace que todo el proyecto sea autónomo. No se necesita ningún otro elemento fuera del proyecto para pasar de los insumos a los resultados. Por el contrario, no es posible la autocontención para la estructura de la Fig. 2C.

INFORMACIÓN: si se va a implementar un conjunto de datos o un subconjunto de datos para una carpeta que solo contiene scripts de codificación, las etapas 1 a 4 deben optimizarse ligeramente. Brevemente, git es mucho más adecuado para el control de versiones de scripts que contienen código. Cuando se ejecuta el paso 1.2, git-annex maneja todo por defecto, la alternativa es usar datalad create --force -c text2git. La configuración adicional pone a git a cargo del contenido de los conjuntos de datos.

Basado en nuestro desarrollo de flujo de trabajo (Fig. 1), esta descripción de caso de uso proporciona una guía paso a paso para usuarios no expertos sobre cómo administrar grandes conjuntos de datos experimentales que contienen archivos multimodales complejos, es decir, los datos sin procesar y procesados, así como el código y los archivos de salida.

Para conocer los requisitos de hardware y software y las rutinas de instalación, consulte la sección Métodos y el Material complementario. El flujo de trabajo consta de 4 etapas obligatorias (Fig. 2B): 1. Inicializar un conjunto de datos de DataLad, 2. Controlar la versión, 3. Inicializar el repositorio remoto (en línea) y 4. Subir al repositorio remoto. También describimos un escenario de caso de uso opcional para uso de terceros, es decir, colaborar en el mismo conjunto de datos con otros investigadores y la publicación del conjunto de datos.

Para crear la estructura de datos, comience con la carpeta principal del Proyecto y ordene los datos sin procesar en la carpeta de entrada relacionada (Fig. 2A).

Al convertir la carpeta del proyecto en un conjunto de datos de DataLad, los archivos de DataLad correspondientes se crean automáticamente sin cambiar los archivos ni la estructura. Los archivos de DataLad contienen la versión y el historial de todos los archivos en la carpeta del proyecto. Project1 sirve como un superconjunto de datos con las carpetas asociadas raw_data y proc_data como subconjuntos de datos con sus propios repositorios en los servicios de repositorio GIN y GitHub, respectivamente. Con esta estructura, DataLad puede registrar acciones como procesar raw_data de una canalización específica en código y almacenar la salida de la canalización en proc_data. Estas acciones se guardan en la información del historial del superconjunto de datos Project1.

En nuestro caso, los datos de varias carpetas de protocolos de animales se copian en la carpeta del proyecto y los datos sin procesar originales (en el archivo) permanecen intactos. Este proceso se puede rastrear si Datalad ya es efectivo para todos los almacenamientos. En el caso de otras estructuras de datos, por ejemplo, utilizando el servidor PACS, la transferencia de los datos a la carpeta principal del Proyecto sería similar. La idea es tener todos los datos relevantes del proyecto disponibles para su análisis y posterior intercambio. Cada subcarpeta de entrada se nombra según la metodología (p. ej., MRI, comportamiento, histología, etc.) y puede contener varios tipos de archivos (Tabla 2). Las otras carpetas incluyen el código, los resultados y los documentos. En este ejemplo, el código contiene las herramientas de análisis de datos de imágenes basadas en Atlas AIDAqc y AIDAmri16 para el control de calidad automatizado, el procesamiento de MRI16 multimodal y el registro con Allen Mouse Brain Atlas17. La carpeta docs contiene toda la información y documentación necesarias (metadatos) para reproducir el conjunto de datos de IRM (p. ej., qué ID de estudio pertenece a qué grupo experimental, puntos de tiempo, tipo de exploración de IRM, etc.).

Las siguientes etapas se ejecutan para iniciar la conversión de la carpeta Project1 en un conjunto de datos DataLad (Fig. 2B). Hay una guía de video disponible (https://gin.g-node.org/Aswendt_Lab/Example_Dataset_Kalantari_Paper/src/master/doc).

1.1 Para comenzar, abra la terminal y cambie el directorio a la carpeta de destino. En este ejemplo, es Project1.

»cd Proyecto1

1.2 Una vez en la carpeta de destino, ejecute el siguiente comando para crear las carpetas y archivos específicos del conjunto de datos de DataLad en la carpeta Project1 (Fig. 2A).

» datalad crear–forzar

INFORMACIÓN: DataLad proporciona numerosos comandos y cada comando tiene diferentes opciones. Puede crear una carpeta de conjunto de datos de DataLad vacía mediante datalad create folder_name. Aquí, en el paso 2, se usó el comando de creación para inicializar un conjunto de datos de DataLad en el directorio de trabajo actual, y la opción --force permitió la creación de conjuntos de datos en una carpeta que ya contiene datos. Para obtener más información sobre otras opciones que puede utilizar, ayuda.

2.1 Después de la etapa de inicialización 1, continúe con el siguiente paso. Tenga en cuenta que este paso puede llevar algún tiempo dependiendo del hardware1.

(1Se refiere a funciones como unidades de almacenamiento conectadas interna o externamente, unidades de red, tipos de almacenamiento como unidades de disco duro (HDD) o unidades de estado sólido (SSD)).

» estado datalad »datalad guardar -m "mensaje de usuario"

Una vez que se crea el conjunto de datos, los pasos que modifican su contenido se registran ejecutando el comando de guardar datalad. La etapa 2 muestra el primer uso práctico de los conjuntos de datos de DataLad: registrar cambios. En nuestro caso, la carpeta raw_data contiene, por ejemplo, datos sin procesar de MRI. Después de procesar con AIDAmri16, los resultados se almacenan en la carpeta proc_data (Fig. 2A).

INFORMACIÓN: El comando de estado datalad se puede considerar como una herramienta de inspección que imprime el estado actual de cada archivo, ya sea que DataLad lo haya rastreado o no, eliminado o modificado. Después de inicializar en el paso 2.1, todas las impresiones de estado mostrarían "sin seguimiento". No se realizará un seguimiento de los archivos recién agregados hasta que se ejecute explícitamente el guardado de datos. Después de que se haya guardado un archivo y el contenido haya cambiado posteriormente, el estado se imprimirá de manera diferente. En general, el estado de datalad se usa solo con fines informativos y puede ser útil para identificar cambios recientes (no guardados).

El comando de guardar datalad, por otro lado, registra nuevos cambios en la carpeta.git. El comando guardar también tiene varias opciones, donde -m asocia guardar con un mensaje de usuario que puede describir el propósito del cambio. Estos mensajes pueden ser beneficiosos para que el usuario encuentre una versión en particular o para recordar cambios en el conjunto de datos más fácilmente. Si está interesado en más opciones para un comando, use la opción --help. Por ejemplo, datalad save --help muestra todas las opciones disponibles para el comando save.

2.2 (Opcional) Si los cambios se realizan mediante programación (por ejemplo, mediante la ejecución de un script personalizado), esto se puede hacer con un comando como el siguiente:

» datalad run -m "mensaje de usuario" --input … python < código.py >

El comando de ejecución registra información sobre los datos de entrada y salida del código ejecutado (aquí, un script de Python) y lo registra en la información histórica del conjunto de datos. El comando datalad save se ejecuta automáticamente cuando se usa datalad run, pero además del mensaje proporcionado por el usuario, también se almacena un registro de ejecución reejecutable para capturar la procedencia.

Es importante recalcar que la Etapa 2 es una Etapa repetitiva (Fig. 2B), es decir, puede repetirse para registrar cambios consecutivos o nuevos estados. Con el tiempo, este proceso crea un libro de registro, en el que se registran todas las acciones que un usuario ha realizado en el proyecto a lo largo del tiempo. En el siguiente paso se explica cómo acceder y utilizar este libro de registro.

2.3 Se puede acceder a toda la información registrada sobre los cambios registrados a través de:

» registro de git

Esto mostrará todos los cambios que se han realizado desde que comenzó el control de versiones. Opcionalmente escribiendo:

» registro de git -2

Solo se imprimirán los dos últimos cambios o confirmaciones (Fig. 3).

Ejemplo de salida de registro de git de un conjunto de datos que muestra información sobre el autor, la fecha, los cambios y el identificador de confirmación correspondiente, también llamado "sha".

INFORMACIÓN: una confirmación es una instantánea del estado actual del proyecto. La diferencia entre dos confirmaciones en un conjunto de datos datalad significa los cambios que han ocurrido entre esos dos estados del proyecto. Algunos datos pueden generarse, cambiarse, moverse o eliminarse. Hay otras formas de acceder al historial como tig (https://jonas.github.io/tig/) o algunas con su propia interfaz gráfica de usuario (GUI) como gitgui, gitk, etc (https://git-scm com/downloads/guis).

En este escenario, estamos utilizando la plataforma de datos GIN (hay otras opciones disponibles, consulte la Tabla 1). Un requisito previo para los siguientes pasos es una cuenta GIN operativa (https://gin.g-node.org/user/sign_up) con un par de claves ssh asociadas (http://handbook.datalad.org/en/latest/basics /101-139-gin.html) entre la cuenta GIN y la cuenta en la computadora local. Nota: este paso puede llevar algún tiempo dependiendo de la velocidad de la red.

Cree un repositorio con un nombre de conjunto de datos específico del proyecto en la cuenta GIN y copie el enlace ssh específico del proyecto generado por GIN.

Ejecute el siguiente comando con sus propias credenciales en la carpeta Project1.

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

INFO: datalad brothers se usa para todas las acciones que afectan a otras copias del conjunto de datos. Aquí, la opción de agregar se usa para vincular el conjunto de datos a una nueva ubicación donde deben ir los hermanos o la copia del conjunto de datos. A continuación, --dataset define la ruta del conjunto de datos que se está configurando, aquí está definido por el ".", lo que significa la ubicación de la carpeta actual. --name es el nombre del hermano que puede ser definido por el usuario. Sin embargo, es lógico nombrarlo de acuerdo con el servicio de repositorio en línea para facilitar su uso y evitar confusiones. Aquí usamos ginebra. La opción --url es para el enlace disponible en la página del proyecto adquirida en el paso 3.1, que se genera explícitamente para el proyecto creado allí. Para algunos repositorios, como GIN, se proporcionan comandos dedicados que automatizan la creación y el registro de hermanos remotos en un solo paso. Para GIN, este comando es create-sibling-gin.

Una vez que se configura el repositorio remoto y se establece una conexión entre los dos, el proyecto se puede cargar (empujar) a GIN.

4.1. Comience ingresando el siguiente comando en la terminal:

datalad empujar --a la ginebra

Al igual que la etapa 2, este paso puede ser repetitivo (Fig. 2B). A medida que avanza un conjunto de datos y su información de historial, se agregan nuevas confirmaciones y las actualizaciones se pueden enviar al repositorio remoto. Esto se hace de manera eficiente, lo que significa que solo se transfieren los archivos modificados. El control de versiones hace que el estado del conjunto de datos cargado sea único. Además, GIN es totalmente compatible con git y git-annex, y su interfaz web puede, por ejemplo, mostrar el historial de cambios y los mensajes de confirmación asociados.

Dependiendo del tamaño del proyecto y la calidad de la conexión a Internet, la ejecución de este paso puede llevar algún tiempo. Por lo tanto, puede ser conveniente no intentar enviar todos los datos en un solo lote, es decir, dividirlos y realizar el proceso de envío en varios lotes. Esto es posible agregando la ruta de una parte más pequeña especificada del proyecto al comando:

4.2 (Opcional) datalad push --to gin

Cualquier persona interesada en el proyecto ahora puede acceder y descargar no solo los datos sino también la historia del proyecto a medida que ha evolucionado a lo largo del tiempo, a través de lo que se denomina "clonación". Desde una perspectiva de terceros, el primer paso es visitar el repositorio respectivo en el sitio web de GIN, donde se puede encontrar el enlace SSH o el enlace HTTPS respectivamente, dependiendo de si el conjunto de datos se va a modificar o solo a descargar.

INFORMACIÓN: en la página de proyectos de una cuenta GIN, hay tres enlaces para acceder al repositorio, SSH, HTTPS y GIN. En términos simples, SSH y HTTPS son diferentes formas de comunicación entre el sistema operativo del usuario y el servicio de repositorio en línea. La principal diferencia en nuestro caso de uso es que se requiere una conexión SSH si queremos cargar o "empujar" los datos al repositorio remoto. Para descargar o "clonar" los datos, una conexión HTTPS es suficiente. Como se mencionó brevemente en la etapa 3, la configuración de un enlace SSH requiere pasos adicionales, pero los enlaces HTTPS se pueden usar sin más preocupaciones.

Copie el enlace SSH/HTTPS de la página web del proyecto GIN.

Abra el terminal y navegue a una carpeta donde se debe ubicar el contenido del proyecto y ejecute el siguiente comando, reemplazando la URL de ejemplo con el enlace copiado.

Para enlaces SSH:

clon del conjunto de datos [email protected] :/username/dataset-name.git

Para enlaces HTTPS:

clon de conjunto de datos https://gin.g-node.org/username/dataset-name

Si se elige el enlace HTTPS, tenga en cuenta que el enlace no tiene una extensión .git.

INFORMACIÓN: una característica útil del comando de clonación datalad es que no descarga todo el conjunto de datos a la vez. Descarga solo la estructura de carpetas, los archivos pequeños y los nombres de archivo de archivos grandes, es decir, archivos que son manejados por git-annex. El comando datalad get se puede usar para descargar selectivamente el contenido de archivos grandes para que todo el contenido esté disponible localmente. Esto puede ser útil desde dos puntos de vista: primero, si todo el conjunto de datos es muy grande y solo algunas partes son de interés, solo esas partes se pueden descargar de forma selectiva. En segundo lugar, si solo interesan la estructura del proyecto y el nombre del archivo, en este caso no se llamaría a datalad get.

Si desea descargar todo el proyecto, continúe con el siguiente comando en la carpeta del conjunto de datos de DataLad creada después del último paso.

Escribe lo siguiente:

cabra computarizada

El comando se puede restringir a una ruta específica (directorio o archivo) para recuperar selectivamente el contenido.

Como se presentó en la sección anterior, el anidamiento de conjuntos de datos puede ser muy útil desde la perspectiva de un tercero. En nuestro ejemplo, el conjunto de datos de nivel superior Project1 contiene varios conjuntos de datos para las carpetas "raw_data" y diferentes canalizaciones de código (Fig. 2A). La intención de esta configuración era, en primer lugar, hacer que los datos sin procesar y los códigos estuvieran disponibles por separado para terceros sin tener que descargar todas las estructuras periféricas del proyecto y, en segundo lugar, preservar la capacidad de actualización de las distintas canalizaciones en la carpeta de códigos, es decir, como las canalizaciones se actualizan con el tiempo, la clonación del conjunto de datos de nivel superior asocia automáticamente las canalizaciones más actualizadas con él.

Dado que nuestro conjunto de datos está destinado a la publicación y reutilización, es fundamental anotarlo con información relevante. En el momento de la creación, los repositorios GIN son por defecto privados, es decir, de acceso restringido, pero se pueden configurar como públicos a través de una casilla de verificación en el menú de configuración. Los conjuntos de datos públicos en GIN pueden recibir un identificador de objeto digital (DOI) único y persistente, lo que los hace citables. Junto a los metadatos de publicación, incluimos documentación sobre el conjunto de datos, como grupos experimentales y puntos de tiempo, así como información específica de la modalidad, por ejemplo, sobre secuencias de resonancia magnética, que se recupera de nuestra base de datos relacional.

Aquí, proporcionamos una guía paso a paso para que los usuarios no expertos implementen un flujo de trabajo de datos FAIR aplicable a los datos de animales pequeños. En este flujo de trabajo, utilizamos un esquema de respaldo local simple pero eficiente y una estructura de datos estandarizada en combinación con GIN como solución para la disponibilidad de datos públicos. DataLad se utilizó como una herramienta de gestión de datos para proporcionar una base para una colaboración transparente y confiable entre investigadores, con la intención de encapsular todos los elementos de un proyecto, como datos de entrada, códigos y resultados, junto con información sobre cómo están conectados18.

Nuestra motivación para implementar este flujo de trabajo fue garantizar la conservación de datos, la colaboración eficiente, el intercambio de datos y una mayor reproducibilidad. Tales necesidades prácticas relacionadas con la gestión de datos de investigación están muy extendidas en el campo y hasta ahora solo se han propuesto soluciones únicas (Kuhn Cuellar et al.19). Una encuesta reciente sobre la gestión y el intercambio de datos en neuroimagen (humana) muestra los desafíos significativos asociados con la gestión y el intercambio adecuados de datos de neuroimagen, siendo las mayores limitaciones el tiempo y la falta de mejores prácticas20. Los investigadores se consideran menos maduros en el intercambio de datos que en las prácticas de análisis y recopilación de datos. Para superar esta limitación, nuestro enfoque se centró en un flujo de trabajo fácil de implementar que utiliza solo software disponible gratuitamente y no requiere ningún conocimiento previo especial.

Un identificador de sujeto y una estructura de archivos/carpetas estandarizados (consulte la sección Métodos) son la base de una gestión eficiente de los datos de investigación. El identificador creado para cada animal y el nombre de archivo estandarizado ayudan a que los datos sean rastreables incluso en ausencia de otros metadatos. En nuestro caso, el protocolo animal determina cuál y con qué frecuencia se puede aplicar un método. Con el fin de proporcionar total transparencia de acuerdo con las pautas de buenas prácticas científicas con animales21 y simplificar la documentación para las auditorías de las autoridades locales, recopilamos todos los datos experimentales en una base de datos relacional electrónica13 y almacenamos los datos sin procesar en la estructura predefinida por el animal. protocolo. Este directorio de datos sin procesar sirve más tarde como archivo, que permanece intacto. Para el procesamiento relacionado con el proyecto/publicación, todos los datos sin procesar, que pueden provenir de diferentes licencias de animales, se copian en la carpeta de entrada para dejar los datos sin procesar intactos por seguridad y al mismo tiempo proporcionar la máxima flexibilidad para trabajar con los datos. La estructura de YODA no solo contiene la carpeta de entrada, sino también la salida, los documentos y el código. Aquí, nuestro enfoque difiere de las estructuras de carpetas sugeridas previamente con una jerarquía de 3 niveles, es decir, nivel de laboratorio (organización que lleva a cabo varios proyectos), nivel de proyectos y nivel experimental subsiguiente22. Para publicación o colaboración, toda la estructura de YODA se sube al servicio de alojamiento de datos en línea, en nuestro caso GIN. Es importante destacar que DataLad es flexible en cuanto a dónde se almacenan los datos. Si los usuarios tienen sus datos completos en soluciones de almacenamiento alternativas como XNAT o servidor PACS para datos radiológicos23 u OMERO24 para datos de microscopía, hay extensiones de DataLad dedicadas (https://docs.datalad.org/), o se pueden agregar extensiones adicionales. desarrollado con un esfuerzo mínimo para soportar servicios adicionales. Nuestro flujo de trabajo no excluye otros servicios de software y alojamiento de datos, por ejemplo, CKAN (https://ckan.org), Harvard Dataverse (https://dataverse.harvard.edu) y Barcelonaβeta Brain25, con su propia estrategia para manejar datos complejos de investigación multimodal. Por el contrario, proporciona un RDM versátil e interoperable, con la flexibilidad y la simplicidad necesarias para adaptarse a los paradigmas experimentales locales y las infraestructuras de TI existentes en pequeños laboratorios a grandes consorcios multisitio12,18.

Los metadatos son un ingrediente muy importante en las prácticas de investigación actuales, especialmente cuando se trata de una colaboración transparente entre investigadores de acuerdo con FAIR y las pautas específicas de la comunidad de neuroimágenes5,26. archivo de encabezado más rico en metadatos, siendo el estándar BIDS la opción más avanzada y más utilizada para estructurar archivos según secuencias de resonancia magnética e incluir metadatos estandarizados15. Nuestro flujo de trabajo es totalmente compatible con el formato BIDS (ver ejemplo en https://doi.org/10.12751/g-node.3yl5qi27) pero decidimos hacer que BIDS no requiera el uso del flujo de trabajo como, por ejemplo, es el caso de los datos. plataforma OpenNeuro, para maximizar la flexibilidad de los investigadores que trabajan con diferentes formatos de archivo. Si bien apoyamos plenamente los esfuerzos para maximizar la estandarización a nivel de metadatos, en nuestra propia experiencia trabajando con datos multimodales (de resonancia magnética, comportamiento, electrofisiología y microscopía), es necesario como un paso intermedio, priorizar la existencia de tantos metadatos como sea posible en archivos legibles por máquina (txt, csv, json), que no necesariamente tienen que ser la estructura actual basada en la comunidad. Por lo tanto, recomendamos usar el flujo de trabajo en combinación con una base de datos relacional como nuestro propio desarrollo13, REDcap28 u otros, que permite la generación de dichos archivos legibles por máquina. Con conocimientos básicos de programación, será fácil para los usuarios de terceros buscar y filtrar los datos compartidos en función de estos archivos.

Si el procesamiento requiere varios pasos o herramientas de procesamiento, sugerimos incluir una guía paso a paso más detallada (por ejemplo, https://github.com/aswendtlab/ Project_C3a_peri-infarct), que va más allá de los requisitos de los informes de metadatos en estándares existentes, es decir, BIDS. Estas guías paso a paso pueden ser necesarias para la replicación de datos en caso de que no se puedan utilizar rutinas automatizadas, es decir, ejecución de datalad.

Cabe mencionar que DataLad requiere una inversión inicial de tiempo y recursos, pero las ganancias en eficiencia, calidad y confiabilidad en el futuro hacen que esas inversiones valgan la pena según nuestra experiencia.

La incapacidad de reproducir los resultados de un estudio en particular no es exclusiva de las neuroimágenes en animales pequeños. Esto se debe principalmente a la falta de transparencia y detalles metodológicos, como un protocolo paso a paso en los artículos científicos. La reproducción de un estudio requiere acceso a una variedad de otros documentos, como parámetros de escaneo, procedimientos de procesamiento previo y posterior y características individuales de los sujetos. Con este fin, además del flujo de trabajo que se presenta aquí, adoptamos un enfoque pragmático, es decir, ponemos a disposición del público los datos sin procesar y procesados ​​en GIN y especificamos los detalles del posprocesamiento en una página de GitHub específica del proyecto.

Convertir las carpetas de datos en un conjunto de datos de DataLad no solo brinda los beneficios descritos anteriormente, es decir, seguimiento de modificaciones, fácil intercambio de conjuntos de datos al publicarlos entre hermanos y administración eficiente de archivos grandes al reducir las necesidades de transporte y almacenamiento. Como se indicó antes, DataLad abre sus conjuntos de datos para un uso mucho más amplio y proporciona una fácil reutilización de conjuntos de datos publicados en otros conjuntos de datos de DataLad a través del mecanismo de subconjunto de datos de DataLad. DataLad también ofrece seguimiento de procedencia (anotación reejecutable de cambios) y gestión de metadatos. Junto con el comando de ejecución y el comando de repetición de DataLad, que permiten la "ejecución rastreada" de operaciones en un conjunto de datos, DataLad permite una investigación verdaderamente reproducible29.

El intercambio de datos abiertos integrado en un protocolo RDM adecuado no resolverá las deficiencias en el diseño del estudio o la estrategia de análisis, pero lo que es más importante, permite que otros investigadores identifiquen las posibles deficiencias y las aborden en el trabajo futuro, lo que evita la repetición de errores20. Nuestros esfuerzos sirven como modelo para otras áreas de imágenes preclínicas con un alto impacto en la práctica de investigación en la comunidad de neuroimagen animal y más allá. De acuerdo con el principio de las 3 R para reducir el número de animales, este flujo de trabajo permite a la comunidad recopilar conjuntos de datos adquiridos y almacenados de manera heterogénea para fomentar experimentos de simulación de cerebro de ratón e implementar un enfoque de modelado entre especies. Además, la estrecha colaboración con los esfuerzos para la estandarización de datos y metadatos, el seguimiento de la procedencia y la gestión del flujo de trabajo, la integración en un ecosistema de plataforma de datos de investigación interoperable y la especificación del modelo computacional utilizando medios estandarizados ayudarán a fortalecer la interacción de todos los participantes y mejorarán la Brecha traslacional actual entre investigadores básicos y clínicos.

En esta sección, describimos los detalles del material necesario para reproducir el flujo de trabajo.

El flujo de trabajo que se describe aquí (Fig. 1A) se desarrolló utilizando una Mac Pro (finales de 2013) como estación de trabajo principal ejecutada en modo servidor. De esta forma, varios usuarios pueden acceder a la Mac a través de la pantalla integrada o compartir archivos (protocolos VNC/SMB) y recuperar datos y ejecutar programas en paralelo. Es posible una forma similar de trabajar con estaciones de trabajo que ejecutan instalaciones de Linux o Windows 10/11 a través de conexiones de escritorio remoto. La estrategia de almacenamiento de datos se desarrolló de acuerdo con las mejores prácticas30, incluido un plan de copia de seguridad, diferentes ubicaciones de copia de seguridad, comprobaciones de validez de la copia de seguridad y la posibilidad de ampliar el almacenamiento de datos. El almacenamiento local principal, conectado directamente a la estación de trabajo, es una unidad LaCie Thunderbolt de 20 TB que funciona en modo Raid-5 (una unidad de disco duro puede dañarse mientras el sistema de archivos permanece intacto). El experimentador responsable primero copia manualmente todos los datos a este almacenamiento local. La ruta a los datos sin procesar está documentada en la base de datos electrónica13. Las copias de seguridad automáticas e incrementales se realizan mediante Carbon Copy Cloner (Bombich Software, Inc., EE. UU.) semanalmente desde el almacenamiento local al almacenamiento en red (administrado por el Departamento de TI del Hospital Universitario).

El flujo de trabajo (Fig. 1A) se basa en software gratuito y de código abierto: Python (https://www.python.org/, RRID:SCR_008394), GIN (https://gin.g-node.org, RRID: SCR_015864) y DataLad (https://www.datalad.org, RRID:SCR_003931). Existen otras opciones de alojamiento de datos (Tabla 1), que se pueden integrar fácilmente en el flujo de trabajo proporcionado. Se proporcionan guías de instalación representativas en el Material complementario. Para obtener las instrucciones de instalación más actualizadas, consulte los sitios web relacionados.

DataLad se utiliza para el control de versiones distribuidas: creación, sincronización y seguimiento de copias de conjuntos de datos vinculados (llamados hermanos). Un conjunto de datos de DataLad puede tener uno o varios hermanos, almacenados localmente (unidades de respaldo, servidores locales, diferentes estaciones de trabajo) o en línea (por ejemplo, GIN). Los cambios realizados en una copia del conjunto de datos se pueden sincronizar con otras copias y la sincronización siempre es explícita (es fácil saber si las versiones divergen o no). Se realiza un seguimiento de la disponibilidad del contenido del archivo y el contenido disponible de forma remota se puede recuperar a pedido para ahorrar espacio localmente. Esto también significa que el intercambio de archivos, la copia de seguridad y la publicación se realizan a través de la misma interfaz de software, incluso si las ubicaciones son diferentes.

Repositorio: Carpeta con archivos y subcarpetas como unidad estructural para la gestión de código o datos; puede ser cualquier conjunto o combinación de archivos con diferentes estructuras de carpetas y diferentes tipos de datos, a veces incluso puede estar vacío y no contener archivos.

Conjunto de datos de DataLad: repositorio en el que se ejecuta DataLad y se ejecuta el control de versiones.

Inicializar un conjunto de datos de DataLad: para crear un conjunto de datos vacío que está sujeto al control de versiones de DataLad. Si se agregan archivos a este conjunto de datos después de eso, DataLad los rastreará.

Inicializar DataLad en un repositorio ya existente: la transición de un conjunto de datos en una estructura de archivo/carpeta a un conjunto de datos administrado por DataLad.

Seguimiento/control de versiones: si un archivo cambia porque ha sido reemplazado o editado por un usuario, DataLad registra esos cambios a lo largo del tiempo.

Un hermano/clon de DataLad: se puede definir como una copia del conjunto de datos. Esto no significa necesariamente que sea una copia exacta, o que todos los datos estén completamente disponibles. Un marcador de posición es un archivo con el mismo nombre que el archivo original pero sin su contenido.

Git: un sistema de control de versiones gratuito y de código abierto que se usa para manejar proyectos pequeños a muy grandes de manera eficiente

Git-annex: git-annex es un sistema de sincronización de archivos distribuidos que tiene como objetivo resolver el problema de compartir y sincronizar colecciones de archivos grandes.

Anidamiento de conjuntos de datos: los conjuntos de datos pueden contener otros conjuntos de datos (subconjunto de datos), que a su vez pueden contener subconjuntos de datos, y así sucesivamente. Cada conjunto de datos que contiene otro subconjunto de datos puede denominarse superconjunto de datos. El conjunto de datos de nivel superior es el superconjunto de datos que tiene el nivel más alto en la jerarquía de conjuntos de datos.

Los proveedores de alojamiento de datos en línea ofrecen la infraestructura para que los investigadores carguen sus datos y los compartan con otros. Estos servicios difieren en su enfoque principal: almacenamiento en la nube (almacenamiento de archivos y uso compartido limitado, sin indexación de metadatos), servicios de alojamiento de datos simples (alojamiento a largo plazo, indexación automatizada de metadatos) y plataformas de datos de investigación (alojamiento a largo plazo, uso compartido, colaboración y datos). manejo) (Cuadro 1).

Los servicios y plataformas que proporcionan identificadores persistentes (DOI) son clave para adoptar prácticas de FAIR y ciencia abierta en línea con aspectos de reproducibilidad y reutilización de datos. Sin embargo, solo una minoría de los estudios comparte sus datos, lo que podría cambiar con la creciente demanda de los editores y las instituciones de financiación. Elegimos la plataforma de datos de investigación GIN (https://gin.g-node.org/G-Node/Info/wiki/), que cuenta con el apoyo del gobierno alemán (BMBF Grant 01GQ1302) y LMU Munich, y desarrollamos open -fuente del Nodo Alemán de Neuroinformática (G-Node). GIN es un recurso registrado (https://doi.org/10.17616/R3SX9N) y cumple con los criterios para repositorios y pasarelas científicas avalados por el INCF31.

Para que un conjunto de datos sea elegible para el servicio GIN-DOI, se deben crear metadatos específicos, incluido un archivo específico de GIN llamado "datacite.yml", que contiene información sobre los autores, el título, la descripción, las palabras clave y la licencia de acuerdo con el Se debe proporcionar el esquema de DataCite (https://schema.datacite.org/). En GIN, estos metadatos deben estar en un archivo llamado "datacite.yml" en la raíz del repositorio. Se debe elegir una licencia (p. ej., https://creativecommons.org/choose/) para especificar los requisitos de atribución, derivados y uso compartido, y el texto de la licencia se incluirá en un archivo de texto llamado LICENCIA. El servicio GIN DOI garantiza el acceso permanente al conjunto de datos mediante un identificador persistente (https://gin.g-node.org/G-Node/Info/wiki/DOI).

INFORMACIÓN: La elección de un servicio de alojamiento de datos debe hacerse con cuidado, ya que varios factores juegan un papel, por ejemplo, la disponibilidad, el cifrado de anonimato, el grupo objetivo general de usuarios internos o externos, el alcance de los datos, la frecuencia de uso, etc. Es importante destacar que DataLad funcionará con todos los servicios enumerados. El control de versiones de DataLad se aplica independientemente de dónde residan los datos, es decir, localmente o en un almacén de datos en línea. Sin embargo, es necesaria una copia de seguridad adecuada para no perder el acceso a los datos, los registros de DataLad y el historial asociado. Por lo tanto, es común almacenar una réplica del conjunto de datos y su historial controlado por versiones en otro lugar con suficiente espacio de almacenamiento.

Estamos trabajando con dos estructuras de datos, una en la que los datos (en bruto) se almacenan de acuerdo con los experimentos descritos en el protocolo animal aprobado (Fig. 2C), y la segunda en la que se almacenan los datos específicos del proyecto (Fig. 2A). Primero, recopilamos todos los datos sin procesar en una estructura de carpetas uniforme de acuerdo con los principales proyectos y subproyectos en nuestras licencias de experimentos con animales y según lo aprobado por las autoridades locales. Una carpeta típica de datos sin procesar (MRI/raw_data/P1/SPs1c4m1_1_1_20180105_094610) especifica el experimento ( IRM), el tipo de datos (datos sin procesar), el punto temporal (P1, es decir, el día 1 posterior al accidente cerebrovascular), el ID del estudio (SPs1c4m1) y un código específico del hardware de IRM (Bruker) (es decir, número de estudio, número de reconstrucción , fecha como AAAA-MM-DD y hora como hh-mm-ss). Recomendamos guardar los datos sin procesar en la estructura de carpetas relacionadas con el protocolo animal, lo que simplifica la documentación para las autoridades. En un segundo paso, antes de inicializar DataLad, los datos sin procesar se copian de una o varias carpetas de datos sin procesar en la estructura de YODA para cada proyecto/publicación. La estructura de YODA agrupa la entrada de datos, la salida, los documentos y el código en una estructura específica del proyecto (Fig. 2A).

Para realizar un seguimiento de la gran cantidad de experimentos, creamos identificadores únicos para cada mouse/escaneo (Fig. 1). El identificador (ID del estudio) combina elementos del protocolo del animal, el (sub)proyecto, la jaula y el número de animales por jaula. Por ejemplo, SPs1c4m1 se relaciona con el proyecto SPasticity, subproyecto 1, jaula 4, ratón 1. En principio, se puede agregar otra información, como el sexo y el genotipo, de acuerdo con la nomenclatura común, p. ej., SPs1c4m1mRbp4, en relación con un macho (m) Tg( Ratón Rbp4-cre)KL100Gsat (Rbp4 corto). Es importante destacar que para los estudios traslacionales, las identificaciones del estudio no deben modificarse para revelar el grupo experimental al usuario, es decir, el usuario permanece ciego durante la recopilación y el análisis de datos. En cualquier caso, las funciones principales del identificador deben conservarse, es decir, anonimizar al sujeto (en términos de detalles experimentales) y permanecer identificable por términos de búsqueda/clasificación de estilo de palabra clave.

INFO: Los ID se refieren al protocolo del animal y se almacenan en una estructura de carpetas fija similar a la utilizada en el formato BIDS. Nuestra convención de archivos para nombrar y estructurar archivos se especificó antes de que BIDS se hiciera popular para los datos de resonancia magnética de animales. Por lo tanto, tenemos conjuntos de datos con guiones bajos y guiones como separadores, por ejemplo, TP_T1_4_1. Si los usuarios planean usar el formato BIDS, el flujo de trabajo aún se puede aplicar ya que DataLad es compatible con BIDS. Sin embargo, dado que BIDS es sensible a caracteres específicos, por ejemplo, guiones y guiones bajos, los ID deben contener solo números y letras. Una posible alternativa para SP_T1_4_1 sería SPsT1c4m1, que reemplaza los guiones bajos con las letras iniciales de subproyecto (s), jaula (c) y ratón (m). Nota: si en el pasado se incluyeron caracteres especiales en los ID del estudio, hacer que los archivos sean compatibles con BIDS requiere mucha más atención, por ejemplo, escribir la información correcta también en el encabezado NIfTy y en todos los archivos de metadatos relacionados.

Siempre que sea posible, los elementos de los nombres de los archivos se generan automáticamente o se deben asignar de acuerdo con un esquema estandarizado, que incluye el StudyID, la prueba/experimento y el punto de tiempo (si corresponde). De esta manera, el nombre del archivo será único y ya contiene metadatos esenciales. Como ejemplo, SPs1c4m1CytD4 estaría relacionado con la prueba del cilindro (Cyt), una prueba de comportamiento del ratón, que se realizó el día 4 (D4) con el ID de estudio SPs1c4m1. Las rutas de archivo/carpeta se almacenan en la base de datos electrónica13 junto con información importante de metadatos sobre el experimento. En el caso de la resonancia magnética, esto incluye el protocolo de anestesia (incluido el tiempo y la dosis exactos), los detalles de configuración (p. ej., bobina, gradiente) y la lista de exploraciones de resonancia magnética.

De acuerdo con las reglas básicas del almacenamiento de datos30, se utilizan formatos de datos abiertos siempre que sea posible. Nuestros conjuntos de datos contienen una amplia gama de archivos, que van desde pequeños archivos de texto hasta archivos de resonancia magnética y grabaciones de video más grandes. No existe una restricción general en el formato de archivo para que sea compatible con el flujo de trabajo (Tabla 2).

INFORMACIÓN: para cualquier formato de archivo de texto (p. ej., txt, csv, json), DataLad realiza un seguimiento de los cambios en el archivo línea por línea (holístico). Como resultado, cada línea en, por ejemplo, el código de Python se puede atribuir a una confirmación (y autor) que la cambió por última vez (usando la funcionalidad de Git). Para todos los demás formatos de datos, DataLad realiza un seguimiento de la diferencia por archivo utilizando sumas de verificación de archivo, es decir, se almacena información sobre cuándo y quién cambió el documento, pero no qué parte del archivo cambió. En términos de ciencia abierta y usabilidad a largo plazo, se recomienda utilizar tipos de archivos línea por línea (legibles por máquina, por ejemplo, csv) siempre que sea posible.

Recomendamos utilizar el conjunto de datos de prueba27 (https://doi.org/10.12751/g-node.3yl5qi). Contiene una estructura básica de yoda (Fig. 2A) y es lo suficientemente pequeña para permitir un procesamiento rápido.

DataLad y GIN están disponibles gratuitamente. El manuscrito contiene todo el código para reproducir el flujo de trabajo.

Nichols, TE et al. Mejores prácticas en el análisis y el intercambio de datos en neuroimagen mediante resonancia magnética. Nature Neuroscience 20(3), 299–303 (2017).

Artículo CAS PubMed PubMed Central Google Scholar

Niso, G. et al. Neuroimagen abierta y reproducible: desde el inicio del estudio hasta la publicación. https://doi.org/10.31219/osf.io/pu5vb (2022).

Markiewicz, CJ et al. El recurso de OpenNeuro para compartir datos de neurociencia. eLife 10 (octubre). https://doi.org/10.7554/eLife.71774 (2021).

Organización Europea para la Investigación Nuclear y OpenAIRE. Zenodo. CERN. https://doi.org/10.25495/7GXK-RD71 (2013).

Wilkinson, MD y col. Principios rectores FAIR para la gestión y administración de datos científicos. Datos científicos 3 (marzo), 160018 (2016).

Artículo PubMed PubMed Central Google Académico

Mandino, F. et al. Resonancia magnética funcional animal: tendencias y camino hacia la estandarización. Fronteras en Neuroinformática 13, 78 (2019).

Artículo PubMed Google Académico

Gabelica, M., Bojčić, R. & Puljak, L. Muchos investigadores no cumplieron con su declaración de intercambio de datos publicada: un estudio de métodos mixtos. Journal of Clinical Epidemiology 150 (octubre), 33–41 (2022).

Artículo PubMed Google Académico

Los principios de la técnica experimental humanitaria. El Diario Médico de Australia 1(13), 500–500 (1960).

Begley, CG & Ioannidis, JPA Reproducibilidad en la ciencia: mejora del estándar para la investigación básica y preclínica. Investigación de circulación 116 (1), 116–26 (2015).

Artículo CAS PubMed Google Académico

Poldrack, RA et al. Escaneando El Horizonte: Hacia Una Investigación De Neuroimagen Transparente Y Reproducible Nature Reviews. Neurociencia 18(2), 115–26. (2017).

Artículo CAS PubMed PubMed Central Google Scholar

Couture, JL, Blake, RE, McDonald, G. & Ward, CL A Requisito de publicación de datos impuesto por los financiadores Intercambio de datos rara vez inspirado. PloS One 13(7), e0199789 (2018).

Artículo PubMed PubMed Central Google Académico

Hanke, M. et al. En defensa de la gestión descentralizada de datos de investigación. Neuroforum 0 (0). https://doi.org/10.1515/nf-2020-0037 (2021).

Pallast, N., Wieters, F., Nill, M., Fink, GR y Aswendt, M. 2018. Base de datos relacional basada en la nube para datos animales multimodales. Base de datos: The Journal of Biological Databases and Curation https://doi.org/10.1093/database/bay124 (enero de 2018).

Halchenko, Y. et al. DataLad: Sistema Distribuido para la Gestión Conjunta de Código, Datos y su Relación. Revista de software de código abierto 6(63), 3262 (2021).

Artículo ANUNCIOS Google Académico

Gorgolewski, KJ et al. La estructura de datos de imágenes cerebrales, un formato para organizar y describir los resultados de los experimentos de neuroimagen. Datos científicos 3 (junio), 160044 (2016).

Artículo PubMed PubMed Central Google Académico

Pallast, N. et al. Canalización de procesamiento para el análisis de datos de imágenes basado en Atlas de MRI de cerebro de ratón estructural y funcional (AIDAmri). Fronteras en neuroinformática 13 (junio), 42 (2019).

Artículo PubMed PubMed Central Google Académico

Wang, Q. et al. El marco de coordenadas comunes del cerebro del ratón Allen: un atlas de referencia 3D. Celda 181(4), 936–53.e20 (2020).

Artículo CAS PubMed PubMed Central Google Scholar

Wachtler, T. et al. NFDI-Neuro: Construyendo una comunidad para la gestión de datos de investigación en neurociencia en Alemania. Neuroforum 0 (0). https://doi.org/10.1515/nf-2020-0036 (2021).

Kuhn, L. et al. Una infraestructura de gestión de datos para la integración de imágenes y datos ómicos en las ciencias de la vida. BMC Bioinformática 23(1), 61 (2022).

Artículo Google Académico

Borghi, JA & Van Gulick, AE Gestión y uso compartido de datos en neuroimagen: prácticas y percepciones de los investigadores de resonancia magnética. PloS One 13(7), e0200562 (2018).

Artículo PubMed PubMed Central Google Académico

Percie du Sert, N. et al. Las Directrices ARRIVE 2.0: Directrices actualizadas para informar sobre investigaciones con animales. Journal of Cerebral Blood Flow and Metabolism: Revista oficial de la Sociedad Internacional de Cerebral Blood Flow and Metabolism 40(9), 1769–77. (2020).

Artículo PubMed Google Académico

Colomb, J., Arendt, T. & Sehara, K. El equipo de Gin-Tonic. Hacia una estructura de carpetas de investigación estandarizada. https://doi.org/10.25815/WCY6-M233 (2021).

Artículo Google Académico

Marcus, DS et al. El kit de herramientas de archivo extensible de neuroimagen: una plataforma informática para administrar, explorar y compartir datos de neuroimagen. Neuroinformática 5(1), 11–34 (2007).

Artículo PubMed Google Académico

Swedlow, JR 2007. El entorno de microscopía abierta: un proyecto colaborativo de desarrollo de software y modelado de datos para la informática de imágenes biológicas. En Imaging Cellular and Molecular Biological Functions, 71–92. Berlín, Heidelberg: Springer Berlín Heidelberg.

Huguet, J. et al. Gestión y control de calidad de grandes conjuntos de datos de neuroimagen: desarrollos del Centro de Investigación Cerebral Barcelonaβeta. Frontiers in Neuroscience 15 (abril), 633438 (2021).

Artículo PubMed PubMed Central Google Académico

Poliné, JB et al. Intercambio de datos en la investigación de neuroimagen. Frontiers in Neuroinformatics 6 (abril), 9 (2012).

PubMed PubMed Central Google Académico

Aswendt, M. & Kalantari, A. Un conjunto de datos de DataLad para una estructura ejemplar de un depósito de datos de animales multimodales, G-Node, https://doi.org/10.12751/g-node.3yl5qi (2023).

Harris, PA y col. Captura electrónica de datos de investigación (REDCap): una metodología basada en metadatos y un proceso de flujo de trabajo para proporcionar soporte informático de investigación traslacional. Revista de informática biomédica 42(2), 377–81 (2009).

Artículo PubMed Google Académico

Wagner, AS et al. FAIRly Big: un marco para el procesamiento computacionalmente reproducible de datos a gran escala. Datos científicos 9(1), 80 (2022).

Artículo PubMed PubMed Central Google Académico

Hart, EM et al. Diez reglas simples para el almacenamiento de datos digitales. PLoS Computational Biology 12(10), e1005097 (2016).

Artículo PubMed PubMed Central Google Académico

Sandström, M. et al. Recomendaciones para repositorios y pasarelas científicas desde una perspectiva neurocientífica. Datos científicos 9(1), 212 (2022).

Artículo PubMed PubMed Central Google Académico

Descargar referencias

Este trabajo fue financiado por la Fundación Friebe (T0498/28960/16) y la Deutsche Forschungsgemeinschaft (DFG, Fundación Alemana de Investigación) – Proyecto-ID 431549029 – SFB 1451. Agradecemos el apoyo para el cargo de procesamiento de artículos de la DFG (Fundación Alemana de Investigación) , 491454339).

Financiamiento de acceso abierto habilitado y organizado por Projekt DEAL.

Universidad de Colonia, Facultad de Medicina y Hospital Universitario de Colonia, Departamento de Neurología, Colonia, Alemania

Aref Kalantari y Markus Aswendt

Laboratorio de Psicoinformática, Instituto de Neurociencia y Medicina, Cerebro y Comportamiento (INM-7), Centro de Investigación Jülich, Jülich, Alemania

Michał Szczepanik, Stephan Heunis, Christian Mönch y Michael Hanke

Instituto de Neurociencia de Sistemas, Facultad de Medicina, Universidad Heinrich Heine, Düsseldorf, Alemania

miguel hanke

Facultad de Biología, Ludwig-Maximilians-University Munich, Planegg-Martinsried, Munich, Alemania

Thomas Wachtler

Neurociencia Cognitiva, Instituto de Neurociencia y Medicina (INM-3), Centro de Investigación Jülich, Jülich, Alemania

marcus aswendt

También puede buscar este autor en PubMed Google Scholar

También puede buscar este autor en PubMed Google Scholar

También puede buscar este autor en PubMed Google Scholar

También puede buscar este autor en PubMed Google Scholar

También puede buscar este autor en PubMed Google Scholar

También puede buscar este autor en PubMed Google Scholar

También puede buscar este autor en PubMed Google Scholar

Conceptualización: AK, MA, MS, Curación de datos: AK, Análisis formal: AK, MA, Adquisición de fondos: MA, MH, Investigación: AK, MA, Metodología: AK, MS, TW, MH, MA, Administración de proyectos: MA, Recursos: MA, Software: AK, MA, Supervisión: MA, MH, Visualización: MA, AK, Redacción: borrador original: MA, AK, MS, SH, TW, Redacción: revisión y edición: MA, AK, CM, SH , MH, TW, Todos los autores leyeron, editaron y aprobaron el manuscrito final.

Correspondencia a Markus Aswendt.

MS, SH, CM y MH son desarrolladores del software gratuito y de código abierto DataLad. TW participa en el desarrollo del software gratuito y de código abierto GIN y en el suministro de la plataforma GIN. Los otros autores no reportan intereses en competencia.

Nota del editor Springer Nature se mantiene neutral con respecto a los reclamos jurisdiccionales en mapas publicados y afiliaciones institucionales.

Acceso abierto Este artículo tiene una licencia internacional Creative Commons Attribution 4.0, que permite el uso, el intercambio, la adaptación, la distribución y la reproducción en cualquier medio o formato, siempre que se otorgue el crédito correspondiente al autor o autores originales y a la fuente. proporcionar un enlace a la licencia Creative Commons e indicar si se realizaron cambios. Las imágenes u otro material de terceros en este artículo están incluidos en la licencia Creative Commons del artículo, a menos que se indique lo contrario en una línea de crédito al material. Si el material no está incluido en la licencia Creative Commons del artículo y su uso previsto no está permitido por la regulación legal o excede el uso permitido, deberá obtener el permiso directamente del titular de los derechos de autor. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by/4.0/.

Reimpresiones y permisos

Kalantari, A., Szczepanik, M., Heunis, S. et al. Cómo establecer y mantener un conjunto de datos de investigación animal multimodal utilizando DataLad. Datos científicos 10, 357 (2023). https://doi.org/10.1038/s41597-023-02242-8

Descargar cita

Recibido: 19 diciembre 2022

Aceptado: 15 de mayo de 2023

Publicado: 05 junio 2023

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

Cualquier persona con la que compartas el siguiente enlace podrá leer este contenido:

Lo sentimos, un enlace para compartir no está disponible actualmente para este artículo.

Proporcionado por la iniciativa de intercambio de contenido Springer Nature SharedIt