CATALOGACIÓN COLABORATIVA
Last updated
Last updated
El módulo de catalogación colaborativa es un aplicativo que permite, uno, crear recursos a través de la carga de archivos, su disposición en el árbol de fondos (carpetas) y su posterior descripción y catalogación a partir de metadatos (anclaje para la búsqueda); y dos, editar recursos (editar o crear metadatos) provenientes de otros entornos como las visualizaciones, los microdatos, etc. Los recursos que se crean y administran desde este aplicativo, son los insumos que alimentan el motor de búsqueda usado por la Comisión de la Verdad.
El módulo está pensado para crear recursos a partir dos tipos de fuentes: fuentes de archivo internas (información misional creada a través del trabajo colaborativo dentro de la Comisión -FAI-), y fuentes de archivo externas (información no estructurada aportada por otras entidades y acopiada por la Comisión de la Verdad -FAE-); las demás fuentes de datos, si bien pueden ser administradas desde la herramienta (es decir, descritas y catalogadas a partir de metadatos para su indexación en el metabuscador), son creadas desde otros entornos como ArcGIS, CKAN, Tableau, etc.
El módulo de catalogación colaborativa es la herramienta que permite gestionar todos los recursos que tiene la Comisión de la Verdad, excepto las entrevistas; para éstas existe la herramienta . La gestión de recursos implica su disposición en fondos y la creación o modificación de metadatos.
El metabuscador de la Comisión de la Verdad existía como una herramienta para filtrar y navegar por el lago de datos que se encuentra en MongoDB; siendo MongoDB un contenedor que recibe información de muchas fuentes. Al inicio, esta información era recogida y recopilada a través de un software libre y de código abierto llamado Omeka. No obstante, y debido al alto volumen de información, Omeka comienza a fluctuar y a presentar fallas con cada renderización del árbol de fondos (carpetas). Adicionalmente, y debido al carácter misional de la información, se ve la necesidad de restringir campos y agregar campos especiales (campos con información geográfica, por ejemplo), sin tener que romper la estructura de datos ya definida; y es allí donde Omeka presenta más restricciones que facilidades. Es en este momento donde se opta por no seguir adaptando el código, sino desarrollar una herramienta a la medida, con un formulario dinámico que permita resolver las necesidades de catalogación sin renunciar a la estructura de datos ya definida por la Comisión. En otras palabras, adaptar Omeka requería adaptar la estructura de datos y los procesos ya definidos, a lo que la herramienta ofrecía; y, hacer esto, implicaba generar nuevos procesos tal vez no acordes con el propósito misional de la organización.
Había dos necesidades: uno, construir una metadata mucho más completa, que no podía ser soportada por las aplicaciones que ya existían (Omeka interna y Omeka externa); y un segundo problema que había con estas herramientas, como manejamos volúmenes de datos tan grandes, las aplicaciones (Omeka interna y Omeka externa) ya no estaban respondiendo. Hicimos un par de cosas para que respondieran, pero ya llegó un momento donde ya ellas se caían por el peso de los datos. Es decir, se hacía una consulta sobre el árbol de fondos y no los mostraba, y ya quedaba la aplicación ahí...