Repositorio Institucional de Documentos

Proyecto Fin de Carrera Ingeniería en Informática Visualizador de ontologías basado en un razonador de Lógica Descriptiva Jorge Bobed Lisbona Directores: Carlos Bobed, Eduardo Mena Septiembre de 2012 Visualizador de ontologías basado en un razonador de Lógica Descriptiva RESUMEN Durante los últimos años, la Web está evolucionando en lo que se denomina la Web Semántica. En esta nueva Web, los contenidos pasan a ser entendidos y procesados por los ordenadores para automatizar y mejorar distintas tareas. Esto se consigue mediante la adición de información semántica a dichos contenidos. Dicha información es ofrecida por las ontologías, denidas por Tomas Grüber como la "especicación de una conceptualización"[9], que permiten modelar y denir distintas vistas del mundo de manera que el ordenador pueda entenderlas y manipularlas. Actualmente, el formalismo más extendido para la denición de ontologías son los llamados lenguajes Description Logics (DLs). Los DLs ofrecen un marco teórico que permite la existencia de razonadores, programas que permiten razonar e inferir nuevos hechos sobre las ontologías, encontrar relaciones no explícitas, clasicar los conceptos e instancias de las ontologías, o encontrar inconsistencias en los modelos, entre otras tareas. Este formalismo es el que se encuentra tras el estándar W3C de representación de ontologías: OWL ( Web Ontology Language ). Asimismo, el correcto modelado y uso de una ontología recae en el conocimiento del conjunto de conceptos y relaciones a representar, y en su dominio sobre la alta complejidad de los formalismos de los DLs. Por tanto, es vital un visualizador que ayude tanto al creador encontrando posibles fallos de modelado (inconsistencias) como a desarrolladores que pretendan entender y utilizar ontologías de terceros. El objetivo de este PFC ha sido por tanto la realización de un visualizador de ontologías semánticamente expresivo. El problema de encontrar una representación visual acorde a la complejidad de estos esquemas no es nuevo. Existen diversos visualizadores con aproximaciones muy diferentes con sus puntos fuertes y débiles. Con el visualizador propuesto se ha pretendido suplir esas carencias que van desde la ausencia de apoyo sobre un razonador a la omisión de entidades como clases anónimas o la representación de la jerarquía de propiedades en el mismo esquema. Para llevarlo a cabo ha sido vital la experiencia del grupo SID en el campo. Con el visualizador se ha conseguido: Ofrecer un lenguaje visual expresivo y semánticamente correcto que facilite el entendimiento de la ontología. Permitir observar la jerarquía de conceptos o clases, así como las clases anónimas que puedan surgir de la denición de éstos. Permitir al usuario ocultar parcialmente el grafo, de modo que pueda centrarse en los aspectos que más le interesen. i Modicar la disposición de los elementos en pantalla para dejarlos según las preferencias personales. Ser capaz de guardar el estado visual y la conguración en cheros XML, para poder restaurarlo en futuras sesiones. Exportar como distintos tipos de imagen (JPG y PNG) para poder visualizar posteriormente con un visor de imágenes. Añadir la jerarquía de roles y propiedades sobre el grafo. Poder listar instancias de las distintas clases. Interactuar con los distintos elementos: Desplazar nodos a voluntad, ocultar subníveles de estos, las propiedades asociadas, mostrar información adicional al de la entidad que tiene el foco de atención, realizar zoom sobre el grafo, etc. Además se ha planteado el desarrollo del mismo como aplicación propia y como plug-in de la plataforma Protégé. La decisión de la integración en Protégé, como plug-in viene justicada por el aumento de usabilidad que supone en un entorno de edición ampliamente extendido en la comunidad de la Web Semántica. Como lenguaje de programación, se ha utilizado Java, dado que tanto Protégé como la API más extendida (OWLAPI) están desarrollados en dicho lenguaje. Por otro lado, se hace uso intensivo de razonadores DL explotando sus capacidades para ofrecer información relevante para la explicación de la ontología. La selección de éstos viene dada por su compatibilidad con OWLAPI (Pellet, Hermit, Fact++ y RacerPro, entre otros). ii Agradecimientos Es mucha la gente que me ha ayudado tanto de forma directa con su apoyo y consejos (mis directores, Roberto, Gorka, Ricardo .... ) como indirecta con el ánimo y apoyo que me han proporcionado en momentos buenos y malos (familia, amigos, Marina...). A todos ellos, va dedicada esta sección. Nobody expects the spanish inquisition! [16]. iv vi Índice general 1. Introducción 1 1.1. Motivación................................. 1 1.2. Objetivoyalcance ............................ 3 1.3. Contenido de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Contexto Tecnológico 5 2.1. Conceptos relacionados con el proyecto . . . . . . . . . . . . . . . . . 5 2.1.1. Ontologías............................. 5 2.1.2. Description Logics . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Lenguajes de representación . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.1. RDF................................ 7 2.2.2. RDFS ............................... 8 2.2.3. OWL................................ 9 2.3. Herramientas ontológicas . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.1. Razonadores DL . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.3.2. OWLAPI ............................. 11 2.4. Softwaredeapoyo............................. 11 3. Estado del arte 13 3.1. Herramientas de visualización . . . . . . . . . . . . . . . . . . . . . . 13 3.1.1. GrOwl............................... 13 3.1.2. OWLViz.............................. 14 3.1.3. OntVis............................... 15 3.1.4. Ontograf.............................. 17 3.1.5. Resumen comparativo . . . . . . . . . . . . . . . . . . . . . . 18 vii xiv Índice de cuadros 2.1. Constructores RDFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Resumen de características de los visualizadores. . . . . . . . . . . . . 19 4.1. Requisitos del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.2. Símbolos utilizados en el renderizado de restricciones. . . . . . . . . . 25 A.1. Clasicación de ontologías por complejidad y tamaño. . . . . . . . . 49 C.1. Reglas de sintaxis ALC. . . . . . . . . . . . . . . . . . . . . . . . . . 81 C.2. Características de las propiedades. . . . . . . . . . . . . . . . . . . . . 83 C.3. Restricciones de propiedades. . . . . . . . . . . . . . . . . . . . . . . 84 xv xvi Capítulo 1 Introducción El presente documento presenta la memoria de trabajo del proyecto de n de carrera  Visualizador de ontologías basado en un razonador de Lógica Descriptiva , realizado por el alumno Jorge Bobed Lisbona bajo la dirección de Eduardo Mena Nieto y Carlos Bobed Lisbona. Este proyecto se ha realizado dentro del Departamento de Informática e Ingeniería de Sistemas de la Escuela de Ingeniería y Arquitectura de la Universidad de Zaragoza, concretamente dentro del grupo de Sistemas de Información Distribuidos (SID). 1.1. Motivación Durante los últimos años estamos observando la progresiva evolución de la Web en lo que se denomina la Web Semántica. En esta nueva Web, los contenidos pasan a ser entendidos y procesados por los ordenadores para automatizar y mejorar distintas tareas. Esto se consigue mediante la adición de información semántica a dichos contenidos. Esta información semántica es ofrecida por las ontologías, denidas por Tomas Grüber como la "especicación de una conceptualización explícita y formal"[12]. Las ontologías permiten modelar y denir distintas vistas del mundo de manera que el ordenador pueda entenderlas y manipularlas. Actualmente, el formalismo más extendido para la denición de ontologías son los llamados lenguajes de Lógica Descriptiva (DLs, de su nombre en inglés Description Logics ). Los DLs ofrecen un marco teórico que permite la existencia de razonadores, programas que permiten: razonar e inferir nuevos hechos a partir de lo asertado en las ontologías encontrar relaciones no explícitas, clasicar los conceptos e instancias de las ontologías, o encontrar inconsistencias en los modelos, entre otras. Este formalismo es el que se encuentra tras el estándar W3C de representación de ontologías, OWL ( Web Ontology Language ). Se trata de un lenguaje que se sustenta sobre más lenguajes de diferente expresividad decreciente como son: RDFS ( RDF Schema ), RDF ( Resource Description Framework ) y, nalmente, XML ( eXtensible 1 Markup Language ). En la Figura 1.1 se puede comprobar la relación existente entre los lenguajes mencionados Figura 1.1: Arquitectura de los lenguajes semánticos. Asímismo, el correcto modelado y uso de una ontología requiere el conocimiento del conjunto de conceptos y relaciones a representar, y dominio sobre la alta complejidad de los formalismos de los DL. Por tanto es vital un visualizador que ayude tanto al creador encontrando posibles fallos de modelado (inconsistencias) como a desarrolladores que pretendan entender y utilizar ontologías de terceros. Esta última tarea es crucial para la explotación y puesta en valor de iniciativas como la de Linked Data, que ofrece una ingente cantidad de información en formato RDF anotada con una relativamente pequeña cantidad de ontologías. En este proyecto se utiliza la experiencia del grupo SID en el campo y se plantea la realización de un visualizador desarrollado como aplicación propia y como plug-in de la plataforma Protégé. La decisión de la integración en Protégé viene justicada por el aumento de usabilidad que supone en un entorno de edición ampliamente extendido en la comunidad de la Web Semántica. El problema de encontrar una representación visual acorde a la complejidad de estos esquemas no es nuevo. Hasta la fecha han aparecido una gran cantidad de visualizadores/editores con representaciones muy distintas y opciones de usuario variables. Con el presente visualizador se aspira a dar una representación más intuitiva que aquellas que utilizan los visualizadores existentes y que además sea capaz de suplir otras carencias más concretas que van desde la ausencia de apoyo sobre un razonador a la omisión de entidades como clases anónimas o la representación de la jerarquía de propiedades en el mismo esquema. 2 1.2. Objetivo y alcance El objetivo del presente proyecto es el desarrollo de un visualizador de ontologías que tenga en cuenta la semántica de las mismas para ofrecer una representación visual más comprensible por parte del usuario. De esta manera, el visualizador a desarrollar debe tener las siguientes características: Ofrecer un lenguaje visual expresivo y semánticamente correcto que facilite el entendimiento de la ontología. Permitir observar la jerarquía de conceptos o clases, así como las clases anónimas que puedan surgir de la denición de éstos. Permitir al usuario ocultar parcialmente el grafo, de modo que pueda centrarse en los aspectos que más le interesen. Modicar la disposición de los elementos en pantalla para dejarlos según las preferencias personales. Ser capaz de guardar el estado visual y la conguración en cheros XML, para poder restaurarlo en futuras sesiones. Exportar como distintos tipos de imagen (JPG y PNG) para poder visualizar posteriormente con un visor de imágenes. Añadir la jerarquía de roles y propiedades sobre el grafo. Poder listar instancias de las distintas clases. Interactuar con los distintos elementos: Desplazar nodos a voluntad, ocultar subníveles de estos, las propiedades asociadas, mostrar información adicional al de la entidad que tiene el foco de atención, realizar zoom sobre el grafo, etc. Como lenguaje de programación, se utilizará Java, dado que tanto Protégé como la API más extendida (OWLAPI) están desarrollados en dicho lenguaje. Para la realización del plug-in mencionado se utilizará el framework OSGI del que hace uso Protégé para la inclusión de plug-ins. Por otro lado, se hará uso intensivo de razonadores DL 1 explotando en lo posible sus capacidades para ofrecer información relevante para la explicación de la ontología. La selección de éstos vendrá dada por su compatibilidad con OWLAPI siendo Pellet 2 , Hermit 3 , Fact++ 4 y RacerPro 5 los principales razonadores que la soportan. En el desarrollo se utilizará principalmente 1 Razonadores http://owlapi.sourceforge.net/reasoners.html 2 Pellet http://clarkparsia.com/pellet/ 3 Hermit http://hermit-reasoner.com/ 4 Fact++ http://owl.man.ac.uk/factplusplus/ 5 RacerPro http://www.franz.com/agraph/racer/ 3 Pellet, aunque se pueda utilizar cualquiera de los anteriormente mencionados. Finalmente, para guardar la información, se hará uso de cheros xml tratados con las librerías DOM y XPATH. 1.3. Contenido de la memoria El contenido de la memoria contempla los siguientes capítulos: El capítulo 2 tiene como objetivo dar una visión de los conceptos básicos sobre las ontologías además de presentar herramientas que faciliten su manipulación y por tanto su desarrollo y evolución. Dentro del contexto tecnológico se citan además las herramientas utilizadas. El capítulo 3 trata el estado del arte. Se seleccionan diversos visualizadores de ontologías existentes para posteriormente enmarcar la propuesta del proyecto presente y destacar los puntos fuertes de la misma. El capítulo 4 aborda la planicación del proyecto. Se especican los requisitos, la metodología seguida, los elementos a visualizar y para acabar las distintas fases de diseño por las que ha pasado El capítulo 5 abarca los aspectos más importantes de la implementación, centrándose en el algoritmo de visualización. Para nalizar, el capítulo 6 reune las conclusiones obtenidas al nal del proyecto junto con la planicación temporal. 4 Capítulo 2 Contexto Tecnológico El objetivo de este capítulo es dar una visión de los conceptos básicos sobre las ontologías además de presentar herramientas que facilitan su manipulación y por tanto su desarrollo y evolución. Aparte se citará también el software que ha sido necesario para la realización del proyecto. 2.1. Conceptos relacionados con el proyecto En esta sección se hablará sobre los conceptos que van a ser mencionados continuamente a lo largo de toda la memoria y cuya comprensión resulta indispensable para el correcto seguimiento de ella. 2.1.1. Ontologías Una ontología es la especicación formal y explicita de una conceptualización compartida [12]. En otras palabras, se trata de un modelo de conocimiento consensuado sobre un determinado dominio, con intención de ser revisado y reutilizado en diferentes aplicaciones. Para poder explotar su potencial, una ontología ha de satisfacer el mayor número posible de los siguientes puntos: No ser exclusiva de una persona o de una institución sino que sea consensuada o compartida por un grupo de personas, instituciones, etc. El modelo a formalizar deber constar de de un conjunto de conceptos organizados jerárquicamente, los cuales se denen a través de un conjunto de propiedades y de sus relaciones con otros conceptos y de un conjunto de axiomas o reglas que permiten inferir conocimientos nuevos a través de los ya existentes. 5 Proporcionar términos que tengan una semántica bien denida y se expresen utilizando lenguajes de programación, que a su vez tienen una semántica bien formada. Ser formal y por tanto interpretable por un ordenador. Elementos de una ontología Las ontologías se componen de los siguientes elementos: Conceptos/Clases : Son esencialmente conjuntos de elementos o individuos que comparten ciertas propiedades. Normalmente se consideran dos clases que estarán en todo modelo: Top/Thing y Bottom/Nothing. Thing es superclase de todas las demás y Bottom es una clase que no puede tener ningún elemento, es por denición subclase de todas las demás y engloba todas las inconsistencias. Roles/Propiedades : Representan las relaciones de los conceptos. Relacionan siempre dos conceptos con papeles diferenciados. Uno será el dominio de la propiedad y el otro el rango. Un ejemplo de rol o propiedad podría ser tiene_consola, con dominio supuesto de Persona y rango Consola . Instancias/Individuos : Representan individuos pertenecientes a un concep- to. Estos tres elementos son los más importantes del modelo. Sin embargo, también disponemos de las restricciones, elementos que pueden ser vistos como operadores sobre roles/propiedades. 2.1.2. Description Logics Los DL son  lenguajes formales para representar conocimiento y razonamiento sobre él  [4]. Están formados por una capa intensional llamada TBox y otra ABox. La TBox es la capa de conocimiento intensional y está compuesta por un conjunto de axiomas terminológicos. Son fórmulas del tipo C≡D o CvD , donde C y D son conceptos. La ABox es un conjunto de aserciones que describen un estado especíco del mundo representado en la TBox asociada. En otras palabras, se diferencia el conocimiento estático sobre los conceptos (TBox) de aquello que se sabe de las instancias (ABox). La descripción de los lenguajes DL es extendida en la sección C.2 de los anexos. 6 2.2. Lenguajes de representación En esta sección se va a dar una reseña de los lenguajes que sirven para representar y publicar información semántica. Se puede encontrar una visión en la Figura 1.1 que indica la relación que existe entre los elementos descritos a continuación. 2.2.1. RDF RDF ( Resource Description Framework ) es un lenguaje para representar y publicar información semántica de recursos en la Web. En primer lugar, estaba enfocado a representar metadatos de cualquier elemento identicable en la red mediante una URI ( Uniform Resource Identier ) como pueden ser autor, fecha de modicación, etc. Sin embargo, se ha extendido el uso de RDF para representar información sobre cualquier tipo de recurso en la red. RDF se basa en la idea de la identicación de elementos a través de URIs y de describir recursos en función de propiedades simples y valores. Todo ello contribuye a que sea capaz de representar armaciones simples como un grafo de nodos y arco, cuya mínima expresión es una tripleta aRb (Figura 2.1), por la cual dos elementos quedan relacionados por la propiedad R . De esta manera se permiten formar grafos con información estructurada. Con RDF se pretende conseguir un vehículo para lograr los objetivos de la Web Semántica. Podría ser considerado su lenguaje ensamblador. Está orientado principalmente para publicar datos de manera interoperable, y en particular, es el lenguaje de representación elegido por la iniciativa Linked Data[6]. Figura 2.1: Ejemplo de tripleta RDF. El ejemplo mostrado en la Figura 2.2 ilustra un grafo RDF obtenido a partir de tripletas. Para el intercambio de información RDF es comúnmente visto sobre XML con una representación como la que vemos en la Figura 2.3. A partir de esas líneas podemos extraer lo siguiente: #me es_de_tipo Person #me tiene_nombre Eric Miller #me tiene_correo mailto:[email protected] #me tiene_titulo Doctor 7 Las restricciones aparecen como roles asociados a una clase en vez de ser realmente clases (se ve en la Figura 3.1). No representan la jerarquía de roles No tienen representaci ón para las restricciones sin cualicar. Figura 3.1: Vista de ontología del visualizador GrOwl. 3.1.2. OWLViz Esta herramienta viene incluída como plug-in de Protégé. Necesita que esté instalado el paquete GraphViz para su funcionamiento. Después de usarlo con unas cuantas ontologías se puede resaltar distintos aspectos. En cuanto a lo positivo podemos destacar: Permite mostrar ramas del grafo (sin necesidad de ver el camino entero desde Thing) Representa la jerarquía de clases con echas 'is-a' que apuntan a la superclase. En cuanto a la disposición del grafo ( layout ), es estático y se muestra como en la Figura 3.2 (permite cambiarlo a vertical/horizontal). Se apoya en el razonador para separar conocimiento asertado de inferido. En cuanto a los aspectos negativos podemos observar 14 La posición de las formas no se puede modicar. La interacción con ellas se reduce a mostrar u ocultar. No muestra información de propiedades ni de clases anónimas ni de instancias. En resumen, éste se parece mucho a la idea que se propone en el proyecto. Sin embargo, pese a mostrar bien la información que muestra, resulta escasa. Figura 3.2: Captura de OWLViz. 3.1.3. OntVis Teniendo en cuenta que la recopilación de herramientas encontradas en el enlace http://techwiki.openstructs.org/index.php/Ontology_Tools podría estar desactualizada, se ha buscado más exhaustivamente y se ha dado con un visualizador no perteneciente a dicha lista que además parece más nuevo y avanzado. Sin embargo se procede a analizarlo y logramos extraer las siguientes conclusiones separadas en pros y contras. Pros: Se trata de una aplicación web (Flash) en una comunidad. Permite guardar estado visual para luego restaurarlo. Permite exportar a formato de imagen. 15 Es visualmente agradable si se logra encontrar una disposición adecuada. Contras: Se expande el grafo de forma manual a partir de una entidad seleccionada también manualmente. No parece haber forma de visualizar la ontología completa si no se ha desplegado manualmente antes. El layout del grafo se realiza de forma manual. Da más libertad que el visualizador del proyecto, pero delega en el usuario la responsabilidad de encontrar una disposición satisfactoria de los elementos del grafo. No incluye como elementos a las clases anónimas. Sobre las propiedades se muestra cual es su dominio al ser mostradas junto a él, pero es imposible ver en la misma vista la jerarquía de propiedades o el rango de estas. No tenemos evidencia de que se apoye en el uso de un razonador para encontrar implicaciones o comprobar la consistencia. La accesibilidad a la vista del visualizador es a través de una pestaña difícil de ver. Como referencia se puede observar una imagen de un grafo parcial en la Figura 3.3 Figura 3.3: Captura de ontVis. 16 3.1.4. Ontograf En Ontograf (Figura 3.4) encontramos otro visualizador popular y que viene incluido como plug-in por defecto en Protégé. Después de probarlo podemos destacar los siguientes aspectos: Añade instancias como nodos identicados con un rombo morado. Distingue clases denidas del resto y muestra la denición en un tooltip. Permite exportar como imágen. Sin embargo, también tiene carencias: En la primera visualización de una ontología hay que extenderla a mano, lo cual puede ser laborioso si es sucientemente grande. Por lo menos tiene soporte para guardar el estado y restaurarlo en una sesión posterior. La disposición del grafo queda a responsabilidad del usuario. Si bien los nodos se desplazan tras abrirlos o cerrarlos, el resultado no es completamente satisfactorio. Las propiedades vienen reejadas como arcos con un color propio. Es necesario ir a mirar la leyenda o esperar al tooltip del arco. No añade clases anónimas como elementos visuales. No hace uso de un razonador en ningún momento. De las propiedades sólo obtenemos el dominio y el rango. No se dice nada del tipo de propiedad ni de su relación con otras propiedades. 17 Figura 3.4: Captura de Ontograf. 3.1.5. Resumen comparativo En el Cuadro 3.1 vamos a agrupar en distintos criterios las aproximaciones tomadas por los visualizadores previamente analizados para compararlo con el nuestro: 18 GrOWL OWLViz OntVis OntoGraf Propuesto Visualización inicial La sección seleccionada en el panel lateral. Vista completa desde Thing con sentido de izquierda a derecha (como propuesto). Nodo seleccionado. Un nodo elegido para expandir manualmente. Vista completa con distribución de Sugiyama. Tratamiento de propiedades Sin jerarquía. Mediante códigos de colores. Sin jerarquía de propiedades. Información de dominio, rango, tipo de propiedad y jerarquía de propiedades. Uso de razonador Diferencia grafo asertado de inferido. Clases anónimas Muestra las deniciones pero no como elementos visuales. Representadas como elementos visuales y expandidas en subexpresiones atómicas. Permite desplazar nodos En el mismo nivel. Visualización parcial Guardar estado Exportar imágen Edición Cuadro 3.1: Resumen de características de los visualizadores. 19 20 Capítulo 4 Planicación del visualizador En este capítulo se abordarán los aspectos más importantes de la planicación del proyecto. Empezando por una lista de requisitos, la metodología utilizada y las distintas fases del diseño. 4.1. Análisis de requisitos 4.1.1. Requisitos En la Tabla 4.1 se muestra el estado nal de la especicación de requisitos del visualizador. Se especica como nal ya que ha habido una evolución en esta lista. Comenzando desde el objetivo principal, creación de un visualizador de ontologías, los requisitos han sido añadidos, modicados e incluso eliminados en distintas etapas del proyecto. Sin embargo, es algo que se ha tenido en cuenta desde un principio, de modo que el enfoque ha sido el de implementar el sistema de forma que un cambio en un requisito no suponga desechar todo el trabajo realizado. En los requisitos se pueden distinguir aquellos que incentivan la utilización del visualizador a partir de características no vitales (aunque importantes) de los que hacen hincapié en representar el modelo de OWL (códigos de la tabla de requisitos 1 o 6 por poner ejemplos). 4.1.2. Metodología seguida La metodología que ha guiado el desarrollo de este PFC se ha basado en un modelo Incremental-Evolutivo. En éste se combinan características de ambos métodos, como la variación en la especicación de requisitos o el incremento de funcionalidades adicionales al sistema. Sobre una especicación inicial abstracta se ha ido añadiendo nuevas características de forma incremental con la previsión de la existencia de 21 Código Descripción 1Permitir observar la jerarquía de conceptos o clases, así como las clases anónimas que puedan surgir de la denición de éstos. 2Permitir al usuario ocultar parcialmente el grafo, de modo que pueda centrarse en los aspectos que más le interesen. 2.1 Se debe poder cerrar/abrir una clase (ocultar subniveles en el estado en el que estén). 2.2 Se debe poder ocultar una clase. 2.3 Se debe poder ocultar y mostrar conectores de disjunción. 2.4 Se debe poder ocultar y mostrar conectores de rango de propiedades. 2.5 Se debe poder ocultar las propiedades asociadas a una clase dada. 2.6 Se debe poder ocultar toda la información referente a las propiedades en un sólo paso. 3Modicar la disposición de los elementos en pantalla para dejarlos según las preferencias personales. 3.1 Debe permitir desplazar en el mismo nivel las clases y restricciones existentes. 4Guardar el estado visual en XML. 5Exportar el estado visual en formato de imagen (jpg,png). 6Añadir la jerarquía de roles/propiedades sobre el grafo. 7Listar instancias de las distintas clases. 7.1 Se listarán las instancias en una ventana aparte. 8Interactuar con los distintos elementos. 9Se debe poder realizar zoom sobre el grafo. 10 Se desarrollará como plug-in de Protégé y como aplicación independiente. Cuadro 4.1: Requisitos del sistema. cambios. En cada incremento ha sido necesario feedback por parte de usuarios de las distintas versiones. A destacar del modelo evolutivo se pueden enumerar los siguientes puntos que lo denen: Los requerimientos no son completamente conocidos al inicio. El software evoluciona con el tiempo. Los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para un primer incremento. La implementación parcial es usada y testeada por los usuarios y proveen feedback a los desarrolladores. En función de esta retroalimentación los requisitos evolucionan con cambios. 22 En denitiva, lo que se ha buscado ha sido encontrar una metodología entre las existentes que satisfaciera el requisito de agilidad y adaptabilidad. La mezcla de ambas ha sido el resultado de dicha búsqueda. 4.2. Elementos a visualizar En esta sección se van a describir los elementos visuales del grafo resultante. Empezando por las clases y restricciones (los elementos más visibles), continuando con las propiedades, y nalizando con las aristas. Clases (conceptos) Representan las clases del modelo de OWL. En el lenguaje visual denido podremos distinguir entre clases con nombre, anónimas y clases denidas. Visualmente se corresponden con rectángulos y dependiendo del tipo de clase variarán las características visuales de los mismos. Clases con nombre Son las que aparecen como la Figura 4.1. Se corresponden con las NamedClasses no denidas de OWLAPI y desde el punto de vista lógico, son aquellas que dan condiciones sucientes para que una instancia pertenezca a ellas. Visualmente se caracterizan por tener un nombre simple (sin prejos de URIS), un fondo grisáceo y fuente plana. Figura 4.1: Clase con nombre. Clases denidas Son clases con nombre con la particularidad de que han sido denidas a partir de una expresión. En otras palabras, se han dado condiciones necesarias y sucientes de pertenencia (ver Figura 4.2). Visualmente son idénticas a las clases con nombre salvo por la fuente, que es cursiva precisamente para diferenciar este caso. Su denición viene asociada como clase anónima (Figura 4.3). 23 Figura 4.12: Resultado visual nal. 30 Capítulo 5 Implementación del visualizador En este capítulo se abordarán los puntos más importantes de la implementación, dejando a la parte de anexos aquellos que se consideren menos relevantes. 5.1. Algoritmo de visualización A la hora de representar la ontología, el paso más importante es la creación del grafo a visualizar. Para ello utilizamos el razonador para diversas tareas como pedir clases relacionadas (subclases, superclases, clases equivalentes), buscar dominios, etc. En el algoritmo, asumimos la ontología y el razonador cargados. En el Algoritmo 5.1 se muestra el algoritmo en alto nivel, el cual incluye creación y la distribución de los nodos en el espacio. El algoritmo se detalla a lo largo de esta sección. 5.1.1. Obteniendo la taxonomía Para crear nuestra estructura que reeje las clases que hay en la ontología y las relaciones existentes entre ellas necesitaremos una estrategia. Esta estrategia consiste en primer lugar en buscar a partir de las clases que van estar en toda ontología ( Thing y clases equivalentes a Thing). A partir de ahí tendremos que realizar un recorrido que obtenga la jerarquía de clases, tanto anónimas como con nombre. El recorrido es realizado en todas las direcciones, es decir, hacia las subclases, superclases y equivalentes ( en expansión ). Así pues ayudado del razonador en conjunción de OWLAPI que permite extraer información explícita de la ontología cargada, podemos obtener todas las expresiones que hay en el esquema. 31 Algoritmo 5.1 Creación del grafo. AccionCrear () { Nodo<OWLClass> nodo = razonador . obtenerNodoTop () Set<OWLClassExpression> set = nodeToSet (nodo) crearGrafo ( set , expandido ) //expandido es un booleano obtenido del panel de control } crearGrafo () { recorrido ( set ) tratarClasesDefinidas() ReorganizarGrafo() ReajustarPosicionYAnchura () Si ( expandido ){ expandirGrafo() ReorganizarGrafo() EncogerGrafo () } ReajustarPosicionYAnchura () AñadirConectoresEquivalencia() AñadirConectoresDisjunción() AñadirPropiedades() EliminarConectoresRedundantes() ReordenacionGrafo (Sugiyama) } La expansión en todas las direcciones obliga a comprobar que la clase actual no ha sido añadida. Para optimizar esta búsqueda, se utiliza una tabla hash como índice para optimizar la búsqueda de expresiones ya añadidas (para no repetir nodos). Cada nodo que se añada al grafo tendrá asociado un nivel que se corresponderá con una posición horizontal sobre la que se alinearán sus elementos. Los niveles y los nodos asociados a ellos serán jos una vez se haya nalizado el algoritmo de visualización (puede variar en los procesos intermedios que se explican en la sección). En alto nivel el algoritmo sería como se indica en el Algoritmo 5.2 5.1.2. Añadiendo clases denidas Un ejemplo de clase denida viene ilustrado por: Student ≡Person ∩(Some(takesCourse, Course) ) Este es un caso especíco que necesita ser tratado a parte por varios motivos: Se puede dar el caso en que se forme un ciclo al darse que la denición de igualdad venga dada por (Definici´on vA)V(AvDefinici´on) , provocando que la reordenación posterior acabe por número máximo de iteraciones en vez de por conseguir el objetivo. 32 Algoritmo 5.2 Recorrido de clases. procedimiento recorrido ( set_expresiones ){ // set_expresiones ha sido iniciado con las clases del nodo top para cada ( expresion : set_expresiones ){ s i ( buscar_shape ( expresion ) == null ){ nuevaClaseVisual = añadirClaseVisual ( expresion ) set_subclases < − owlapi . subclases ( expresion ) set_subclases < − razonador . subclases ( expresion ) // igual con superclases y clases equivalentes recorrido ( set_subclases ) recorrido(set_superclases) recorrido(set_equivalentes) añadirConectores ( nuevaClaseVisual ) } } } Se quiere mantener visualmente las deniciones siempre en un nivel superior a la clase que dene como en Figura 5.1 Figura 5.1: Denición (clase anónima) junto a clase denida. Por ello, estas instancias concretas de conector se añadirán después del recorrido inicial. 5.1.3. Reorganizar el grafo El recorrido en expansión hasta ahora permite que haya aristas salientes de una clase a otra clase que esta en el mismo nivel o anterior. Esta es una característica que se quiere evitar para mantener una dirección del grafo, con motivo de mejorar la legibilidad. Si encuentra alguna situación en la que el sentido de la arista no sea el deseado, colocara la clase destino en el nivel siguiente para corregirlo (ver Figura 5.3). La reordenación es satisfactoria en caso de que no haya ciclos, pero se trata de un grafo dirigido y no existe problema en ese sentido. Sin embargo,se ha mostrado en la subsección de clases denidas que pueden aparecer ciclos evitables. 33 Figura 5.2: Reordenando clases. Algoritmo 5.3 Código reorganizando el grafo. procedimiento reorganizarGrafo () { completado = false Mientras_que ( not completado ){ completado = true Para cada ( Figura : set_de_shapes ){ Para cada ( conector_saliente : Figura . conectores_salientes ){ Figura2 = conector_saliente . Figura_en_extremo si ( nivel ( Figura2 ) <= nivel ( Figura ) ){ nivel ( Figura2 ) = nivel ( Figura )+1 completado = false } } } } } 5.1.4. Ajuste de posición y anchura Mover clases de un nivel a otro como se ha hecho en el paso anterior deja al grafo construido, pero con información visual desactualizada. En la situación actual podríamos tener dos niveles distintos con la misma coordenada X o tener un nivel con una anchura mucho menor que la forma más ancha del nivel. Este proceso consta de dos pasos: 1. Actualizar las anchuras de los niveles en función de la forma de mayor anchura que contengan. 2. A partir del primer nivel, actualizar la posición de los niveles y de las formas que hay en ellos. 5.1.5. Expansión del grafo : Añadiendo restricciones La idea visual de expandir un nodo de clase anónima se ilustra en la Figura 5.3. Las clases anónimas que aparecen en el esquema pueden llegar a ser expresiones complejas construidas a partir de más expresiones. El proceso de expansión sustituye la clase anónima por su descomposición en átomos lógicos (restricciones). 34 Figura 5.3: Expansión de nodo. Añadiendo Restricciones Como se observa en la Figura 5.3 el conjunto de expresiones simples que dan lugar a la clase expandida, ocupan más niveles. En otras palabras, el grafo crece en profundidad a la vez que se expanden nodos. La solución más directa pasa por añadir un nuevo nivel en medio (actualizando aquellos que tuviesen un id mayor o igual al nivel introducido) y añadir en el la restricción. Sin embargo, esta solución no es gratis, ya que permite que de nuevo vuelvan a aparecer situaciones como las que queríamos evitar en (ver Figura 5.2). Tiene fácil solución si aplicamos el mismo procedimiento. Además se crea otra nueva situación: en grafos con expresiones anónimas muy largas se introducen demasiados niveles semivacíos que extienden horizontalmente el grafo más de lo deseable. En este punto nos falta comprimir al máximo el grafo. Para ello, los niveles con sólo restricciones son plegados. Con plegar nos referimos a traer al nivel actual todas las restricciones que estén en niveles superiores y que estén libres de dependencias. Se considerará libre de dependencias si traer el elemento mantiene la restricción de sentido (izquierda a derecha). Después de este realojamiento es muy probable que queden niveles completamente vacíos, así que conviene eliminarlos. En resumen: primero, se realojan las restricciones al nivel más bajo posible, y segundo, se eliminan los niveles vacíos resultante. 35 5.1.6. Distribución de los nodos en un plano 2D (Algoritmo de Sugiyama) El último paso del algoritmo de visualización consiste en disponer los nodos en el plano 2D de forma que se minimicen los cruces entre aristas y la distancia entre un nodo padre y su hijo. De esta manera, se presentará al usuario una primera disposición que resulte agradable por la minimización de cruces. Para este problema se ha utilizado la solución de Sugiyama [15] (Anexo E) con el paquete pedviz.jar 1 que la implementa. En este punto se ha ajustado con los siguiente pasos: 1. Eliminar conectores is-a redundantes (para que el algoritmo de Sugiyama sea eciente). 2. Clonar la estructura del grafo (los nodos de clases) a un grafo del paquete pedviz. En la Figura 5.4 se observa el grafo clonado. Figura 5.4: Grafo con layout Sugiyama. 3. Aplicar su implementación de Sugiyama al grafo clonado. 4. Acceder a la información visual del grafo ordenado. 5. Traducir esa información absoluta a una relativa (al tamaño del panel) para usarla en el grafo principal. 1 pedviz - http://www.pedvizapi.org/ 36 5.2. Características generales 5.2.1. Diferencias Plugin-Applet En la realización de las dos versiones del visualizador han surgido diferencias debidas la propia API de Protégé que ofrece para el desarrollo de plug-ins. En denitiva, el objetivo ha sido intentar independizar al máximo el visualizador de los servicios de Protégé (Figura 5.5) y hacerlo dependiente del factor común: OWLAPI . Estos servicios en la práctica se concretan en la carga de la ontología y del razonador y para ello se han abstraído en ambos casos en métodos propios ( loadOntology y loadReasoner ). Figura 5.5: Diferencias plug-in y applet. 5.2.2. Instancias Las instancias o individuos pertenecientes a una clase son representados como una lista de nombres en una ventana aparte (Figura 5.6). No se añaden como elementos visuales para no añadir ruido a la visualización swl esquema de la ontología. 5.2.3. Características congurables Con el objetivo de dejar congurables características tales como el grosor de los conectores o los colores, se ha optado por un módulo de conguración programado con el patrón Singleton como referencia. En la actualidad soporta el la conguración del color y grosor de los conectores principales, pero se ha pensado en la proyección 37 Figura 5.6: Visualizando las instancias. futura del proyecto (que será continuado) en añadir más parámetros en función de las necesidades que vayan surgiendo. Un ejemplo de chero de conguración se ve reejado en la Figura 5.7 .Para el Figura 5.7: Conguración de parámetros sobre chero XML. parseo del chero XML se ha hecho uso de un API de XPATH[3] para Java, un lenguaje de consulta sobre cheros XML. 5.3. Utilización del prototipo En esta sección se va a presentar el prototipo implementado. Se va a empezar dando consejos para poder dar los primeros pasos con la aplicación. En segundo lugar, se presenta una evaluación breve frente a distintas ontologías de complejidad y tamaño variables (más detalles de sobre el uso del prototipo en el Anexo B y sobre la evaluación en el Anexo A). 38 5.3.1. Obtención de la aplicación y uso El visualizador en su estado actual puede ser probado como applet 2 , descargado como aplicación independiente 3 , o como plug-in para la plataforma Protégé 4 . La iniciación varía para cada una de las versiones de la aplicación. En caso del applet sólo es preciso un navegador con soporte de Java apuntando a la URL. Para la aplicación, basta con ejecutar el archivo .jar de las distintas formas posibles (doble-click, java -jar ...). En cuanto a Protégé, hay que copiar plug-in a la carpeta plugins de la instalación de Protégé. Será detectado en el inicio del programa. Para mostrar una ontología clasicada el proceso es igual en el caso del applet y la aplicación independiente (Figura 5.8). Figura 5.8: Carga y clasicación de una ontología. 5.3.2. Probando la aplicación En el anexo A se encuentra una evaluación del visualizador frente ontologías con expresividades y tamaños variables junto a la comparación con el resultado obtenido de otros visualizadores. Esta subsección pretende resumir las conclusiones que se pueden obtener de un uso normal de la aplicación realizada. Con el ejemplo más sencillo de los utilizados, pero no por ello incompleto, podemos observar grandes diferencias. La ontología proyectos.owl abarca muchos aspectos de OWL con apenas unos pocos axiomas. Tiene propiedades, subpropiedades, y 2 Applet - http://sid.cps.unizar.es/OntView/OntView.html 3 Standalone - http://sid.cps.unizar.es/OntView/OntView.jar 4 Plug-in de Protégé - http://sid.cps.unizar.es/OntView/OntViewPlugin.jar 39 Tiempo dedicado por tarea Tarea Tiempo Estudio Previo 60 Análisis y Diseño 190 Implementación y tests 380 Memoria 110 Figura 6.2: Diagrama de Gantt y reparto de tiempo. 46