DATOS. Limpieza de datos

Tablas complejas (.odt) (I)

Tablas-formulario y su contexto

Lo visto y trabajado en las entradas anteriores responde (y lo hace correctamente) a las situaciones más simples y favorables; aquellas en las que, con independencia de la cantidad de datos que contenga/n la/s tabla/s del .docx, su estructura es asimilable a la de los datos estructurados y el reto para la automatización se limita a identificar la tabla como tal, recorrerla y obtener su contenido. En estas labores y condiciones los recursos empleados han permitido dearrollar con éxito la automatización de la obtención de datos y su conversión a formatos de datos estructurados (por ejemplo, como .xlsx). Pero si en vez de trabajar con ese tipo de tablas tenemos que hacerlo con tablas como la que se muestra abajo, la cosa cambia radicalmente.

Es este un extracto del modelo de informe psicopedagógico, sólo de una pequeña parte de dicho documento, pero mucho más que suficiente para comprobar lo alejados que estamos en este caso de la sencillez de las fuentes de datos con las que hemos trabajado antes. En realidad es dudoso que ahora podemos hablar de tablas en sentido estricto, ya que lo que aquí mostramos tiene más de formulario (sobre tabla) que de tabla en sentido estricto.

Lo cierto es que el abordaje de este tipo de tabla-formulario suele hacerse en sentido inverso al que aquí se plantea: el reto suele consistir en automatizar la cumplimentación de estas "tablas" con un conjunto ya estrucurturado de datos a fin de automatizar parte de la composición del documento; eso que podemos llamar automatizar la composición de la carátula del informe (ver en este enlace cuestiones relativas a temática). Pero ahora nos estamos planteando automatizar la obtención de los datos contenidos en documentos creados mediante servicios de procesamiento de texto (.docx, .odt, por ejemplo) de este nivel de complejidad formal y estructural (eso que hemos llamado antes tabla-formulario) como recurso para la obtención de datos, a su vez, como parte de un proyectos de análisis de datos.

Veamos brevemente algunas diferencias entre estas tablas-formulario y una tabla sencilla:

• La disposición puede obedecer a la disposición fila-columna, pero la más frecuente obedece a la secuencia etiqueta->contenido
• Esta secuencia (etiqueta->contenido) se presenta en sucesiones lineales variadas, una vez o varias veces por linea de texto; aunque en todas se observa la distribución vertical de la estructura (disposición de bloques etiqueta->contenido, por oposición a la horizontal de la tabla simple: etiqueta - etiqueta - etiqueta ... |contenido - contenido - contenido...
• En una misma tabla (visualmente identificada como una unidad y localizable como tal desde el navegador del procesador de texto) se pueden mezclar diferentes presentaciones, además de fusiones de celdas y otras modificaciones respecto a la configuración dominante en la tabla.
• Además de las estrucuras anteriores y sus contenidos básicos de interés, las tablas pueden tener otros contenidos, como encabezados, subencabezados (para diferenciar secciones), textos explicativos...
• En ocasiones se pueden emplear controles de formulario, acentuando aun más la configuración de la tabla como formulario.
• En ocasiones también, en celdas de amplia extensión (toda la línea e incluso resultante de la fusión de celdas) se puede ubicar dentro de la estructura tabular un volumen importante de información en forma de contenido textual (de una o varias frases a párrafos enteros); este contenido requiere, cuanto menos, un tratamiento posterior como bloque de texto
• También se pueden anidar tablas (subformulario) dentro de la tabla principal.

Lo determinante de esta complejidad es la variedad de formulaciones y su combinación dentro del mismo documento y e incluso de la misma tabla. Ante tanta complejidad, script pensados para trabajar con tablas sencillas fracasan absolutamente, desmintiendo cualquier pretensión de universalidad. Esto sucede con independencia del tipo de documento que sea, .dpf, .docx o .odt. Ante esta complejidad, ¿cuál puede ser la alternativa?.

En principio podríamos pensar en la IA como alternativa; pero ni podemos asegurar el exito ni debemos darlo por supuesto; lo que rompe radicalmente la confiabilidad del recurso y obliga a la revisión sistemática y exhaustiva del resultado, con el coste de tiempo que esto supone. Pero la principal limitación de la IA es la ausencia de confidencialidad que implica, dado que no es viable la anonimación del contenido de las tablas, puesto que es precisamente la recuperación de sus datos (confidenciales) el motivo de la automatización del proceso. Existen alternativas que prometen respetar el anonimato de los datos y garantizar su correcto procesamiento, pero estas soluciones implican cargos económicos que no suelen estar al alcance de los SEO, y que no se justifican por el objetivo último que da sentido al tratamiento de esta documentación.

En resumen, estamos ante un posible callejón sin salida, aunque también cabe verlo como un proceso en el que ciertas tecnologías solamente pueden aportar soluciones parciales y relativamente satisfactorias; siendo necesaria la intervención "manual", la cual, a su vez, también puede ser auxiliada parcialmente mediante la tecnología. A falta de ¿mejores? opciones, menos es nada, pero no deja de ser "curioso" que el proceso inverso (cumplimentar documentos tabulares mediante asociación a bases de datos) haya sido tan temprana y eficientemente resuelto, y su reverso ofrezca tantas resistencia a la automatización. Pero sea curioso o no lo sea tanto, lo cierto es que es lo que hay.

En ausencia de procedimientos sencillos y universales de automatización, vamos a plantear en esta entrada y en las siguientes cómo abordar el tratamiento de estas tablas complejas, empezando por contextualizarlas en escenarios posibles, ya que no deja de resultar hasta cierto punto una anomalía que nodebería ser necesario abordar: lo lógico sería disponder de la base de datos que permitió "escribir" el contenido de esas tablas, pero la realidad es la contraria, muy frecuentemente y por muchas razones, empezando por la escasa práctica de automatizar la escritura de las tablas de este tipo de de domentos, siendo que sus "formularios" se rellenan tan manualmente como se componen los textos explicativos que pueden contener. Otra buena razón es que la procedencia o la antiguedad del documento haga inviable acceder a una supuesta fuente de datos que, casi con toda seguridad, no existe como conjunto estructurado. Para no tener que justificar lo que es difícilmente justificable, es en este segundo escenario donde nos vamos a situar, concretamente en el manejo de documentación propia de cierta antiguedad con fines de análisis de prácticas y de datos digitalizados en soporte documental.

El primer paso será obtener los documentos (tema de cierta complejidad que no corresponde abordar aquí, por lo que lo damos simplemente por resuelto) y el segundo unificar la tipología del soporte, optando en este caso por uniformar todos los documentos como .odt, dado que la arquiteftura interna de este soporte facilita el acceso a su contendio mediante código Python (pero tampoco es en esta entrada donde se tratan estas cuestiones técnicas, por lo que también las damos simplemente por resueltas). Partimos pues de que diponemos de un conjunto suficientemente amplio de documentos que contienen información de interés en una estructura compleja de tablas-formulario. Esta documentación ha sido transformada al formato .odt, lo que facilita su tratamiento mediante un conjunto de bibliotecas Python específicamente desarrolladas para procesar estos documentos. Lo que nos plantearemos a continuación, en las entradas que siguen, es cómo resolver distinto tipo de problemas o retos; desde el acceso al documento y la identificación de las tablas hasta la extracción masiva de datos o la obtención de todos los datos de un documento individual.Todo ello poco a poco y en las entradas que vienen.