Seguro que habéis oido que el 80% del tiempo de un proyecto de datos se dedica a organizar y limpiar los datos, y el resto a analizarlos, ¿o era el 90%? Desde luego cualquiera que se haya puesto manos a la obra, habrá experimentado que es una cantidad de tiempo no despreciable.

Lo que sigue es una serie de consejos que tienen como objetivo crear conjuntos de datos más ordenados para facilitar la tarea del analista, y reducir, así, el tiempo para obtener resultados. Son recomendaciones básicas orientadas a datos estructurados (tablas) aunque algunas recomendaciones también aplican a datos con texto libre. Si se te quedan cortas puedes encontrar útil otras guías más avanzadas [1].

Tened en cuenta que muchas de las aplicaciones y lenguajes de programación han sido desarrollados con el idioma y la cultura anglosajona en mente, lo que hace que algunas de las recomendaciones pueden sonar un tanto peregrinas vistas desde la perspectiva latina.

Primeramente, incluyo un resumen con los puntos que hay comprobar antes de compartir un conjunto de datos, y seguidamente se desarrollan cada una de estos puntos.

Resumen

Si hubiera que resumir en un único consejo sobre cómo organizar los datos sería:

Sigue tu corazón pero, por favor, sé consistente en tus decisiones.

Además, antes de compartir el conjunto de datos mi recomendación es que revises que cumplas los siguientes puntos:

• Datos tabulares organizados en un fichero por cada tabla
• Formato del archivo CSV (separado por , o por ;), o TSV (separado por tabuladores).
• Nombre del archivo relevante.
• Los datos en cada tabla tienen que cumplir:
  • Primera fila reservada para la cabecera.
  • Nombre de las variables relevantes sin incluir espacios.
  • Utilizar el punto como separador decimal.
  • No incluir el separador de miles.
  • Los valores de las variables categóricas deberían ser descriptivos.
  • Codificar correctamente los valores perdidos.
  • Utilizar una representación los más estándar posible para codificar fechas (YYYY-MM-DD) y horas (hh:mm:ss).
• Codificación del texto UTF-8.
• Documentación del conjunto de datos.
• No incluir información que pueda identificar personas directa o indirectamente.

1. Organización del conjunto del datos

Las tablas son la manera más habitual de organizar datos estructurados. Una tabla es una estructura en dos dimensiones que se compone de filas y columnas. Cada fila se corresponde con una observación, y cada columna con los valores de distintas variables relativas a esa observación. Si tuvierais conjuntos de observaciones distintas tendrían que organizarse en tablas separadas y almacenarlas en un fichero por cada tabla. Esto es lo que se conoce como tidydata [2].

1.1 El formato de archivo más recomendable para compartir tablas es CSV (Comma-Separated Value). Los separadores de campos deberían ser , o ;

Ejemplo de archivo CSV

Altura,Peso,Genero
1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M

Una alternativa muy interesante es el formato TSV (Tab-Separated Value) que emplea el tabulador como separador.

Si no es posible obtener un archivo en CSV ó TSV, y dado su enorme popularidad, otra alternativa son los formatos nativos de Excel, XLSX, o XLS. En este caso, es imporante que se incluya una única hoja por archivo, y no se añada información de formato (por ejemplo, no incluir colores, o formatos condicionales) ni fórmulas. Únicamente el puro dato siguiendo las indicaciones de esta guía.

También se puede compartir un enlace a una hoja de cálculo en Google Drive.

En el caso de que los datos no estructurados (texto libre) o con una estructura compleja, los formatos preferidos son JSON y XML.

Si el archivo es pesado, hay que comprimirlo en formato ZIP, y si fuera muy pesado separarlos en  múltiples archivos. Evitar utilizar otras extensiones como RAR.

1.2 El nombre del archivo del conjunto de datos debería ser un resumen relevante de su contenido. No incluyais espacios dentro del mismo, acentos, ni nuestra querida ñ.

Ejemplo

2019-calificaciones-cienciadatos.csv

mejor que:

misdatos.csv

2. Organización de una tabla

Una serie de reglas básicas que tiene que cumplir cada tabla que compartamos:

2.1 La primera fila se denomina cabecera, y se reserva para el nombre de las variables. Siempre se incluye la cabecera, y no se incluyen más filas antes de la cabecera (ni tan siquiera vacías), ni al final de los datos. La cabecera tiene que comenzar en la primera columna, es decir, no dejar columnas vacias a la izquierda de la primera variable.

En el ejemplo anterior la cabecera es:

Altura,Peso,Genero

Un ejemplo incorrecto de archivo sería:

1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M

ya que no tiene la cabecera.

Tampoco sería válido:

Archivo que incluye distintas medidas de peso y altura 
Altura,Peso,Genero
1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M

ya que incluye una primera línea antes de la cabecera.

