🚩 Control de Versiones OWL

[thewillyhuman]

El día 15 de mayo de 2020 se realiza la entrega del hito 1 para el proyecto hércules. Este issue representa el entregable Control de Versiones OWL del cual el tipo de entregable es: Método y Software.

[thewillyhuman]

Validación del entregable

1. Se realiza un cambio erroneo en la ontología y la integración continua debería detectarlo e impedir que dicho cambio llege a la rama estable.
2. Se realiza un cambiuo correcto en la ontología. La integración continua debería de permitir que el cambio se propagase a la rama estable.
3. Deberá de existir un documento que acompañe al software en el que se explique la arquitectura del software, las decisiones de implementación y un pequeño manual de instrucciones de como se usa.

[thewillyhuman]

Actualmente se encuentra desplegada una versión beta del sistema de integración continua en el repositorio de hercules-ontology. Esta versión emplea un manifest para definir los casos de prueba y posteriormente los ejecuta creando un JUnit TestCase para cada caso de prueba definido.

[thewillyhuman]

Durante esta semana 11-15 Mayo se preparará la documentación y limpiará el módulo para proceder a su entrega.

[alejgh]

Se añade el siguiente markdown:

Control de versiones sobre ontologías OWL.

Este documento se centra en explicar las decisiones tomadas para intentar solucionar los problemas que emergen cuando se intenta mantener un control de versiones efectivo durante el desarrollo de ontologías.

Introducción

Una problemática conocida de las ontologías es su serialización no determinista. Esto implica que realizar un control de versiones efectivo sobre ellas sea imposible. En el siguiente artículo se puede ver más en detalle la problemática descrita.

Sin embargo existen distintas metodologías y procesos que se pueden aplicar para paliar este problema. De forma que se puede a llegar a desarrollar una ontología bajo un control de versiones en el que los cambios realizados queden registrados de forma unívoca.

Solución planteada

A continuación describiremos la solución que hemos planteado para solucionar la problemática descrita previamente. Nuestra solución se divide en cinco niveles ortogonales y totalmente complementarios, con distintos niveles de completitud actualmente. La primera es una solución sintáctica, mientras que el resto serían soluciones a nivel semántico. Estos niveles se describirán a continuación.

Nivel 1: Ontología

A nivel de la ontología, planteamos una solución sintáctica que es obligar el uso del editor Protégé por parte de los contribuidores de la ontología. En las últimas versiones de Protégé, basado en OWLAPI, se mantiene un orden determinista en la serialización de las ontologías que permite un mayor seguimiento de las diferencias entre versiones. Información adicional sobre el algoritmo implementado para mantener un orden determinista puede ser consultada a través del siguiente issue del repositorio de OWLAPI. Además, en el siguiente artículo se especifica en detalle las optimizaciones llevadas a cabo en los algoritmos de serialización de ontologías.

Nivel 2: Sistema de control de versiones

El propio sistema de control de versiones (en nuestro caso GitHub, basado en Git) también hay bastantes soluciones dispobibles para el problema presente.

Una de las soluciones que hemos llevado a cabo es el almacenamiento de forma independiente de cada una de las versiones de la ontología a traves de la rama donde ésta se encuentra publicada (gh-pages). Cada vez que se crea una nueva release en GitHub, se lanza un sistema de scripts que se encarga de mergear cada uno de los grafos procedentes de la ontología (core + módulos verticales + alignments) y de serializar el grafo mergeado en la rama gh-pages, junto con la información del día en el que se produjo esa versión. Esta serialización se lleva a cabo con la librería rdflib de Python, y está implementada de forma determinista.

Por último, la organización de carpetas correspondientes a la publicación de la ontología sigue un criterio de nombrado ya utilizado por ejemplo en las SPAR Ontologies, que facilita el acceso y uso de cada una de las versiones por parte de los consumidores.

Nivel 3: Wikibase

A nivel de Wikibase, el propio software tiene un sistema de control de cambios que nos permite obtener información adicional sobre los cambios que se han realizado. Estos cambios incluyen un timestamp, información sobre la cuenta que los ha realizado, así como la opción de poder revertir los cambios que sean necesarios.

Aunque este sistema fue originalmente diseñado como medida para evitar posibles actos de vandalismo a nivel de datos por parte de contribuyentes externos, creemos que nos puede ofrecer una gran base para poder manejar el control de versiones y cambios que se realicen en la ontología, la cuál se encontrará publicada en este sistema.

Nivel 4: Sincronización a wikibase

Actualmente Wikibase ya ofrece información sobre la evolución de los datos que guarda y por tanto se puede seguir el rastro de las distintas versiones de los componentes de una ontología. Sin embargo, el sistema de propagación de cambios diseñado permitiría enriquecer aún más esta información.

Desde este sistemas sería posible añadir metadatos adicionales en el momento de la sincronización de la ontología con Wikibase. Estos metadatos pueden incluir por ejemplo el fichero original a través del cual se realizó la sincronización, y otros datos procedentes del propio sistema de control de versiones, como puede ser el issue o el pull request relacionado con el cambio.

Actualmente este nivel todavía no se encuentra implementado en el sistema de sincronización, pero es algo que tenemos contemplado y nuestra idea es implementar este nivel de cara a futuras versiones del sistema de sincronización.

 Nivel 5: Sincronización desde Wikibase

Este nivel se correspondería con la sincronización de cambios que se produzcan en Wikibase al sistema de control de versiones donde se almacena la ontología (sincionización hacia atrás).

Por ejemplo, sería posible añadir metadatos a la propia ontología indicando la versión y la procedencia de estos cambios.

Dado que la sincronización hacia atrás todavía es una funcionalidad que no se encuentra disponible en el sistema de sincronización, este nivel todavía se encuentra en una fase de análisis y exploración por nuestra parte. A medida que se vaya avanzando en la funcionalidad, se irían concretando las medidas adicionales que podrían llevarse a cabo en este nivel.

Validación de los cambios en el sistema de control versiones

Una vez se han producido cambios sobre la ontología y por tanto en el control de versiones es necesario validar que estos cambios no tienen un efecto negativo sobre las versiones ya existentes de la ontología. Esto es, que por ejemplo no se empleé un prefijo que no ha sido definido con anterioridad, algo que sintácticamente es posible pero semánticamente produciría un error en los sistemas que consuman la ontología en el futuro.

Para ver como se soluciona este problema se ha diseñado e implementado un sistema de integración continua que se ejecuta cada vez que se produce un cambio en la ontología dentro del sistema de control de versiones. Toda la documentación referente a este sistema se encuentra dentro de la carpeta integracion_continua_github de este mismo directorio.

Propagación de los cambios al triplestore

Una vez los cambios en la ontología han pasado el proceso de validación, y los administradores de ésta consideran que se puede crear una nueva versión estable, se procederá a la sincronización de los cambios producidos en la ontología a Wikibase.

Estos cambios se realizarán de forma automática cada vez que se realice una nueva release en el repositorio donde la ontología se encuentra almacenada. Toda la documentación sobre este sistema se encuentra dentro de la carpeta sincronizacion_ontologia_wikibase de este directorio.