Documentación automática de conjuntos de datos

Question

Estoy trabajando en un proyecto en este momento en el que poco a poco he estado acumulando un montón de variables diferentes de varias fuentes diferentes. Siendo una persona algo inteligente, creé un subdirectorio diferente para cada uno en un directorio principal "original_data", 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 documenta todas las diferentes fuentes de datos. Estoy dispuesto a analizar y agregar estructura a los datos, pero luego tendría que 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 una herramienta de este tipo?

Si no es así, ¿qué consideraciones se deben tener en cuenta para proporcionar la máxima flexibilidad? Algunas ideas preliminares: (? YAML)

1. Un lenguaje de marcas deben utilizarse
2. Todos los subdirectorios se deben analizar los
3. Para facilitar (2), una extensión estándar para un descriptor conjunto de datos se debe utilizar
4. Críticamente, para hacer esto más útil, tiene que haber alguna manera de hacer coincidir los descriptores de variables con el nombre que finalmente asumen. Por lo tanto, o bien el cambio de nombre de las variables debe hacerse en los archivos fuente 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 rastrear los cambios de nombre de variable (ugh!), O Se debe usar un híbrido más simple, como permitir que los nombres de las variables se especifiquen en el archivo de marcado.
5. Idealmente, el informe también se modelaría (por ejemplo, "sacamos la variable [var] del conjunto de datos [dset] el [fecha].") Y posiblemente se vinculó con Sweave.
6. La herramienta debe ser lo suficientemente flexible como para no ser demasiado gravosa. 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 hacer hincapié en que esto parece bastante relacionado con el objetivo general de la gestión data provenance. También podría darle un Google link para leer más. :) Hay una gran cantidad 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 Provenance Challenge) y más.

eso es un comienzo conceptual, ahora para hacer frente a cuestiones prácticas:

que estoy trabajando en un proyecto en este momento en el que se han ido acumulando lentamente un montón de diferentes variables de un montón de diferentes fuentes. Siendo una persona algo inteligente, creé un subdirectorio diferente para cada uno en un directorio principal "original_data", 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.

Bienvenido a la pesadilla de todos. :)

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

No hay problema. list.files(...,recursive = TRUE) podría convertirse en un buen amigo; ver también listDirectory() en R.utils.

Vale la pena señalar que el llenado en una sección de métodos en fuentes de datos es una aplicación estrecha dentro de la procedencia de los datos. De hecho, es desafortunado que el CRAN Task View on Reproducible Research se centre únicamente en la documentación. Los objetivos de la procedencia de los datos son, en mi experiencia, un subconjunto de la 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 con respecto a la investigación reproducible. Puede ser útil para sus objetivos, pero eventualmente lo superará. :)

¿Existe una herramienta de este tipo?

Sí. ¿Cuáles son esas herramientas? Mon dieu ... está 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 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 utilizo JSON (consulte this answer y this answer para obtener comentarios sobre lo que estoy haciendo). Para gran parte de mi trabajo, represento esto como un "modelo de flujo de datos" (dicho término puede ser ambiguo, por cierto, especialmente en el contexto de la informática, pero lo digo desde el punto de vista del 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 determinados resultados.

Para proyectos más complejos o regulados, JSON no es suficiente, y uso bases de datos para definir cómo se recolectaron, transformaron, etc. Para proyectos regulados, la base de datos puede tener mucha autenticación, registro y más en ella, para garantizar que la procedencia de los datos esté bien documentada. Sospecho que ese tipo de DB es mucho más allá de su interés, por lo que vamos a pasar ...

1. Un lenguaje de marcado se debe utilizar (YAML?)

Francamente, lo que sea necesario para describir su flujo de datos será adecuado. La mayoría de las veces, me parece adecuado tener un buen JSON, buenos diseños de directorio de datos y buena secuencia de scripts.

2. todos los subdirectorios deben ser escaneados

realizarse: listDirectory()

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

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

4. críticamente, para que este más útil es necesario que haya alguna manera para que coincida con los descriptores de variables con el nombre que finalmente adquieren. Por lo tanto, o bien el cambio de nombre de las variables debe hacerse en los archivos fuente 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 rastrear los cambios de nombre de variable (ugh!), O Se debe usar un híbrido más simple, como permitir que los nombres de las variables 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 de var1 y var2; o podría crear var4 desde var2 al truncar valores extremos. Si lo hago, ¿conservo el nombre de var2? Por otro lado, si se refiere simplemente a emparejar "nombres largos" con "nombres simples" (es decir, descriptores de texto a variables R), entonces esto es algo que solo usted puede hacer. Si tiene datos muy estructurados, no es difícil crear una lista de nombres de texto que coincidan con los nombres de las variables; alternativamente, podría crear tokens en los que se podría realizar una sustitución de cadena. No creo que sea difícil crear un archivo CSV (o, mejor aún, JSON ;-)) que coincida con el nombre de la variable en el descriptor. Simplemente siga comprobando que todas las variables tengan cadenas de descriptores coincidentes, y deténgase una vez hecho.

5. Lo ideal sería que el informe sería de plantilla, así (por ejemplo, "Sacamos la [var] variable a partir de [DSET] conjunto de datos el [fecha]."), Y posiblemente ligados a Sweave.

Ahí es donde pueden aplicarse las sugerencias de otros roxygen y roxygen2.

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

Hmm, estoy perplejo aquí. :)

(*) Por cierto, si quiere un proyecto de FOSS relacionado con esto, consulte Taverna. Ha sido integrated with R según lo documentado en varios lugares. Esto puede ser excesivo para sus necesidades en este momento, pero vale la pena investigarlo como un ejemplo de un sistema de flujo de trabajo decentemente maduro.

---

Nota 1: Porque yo utilizo con frecuencia 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 coincidan con nombres de variables (y matrices) con descriptores. Si almacena sus datos en una base de datos u otros archivos externos que admiten acceso aleatorio y acceso R/W múltiple (por ejemplo, archivos mapeados en memoria, archivos HDF5, cualquier cosa menos archivos .rdat), probablemente encontrará que agregar descriptores se convierte en algo natural.