reales - Documentación automática de conjuntos de datos.

libro de android studio en español pdf

Question

Estoy trabajando en un proyecto en este momento donde he ido acumulando lentamente un montón de variables diferentes de un montón de fuentes diferentes. Siendo una persona un tanto inteligente, creé un subdirectorio diferente para cada uno en un directorio principal "datos originales" e incluí un archivo .txt con la URL y otros descriptores de donde obtuve los datos. Al ser una persona insuficientemente inteligente, estos archivos .txt no tienen estructura.

Ahora me enfrento a la tarea de compilar una sección de métodos que documente todas las diferentes fuentes de datos. Estoy dispuesto a revisar y agregar estructura a los datos, pero luego necesitaría encontrar o crear una herramienta de informes para escanear los directorios y extraer la información.

Esto parece algo que ProjectTemplate ya tendría, pero parece que no puedo encontrar esa funcionalidad allí.

¿Existe tal herramienta?

Si no es así, ¿qué consideraciones deben tenerse en cuenta para proporcionar la máxima flexibilidad? Algunos pensamientos preliminares:

1. Se debe usar un lenguaje de marcado (¿YAML?)
2. Todos los subdirectorios deben ser escaneados
3. Para facilitar (2), se debe usar una extensión estándar para un descriptor de conjunto de datos
4. Críticamente, para hacer esto lo más útil, debe haber alguna forma de hacer coincidir los descriptores de las variables con el nombre que finalmente toman. Por lo tanto, todo el cambio de nombre de las variables se debe hacer en los archivos de origen en lugar de en un paso de limpieza (menos que ideal), el motor de documentación debe realizar un análisis de código para realizar un seguimiento de los cambios de nombre de las variables (¡ugh!), O algunos Se debe utilizar un híbrido más simple, como permitir que los nombres de variable se especifiquen en el archivo de marcado.
5. Lo ideal sería que el informe también tuviera una plantilla (por ejemplo, "Extrajimos la variable [var] del conjunto de datos [dset] el [fecha]"), y posiblemente lo vinculamos a Sweave.
6. La herramienta debe ser lo suficientemente flexible como para no ser demasiado pesada. Esto significa que la documentación mínima sería simplemente un nombre de conjunto de datos.

Answer 1

Esta es una muy buena pregunta: la gente debería estar muy preocupada por todas las secuencias de recopilación de datos, agregación, transformación, etc., que forman la base de los resultados estadísticos. Desafortunadamente, esto no se practica ampliamente.

Antes de responder a sus preguntas, quiero enfatizar que esto parece estar bastante relacionado con el objetivo general de administrar la procedencia de los datos . También podría darle un enlace de Google para leer más. :) Hay un montón de recursos que encontrará, como las encuestas, las herramientas de software (por ejemplo, algunas enumeradas en la entrada de Wikipedia), varios proyectos de investigación (por ejemplo, el Reto de la procedencia ) y más.

Eso es un comienzo conceptual, ahora para abordar cuestiones prácticas:

Estoy trabajando en un proyecto en este momento donde he ido acumulando lentamente un montón de variables diferentes de un montón de fuentes diferentes. Siendo una persona un tanto inteligente, creé un subdirectorio diferente para cada uno en un directorio principal "datos originales" e incluí un archivo .txt con la URL y otros descriptores de donde obtuve los datos. Al ser una persona insuficientemente inteligente, estos archivos .txt no tienen estructura.

Bienvenidos a la pesadilla de todos. :)

Ahora me enfrento a la tarea de compilar una sección de métodos que documente todas las diferentes fuentes de datos. Estoy dispuesto a revisar y agregar estructura a los datos, pero luego necesitaría encontrar o crear una herramienta de informes para escanear los directorios y extraer la información.

No hay problema. list.files(...,recursive = TRUE) puede convertirse en un buen amigo; Véase también listDirectory() en R.utils .

Vale la pena señalar que completar una sección de métodos en las fuentes de datos es una aplicación estrecha dentro de la procedencia de los datos. De hecho, es bastante desafortunado que la Vista de Tareas CRAN sobre Investigación Reproducible se enfoque solo en la documentación. Los objetivos de la procedencia de los datos son, en mi experiencia, un subconjunto de investigación reproducible, y la documentación de la manipulación de datos y los resultados son un subconjunto de la procedencia de los datos. Por lo tanto, esta visión de la tarea todavía está en su infancia en relación con la investigación reproducible. Puede ser útil para sus objetivos, pero eventualmente lo superará. :)

¿Existe tal herramienta?