El siguiente ejemplo también es incorrecto debido a que aparecen filas adicionales después de los datos.

Altura,Peso,Genero
1.65,59,F
1.80,85,M
1.72,95,M
1.83,68,F
1.66,70,M
Media=1.74,Media=75.4
F=2, M=3

2.2 El nombre de las variables tiene que ser descriptivo, sin incluir espacios, y empleando únicamente caracteres anglosajones (sin acentos, ni ñ).

Ejemplos válidos

RentaPerCapita, Rentapercapita, RENTAPERCAPITA, Renta_per_capita

mientras que habría que evitar:

Renta per capita, Renta, RPC

El primer ejemplo incluye espacios dentro del nombre de la variable. El segundo ejemplo es un nombre poco claro ya que no se sabe a qué tipo de renta se refiere. Si se utilizan siglas y abreviaturas, hay que asegurarse que son aceptadas y conocidas por la amplia mayoría de los usuarios del datos.

Eligamos nombres en inglés si nuestro conjunto de datos tienen vocación internacional.

2.3 Utilizar el punto (.) como separador decimal. Este es un problema muy típico cuando se exportan datos de un programa como Excel y la configuración del idioma está en Español, ya que por defecto utiliza la coma como separador. Desde 2010, la RAE recomienda utilizar el punto en lugar de la coma con el fin de unificar criterios [3].

Así, el siguiente ejemplo sería incorrecto:

Altura,Peso,Genero
1,65;59;F
1,80;85;M
1,72;95;M
1,83;68;F
1,66;70;M

2.4 No incluir el separador de millares. Cuando escribimos un número en un texto, habitualmente se separa en grupos de tres cifras para faciltar la lectura del mismo. En cambio, de cara al análisis de datos este separador no tiene ninguna función, es más dificulta el análisis independientemente del separador que se use (espacio en blanco, coma o punto) ya que hay que eliminarlo antes de poder utilizar el dato.

Por ejemplo, su en una celda el dato es cien mil, la única manera válida de representarlo es:

100000

Por el contrario, las siguientes representaciones son incorrectas:

100 000
100,000
100.000

2.5 No incluir la unidades de medida en la misma celda que el dato. Es fundamental indicar las unidades de medida de cada variable (véase el punto 4) pero nunca acompañando al propio dato.

El siguiente ejemplo es incorrecto:

Altura,Peso,Genero
1.65 m,59 kg,F
1.80 m,85 kg,M
1.72 m,95 kg,M
1.83 m,68 kg,F
1.66 m,70 kg,M

2.7 Los valores de las variables categóricas deberían ser descriptivos, y tener el mismo formato. Una variable categórica es aquella que puede tomar un número limitado y fijo de valores como, por ejemplo, género, colores, o paises.

Las variables categóricas suelen ser fuente de errores, y hay que ser cuidadoso para asegurar que una  categoría no se representa con distintos valores.

Tres comprobaciones básicas

• Elegir nombres descriptivos de las categorías. Si se emplean siglas o abreviaturas, tienen que ser ampliamente aceptados. Hay que evitar codificar con números estas variables, así mejor F y M, que 0 y 1.
• Asegurarse que todos los valores se escriben con el mismo formato de minúsculas y mayúsculas. Escogamos un formato (FEMENINO, femenino, ó Femenino), y mantengamos fiel a él en todas las variables categóricas.
• Revisar que una misma categoría no tiene distintos valores. La casuística es variada. Por ejemplo, puede ocurrir que se hayan cometido errores ortográficos (ej. femnino), que se hayan utilizado sinónimos (ej. varon, masculino), que se hayan combinado nombres y abrevituras/siglas (ej. masc, masculino), múltiples combinaciones de las anteriores, o nuevas alternativas que se me pasan.

El siguiente ejemplo contiene errores en la variable categoríca:

Altura,Peso,Genero
1.65,59,Femenino 
1.80,85,Masc 
1.72,95,Masculino 
1.83,68,Femenino 
1.66,70,Masclino

Cuando se establece un orden entre las categorías se denominan variables ordinales, como por ejemplo, intervalos en una medición (bajo, moderado, alto), calificaciones (suspenso, aprobado, notable sobresaliente), o medallas (oro, plata, bronce).

En este caso aplican las mismas reglas que hemos visto para las variables categóricas con la salvedad que algunas variables ordinales se representan correctamente con valores númericos. Por ejemplo, la posición en una competención es mejor codificarla numéricamente (1, 2, 3…) que utilizar los cardinales (primero, segundo, tercero…).

2.8 Codificar correctamente los valores perdidos. Es posible que nos dispongamos datos de todas las observaciones, y que algunas celdas se nos hayan quedado vacias. Ahora bien, también es común codificar estas celdas con algún valor numérico fuera del rango de posible valores en vez de dejarlas vacías, por ejemplo, 0, -1o 999.  Esto puede llevar a dos errores:

