Tidyverse: colección de paquetes de R para la ciencia de datos

[VeruGHub]

Hola,

¡Tenemos nueva nota ecoinformática para revisar! @OliviaLorente-Casalini y colaboradores han escrito una nota con una introducción al conjunto de paquetes englobados en tidyverse, sus perspectivas futuras y tutoriales de las funciones principales.

Archivo Word: 2745-Texto del artículo-14062-2-2-20240415.docx

Queda abierta la revisión grupal hasta el día 8 de mayo. Aquí podéis leer cómo funciona el proceso de revisión abierta.

Gracias por vuestra participación.

[VeruGHub]

@MalditoBarbudo ¿te animas a revisar esta nota? :)

[juliagdealedo]

Hola. Muchas gracias Olivia Lorente-Casalini y coautores por la nota. Me ha resultado muy interesante y bien explicada, a grandes rasgos, una nota muy útil para la comunidad. También el material suplementario en zenodo añade la información necesaria para profundizar en tydiverse para quien quiera.

Lo único que se me ocurre para mejoraralo sería añadir después de cada código de R el resultado del objeto creado. No sé si lo alarga demasiado y tampoco considero que sea totalmente necesario, pero lo propongo para que os lo planteéis, ya que creo que quedaría más claro qué hace cada función.

Eg. L121, añadir

head(penguins_tb_mean, 4)
A tibble: 15 × 5
island species year bill_length_mm_mean bill_depth_mm_mean

1 Biscoe Adelie 2007 38.3 18.4
2 Biscoe Adelie 2008 38.7 18.1
3 Biscoe Adelie 2009 39.7 18.6
4 Biscoe Gentoo 2007 47.0 14.7

Por lo demás tengo pocos comentarios, y todos menores.
L52. Se podría añadir la lista de los 8 paquetes de tidyverse, como se ha hecho en Rbase en L36-37.
L92. Aquí se podría añadir algún ejemplo de los problemas o las mejoras?
L93. “Lo lee como un tibble” > “tidyverse lee bases de datos en formato tibble” ?
L104. “Lo lee como un data frame” > “Rbase lo lee como un dataframe”
L132. Quizás dar una breve explicación de qué es una tabla en “formato largo”? Algo como: "tidyr tiene como objetivo el cambio entre bases de datos en formato “ancho” (e.g. matriz) a formato “largo”, e.g. bases de datos ordenadas." ?
L164. Indicar en algún lugar que la función fct_revel() no cambia el orden de los datos en el dataframe, sino internamente el orden de los factores, siendo especialmente útil y visible en los gráficos. Lo comento porque si vemos la tabla tras hacer un fct_revel, no vemos diferencias en su orden (comparado con Rbase, que sí cambia la tabla per se).
L176. Entiendo que se prefiere no poner tildes en los comentarios de R. En caso que fuera un despiste, “gráfica” va con tilde.
L224. Evitaría “previamente desarrolladas”, no es claro si está refieriéndose a las funciones anteriormente desarroladas en tidyverse (pasado) o a aquellas expuestas en este mismo artículo anteriormente. Especificaría.
L313. Por lo que he entendido, la figura es original del artículo. Sin embargo, confunde el logo de quarto al final. Si lo que indica es que la comunicación ha de hacerse a través de quarto, lo pondría algo más pequeño al lado derecho del cuadrado “comunicar”. Actualmente, al estar en la base de la figura, parece que es la “firma” de la figura.

Eso sería todo, cualquier duda extra aquí estamos.

Enhorabuena por el trabajo!

Julia gdealedo

[ajcanepa]

Hola,
Lo primero agradecer a Olivia Lorente-Casalini y coautores por la nota.

En general está muy bien explicado y sobretodo se mantienen neutros en la discusión.

Aún así, me gustaría aportar algunos comentarios/opiniones.

