El desarrollo de Biotica© fue el resultado de una exitosa estrategia de Conabio iniciada en 1995. Con ella se avanzó firme y ampliamente en la sistematización de los datos de las colecciones biológicas de México. Se acertó en hacerlo en forma colaborativa con las diversas instituciones involucradas. El Inecol fue desde un principio un entusiasta colaborador de esta gran iniciativa nacional.
Biótica© se concibió para hacer converger las numerosas bases de datos existentes (en número, tipo, organización física y lógica). También se diseñó para acoger los datos provenientes de proyectos de diversa naturaleza: taxonómicos-biogeográficos, ecológico-genéticos, etc. Biótica © fue así, la solución que desarrolló la Conabio para disponer de un modelo de datos único, para la gestión de datos del universo de especímenes biológicos, que son la base física para el estudio y documentación de la biodiversidad mexicana. Aunque algunas instituciones ya tenía procesos de sistematización computacional de datos de colecciones (Inireb/Inecol por ejemplo), éste fue el primer esfuerzo de envergadura nacional en el país. Conabio logró así dar pasos muy substanciales para unificar, sintetizar y homogeneizar la información taxonómica-biogeográfica (taxogeoreferenciada) y fue el orígen del Sistema Nacional de Información sobre Biodiversidad (SNIB).
Hoy, el consorcio de uso de Biótica© está llegando a su fin, pues Biotica 5 será la última versión de este producto que se producirá. Al mismo tiempo, el contexto internacional ha venido evolucionando para ofrecer un creciente impulso a las estrategias de desarrollo de software de fuente abiera. También ha surgido y crecido la oferta tanto de almacenamiento en la nube como de cómputo en la nube. Habrá que considerar las oportunidades que estas capacidades ofrecen para nosotros y en su caso identificar lo necesario para aprovecharlas.
Ciencia abierta
El tiempo actual, y con base en el posicionamiento que estamos impulsando en el Inecol para asimilar el paradigma de ciencia abierta, nos plantea el desafío de reconfigurar la gestión de datos sobre biodiversidad que produce y custodia el Inecol. Hemos iniciado el proceso de construcción de la nueva estrategia de datos sobre biodiversidad, con el impulso a proyectos específicos que ha definido e impulsado la Dirección General del Inecol. La propuesta que ha emergido de la reflexión colectiva con los especialistas involucrados en el Instituto, es generar un grupo de trabajo con base en los actores clave de las colecciones del Inecol, así como los participantes en los proyectos institucionales estratégicos e-flora, e-fungaMEX, e-Scarab.mx: La Scarabaeoidea-fauna electrónica de México y Sistematización del conocimiento e I-GAMMA (Ciencia Abierta). En esta nota consideramos importante hacer un recuento de los elementos que hemos venido identificado como relevantes para el proceso de reconfiguración que estamos iniciando.
En 2018 la UNESCO, en una reunión celebrada en París, hizo un llamado mundial para considerar al código fuente del software como patrimonio de la humanidad. El código fuente es la versión que los humanos podemos leer de un programa, escript o algoritmo para computadora. La frase que enmarca el Llamado de París es muy elocuente.
Para el proyecto Ciencia Abierta Inecol, esta proposición es un gran referente, pues también el Llamado de París, destaca la relevancia de esta manifestación de la creatividad humana, sobre las opciones de desarrollo sostenible que podremos poner en práctica. En 2021, la UNESCO emitió la recomendación sobre Ciencia Abierta, que incluye la carta de la UNESCO para la preservación del Patrimonio Digital de la humanidad. La iniciativa fue adoptada por 193 países miembros. En respuesta a todo esto se ha creado, entre otras cosas, el repositorio de software fuente para el acceso público permanente.
Considerando este marco es que insistimos en que el desarrollo que adoptemos o hagamos para la gestión de los datos sobre biodiversidad que genera y custodia el Inecol, debería apegarse a una filosofía de código fuente abierto.
Alternativas disponibles
Contamos con los datos que ya están siendo gestionados en las bases de datos de las distintas colecciones del Inecol (XAL, IEXA, IEB, Jardín Botánico, etc.) y la experiencia del personal que ha estado involucrado en la curatoria de las colecciones y sus datos, así como la documentación disponible de Biótica. A continuación y como referencia para disponer con elementos de juicio, se presenta un cuadro resumen de iniciativas existentes a las que podríamos sumarnos o históricas que podríamos tomar como inspiración para nuestro proceso de desarrollo.
| Proyecto | Respositorio | Motor SQL | Descripción |
|---|---|---|---|
| symbiota | symbiota en github | MariaDB | Video general |
| specify 7 | specify 7 en github | MySQL | Demo |
| Biota | No lo indica | No especifica | Manual completo, 862 páginas |
| ibdata | No lo indica | No indidca | Manual V3 |
| Biotica 5 | No especifica | SQL server y MS Access | Sitio Web |
Algunos conceptos básicos y criterios de diseño
A riesgo de hacer un poco tediosa la lectura de esta contribución, consideramos importante ofrecer al lector un brevísimo recuento de conceptos clave para comprender con mayor exactitud las implicaciones de la gestión de los datos de las colecciones biológicas del Inecol. También consideramos que, con un poco más de familiaridad con los conceptos involucrados en el tema, estaremos en mejor posición para orientar el proceso de migración de datos en el que estamos involucrados.
Digitalización y Datificación
El compromiso de producir datos abiertos tiene un marco normativo específico en México. Particularmente la Ley General de Transparencia define algunos atributos para los datos abiertos. Los define como datos digitales de carácter público accesibles para ser usados, reutilizados y redistribuidos por cualquier interesado. Los datos abiertos son, entre otras cosas, accesibles, integrales, gratuitos, oportunos, permanentes, legibles por máquinas (y por humanos).
En el proceso de producir datos abiertos a partir de documentos solemos usar el término digitalización, que efectivamente es un primer paso para hacerlos legibles en máquinas de cómputo, pero no basta para hacerlos plenamente útiles. El siguiente paso necesario es datificarlos, es decir convertirlo en datos operables. Todo este proceso: colecta del espécimen → digitalización → datificación, es justamente lo que hacemos para convertir especímenes biológico en datos organizados en una base de datos.
Base de datos relacional
Biótica, y por tanto los datos de las colecciones biológicas que actualmente tenemos en el Inecol, están organizados como bases de datos relacionales. La idea del modelo relacional se planteo en 1970 y su uso está actualmente muy desarrollado y extendido. El concepto se refiere a una colección de información que contiene datos en múltiples tablas (llamadas relaciones) predefinidas. Los datos en ellas los podemos imaginar a su véz como arreglados en filas, con columnas que contienen atributos concretos. Las tablas se vinculan entre sí a través de atributos compartidos que aseguran la correspondencia entre el contenido temáticamente desagregado, que significan las distintas tablas. Este forma de organización de datos se suele procesar mediante el lenguaje especializado SQL (Structured Query Language), del cual existen múltiples dialectos o variantes. Aunque la conformación de un modelo relacional de datos tiene su complejidad, hay muchas ventajas en su uso, por lo que nos proponemos seguir con este paradigma en este proyecto.
Backend, Front-end y Middleware
En el proceso de reflexión que hemos venido propiciando, ha surgido en forma un tanto confusa la noción de base de datos y el uso de programas para captura y procesamiento de la información. En esta sección queremos aclarar dos conceptos importantes al respecto, que esperamos contribuyan a facilitar el diálogo y la comprensión del proceso de desarrollo en el que nos estamos involucrando. Primero, habrá que considerar que, en el contexto que estamos tratando, hay dos tipos de equipos de cómputo involucrados: 1) el servidor, que es el equipo físico en el que se realizan las tareas básicas de almacenamiento, mantenimiento y recuperación de datos, y 2) el cliente que es el equipo en el que opera normalmente el usuario y que envía ordenes al servidor para obtener los datos que interesan al usuario. En esta misma lógica, es natural concebir que debe haber elementos de software que sólo necesitamos que operen en el servidor, a ese conjunto de algoritmos se le suele llamar backend. Por lo mismo, debe haber componentes de código computacional que sólo necesitamos en el cliente. A este otro paquete se le suele llamar front-end. A partir de esta explicación no debe ser difícil imaginar que el backend privilegia aspectos de desempeño computacional en tanto que el front-end debe diseñarse con criterios de usabilidad y debe atender las distintas formas de uso del sistema (captura, actualización, consulta, resumen, mapeo, etc.).
En el complejo ecosistema de telecomunicaciones y cómputo a distancia, es cada vez más importante contar con un conjunto adicional de software que sirva de enlace seguro para operar las transacciones que ocurren entre equipos de diverso tipo, servidores y clientes. Podemos referirnos a ese paquete de algoritmos como el middleware, por su obvio papel de mediador entre las transacciones que se realizan entre múltiples equipos de cómputo. Este componente es vital en la resolución de intercambios que no tenemos garantía de que se realizarán en forma completa en un instante dado, ofrece recursos para enfrentar desfaces en el tiempo procurando asegurar la integridad de las transacciones. Se involucra en la gestión del flujo controlado de datos, la autenticación y muchos otros asuntos vitales de seguridad.
Datos federados y datos centralizados
La organización de cómo y en dónde se almacenas físicamente los datos es un tema de interés. Básicamente podemos optar por hacerlo en forma centralizada (digamos en una sóla computadora) o distribuida (en distintas máquinas e incluso lugares). El concepto de datos federados es interesante a este respecto y la ilustración que sigue da una idea bastante buena del concepto. La tomamos de esta página de TIBCO. Por cierto, en esta figura ETL significa extraer, transformar y cargar. Se refiere a los proceso de integración de datos a partir de múltiples fuentes en un único almacén. El planteamiento es rico y complejo, lo compartimos como una mirada a situaciones que actualmente se están presentando en el mundo, en la era de la información.
Seguridad
En las reuniones preparatorias que hemos tenido en el Inecol para atender la necesidad de migración de nuestros acervos digitales, se ha hecho mucho énfasis sobre el tema de aseguramiento de los datos y la infraestructura de almacenamiento físico relacionada. Actualmente hay amenazas de todo tipo, que van desde el hackeo o jaqueo (ortografía preferido por la RAE), que puede expresarse como parasitismo, suplantación, secuestro patrimonial, etc., hasta la destrucción fortuita o intencional de los equipos. También se ha mencionado aquí el tema de la necesitad de reservar piezas de información por razones de protección de especies reconocidas como vulnerables. El proyecto que estamos preparando, deberá incluir un tratamiento de este tema con una perspectiva de gran visión. Esto deberá incluir la generación de copias seguras de respaldo del conjunto completo de los datos y el código con el que se procesa.
Telecomunicación de datos
En este rubro, la reflexión que se ha venido haciendo, es considerar los volúmenes de flujo de datos, que podría implicar la consulta de la o los repositorios de datos. Hay algo de experiencia y referencias históricas sobre la cantidad de consultas que han tenido las bases de datos del Inecol. Esta información sin duda es un referente útil. Habrá que considerar también que se busca generar productos de información que sean de interés, no sólo para los especialistas, sino para el público general. Esto implica hacer previsión para un crecimiento de visitantes virtuales en el futuro. Otro aspecto a considerar es que la propia dinámica de captura y curatoria de datos generará transacciones con los repositorios, que deberán ser garantizadas en cuanto a integridad y agilidad del flujo de datos.
Ingesta de datos
Un tema fundamental que hay que planear es la transferencia de datos. Hay que transportarlos de la estructura actual que es una base de datos relacional desarrollada para MSAccess/SQL server, se tienen los archivos respectivos en formato mdb. También se ha propuesto extraer todos los datos como una tabla plana en formato csv, esto eliminaría la estructura relacional pero mantendría los datos esenciales de los ejemplares. A partir de ahí se podría alimentar el nuevo sistema de gestión de datos. La otra posibilidad es obtener los datos en archivos sqlite. Esto es una solución interesante, pues estos archivos contienen un mini motor SQL que permite operar la estructura relacional directamente, así que se trata de una versión transportable de bases de datos relacionales. Finalmente, existe la posibilidad de intentar una transferencia directa del sistema actual al nuevo que se determine. Contamos con la oferta de Conabio de generar los archivos en el formato que nos convenga y con el contenido total de nuestras colecciones que tienen en su custodia.
A partir del documento sqlite que tenemos con datos del herbario XAL relacionados con el proyecto Digitalización y sistematización de las colecciones biológicas del INECOL, obtuvimos los siguientes números generales:
| Concepto | Tamaño |
|---|---|
| Archivo | 481.28 MB |
| Tablas (relaciones) | 38 tablas |
| Ejemplares | 308,452 registros |
| Determinaciones | 24,415 taxa |
| Sitios | 39,891 lugares |
Estos datos dan una muy buena idea del espacio de almacenamiento que podría requerirse. En la documentación que recibimos, también está el diccionario de datos. Es información valiosa para la reingeniería del repositorio institucional que estamos emprendiendo. Estos datos son sólo de naturalez alfanumérica, no incluye imágenes u otros datos binarios que usualmente resultan ser demandantes de espacio de almacenamiento. También hay que considerar que no todos los ejemplares de una colección son de igual interés para acompañarlos de imágenes. Se suele dar preferencia a los especímenes tipo protagónicos: holotipos, isotipos, paratipos, topotipo, etc.