1. El valor empleado para codificar el perdido realmente también sea un valor válido, y estamos codificando dos informaciones distintas de la misma manera. Por ejemplo, en una variable como RentaPerCapitapuede pasar que el 0represente que la persona no haya querido revelar sus ingresos, o que no tenga ingresos.
2. En el proceso de elaboración del conjunto de datos se comete un error, y se baila o se cambia una cifra del valor perdido, y se convierte en un valor válido, o viceversa.

El siguiente ejemplo ilustra este problema codificando los perdidos con 999:

Altura,Peso,Genero
1.65,59,F
999,85,M
1.72,99,M
1.83,999,F
1.66,70,M

En la tercera fila de datos, ¿es el 99un valor válido, o se han olvidado un 9al incluirlo?

Es preferible, dejar las celdas vacías, o utilizar una etiqueta como NA (Not Available) que identifique inequivocamente que es un valor perdido.

Más claro en el siguiente ejemplo:

Altura,Peso,Genero
1.65,59,F
NA,85,M
1.72,NA,M
1.83,NA,F
1.66,70,M

Y, por supuesto utilizar la misma manera de codificarlos en todas las variables.

2.9 Utilizar una representación los más estándar posible para codificar fechas y horas. Existe un reportorio de formatos para representar fechas y horas que incluso llegan a dificultar muchas veces la propia comprensión del dato 03/11/1978  ¿hace referencia al 3 de noviembre, o al 11 de marzo? Pues depende de la nacionalidad de a quién le preguntes. Además, esta variedad incluye elegir entre distintos símbolos para separar los campos, sustituir los meses del año por su nombre o abreviaturas de los mismo.

Reglas básicas

• Como mínimo, y no me cansaré de decirlo, deberíamos ser coherente y emplear la misma representación en todo el fichero.
• Evitar utilizar los nombres de los meses ya que son dependientes del idioma.
• Representar los años con cuatro cifras.
• Restringuirse al guión (-) o la barra (/) como separadores.
• Indicar en la documentación cualquier particularidad que pudiera tener la representación escogida. Por ejemplo, la posición de los días y de los meses.

El siguiente fichero incumple las reglas anteriores:

Altura,Peso,Genero,FechaNac
1.65,59,F,19 de marzo de 1982
1.80,85,M,3-11-1978 
1.72,95,M,18/Jan/1996
1.83,68,F,7/4/14
1.66,70,M,15 de Febrero, 2001

Idealmente deberíamos seguir el formato establecido en el estándar internacional ISO 8601 [4].

En esta representación, las fechas se codifican como YYYY-MM-DD siendo YYYYel año entre 0000 y 9999, MM el mes entre 01 y 12, y DD el día entre 01 y 31.

Ejemplo, el 23 de marzo de 2019 sería:

2019-03-23

Podríamos omitir el día, si quisieramos representar sólo año y mes, y seguiría siendo una fecha en formato válido:

2019-03

Con las horas tenemos también nuestro quebraderos de cabeza aunque son menos frecuentes. Principalmente, hay que tener en cuenta que las horas siempre se representan bajo el sistema de 24 horas, nunca se emplea el sistema de 12 horas donde se divide el día en dos mitades mediante los marcadores AM (Ante Meridiem) y PM (Post Meridiem) para hacer referencia a la hora antes o después del mediodía.

En ISO 8601, la información horaria tiene el siguente formato hh:mm:ss siendo hhlas horas entre 00 y 23, mm los minutos entre 00 y 59, y ss los segundos entre 00 y 59.

Ejemplo

18:03:45

Si queremos representar información horaria en diferentes zonas horarias emplearemos el estándar UTC (Coordinated Universal Time)  [5] que refleja la diferencia relativa respecto a la zona horaria de referencia (UTC±00:00, meridiano de Greenwich) [6].

Por ejemplo, México se encuentra oficialmente en UTC-06:00, es decir, seis horas menos que la zona horaria de referencia, mientras que la España peninsular se encuentra en UTC+01:00. Para añadirle más complejidad al tema, algunas paises cambian sus horarios en verano, cambiando en consencuencia su desplazamiento respecto a la hora de referencia que es fija. Así, México en verano se convierte en UTC-05:00, y la península en UTC+02:00.

En ISO 8601, se representaría la hora de la zona horaria de referencia (UTC±00:00) y el desplazamiento que hay que sumar o restar para obtener la hora local. El formato sería hh:mm:ss±hh:mm. En el caso de la hora de referencia se sustituye el desplazamiento por una Z.

Ejemplo

Las diez y ocho (10:08) de la mañana en UTC±00:00 sería en horario de inverno las 4:08 en Ciudad de México (UTC-6), y las 11:08 en Valencia (UTC+1). En formato ISO 8601:

