Quiero compartir (1) códigos de programación y (2) conjuntos de datos relacionados con un proyecto de investigación.
Si bien conozco superficialmente algunas plataformas adecuadas, no puedo calibrar sus pros y sus contras con demasiada profundidad porque carezco de experiencia. (Además, muchas de sus páginas "Acerca de nosotros" no son demasiado informativas). Esto es lo que conozco:
Primero, en cuanto a códigos, parece que la mejor plataforma sería GitHub . Tienen una gran audiencia de codificadores e incorporan un sistema de control de versiones para garantizar una colaboración transparente.
En segundo lugar, en lo que respecta a los conjuntos de datos relacionados con la ciencia, parece que Open Science Framework (OSF), Zenodo , Dryad y Figshare se encuentran entre las mejores opciones. Asignan DOI, vinculan automáticamente su perfil a ORCID, se adhieren a principios de ciencia abierta altamente confiables (por ejemplo, C0PE) y son plataformas impulsadas por la comunidad sin fines de lucro. (Me opondría a, digamos, Mendeley Data , que pertenece a una gran editorial comercial).
Ahora me pregunto lo siguiente:
Si quiero publicar un artículo y compartir sus códigos y conjuntos de datos, ¿cuál sería el mejor enfoque?
(a) ¿Debería dividirlos compartiendo el código en GitHub y compartiendo los conjuntos de datos en, digamos, OSF ?
(b) ¿Debo compartir códigos y conjuntos de datos en una sola plataforma? Si es así, ¿qué criterios podría utilizar antes de elegir la plataforma adecuada?
Cada plataforma tiene sus usos, por lo que es mejor usar GitHub para su código y un repositorio de archivo de datos científicos, como Zenodo , para su código y datos.
GitHub le permite compartir su código de una manera que fomenta la colaboración a través de estrellas, problemas, bifurcaciones, solicitudes de incorporación de cambios y notificaciones. Así que definitivamente ponga una copia de su código allí. Sin embargo, GitHub no está diseñado para garantizar la permanencia de los repositorios alojados. Por ejemplo, siempre se puede eliminar por completo un repositorio a través de la interfaz de GitHub y también eliminar o modificar el código antiguo con un impulso forzado de Git. A más largo plazo, no podemos saber si la empresa que controla GitHub (solía ser GitHub, ahora es Microsoft) continuará operándolo de una manera que sirva a la ciencia. Considere cuántos productos y servicios corporativos han desaparecido o cambiado de rumbo en los últimos veinte años, incluso los que provienen de grandes empresas establecidas, como Google (consulte esta lista) o Sun Microsystems después de que fuera adquirida por Oracle (licencias de Java y Solaris).
En consecuencia, para una mejor garantía de la permanencia y disponibilidad de su trabajo para futuros científicos, también debe colocar sus datos y código en un repositorio de datos científicos, como Zenodo. Esto asociará un DOI con sus artefactos depositados, que se vinculará permanentemente a la versión correspondiente. (Una vez que carga algo en Zenodo, casi no hay posibilidad de deshacer la acción). GitHub y Zenodo incluso le ofrecen la posibilidad de archivar una versión específica de GitHub en Zenodo .
Si el volumen de los datos es grande o es probable que se use solo con frecuencia, sepárelos del código y cargue cada uno en Zenodo como un conjunto de datos separado. Zenodo le permite vincular los dos (y también el repositorio de GitHub) con los metadatos de "Identificadores relacionados". Puede usar los identificadores Compilesy Compiled bypara vincular el código con los datos, y el Supplement toidentificador para vincular su repositorio de GitHub.
Para ver un ejemplo de una división asociada con un gran conjunto de datos, considere este conjunto de datos con respecto a la vida útil de las líneas de código (3,7 GB), el software asociado y el repositorio de GitHub del software . Por ejemplo, una división asociada con un conjunto de datos utilizable de forma independiente, considere esta lista de repositorios creados por empresas y el paquete de replicación asociado .
Si el volumen de datos es modesto, está bien (o quizás mejor) combinar los dos en una sola carga de Zenodo, como es el caso de este paquete con respecto a la finalización de los enlaces de Wikipedia .
Como usuario, definitivamente me gustaría obtener ambos en el mismo lugar. Pero si hay vínculos claros entre los dos sitios, no me rendiré solo porque tengo que hacer clic un par de veces más. Entonces, en ese frente, no es muy diferente para mí.
Como creador, primero determinaría si los códigos son esenciales para las personas que usarán los datos. Por ejemplo, los códigos para el procesamiento y la importación de datos, la gestión y el etiquetado de variables, la imputación faltante y la construcción de escalas/índices deberían estar razonablemente con el conjunto de datos. Otros códigos más periféricos, como el análisis de regresión realizado para el segundo manuscrito, probablemente sea mejor quedarse con la publicación. Dentro del código es fácil volver a vincular donde se alojan los datos, por lo que se debe conservar la vinculación.
Otra característica a la que prestaré atención es si el repositorio le permite presentar publicaciones generadas a partir de los datos. Si lo hacen, entonces tendría sentido colocar el código de análisis allí. Si no es así, los mantendría separados o ese análisis se sentiría muy fuera de contexto.
El sentido de permanencia también puede ser un factor. Para el repositorio, probablemente solo envíe los datos esperando que no se actualice nada. Si un análisis aún está en curso y los códigos se actualizarán y publicarán activamente, consideraría algo más dinámico como GitHub.
Además, verifique a dónde irían sus colegas o personas en su campo. Esas deberían ser opciones seguras.
El código siempre debe estar en GitHub (u otras plataformas de control de versiones). Muchos investigadores no se esfuerzan mucho en las buenas prácticas de programación, pero aprender a usar el control de versiones correctamente es la mejor práctica para desarrollar su proyecto y la mejor práctica para compartir el código con otros. También resulta ser la mejor manera de manejar la colaboración con los coautores.
Para los datos que no son "grandes", clasificaría sus opciones de esta manera:
La última opción es la mejor porque puede alojar sus datos donde quiera y simplemente actualizar la parte de recuperación de su código si necesita moverlo, y luego solo necesita distribuir enlaces a su código. Sincronizar su código con su repositorio de GitHub funciona bien si no es un conjunto de datos muy grande; de lo contrario, esto se vuelve inviable.
Si sus datos son "grandes", probablemente quiera ver algo como S3.
Azor Ahai -él-