Sí. ¿Qué son esas herramientas? Mon dieu ... es muy centrado en la aplicación en general. Dentro de R, creo que estas herramientas no reciben mucha atención (* ver más abajo). Eso es bastante desafortunado: o me estoy perdiendo algo o la comunidad R se está perdiendo algo que deberíamos estar usando.

Para el proceso básico que ha descrito, normalmente uso JSON (vea esta respuesta y esta respuesta para comentarios sobre lo que estoy haciendo). Para gran parte de mi trabajo, represento esto como un "modelo de flujo de datos" (ese término puede ser ambiguo, por cierto, especialmente en el contexto de la computación, pero lo digo desde una perspectiva de análisis estadístico). En muchos casos, este flujo se describe a través de JSON, por lo que no es difícil extraer la secuencia de JSON para abordar cómo surgieron los resultados particulares.

Para proyectos más complejos o regulados, JSON no es suficiente, y yo uso bases de datos para definir cómo se recopilaron, transformaron, etc. Los datos regulados, la base de datos puede tener mucha autenticación, registro y más, para asegurar que los datos La procedencia está bien documentada. Sospecho que ese tipo de DB está más allá de su interés, así que sigamos adelante ...

1. Se debe usar un lenguaje de marcado (¿YAML?)

Francamente, todo lo que necesite para describir su flujo de datos será adecuado. La mayoría de las veces, me parece adecuado tener un buen JSON, un buen diseño de directorios de datos y una buena secuencia de secuencias de comandos.

2. Todos los subdirectorios deben ser escaneados

Hecho: listDirectory()

3. Para facilitar (2), se debe usar una extensión estándar para un descriptor de conjunto de datos

Trivial: ".json". ;-) O ".SecretSauce" también funciona.

4. Críticamente, para que esto sea lo más útil, debe haber alguna forma de hacer coincidir los descriptores de las variables con el nombre que finalmente toman. Por lo tanto, todo el cambio de nombre de las variables se debe hacer en los archivos de origen en lugar de en un paso de limpieza (menos que ideal), el motor de documentación debe realizar un análisis de código para realizar un seguimiento de los cambios de nombre de las variables (¡ugh!), O algunos Se debe utilizar un híbrido más simple, como permitir que los nombres de variable se especifiquen en el archivo de marcado.

Como se dijo, esto no tiene mucho sentido. Supongamos que tomo var1 y var2 , y creo var3 y var4 . Quizás var4 es solo un mapeo de var2 a sus cuantiles y var3 es el máximo de observación var1 y var2 ; o podría crear var4 partir de var2 truncando valores extremos. Si lo hago, ¿conservo el nombre de var2 ? Por otro lado, si te refieres a simplemente hacer coincidir "nombres largos" con "nombres simples" (es decir, descriptores de texto con variables R), esto es algo que solo puedes hacer. Si tiene datos muy estructurados, no es difícil crear una lista de nombres de texto que coincidan con nombres de variables; alternativamente, podría crear tokens sobre los cuales se podría realizar la sustitución de cadenas. No creo que sea difícil crear un CSV (o, mejor aún, JSON ;-)) que haga coincidir el nombre de la variable con el descriptor. Simplemente continúe verificando que todas las variables tengan cadenas de descriptores coincidentes, y deténgase una vez que haya terminado.

5. Idealmente, el informe también tendría una plantilla (por ejemplo, "Extrajimos la variable [var] del conjunto de datos [dset] el [fecha]."), Y posiblemente lo vinculemos con Sweave.

Ahí es donde se pueden aplicar las sugerencias de roxygen y roxygen2 .

6. La herramienta debe ser lo suficientemente flexible como para no ser demasiado onerosa. Esto significa que la documentación mínima sería simplemente un nombre de conjunto de datos.

Hmm, estoy perplejo aquí. :)

(*) Por cierto, si quieres un proyecto FOSS relacionado con esto, visita Taverna . Se ha integrado con R como se documenta en varios lugares. Esto puede ser excesivo para sus necesidades en este momento, pero vale la pena investigar como un ejemplo de un sistema de flujo de trabajo bastante maduro.

Nota 1: Debido a que frecuentemente uso bigmemory para grandes conjuntos de datos, tengo que nombrar las columnas de cada matriz. Estos se almacenan en un archivo descriptor para cada archivo binario. Ese proceso fomenta la creación de descriptores que relacionan nombres de variables (y matrices) con descriptores. Si almacena sus datos en una base de datos u otros archivos externos que admitan el acceso aleatorio y el acceso múltiple a R / W (por ejemplo, archivos asignados en memoria, archivos HDF5, cualquier cosa que no sean archivos .rdat), es probable que la adición de descriptores se convierta en algo natural.