10:08:00Z
10:08:00-06:00
10:08:00+01:00

Finalmente, indicar que se pueden combinar fechas y horas separándolas por una T.

Ejemplo

2019-03-23T18:03:45

3. Codificación del texto

La codificación del archivo debería ser UTF-8. Existen múltiples codificaciones que organizan la información de un archivo de manera distinta. Cuando se abre un archivo es preciso indicar la codificación correcta, ya que en caso contrario ciertos caracteres, como las vocales acentuadas, o la ñ pueden aparecer mal.  Este es un tema que trae muchos dolores de cabeza, ya que distintos programas guardan la información con distinta codificación. Afortunadamente cada vez más se tiende a que los archivos se distribuyan con esta codificación.

4. Documentación

Es muy útil incluir un archivo con información adicional que contenga la descripción y significado de cada variable. Este archivo debería contener, al menos, para cada variable: nombre,  tipo, unidades de medida, rango de valores permitidos, y descripción.

Un posible ejemplo de fichero de documentación:

Relación entre altura y peso por género
5 Observaciones, 3 Variables

RESUMEN:

Este conjunto de datos contiene medidas de la altura, peso, y 
genéro de cinco individuos (3 hombres y 2 mujeres).

FUENTE:

Las medidas fueron realizadas, inicialmente, por Pablo A. Haya a 
cuatro compañeros ficticios de trabajo seleccionados al azar. 
Posteriormente, se añadió una medida adicional de un compañero 
ficticio igualmente seleccionado al azar.  

DESCRIPCIÓN DE LAS VARIABLES:

Altura   (continua)   Altura del individuo en metros. 
Peso     (continua)   Peso del individuo en kilogramos. 
Genero   (categórica) M - Masculino o F - Femenino

FORMATO:

CSV separado por comas con valores perdidos codificados con NA

5. Datos de caracter personal

En ningún caso, se debe incluir información de carácter personal (nombres, NIF, direcciones IP, cuentas de correo electrónico, usuarios de redes sociales…). La manera más segura de proceder es eliminar los campos de carácter personal del conjunto de datos.

Si es necesario preservar las columnas, un primer paso es disociarlos, sustituyendo los datos personales por valores autogenerados, por ejemplo, cambiando los NIF por números aleatorios, o los nombres por nombres escogidos al azar de una lista.

Si tenemos variables tablas relacionadas por un dato de caracter personal (ej. NIF) es necesario preservar la coherencia entre ambas, de manera que en el proceso de disociacion el número que escogamos para sustituir el NIF de un individuo sea el mismo en las dos tablas.

Hay que tener en cuenta que según el Reglamento General de Protección de Datos (RGPD) de la UE [7], dato personal es toda información sobre una persona física identificada o identificable ya sea directa o indirectamente. Es posible que hayas eliminado todos los identificadores personales, y aun así sea posible inferir la identidad de una persona. Por ejemplo, a partir de las variables de nuestro ejemplo (Altura, Peso, Genero) podríamos localizar un individuo concreto si conocieramos y tuvieramos bien acotada la población de donde hemos seleccionado la muestra.

Con todo esto, si tienes en tu poder datos de caracter personal, lo primero que tendrías que hacer es asegurarte que cumples con la RGPD, ya que, entre otras múltiples consideraciones es preciso que dispongas del consentimiento explícito e informado de estas personas para disponer y tratar sus datos.

Referencias

1. How to share data with an statistician from Leek group guide to data sharing [Acceso: 2019-08-10] https://github.com/jtleek/datasharing

2. Tidy Data. Hadley Wickham [Acceso: 2019-08-10] http://vita.had.co.nz/papers/tidy-data.pdf

3. Ortografía de la lengua española (Versión beta) de la Real Academia Española y Asociación de Academias de la Lengua Española (2010). Edición en línea (www.rae.es). [Acceso: 2019-08-10] http://aplica.rae.es/orweb/cgi-bin/v.cgi?i=fuRhOImVQKYykcp,

4. ISO 8601 «Elementos de datos y formatos de intercambio — Intercambio de información — Representación de fechas y horas» [Acceso: 2019-08-10] https://es.wikipedia.org/wiki/ISO_8601

5. Coordinated Universal Time from Wikipedia, the free encyclopedia [Acceso: 2019-08-10] https://en.wikipedia.org/wiki/Coordinated_Universal_Time

6. List of UTC time offsets from Wikipedia, the free encyclopedia [Acceso: 2019-08-10] https://en.wikipedia.org/wiki/List_of_UTC_time_offsets

7. Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE (Reglamento general de protección de datos) [Acceso: 2019-08-10] https://www.boe.es/buscar/doc.php?id=DOUE-L-2016-80807