Requerimientos

Limitaciones y alcances

✔️ El manejo del portal de microdatos es bastante sencillo. Se selecciona la base de datos que se quiere visualizar, la cual se encuentra asociada a alguna entidad, y se ingresa al recurso para explorarlo y/o descargarlo; adicionalmente, es posible identificar cuándo y quién cargó la información (la trazabilidad de las operaciones). La visualización preliminar de los datos se hace a través de un formato estandarizado (Excel), con el fin de que puedan ser consultados por el mayor número de personas; no obstante, el portal recibe varios formatos en función de lo que puede componer un dataset: diccionario, presentaciones en Power Point, scripts en R, etc. Esto implica que un dataset debe tener, como mínimo, un Excel (o un TXT o CSV para bases de datos de varios millones de registros) en tanto es el formato que permite estructurar y establecer una visualización de los datos, tal y como se muestra en el siguiente ejemplo:

Vista preliminar de una base de datos en formato Excel

Existen bases de datos muy pesadas. Por ejemplo, el Registro Único de Víctimas cuenta con aproximadamente 9 millones de registros, y eso dificulta abrir el archivo; para solucionar la limitación, el procedimiento que se sigue es dividir la información entre las diferentes hojas de Excel, con el fin de que cualquier persona la pueda consultar y utilizar el recurso desde este formato; de lo contrario, son bases de datos que deben ser descargadas en formatos TXT o CSV. Para el caso específico de la Comisión de la Verdad, las bases de datos que cuentan este proceso son: RUV, SPOA y Sistema de Información de Justicia y Paz de la Fiscalía.

La visualización de los datos en el portal de microdatos depende 100% de cuántos registros tenga el archivo. No es posible visualizar, dentro del portal, una base de datos con un número significativo de registros.

✔️ Los requerimientos de máquina (infraestructura), dependen de la cantidad de recursos almacenados a través del aplicativo. Al existir bases de datos de grandes tamaños, crece el consumo de recursos; esto puede llevar a que los servidores colapsen. A medida que aumenta el sistema, deben aumentar los recursos.

✔️ El portal de microdatos permite visualizar tablas, mapas y gráficos; sin embargo, los mapas y los gráficos presentan ciertas limitantes para estructurar la visualización, ya que muchas de las bases de datos contenidas en el repositorio, no cuentan con una georreferenciación adecuada (solo cuentan con el nombre de un municipio, por ejemplo) para generar el mapa; y, muchas otras, al ser tan grandes, poseen demasiadas variables que hacen que su graficación sea compleja. En este sentido, estas dos posibilidades visuales no son aprovechadas por la herramienta.

Lo que se realiza para suplir estas limitantes es definir unas tablas dinámicas que permiten interpretar la base de datos de manera más sencilla; no obstante, este ejercicio depende del proceso de investigación y de la base de datos. En otras palabras, es un proceso que se hace solo cuando es solicitado desde los equipos de investigación, ya que implica alterar las tablas originales (se quitan datos o se hace un proceso de depuración); en este sentido, dentro de los dataset no se encuentran tablas dinámicas, ya que es un alternativa para el ejercicio de investigación y no un recurso del dataset.

Las bases de datos que tienen el campo geoespacial, se disponen en el geoportal de la Comisión de la Verdad (ver documentación de geoportal).

✔️Cada dataset entregado a la Comisión de la Verdad se documenta a partir de los oficios y/o expedientes que acompañan su proceso de entrega y recepción. En la Comisión de la Verdad, estos documentos se archivan en el FileServer, clasificándolos de acuerdo con la entidad que entrega: entidad pública, entidad privada o Comisión de la Verdad (para las bases de datos originadas por la institución).

✔️ Los dataset se clasifican, entre muchas otras cosas, a partir de licencias. Estas licencias establecen la manera en que cada dataset debe ser usado; es decir, son las condiciones en las que el contenido del recurso puede ser utilizado, distribuido o reproducido. Para mayor información visitar: https://opendefinition.org/licenses/.

Recomendaciones para la interacción con el código fuente CKAN

✔️ Es importante entender la arquitectura de CKAN, basada en la inyección de dependencias, con el fin de poder hacer modificaciones al código. Una de las limitantes tiene que ver con la complejidad de la estructura y la poca documentación existente al respecto. En efecto, la inyección de dependencias implica que para cambiar una funcionalidad, se debe crear una nueva que modifique la existente (no es posible modificar la funcionalidad directamente); esto conlleva a que el desarrollo se de en función de herencias que complejizan la estructura del aplicativo: las funcionalidades no desaparecen, sino que se ocultan y se ejecutan las nuevas instrucciones.

La documentación de CKAN es poca y sencilla, lo que dificulta articularse con el código. Según el equipo de ingenieros, la documentación no habla de la estructura del código, sino de algunas capas: el núcleo donde se hacen las consultas, la capa donde se procesan los datos y finalmente la interfaz donde se visualizan.

Por lo general las herramientas de software libre no entregan una gran documentación del código. Esto implica un trabajo adicional para el ingeniero desarrollador, el cual tiene que hacer un estudio de ese código que puede demandarle una importante inversión de tiempo.

✔️ La versión de CKAN que se usó para el desarrollo del portal de microdatos de la Comisión de la Verdad, combina dos Framework para el desarrollo web: Flask y WZ Werkzeug. En este sentido, una de las dificultades fue estabilizar ambos Framework, en tanto una parte del desarrollo funciona en Flask y otra parte funciona en WZ Werkzeug. Adicionalmente, adaptar el plugin DDI tuvo también un nivel de dificultad en tanto era necesario adaptarlo para las especificidades de la Comisión de la Verdad.