# CATALOGACIÓN COLABORATIVA
## ¿Qué es?
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.
{% hint style="info" %}
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 [módulo de escucha](https://docsmoduloescucha.comisiondelaverdad.co/). La gestión de recursos implica su disposición en fondos y la creación o modificación de metadatos.
{% endhint %}
## ¿Cuál es su historia?
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í...*
# Funcionalidad
## Usuarios
El módulo de catalogación colaborativa funciona para tres clases de perfiles:
* **Gestores:** los gestores tienen un perfil especializado, con el que pueden gestionar todo el árbol de fondos: reorganizar la estructura de carpetas, mover recursos de un fondo a otro, eliminar, cargar y modificar recursos de manera masiva, etc. Adicionalmente, los gestores tienen la posibilidad de gestionar las listas para los formularios; y pueden realizar seguimiento a la labor realizada por cada uno de los catalogadores. Es el usuario que desarrolla toda la labor de gestión documental del proyecto.
* **Catalogadores:** los catalogadores son los usuarios que tienen un perfil a través del cual crean y modifican recursos. Lo primero, lo hacen a través del formulario de carga, donde suben el archivo, lo clasifican en un fondo y le agregan toda la metadata que lo describe y cataloga; lo segundo, lo hacen a través de la navegación por el árbol de fondos, donde pueden seleccionar un recurso y editar su metadata.
* **Usuarios:** los usuarios son aquellas personas que pueden buscar información navegando a través del árbol de fondos; no son catalogadores ni gestores, pero pueden, de manera colaborativa, aportar a la metadata a partir de unos pocos campos cerrados.
## Tareas que el sistema proporciona
### 1) Catalogador gestor.
La interfaz de catalogador gestor es la funcionalidad dentro del módulo que permite toda la labor que realizan los gestores. Es decir, a partir de allí los gestores pueden acceder a todo el árbol de fondos, o estructura de carpetas, el cual pueden reestructurar eliminando, moviendo o creando fondos (y/o modificando sus respectivos metadatos); pueden visualizar, a través de filtros, la gestión de los catalogadores; y pueden mover, modificar y/o eliminar recursos de manera masiva.
#### Actualización masiva de recursos:
La modificación masiva de recursos (de su metadata) se hace a través de la interfaz Actualización masiva de recursos. Allí se sube el archivo en Excel, con los datos modificados, se genera una validación con los registros existentes en la base de datos y finalmente se hace la unión.
#### Gestión de listas:
La gestión de listas se hace a través de la interfaz Gestión de listas, y permite a los gestores definir listas de manera dinámica; de esta manera, se crean listas que, automáticamente, van siendo cargadas por el formulario. Estas listas están homologadas con los términos y los campos semánticos definidos en el tesauro que ha desarrollado el equipo de lenguaje controlado de la Comisión de la Verdad.
### 2) Catalogadores.
La interfaz para catalogadores permite visualizar los recursos gestionados donde es posible modificar los metadatos (`Mis recursos`); adicionalmente, a través de esta funcionalidad, los catalogadores pueden crear nuevos recursos y/o fondos (los fondos pueden crearse, pero no eliminarse, ni moverse). La creación de los recursos se hace a través del formulario de carga el cual contiene unas categorías administrativas; unas categorías de nivel analítico para conocer el contenido (descripción o síntesis del producto -video, texto, mapa, etc.-); y unas categorías asociadas con las metas de la institución (por ejemplo, a cuál de los puntos del mandato apunta un producto particular -video, texto, mapa, etc.-).
### 3) Gestión de formularios.
La herramienta cuenta con una tarea adicional para gestionar formularios de manera dinámica; es decir, desde un usuario administrador, especializado, se pueden agregar o quitar campos de acuerdo con características o necesidades específicas de una institución particular. Esta funcionalidad permite que cada organización defina los metadatos con los que quiere catalogar y clasificar la información que carga.
# Requerimientos
## Limitaciones y alcances
### Requerimientos para la óptima ejecución del aplicativo
:heavy\_check\_mark: Cuando se intentan cargar archivos muy pesados, de 4 o 5 Gb, la aplicación no funciona debido a que la velocidad de subida es, generalmente, inferior a la velocidad de descarga. Se puede asociar con un error del aplicativo, pero se trata de un problema de red; cuando se tiene una latencia buena, el archivo sube sin problemas.
:heavy\_check\_mark: Se recomienda que el módulo de catalogación colaborativa vaya de la mano con un motor de búsqueda. La carga de información implica su posterior recuperación a partir de un buscador.
### Limitaciones y posibilidades de mejora
:heavy\_check\_mark: Una de las funciones que el módulo no hace y que podría ser una mejora importante, es la posibilidad de asignar y validar recursos; esta es una limitante importante dentro del proyecto. Al cierre de esta documentación, la asignación de recursos se hace de forma manual, donde el catalogador, a través de un identificador, accede a los recursos que le han sido asignados.
{% hint style="info" %}
Para que el metabuscador o los motores de búsqueda puedan renderizar algunas visualizaciones del módulo de catalogación colaborativa, es necesario modularizar algunas partes; para este proceso se recomienda usar Web Components y arquitecturas microfrontend. Para el caso de la Comisión de la Verdad, estos módulos se encuentran en desarrollo; no obstante, al integrar el módulo de catalogación colaborativa en procesos de otras organizaciones, es importante tener en cuenta este proceso.
{% endhint %}
# Entornos y metodologías
## Desarrollo
El desarrollo del módulo de catalogación colaborativa estuvo ceñido a los lineamientos ya establecidos dentro del metabuscador desarrollado en la Comisión de la Verdad, en tanto, en su momento, fue uno de los módulos funcionales de esta herramienta. En este sentido, hereda la arquitectura y las tecnologías usadas por el motor de búsqueda o metabuscador. Tenemos entonces los siguientes entornos:
### Tecnologías y arquitectura
**Para el FRONTEND:**
* ReactJS; versión 16.13.1
*
* Bootstrap; versión 4.4.1
*
* Material-UI; versión 4.11.4
*
* Template Metronic (al cierre de esta documentación, aún se utiliza el template; sin embargo, por no ser de uso libre, posiblemente sea retirado del desarrollo en la versión final).
*
**Para el BACKEND:**
* MongoDB; versión 5.0.3
*
* API RESTful que gestiona la data a través de NestJS (versión 7.1.5), escrito sobre el lenguaje de programación TypeScript (versión 4.2)
*
*
Para profundizar en la infraestructura utilizada por el aplicativo, se recomienda visualizar el siguiente documento:
{% file src="/files/WHZEyc0BEbe17hRmFRz2" %}
Configuración de servidores
{% endfile %}
:heavy\_check\_mark: Con [Python ](https://www.python.org/doc/)(versión 3) se generan algunos script para la corrección de datos.
:heavy\_check\_mark: Se consumen API de [ArcGIS](https://resources.arcgis.com/es/help/getting-started/articles/026n00000014000000.htm) para el manejo de información geográfica.
:heavy\_check\_mark: **Arquitectura orientada a servicios:** se continúa con la arquitectura implementada en el [metabuscador ](https://docsmetabuscador.comisiondelaverdad.co/)de la Comisión de la Verdad, en función de tener una identidad misional, y con el fin de reutilizar elementos ya existentes. Esta arquitectura permite ahorrar tiempos de desarrollo en tanto la estructura de datos, las distintas ETL y los diferentes procesos que resguardan la información en un mismo lugar, ya están definidos.
:heavy\_check\_mark: El software se encuentra dividido en dos niveles: el backend y el frontend. A nivel de backend, cada módulo administra una colección. Por ejemplo, el módulo `resource` administra la colección resource. Dentro de este módulo existen varias funcionalidades vitales del software. Por ejemplo, en `resource.service.ts`se gestiona parte del código que tiene que ver con los fondos y con los records; es decir, es el encargado de gestionar fondos (cuál es el fondo del recurso) y records (cuáles son los archivos asociados al recurso). Adicionalmente, es el módulo donde se gestiona la edición y la eliminación masiva de recursos; esto hace que sea un módulo robusto y complejo. La gestión de listas y la gestión de formularios, se llevan a cabo en el módulo de catalogación. A nivel de frontend, existe el componente`formfieldbootstrap.js` dentro del cual se administra el código que arma los campos de los formularios (es el componente maestro de los formularios); en este sentido, cada que haya un formulario, se gestiona desde este componente, de allí que también sea uno de los más robustos.
{% hint style="info" %}
Algunas vistas del módulo de catalogación colaborativa -visualizaciones geográficas, por ejemplo- se incluyen en el archivo del esclarecimiento de la Comisión de la Verdad a través de un Web Component que los empaqueta en archivos .js. Estos Web Component permiten que estas vistas de ReactJS sean catalogadas; con ello se asegura que puedan recuperarse como un recurso más dentro del archivo y el metabuscador.
{% endhint %}
### Manual de instalación y configuración
Para profundizar en la instalación y la configuración del módulo de catalogación colaborativa, la Comisión de la Verdad pone a disposición el siguiente archivo:
{% file src="/files/dkPk6zEyxD0cSCOPZLQ0" %}
Manual de instalación y configuración
{% endfile %}
### Metodologías
* **Programación Sprint Scrum:**
* Historias de usuario
* Definición de tableros y actividades (sprints)
* Planeación y seguimientos
* **GitLab:** se utiliza GitLab como herramienta para el control de versionamiento del proyecto.
* GitFlow: flujo de trabajo a través de ramas (branchs) que, de manera descentralizada, permite a varias personas trabajar en un mismo proyecto.
{% hint style="warning" %}
De acuerdo con la experiencia del equipo desarrollador, GitFlow, por sí solo, no es suficiente para evitar conflictos y/o borramiento de código dentro de un proyecto. Es necesario recurrir a los Merge request, con el fin de que una sola persona sea la encargada de identificar los conflictos y hacer las fusiones dentro de la rama principal.
[¿Qué es GitFlow?](https://www.atlassian.com/es/git/tutorials/comparing-workflows/gitflow-workflow) [¿Qué es Merge request?](https://docs.gitlab.com/ee/user/project/merge_requests/)
{% endhint %}
## Buenas prácticas
**Programación Scrum:** se recomienda trabajar bajo la metodología de programación Sprint Scrum, dado que es una metodología que permite la articulación fácil y rápida de modelos simples y funcionales, los cuales pueden ir evolucionando con el feedback y las necesidades del cliente.
Bajo esta metodología estaremos en función de un desarrollo iterativo o incremental, el cual consiste en dividir el trabajo en pequeñas partes o bloques temporales (sprint). Al final de cada etapa se entrega una funcionalidad completa. Para estructurar la evolución se recomienda crear el Mínimo Producto Viable (Minimum Viable Product, MVP): producto con suficientes características para satisfacer a los clientes y proporcionar retroalimentación para el desarrollo futuro.
**MVP:** herramienta que permite aprender mientras se desarrolla. Gracias a la iteración, el producto evoluciona y se reduce el tiempo para la validación de nuevas ideas.
**Estandarizar código:** definir unas reglas de trabajo; es decir, estandarizar la manera en que se van a crear y llamar las funciones, los métodos, las variables, los atributos, etc. La normalización del código es fundamental para el mantenimiento óptimo del desarrollo.
**Comentar el código:** es una buena práctica comentar el código a fin de que se convierta en un texto legible, autoexplicativo y facilite las modificaciones y el mantenimiento.
**Interacción con usuarios:** es una buena práctica tener entrevistas previas con los usuarios del sistema; dichos encuentros permiten entender los requerimientos puntuales y las funcionalidades concretas sobre las que debe basarse el desarrollo. Además, se recomienda encontrar un lenguaje común entre lo técnico del sistema y el requerimiento del usuario, a fin de no generar reprocesos y lograr comunicar fácilmente las funcionalidades del sistema.
# Colecciones DB
## Arquitectura DataBase
#### Colecciones usadas en MongoDB
_1.PNG?alt=media\&token=dcac38a6-8d15-443c-bb80-7da0c312e085)
Las colecciones Form, List y Options almacenan los campos, las listas y las opciones de lista que estructuran los diferentes formularios de carga que maneja el módulo de catalogación colaborativa.
Las colecciones ResourcesGroups, Resources y Record, son las colecciones que almacenan y gestionan los fondos, los recursos y los archivos asociados a cada recurso. Con ResourcesGroups se genera el árbol de fondos, y en Record se almacenan los archivos asociados a cada recurso (detallado con sus metadatos en Resources).
# Desarrolladores
La construcción del módulo de catalogación colaborativa surge como respuesta a la gran afluencia de información acopiada por la Comisión de la Verdad. La necesidad de una clasificación y descripción pertinente que permitiera catalogar todo el acopio de archivos, fue forjando, de manera particular y exclusiva, la estructura de datos. En este sentido, el módulo de catalogación colaborativa es una herramienta hecha a medida, la cual se adaptó a esta estructura y ha permitido la administración de la información acorde con estos lineamientos particulares.
Hace parte de una arquitectura previa, por ello, en un primer momento, funcionó integrado a lo que se denominó buscador o metabuscador, motor a través del cual se navega por todos los recursos acopiados por la organización. Este hecho ha implicado, al menos en las primeras fases de desarrollo, que varios desarrolladores toquen los mismos archivos y los mismos recursos, generando algunos conflictos a nivel del manejo de branches en el GitLab.
## ¿Por qué se ha logrado una buena herramienta?
Según el equipo desarrollador, una buena herramienta es aquella que hace lo que tiene que hacer, y lo hace bien. El módulo de catalogación colaborativa es una buena herramienta en tanto sirve para los procesos de la Comisión y las necesidades que surgen en materia de la carga de archivos, la estructuración de datos y el coleccionamiento de los recursos acopiados por la organización; en últimas, permite solucionar el problema de catalogar un conjunto de datos muy grande, sin que, por la magnitud de la información, se deba romper o rediseñar la estructura indefinidamente.
En un primer momento se utilizó Omeka para esta labor. Omeka es un aplicativo open source, desarrollado en PHP, que cuenta con una base de datos relacional; esta arquitectura limitó el flujo de carga cuando la información comenzó a crecer de manera exponencial. En efecto, el hecho de pasar de una estructura relacional a un árbol empezó a tener limitantes importantes: renderizar el árbol en la interfaz de usuario consumía recursos de máquina que hacían muy lento el proceso, se hacía necesario rediseñar constantemente la estructura de datos para adaptarla a lo que el software ofrecía ocasionando con ello que se perdiera la esencia del proceso, entre otros aspectos que llevaron a desarrollar una herramienta a medida.
Ahora bien, la herramienta no es un software complejo, puede ser definido como un módulo sencillo para cargar información; sin embargo, y es lo que lo convierte en una buena herramienta, el módulo es un engranaje importante dentro de todo el proceso de la Comisión de la Verdad, porque permite organizar y clasificar la información, para que luego pueda ser buscada. Sin esta herramienta, los procesos de catalogación, indexación y búsqueda, posiblemente, hubieran sido lentos.
La particularidad que caracteriza la estructura de datos y los procesos que posibilita el módulo, son los que hacen a la herramienta única para la Comisión de la Verdad; sin embargo, y a través de la gestión de formularios, la herramienta puede adaptarse a otras instituciones sin que sus respectivas estructuras de datos tengan que modificarse. Ahora bien, para que la herramienta sea funcional en otras entidades, debe ir acompañada de un motor de búsqueda que permita navegar por el mar de información que se clasifica y cataloga; es decir, no tiene mucho sentido si se carga información, pero no se busca en lo que se añade.
## Aprendizajes y experiencias
Los procesos misionales de la Comisión de la Verdad implican que profesionales de diferentes áreas generen diálogos y trabajo colectivo que lleven adelante las diferentes metas de cada proyecto. Implementar una herramienta para la administración de un volumen tan alto de información, requiere un trabajo colaborativo con las personas que van a usar la herramienta para la catalogación y la descripción de dicha información, y los ingenieros de software que se van a encargar de todo el proceso de desarrollo. En este sentido, los aprendizajes del equipo desarrollador vienen dados, en gran medida, por la interlocución con profesionales de otras áreas, por ejemplo, los catalogadores. Según el equipo desarrollador, la diferencia en las estructuras de pensamiento entre un equipo y otro fue un reto importante que abonó el terreno para las posibilidades de mejora que alberga la herramienta.
De acuerdo con lo anterior, y según el equipo de ingenieros, el desarrollo de la herramienta, durante sus primeras fases, estuvo cargado de varios reprocesos propiciados por la falta de una estructura común para la definición de los campos de los formularios; reprocesos que conllevaron a que el avance fuera lento y complejo: se necesitaron muchos cambios para llegar a lo que es hoy los formularios de carga para los distintos tipos de fuente de información que acopia la Comisión. No obstante, esta dificultad se convirtió en el insumo para el potencial de la herramienta: de un formulario estático, se convirtió en un formulario dinámico, estructurado a través de un pseudolenguaje, que permitió ir armando los diferentes campos. Este logro y aprendizaje del equipo, catapultó la herramienta para que pudiera ser adaptada a instituciones particulares a través de la gestión de formularios.
*Finalmente, luego de haber hecho el formulario dinámico, ya si pedían cambios no era tan traumático, porque el desarrollo estaba hecho para eso precisamente: si querían otro campo, yo escribía cinco líneas y ya, estuvo el nuevo campo... y adaptado de principio a fin, desde el momento en que aparece en el formulario, hasta que llega a la base de datos tipado donde debe estar. Una dificultad que se resolvió con desarrollo, porque catalogación necesitaba ver el formulario… es un proceso de retroalimentación necesario; ellos necesitaban ver cómo operaba el formulario, para hacer los ajustes o para ver qué era lo que se necesitaba, y sobre eso reconstruir. El problema es que fueron muchas iteraciones, entonces fue un poco tedioso…*
{% hint style="success" %}
El formulario dinámico es lo que más tiempo de desarrollo ha tenido; se hizo con el fin de adaptarse a las necesidades de catalogación y al ritmo de edición que presentaba el proceso. El equipo de catalogación necesitaba ver constantemente el formulario para ir tomando decisiones: crear, eliminar o modificar campos. En este sentido, el formulario dinámico es un formulario moldeable, que permitió este flujo de trabajo.
{% endhint %}
Estas iteraciones y constantes cambios, según el equipo, ha dejado una data sucia que se va limpiando con scripts construidos en Python; no obstante, más allá de ser una data sucia, da cuenta de los procesos de retroalimentación y mejora continua que se han seguido con el módulo de catalogación colaborativa.
El módulo permitió centralizar toda la información manejada por la Comisión en una misma interfaz gráfica, lo cual facilitó muchas tareas; adicionalmente, permitió entender la necesidad del usuario más allá de las historias de usuario (ver: [¿Qué es una historia de usuario](https://www.atlassian.com/es/agile/project-management/user-stories)?). Este último punto, generó la posibilidad de interactuar directamente con los usuarios en un diálogo que abonó el terreno para un escenario de construcción colectiva, donde se iba desarrollando y desplegando a producción, mientras se conversaba en mesas de trabajo; algo que, generalmente, no se hace en procesos Scrum para el desarrollo de software.
*Entendí que yo podría resolver y resolver historias de usuario, pero si no resolvía la necesidad del usuario, no tiene mucho sentido… entonces, uno como ingeniero es el que tiene la tarea de adaptarse al lenguaje y al discurso del otro, y eso llevado a la vida: uno es el que debe adaptarse y cambiar, y en el camino todo se transforma, todo se vuelve más tranquilo... de hecho, intenté llevar mi forma de pensar, mi discurso, mi pensamiento sistémico arraigado… pero nunca existía una comunicación tan chévere, hasta que empecé a flexibilizarme y a entender un poco la necesidad de ellos…*
# Usuarios
El equipo de catalogación del Sistema de Información Misional de la Comisión de la Verdad, es el equipo que, con mayor medida, ha utilizado la herramienta; adicionalmente, es el equipo que ayudó en la co-creación del módulo, trabajando de la mano con los ingenieros de desarrollo.
## Experiencias: aprendizajes, retos y oportunidades
La labor de catalogación, ha sido una de las labores más importantes dentro de la Comisión de la Verdad en tanto permite disponer y organizar la información que los investigadores necesitan para cumplir a cabalidad con la misión de esclarecimiento. En ese sentido, y según el equipo de catalogadores, el ejercicio práctico de describir y cargar información estructuró una labor esencial dentro del flujo de trabajo que se perfiló en la institución; adicionalmente, y debido a la gran cantidad de información recibida por la Comisión, no solo se estructuró una labor, sino también un equipo interdisciplinar importante.
### Apuestas y retos
La información recibida y acopiada por la Comisión de la Verdad ha generado retos importantes en tanto, debido a su diversidad y heterogeneidad, desdibuja los límites de lo que puede, eventualmente, ser una estandarización de datos. En este sentido, y según el equipo de catalogadores, homogeneizar o realizar un trabajo normalizado en la descripción de los datos, se convierte en una labor que conlleva cierto grado de dificultad; dificultad que se acrecienta por el alto volumen de información recibida. Dado este aspecto, y al menos en lo que respecta a los archivos de fuente externa (FAE), solo se han descrito, de manera individual, algunos archivos; el grueso de la información se encuentra descrita a partir de agrupaciones, carpetas gruesas o lo que dentro del módulo de catalogación colaborativa se denomina como fondos.
Ahora, si bien el alto volumen de información manejado por la entidad fue un reto importante para el grupo de catalogadores, también los escenarios cambiantes imprimieron un matiz inédito a todo el proceso de catalogación de la Comisión de la Verdad. En efecto, y de acuerdo con el equipo, primero se pensó en una biblioteca digital, luego en un centro documental (dado que la mayoría de la información estaba asociada con archivos de investigación), y, finalmente, con llegada del Covid-19, se puso sobre la mesa la urgencia de un escenario completamente virtual. Según los catalogadores, mucha información iba a ser resguardada de manera física, sobre todo porque el intercambio con las territoriales se daba de manera física; sin embargo, y con la llegada del virus SARS-CoV-2, no fueron posibles estos escenarios, y se puso sobre la mesa la urgencia de lo digital y los parámetros sobre el acceso y la seguridad de la información: qué información es pública, qué información requiere anonimización, qué información no puede ser pública, entre otros aspectos. Todas estas condiciones cambiantes llevaron al equipo a repensar muchos procesos para definir el sentido de los metadatos y la esencia de la descripción:
*Desde el inicio, no se había pensado que todo se iba a hacer en estos medios, y hay unos temas de derechos y accesos para los que tuvimos que dar cuenta porque, inicialmente, otras áreas estaban encargadas. Entonces, al principio era biblioteca digital, luego centro documental de un espacio físico. Nosotros reenfocamos todo, tuvimos que repensar los metadatos y la esencia de la descripción (a dónde le apuntaba para responder a eso). Luego ya no había espacio físico porque llegó la pandemia, ya no podíamos trabajar presencialmente, y, durante tres meses, el intercambio de información con las territoriales, que antes había intercambio físico, quedó cancelado. Ahí tocó volver a repensar todo. Luego nos dimos cuenta que estaba bastante complejo, porque la información que circula dentro de la Comisión de la Verdad es muy diversa...*
Todas estas condiciones desembocan en la necesidad de una herramienta a medida para disponer, describir y catalogar toda la información acopiada por la Comisión de la Verdad. De acuerdo con el equipo de catalogadores, el inicio del proceso de co-creación se centró en función de la gestión más básica: cumplir y darles la información a los investigadores; es decir, dado el corto tiempo de la institución, se requería algo rápido y funcional que permitiera cumplir a cabalidad con el objetivo de esclarecimiento.
El tema del legado no ha sido un tema menor; en este sentido, el proceso de co-creación incluyó apuestas para determinar de qué manera disponer la información entregada a la entidad receptora y la ciudadanía en general. En palabras de los catalogadores,
*Que la herramienta nos permita recuperar la información de la investigación; aunque hay cosas a las que no se puede acceder, al menos que la gente sepa que los investigadores usaron esa información para sacar sus conclusiones, así no tengan acceso, porque hay mucha información que ni siquiera es de la Comisión, sino de otras instituciones, y tienen muchos años de reserva, y la Comisión no puede llegar a romper con eso… tiene que respetar los acuerdos de entrega y garantizar que se respeten también en el ejercicio de catalogación...*
#### Fuentes internas y fuentes externas
El tipo de información que se catalogó en la Comisión de la Verdad se divide entre fuentes internas y fuentes externas; las primeras en función de toda la producción misional llevada a cabo por la institución, y las segundas en función de toda la información aportada por otras instituciones a la Comisión de la Verdad para el cumplimiento de sus objetivos misionales. De acuerdo con el grupo de catalogadores, para el módulo de catalogación colaborativa se pensaron dos formularios de carga: el formulario para fuentes internas, el cual fue estructurado para que dialogara con los diferentes equipos de la Comisión de la Verdad en función de las metas de la institución (es decir, un recurso se describe de acuerdo con los puntos del mandado con los que se relaciona); el objetivo fue, según el equipo, mostrar a la sociedad qué se hizo y con qué vacíos se queda. El formulario para las fuentes externas, se estructuró en función de la composición de los archivos: de dónde viene la información, de qué forma está organizada, qué actores aparecen en los documentos y cuál es el contenido de los mismos; a diferencia del formulario de fuentes internas, el de externas tiene un tema de gestión debido a que la información que llega es diferente a la que se produce en la institución (un tema de gestión que incluye, entre muchas otras cosas, el asunto de los accesos y los permisos).
{% hint style="info" %}
La diferencia entre ambas fuentes de información se da no solo por los procesos en sí mismos, sino por el tipo de información y el contenido. Un ejemplo. En el marco de un reconocimiento, se van a recoger o se van a producir documentos de planeación, de asistencia, de organización (quiénes van a estar), contexto, levantamiento de información (por qué ese reconocimiento y qué temáticas); son documentos relacionados con labores que hace la Comisión. En fuentes externas, una documentación que se consultaría en el marco de un reconocimiento sería, por ejemplo, un expediente de Fiscalía sobre ejecuciones extrajudiciales. En este sentido, si bien se procesan de manera similar (y los formularios de carga dentro del módulo son similares en algunos puntos), hay que diferenciar su naturaleza.
{% endhint %}
### Dificultades y aprendizajes
Una de las dificultades a las que se ha enfrentado el grupo de catalogadores ha sido la gestión de los metadatos, sobre todo si se piensa en los procesos y reprocesos que han estructurado el flujo de trabajo de este equipo. ¿De qué manera describir la información acopiada por la Comisión de la Verdad para que exista una real interoperabilidad entre las herramientas del Sistema de Información Misional? Esta pregunta no es menor en tanto se instaura en la raíz de las discusiones entre el equipo de ingenieros y el equipo de catalogadores (y profesionales en archivística); en efecto, la necesidad de adicionar y quitar campos de manera constante fue una de las dificultades para el equipo de ingenieros ([Desarrolladores](/idiosincrasia-proyecto/desarrolladores-idiosincrasia-proyecto#aprendizajes-y-experiencias)), y uno de los retos del equipo de catalogadores que tenían al frente el problema de la interoperabilidad entre herramientas muy diversas y datos muy heterogéneos. Según el equipo de catalogación, la información que circulaba dentro de la Comisión de la Verdad era muy diversa: se podía encontrar desde un documento de investigación hasta una cartografía hecha a partir de una aplicación; en este sentido, es importante insistir en que se recibió información de muchos lugares, que los documentos hacen parte de contextos muy diversos y poseen características muy diferentes. Por todo ello, desarrollar una estructura de datos común, centralizando, limpiando y ordenando el esquema de metadatos usados para la catalogación, fue una de las mayores dificultades, aprendizajes y logros que el grupo de catalogadores resalta como importante.
{% hint style="success" %}
Omeka, el primer software utilizado para los procesos de catalogación, no permitía construir esta estructura de datos debido a que está desarrollado con una estructura de campos ya definidos que van adaptándose según necesidades puntuales. En este sentido, se generó un proceso inverso: no se pensó un esquema de metadatos estructural para el Sistema de Información Misional, sino que a medida que se iba haciendo se iba mirando cómo ajustar las herramientas. El formulario hecho "a medida" permitió hacer los ajustes específicos para que la metadata respondiera a ese esquema estructural que resolviera el problema de la interoperabilidad.
{% endhint %}
#### Diálogos interdisciplinares
De acuerdo con este punto, y según el equipo de catalogadores, poder generar un lenguaje común con los ingenieros desarrolladores, implicó la necesidad de construir explicaciones sencillas, en muchas ocasiones con ejemplos visuales, para poder justificar la necesidad o no de un campo dentro del formulario. Adicionalmente, y según reseñan, las directrices sobre cómo estructurar los formularios no recaían únicamente sobre los catalogadores, sino que debían responder a las orientaciones dadas desde la coordinación, a las necesidades de los investigadores y a las orientaciones de los comisionados, lo cual hacía de esta dificultad inicial un reto cada vez más complejo.
*Es tener muy claro qué información ellos necesitan para poder hacer lo que necesitamos; usualmente, suelen ser muy visuales: sentarse, explorar la herramienta juntos, hacer mockups manuales (mira este botón tiene que estar aquí de esta manera). Si les explicamos en términos contextuales (todas las decisiones que hay arriba del equipo de catalogadores: coordinación, investigadores, comisionados), que también lo hacemos, muchas veces no queda claro... es difícil transmitir todos estos asuntos en una cosa más pragmática de uno, dos, tres, cuatro, cinco... pero es el reto de comunicación con ellos...*
Parte de estas dificultades se debe, entonces, a la idiosincrasia de la Comisión de la Verdad (planear e implementar en la marcha). De esta manera, ir diseñando a medida de las necesidades, sin tener la posibilidad de una etapa de planeación, ha conllevado retos importantes en términos no solo de los flujos de trabajo, como pone en evidencia el equipo de catalogadores, sino también en términos de la comunicación y el diálogo interdisciplinar que se genera al interior de los equipos. En efecto, y según el equipo, si se hubiera tenido la etapa de planeación muchas cosas hubieran sido más sencillas; no obstante, cuando se trata de un proceso de cocreación en la marcha, el diálogo interdisciplinar emerge como única vía para planear y, al mismo tiempo, implementar. En últimas, esta manera de proceder obligó a que cada equipo se pusiera en el lugar del otro; en esa medida, más que una dificultad, es un aprendizaje y una riqueza intrínseca, que no todas las instituciones u organizaciones pueden tener.
*Yo creo que es un aprendizaje de parte y parte, porque de parte nuestra hay cosas que uno espera: que el formulario sea rápido, que el gestor validador pueda marcar el registro y decir que ya está validado; y uno quiere que la herramienta le de todo, para que se haga todo perfecto, pero eso no se hace de un día para otro. Nosotros lo entendimos en el proceso… eso puede tomar mucho tiempo. Ellos, los ingenieros, también en el proceso, aprendieron que la gestión de archivos no es simplemente acumular carpetas o guardar información; eso no es suficiente, más si son archivos de derechos humanos que tienen violencias, contenido de víctimas y de otros actores, datos que necesitan protegerse. De esta manera, ellos han aprendido la experiencia más mixta entre social y ciencias de la información, que no es nada fácil; y también nosotros hemos aprendido cuál es la labor de un desarrollador…*
### Logros y posibilidades que presenta la herramienta
Al principio, antes de que hubiera una implementación de Omeka, la catalogación se realizaba a través de archivos en Excel. Este proceso, según el equipo de catalogadores, presentó un flujo de trabajo lento e impreciso debido a que, en lo que respecta a los archivos de fuente interna, no se generaba una real apropiación por parte de los equipos, quienes empezaron a ver la tarea como una labor innecesaria, y no como una labor que permitía disponer la información de manera ordenada para ser consultada y recuperada. En este sentido, uno de los mayores logros de la herramienta, según el equipo, fue la posibilidad de que las diferentes áreas de la institución se apropiaran de la tarea permitiendo que la información pudiera circular de la mejor manera por el motor de búsqueda de la Comisión de la Verdad.
*Una cosa es que tú le muestres a una persona que va a describir la información en un Excel, y otra cosa es que le muestres la herramienta, que es un buscador y le digas: ya está la herramienta, mira el formulario, te vas a loguear, tienes tu perfil, tienes un lugar donde ves lo que has cargado, puedes hacer correcciones de eso, tus compañeros van a poder consultar esa información, otras áreas pueden consultar esa información en el catálogo. Eso es otra cosa...*
Adicionalmente, y gracias a la herramienta, la labor de catalogación, descripción e indexación se facilita debido a que los campos están estandarizados, existen listas construidas a través de un vocabulario controlado, y la seguridad de la información se garantiza dados los niveles de acceso que pueden determinarse para cada tipo de archivo; ahora bien, la posibilidad de integrar un vocabulario controlado, por ejemplo, permite la articulación de los equipos en función de entender cómo se está haciendo el trabajo, cómo se está entendiendo el conflicto. Es de esta manera, que la herramienta se convierte en un eje de referencia para todas las personas: cuáles son las metas, cuáles son los productos, cuáles son los temas, cuáles son los avances de otros equipos; en últimas, la herramienta permite fortalecer el trabajo colaborativo.
Todos estos procesos convergen en el logro más grande: ayudar en el cumplimiento de uno de los objetivos misionales de la Comisión de la Verdad; en efecto, es a través de los catálogos que los investigadores lograron llegar a mucha información importante para la investigación, información que, de no estar ordenada, no hubiera podido consultarse de manera adecuada, estaría dispersa y no se tendría la trazabilidad de cómo los diferentes grupos de investigación hicieron su labor.
#### Catalogación colaborativa
El proceso de catalogación colaborativa implica la posibilidad de que otras áreas puedan colaborar con la catalogación y la descripción; es decir, permite que la catalogación no sea una labor única de catalogadores. La herramienta facilitó la catalogación colaborativa haciendo que fuera una labor mucho más fructífera, dada la estandarización y las posibilidades ya señaladas en el párrafo anterior. No obstante, la catalogación colaborativa se convierte en una dificultad si se piensa en una organización donde sus áreas no están estructuradas o estables, como ha sido el caso de la Comisión de la Verdad.
### Aportes a la ciudadanía
Según el equipo de catalogadores, la herramienta permite que todo lo que se recolectó y produjo para el esclarecimiento dentro de la Comisión de la Verdad, quede disponible para la consulta por parte de la ciudadanía (con restricciones y limitaciones por el tema de los accesos). Este es, según el equipo, el aporte más grande, ya que la gestión de la información no solo se reduce a agruparla y organizarla en fondos y/o carpetas, sino también en cómo la institución puede llevar esto a la ciudadanía para que se siga comprendiendo qué es lo que pasa con el conflicto en Colombia. Es un aporte archivístico y científico, que integra no solo la perspectiva de investigación, sino que incorpora también la perspectiva de las comunidades, ya que el eje central de la investigación fueron los testimonios tomados de las víctimas. En este sentido, y siguiendo el relato de los catalogadores, tener un lugar para la información y, más allá de eso, tenerla organizada, puede, eventualmente, facilitar la labor de historiadores e investigadores, y facilitar los procesos judiciales y legales de las víctimas y la ciudadanía en general.
*Es impresionante que podamos decir: pusimos un granito de arena para que el legado de la Comisión permita recuperar toda esa información que se produjo y se recolectó. Tener eso, y el aporte específico nuestro, tener eso catalogado y organizado, permite garantizar el derecho a la verdad al país. No es suficiente lo que haga la Comisión de la Verdad para resolver todos los conflictos que hay, porque el conflicto tiene muchas formas, pero, por lo menos, en el plano del acceso a la información, que es en el área en la que nosotros trabajamos, creo que sí le aportamos bastante a que ese derecho a la verdad sea en algún momento posible. En otras palabras, este ejercicio sí se convierte en un insumo primordial para avanzar en la transformación del conflicto...*
Adicionalmente, el software puede servir a procesos amplios llevados a cabo en organizaciones y/o universidades que quieran administrar, describir y catalogar sus archivos y recursos. Por otro lado, la información que la Comisión de la Verdad ha catalogado está disponible en el [archivo del esclarecimiento](https://docsarchivoesclarecimiento.comisiondelaverdad.co/), y puede ser consultada para gestar procesos participativos específicos.
### Expectativas
Es importante que siempre exista una política de preservación a largo plazo. La tecnología es cambiante, por tanto, es necesario que siempre haya un grupo de profesionales que, de manera permanente, nutran los procesos a partir de los nuevos conocimientos que sobre las tecnologías de la información vayan emergiendo. La vulnerabilidad, en escenarios digitales, es mayor; es por ello que se requiere de un acompañamiento permanente que evite que el sistema quede caduco o que la información se pierda por una mala actualización. De igual manera, es importante que el ejercicio de descripción y catalogación perdure, porque de lo contrario se puede cargar mucha información, con todos los parámetros de archivo resueltos, pero no con parámetros de descripción que permitan fácilmente su recuperación y su comprensión (gestión del conocimiento); no todo puede ir por carga masiva, siempre debe haber un ser humano corrigiendo datos. Este enlace entre archivar en carpetas y hacer gestión del conocimiento es uno de los puntos que el equipo de catalogadores resalta como más importante, ya que se ubica en la base misma de la estructura que todo sistema de información debería tener.