1. Como en el comentario anterior de @juliagdealedo agregaría los resultados de los códigos, ya que tanto en un formato .pdf como .html, se podrá leer muy bien el código y el output de la salida.
2. Si bien se habla de la filosofía común de Tidyverse, no se muestra un ejemplo claro (sólo se previsualiza uno con la función purrr::map() en el que los paquetes se unan en un hilo conductor común de análisis de datos, por lo que sugiero que se agregue un ejemplo final aludiendo precisamente a esto, no solo a explicar cada función sino a concatenar 2 o 3 funciones (readr + group_by + summarize + ggplot2) en una única tubería (pipeline) hasta el gráfico final. De esta manera se verá una clara diferencia con R base.
3. En el documento se revisan las funciones más comunes de cada paquete, yo agregaría una descripción un poco más elaborada y un enlace al paquete en cuestión.
4. En el documento, cuando se habla de forcats, yo definiría brevente lo que es un factor. Si queremos que sirva para introducir a la "gente nueva" es importante no encontrarse de frente con un nombre factor sin saber lo que es.

Por lo demás está muy bien.

Enhorabuena por el trabajo,

Antonio (Toño)

[OliviaLorente-Casalini]

Gracias por vuestros comentarios y sugerencias @juliagdealedo y @ajcanepa, muy útiles para mejorar el trabajo.

@VeruGHub hoy era el último día para la revisión? En principio, espero indicaciones para ponernos manos a la obra.

Olivia

[VeruGHub]

Gracias @juliagdealedo y @ajcanepa por vuestros comentarios en el artículo. Encuentro que son muy útiles y animo a los autores a integrar todos ellos en la nota. Por limitaciones de espacio es difícil añadir los resultados de los códigos. En este sentido, mi recomendación es que los autores valoren incluir los que sean más importantes para la comprensión del script si fuera posible e incluyan las figuras creadas que se pueden añadir sin mucho problema de espacio.

@OliviaLorente-Casalini et al, enhorabuena por la nota. Me ha gustado mucho y me parece muy util la presentación de scripts con las mismas funcionalidades en Rbase y en tidyverse para facilitar "el trasvase" de los usuarios de uno a otro "dialecto" y del otro al primero.

Tras una lectura de la nota me gustaría también añadir otros comentarios a considerar antes de la publicación de la misma:

1. Me parece que si váis a dar una definición de ciencia de datos que se publique en una revista científica esta debe ser precisa; si no, mi recomendación es omitirla ya que no es el objetivo del artículo. No me atrevería a llamar a la "ciencia de datos" como una ciencia entendida como tal y no lo he visto en ningún sitio definido así. Además, la ciencia de datos no emplea necesariamente algoritmos de aprendizaje automático si no que pueden emplearse o no. Wickham et al. (2023) ofrece una definición informal que no se ajusta tampoco exactamente a la que ponéis y que complementaría con más fuentes si decidís dejarlo.
2. También se me hace raro que en el repositorio de zenodo hayáis explicado las funciones principales de todos los paquetes menos dos.
3. El objetivo del artículo es presentar el meta-paquete tidyverse y, en mi opinión, para que sea completo falta completar la discusión con algunas de sus limitaciones, no tanto desde el punto de vista del usuario. Por ejemplo, las funciones de tidyverse cambian más rápidamente que las de Rbase limitando la reproducibilidad de los scripts.
4. Los scripts incluidos en la nota no son reproducibles. Quizás poséis omitir el ejemplo de readr y crear los data.frames/tibble al ilustrar tibble

@OliviaLorente-Casalini si estás de acuerdo con los comentarios y quieres seguir con el proceso de revisión, por favor, valora las sugerencias y responde a los revisores si en algo no estás de acuerdo utilizando este issue. Cuando tengas la siguiente versión puedes subirla aquí y te agradecería que nos indicaras al hacerlo los principales cambios que has hecho respecto a la anterior versión.

[OliviaLorente-Casalini]

Respuesta a los comentarios de @juliagdealedo

Lo único que se me ocurre para mejoraralo sería añadir después de cada código de R el resultado del objeto creado. No sé si lo alarga demasiado y tampoco considero que sea totalmente necesario, pero lo propongo para que os lo planteéis, ya que creo que quedaría más claro qué hace cada función.

Hemos dejado el output del ejemplo de tibble para que se vean bien las diferencias respecto a data.frame y hemos añadido las figuras generadas a través del ejemplo de pipeline (también añadido a sugerencia de @ajcanepa).

L52. Se podría añadir la lista de los 8 paquetes de tidyverse, como se ha hecho en Rbase en L36-37.

Añadido L50

L92. Aquí se podría añadir algún ejemplo de los problemas o las mejoras?

Añadido L95 y L96

L93. “Lo lee como un tibble” > “tidyverse lee bases de datos en formato tibble” ?
L104. “Lo lee como un data frame” > “Rbase lo lee como un dataframe”

Explicado y añadido L96 a L99

L132. Quizás dar una breve explicación de qué es una tabla en “formato largo”? Algo como: "tidyr tiene como objetivo el cambio entre bases de datos en formato “ancho” (e.g. matriz) a formato “largo”, e.g. bases de datos ordenadas." ?

Añadido L133 a L135

L164. Indicar en algún lugar que la función fct_revel() no cambia el orden de los datos en el dataframe, sino internamente el orden de los factores, siendo especialmente útil y visible en los gráficos. Lo comento porque si vemos la tabla tras hacer un fct_revel, no vemos diferencias en su orden (comparado con Rbase, que sí cambia la tabla per se).

Indicado dentro del código, L175 a L177. Además, se ha modificado en el script de chunks del repositorio.

L176. Entiendo que se prefiere no poner tildes en los comentarios de R. En caso que fuera un despiste, “gráfica” va con tilde.

Sí, hemos preferido no añadir tildes. Somos conscientes de que existen codificaciones para trabajar con ello (e.g. UTF-8), pero seguía dando algunos problemas y hemos decidido dejar el código limpio de caracteres "extraños".

L224. Evitaría “previamente desarrolladas”, no es claro si está refieriéndose a las funciones anteriormente desarroladas en tidyverse (pasado) o a aquellas expuestas en este mismo artículo anteriormente. Especificaría.

Se ha eliminado la frase que hacía alusión a esta idea de funciones “previamente desarrolladas”

L313. Por lo que he entendido, la figura es original del artículo. Sin embargo, confunde el logo de quarto al final. Si lo que indica es que la comunicación ha de hacerse a través de quarto, lo pondría algo más pequeño al lado derecho del cuadrado “comunicar”. Actualmente, al estar en la base de la figura, parece que es la “firma” de la figura.

Modificado conforme a lo sugerido.

De nuevo, gracias por los comentarios que nos han ayudado a mejorar la nota.

[OliviaLorente-Casalini]

Respuesta a los comentarios de @ajcanepa

1. Como en el comentario anterior de @juliagdealedo agregaría los resultados de los códigos, ya que tanto en un formato .pdf como .html, se podrá leer muy bien el código y el output de la salida.

Hemos optado por añadir el output de la creación de figuras a través del ejemplo de pipeline para mostrar la funcionalidad de tidyverse (tal y como hemos comentado también a @juliagdealedo).

2. Si bien se habla de la filosofía común de Tidyverse, no se muestra un ejemplo claro (sólo se previsualiza uno con la función purrr::map() en el que los paquetes se unan en un hilo conductor común de análisis de datos, por lo que sugiero que se agregue un ejemplo final aludiendo precisamente a esto, no solo a explicar cada función sino a concatenar 2 o 3 funciones (readr + group_by + summarize + ggplot2) en una única tubería (pipeline) hasta el gráfico final. De esta manera se verá una clara diferencia con R base.

Se ha añadido un ejemplo de pipeline L229 a L260. Además, se ha modificado en el script de chunks del repositorio.

3. En el documento se revisan las funciones más comunes de cada paquete, yo agregaría una descripción un poco más elaborada y un enlace al paquete en cuestión.

Se ha ampliado la definición y añadido el enlace en cada uno de los paquetes. readr (L87 y L88); tibble (L95 a L98); dplyr (L114 a L116); tidyr (L132 a L135); stringr (L154 a L157), forcats (L167, L168 y L170), ggplot2 (L185 y L186), purrr (L201 a L204).

4. En el documento, cuando se habla de forcats, yo definiría brevente lo que es un factor. Si queremos que sirva para introducir a la "gente nueva" es importante no encontrarse de frente con un nombre factor sin saber lo que es.

Añadido, L167 a L168.

Reiterar también a ti, @ajcanepa las gracias por los comentarios para mejorar el trabajo.

[OliviaLorente-Casalini]

Respuesta a los comentarios de @VeruGHub

1. Me parece que si váis a dar una definición de ciencia de datos que se publique en una revista científica esta debe ser precisa; si no, mi recomendación es omitirla ya que no es el objetivo del artículo. No me atrevería a llamar a la "ciencia de datos" como una ciencia entendida como tal y no lo he visto en ningún sitio definido así. Además, la ciencia de datos no emplea necesariamente algoritmos de aprendizaje automático si no que pueden emplearse o no. Wickham et al. (2023) ofrece una definición informal que no se ajusta tampoco exactamente a la que ponéis y que complementaría con más fuentes si decidís dejarlo.

Se modifica el texto de manera que no se pretende dar una definición de ciencia de datos y se complementa la información con otra fuente. L17 a L19.

2. También se me hace raro que en el repositorio de zenodo hayáis explicado las funciones principales de todos los paquetes menos dos.

L307 a L311. Se explica que esta nota es resultado de un grupo de trabajo de estudiantes de la Unidad Docente de Ecología de la Universidad de Alcalá y que, para ampliar información de la nota, pueden consultar el repositorio. Como resultado del grupo de trabajo se abordaron únicamente esos paquetes. Aunque no hay información en el repositorio, que es un material complementario, sí los hemos desarrollado para completar la publicación de la nota, de manera que en la publicación aparecen los 8 paquetes

3. El objetivo del artículo es presentar el meta-paquete tidyverse y, en mi opinión, para que sea completo falta completar la discusión con algunas de sus limitaciones, no tanto desde el punto de vista del usuario. Por ejemplo, las funciones de tidyverse cambian más rápidamente que las de Rbase limitando la reproducibilidad de los scripts.

Se complementa esta información desde L263 a L269.

4. Los scripts incluidos en la nota no son reproducibles. Quizás poséis omitir el ejemplo de readr y crear los data.frames/tibble al ilustrar tibble.

Desde el propio código empleado en la nota no se puede trabajar "directamente", ya que hay que utilizar el dataset de penguins.csv que está en el repositorio (indicado en L81 a L83). Entendemos que es una limitación, pero preferimos no eliminar el ejemplo de readr y mediante fork del repositorio de GitHub, está todo en abierto y disponible para que cualquiera pueda trabajar y repetir lo que se muestra.

Gracias a ti también @VeruGHub. Dejo por aquí el documento revisado
Ecosistemas_nota_tidyverse_definitivo_revisiones.docx

Un saludo,

Olivia

[VeruGHub]

@OliviaLorente-Casalini gracias por las respuestas y los cambios en el manuscrito.

Por mi parte es importante solucionar el tema de la reproducibilidad del código en la nota. Uno de los puntos que los revisores de las notas ecoinformáticas deben valorar es que el código funcione (https://github.com/ecoinfAEET/Notas_Ecosistemas/blob/master/directrices_revisores.MD). Para ello, dada la limitación de espacio, y para no cambiar la base de datos que luego utilizáis en los tutoriales, una buena solución en vuestro caso es explicar brevemente en el texto que read_csv funciona similar a read.csv, eliminar el ejemplo de código aquí (y eliminar los sucesivos read_csv/read.csv que se usan después) y remitir al lector a los tutoriales para ver un ejemplo de readr. A continuación en el siguiente chunk the código podéis poner:

penguins_tb <- tibble(penguins)
penguins_df <- data.frame(penguins)

De esta manera todo el script sería reproducible. La alternativa actual para que el código funcione resulta confusa. Aunque el uso de Git y GitHub está cada vez más extendido, muchos lectores de Ecosistemas no tienen una cuenta en GitHub y el concepto de copiar un repositorio mediante fork me parece avanzado y que igualmente no soluciona el problema de la reproducibilidad del script de la nota. De hecho quitaría esta sugerencia de hacer fork ya que los datos ya están disponibles para el usuario cuando cargas el paquete "palmerpenguins".

Una vez solucionado esto y si @juliagdealedo y @ajcanepa no tienen objeción, podemos continuar el proceso de publicación en la plataforma de la revista.

[ajcanepa]

@OliviaLorente-Casalini gracias por las respuestas y los cambios en el manuscrito.

Por mi parte es importante solucionar el tema de la reproducibilidad del código en la nota. Uno de los puntos que los revisores de las notas ecoinformáticas deben valorar es que el código funcione (https://github.com/ecoinfAEET/Notas_Ecosistemas/blob/master/directrices_revisores.MD). Para ello, dada la limitación de espacio, y para no cambiar la base de datos que luego utilizáis en los tutoriales, una buena solución en vuestro caso es explicar brevemente en el texto que read_csv funciona similar a read.csv, eliminar el ejemplo de código aquí (y eliminar los sucesivos read_csv/read.csv que se usan después) y remitir al lector a los tutoriales para ver un ejemplo de readr. A continuación en el siguiente chunk the código podéis poner:

penguins_tb <- tibble(penguins)
penguins_df <- data.frame(penguins)

De esta manera todo el script sería reproducible. La alternativa actual para que el código funcione resulta confusa. Aunque el uso de Git y GitHub está cada vez más extendido, muchos lectores de Ecosistemas no tienen una cuenta en GitHub y el concepto de copiar un repositorio mediante fork me parece avanzado y que igualmente no soluciona el problema de la reproducibilidad del script de la nota. De hecho quitaría esta sugerencia de hacer fork ya que los datos ya están disponibles para el usuario cuando cargas el paquete "palmerpenguins".

Una vez solucionado esto y si @juliagdealedo y @ajcanepa no tienen objeción, podemos continuar el proceso de publicación en la plataforma de la revista.

Por mi parte, todo OK. Adelante con la publicación.

[juliagdealedo]

Después de haber leído los cambios en el texto y los comentarios, encuentro el manuscrito listo para su publicación. Han sido buenas adiciones las funciones tibble y data.frame para que sea 100% reproducible, así como la adición del chunk completo con "pipes" para trabajar de una vez desde la importación de la base de datos hasta su representación gráfica.
PD. Solo recordar que para que sea reproducible además de al principio (L84, L85), también ha de estar en el "pipe" la función tibble() (L232 y L241 del ultimo doc Ecosistemas_nota_tidyverse_definitivo_revisiones.docx).

[OliviaLorente-Casalini]

@VeruGHub @ajcanepa @juliagdealedo

Subimos el archivo de nuevo, donde hemos intentado mantener el principio de reproducibilidad del código, de manera que únicamente con lo que aparece en los chunks de la nota pueda desarrollarse un flujo de trabajo desde el inicio (importando datos de archivos externos), y sin tener que hacer un fork del repo.

Ecosistemas_nota_tidyverse_definitivo_revisiones_25062024.docx

[OliviaLorente-Casalini]

PD. Me espero al visto bueno final antes de actualizar el repositorio, donde habrá que subir la versión final del script que incluye los chunks de la nota, y actualizar el DOI de Zenodo.

[VeruGHub]

Por mi parte adelante con la publicación. Enhorabuena, ha quedado muy bien. Gracias por mejorar la reproducibilidad de los scripts. Pasamos el proceso a la plataforma de la revista Ecosistemas @OliviaLorente-Casalini. Por favor, cuando subas la nota allí, acuerdate de cambiar en la línea 239 "penguins.csv" por "penguins1.csv" y en la 248 por "penguins2.csv".