Extracción de ontologías OWL desde diagramas de clases UML

Texto completo

(1)Universidad Central “Marta Abreu” de Las Villas. Facultad Matemática, Física y Computación Licenciatura en Ciencia de la Computación. EXTRACCIÓN DE ONTOLOGÍAS OWL DESDE DIAGRAMAS DE CLASES UML. AUTOR: RETSEL RIVERO RODON TUTOR: MSc. NORMA ELIZA CABRERA. “Año 53 de la Revolución”. 1ro de Julio del 2001.

(2) Dictamen.. El que suscribe, , hago constar que el trabajo titulado fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de , autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.. Firma del autor. Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.. Firma del tutor. Firma del jefe del Laboratorio. Fecha. ii.

(3) Resumen. RESUMEN. Los esquemas de datos conceptuales y ontologías son similares en cuanto ambos definen conceptos, relaciones conceptuales y restricciones; de modo que algunos autores han propuesto reusar metodologías y herramientas conceptuales para modelar ontologías. Los esquemas conceptuales como diagramas de clases UML capturan abundante información sobre los conceptos de un universo de discurso, por lo que en la literatura científica se pueden encontrar varios trabajos que investigan las correspondencias entre los diagramas de clases UML y el lenguaje OWL. Los autores concuerdan en que las ontologías y los diagramas de clases UML no son estructuras isomorfas por lo que se puede perder información en la transformación de una estructura a otra. Las implementaciones propuestas no todas están disponibles, otras realizan transformaciones con errores semánticos, o no todas las transformaciones se realizan como se esperan. En este trabajo se presenta una herramienta dinámica que permite crear diferentes escenarios, para ejecutar traductores que extraen ontologías en OWL desde diagramas de clases UML y se propone además, un método que garantiza la preservación del significado de las construcciones de los diagramas de clases UML en la transformación automáticamente, de modo que dicha transformación pueda ser revertida.. iii.

(4) Abstract. ABSTRACT. Conceptual data schemes and ontologies are similar in that both define concepts, conceptual relations and constrains, so that some authors have proposed reuse methodologies and conceptual tools for modeling ontologies. Conceptual schemas like UML class diagrams capture extensive information on the concepts of a universe of discourse, so in the scientific literature can be found several papers that investigate correspondences between UML class diagrams and the OWL language. The authors agree that ontologies and UML class diagrams are not isomorphic structures so some information can be lost in the transformation of one structure to another. The proposed implementations are not all available, other transformations made semantic mistakes, or not all transformations are performed as expected. This paper presents a dynamic tool that allows you to create different scenarios to implement translators from OWL ontologies extracted UML class diagrams and also proposes a method that guarantees the preservation of the meaning of the constructs of UML class diagrams in automatically transformation, so that conversion can be reversed.. iv.

(5) Tabla de Contenidos. TABLA DE CONTENIDOS RESUMEN......................................................................................................................................... iii ABSTRACT ....................................................................................................................................... iv INTRODUCCIÓN .............................................................................................................................. 1 CAPÍTULO I.. GENERACIÓN AUTOMÁTICA DE ONTOLOGÍAS .......................................... 4. 1.1. Introducción a las ontologías .............................................................................................. 4. 1.2. Tipos de ontologías ............................................................................................................. 5. 1.3. Principales características de las ontologías de dominio..................................................... 8. 1.4. Las ontologías y los modelos conceptuales......................................................................... 9. 1.5. Extracción de ontologías ................................................................................................... 13. 1.6. Calidad de las ontologías .................................................................................................. 14. 1.7. Lenguaje OWL para representar ontologías...................................................................... 15. Conclusiones del capítulo ............................................................................................................. 16 CAPÍTULO II.. ONTOLOGÍAS OWL Y DIAGRAMAS DE CLASES UML .......................... 17. 2.1. Diagramas de clases UML y ontologías OWL.................................................................. 17. 2.2. Ontologías OWL para describir UML .............................................................................. 19. 2.3. Descripción en UML y OWL para la metaontología Bunge ............................................. 23. 2.4. Preservación semántica de algunas construcciones UML ................................................. 27. 2.4.1. Formalización matemática para diagramas de clases UML ...................................... 28. 2.4.2. Algoritmo de traducción ........................................................................................... 29. 2.5. Generación automática de ontologías modeladas con herramientas UML ....................... 31. Conclusiones del capítulo ............................................................................................................. 34 CAPÍTULO III. 3.1. TRADUCCIÓN DE DIAGRAMAS DE CLASES A ONTOLOGÍAS OWL .. 35. Introducción a la herramienta MXSLT ............................................................................. 35. 3.1.1. Definición de estructuras........................................................................................... 36. 3.1.2. Especificación de los XSLT ...................................................................................... 36 v.

(6) Tabla de Contenidos. 3.1.3. Selección de los procesadores de XSLT ................................................................... 38. 3.1.4. Consideraciones finales sobre la herramienta ........................................................... 39. 3.2. Uso de MXSLT para extraer ontologías OWL ................................................................. 39. 3.3. Metaontología para UML.................................................................................................. 40. 3.4. Observaciones Generales .................................................................................................. 57. 3.5. Presentación de un caso de estudio ................................................................................... 59. Conclusiones del capítulo ............................................................................................................. 65 CONCLUSIONES ............................................................................................................................ 66 RECOMENDACIONES ................................................................................................................... 67 REFERENCIAS ................................................................................................................................ 68. vi.

(7) Introducción. INTRODUCCIÓN. Con el desarrollo tecnológico el volumen de datos crece exponencialmente y se necesita mucho dinamismo para la interpretación e interoperabilidad entre los datos. Las ontologías son usadas para solucionar en cierta medida este problema, al proporcionar una estructura rica para representar el acuerdo semántico sobre un universo de discurso. Esta es una de las principales razones por la cual son ampliamente usadas en diferentes áreas de investigación (Guarino, 1998), existiendo diferentes tipos de ontologías según sea el propósito y nivel de abstracción. Particularmente las ontologías de dominio según (Sowa, 2000), estudian las categorías de las cosas que existen o pueden existir en un universo de discurso, informalmente, una ontología de dominio describe la terminología o vocabulario del dominio, todos los conceptos esenciales, su clasificación, la taxonomía, las relaciones entre ellos y los axiomas o restricciones del dominio. Formalmente, (Guarino, 1998) define las ontologías de dominio como una estructura capaz de describir los conceptos de un dominio D usando un lenguaje L, de manera que la ontología proporciona el catálogo de los términos que pueden existir en dicho dominio D y lo hace a través de conceptos, relaciones y predicados sobre el lenguaje L. En la literatura científica se pueden encontrar varias metodologías (Fernandez-Lopez et al., 1997, Corcho et al., 2003, Nicola et al., 2009, Sure et al., 2003) para la construcción de ontologías que mejoran el proceso de desarrollo, sin embargo, construir ontologías manualmente es una tarea laboriosa y consumidora de tiempo, que requiere el esfuerzo de ingenieros ontológicos entrenados. Por otro lado, es bien conocido el éxito que han tenido los enfoques de modelación conceptual como el modelo Entidad Relación Extendido en construir esquemas conceptuales para Sistemas de Información, o los diagramas de clases UML (Unified Modeling Language) para representar las estructuras estáticas durante el análisis de requisitos en la producción de Software. Gracias a sus lineamientos metodológicos los esquemas conceptuales, también llamados modelos de datos semánticos, fueron desarrollados para capturar el significado de un dominio de aplicación tal y como es percibido por sus usuarios (Wand et al., 1999, Meersman, 1999). Los esquemas de datos conceptuales y ontologías son similares en que ambos definen conceptos, relaciones conceptuales y reglas; de modo que algunos autores han propuesto reusar metodologías y. 1.

(8) Introducción. herramientas conceptuales para modelar ontologías (Meersman, 2001). El reúso de técnicas de modelación conceptual para ingeniería ontológica es muy beneficioso porque favorece a que las ontologías sean más comprensibles, fáciles de adoptar, construir y visualizar. Los esquemas conceptuales como diagramas de clases UML capturan abundante información sobre los conceptos del dominio. En la literatura científica se puede encontrar varios trabajos que investigan las correspondencias entre los diagramas de clases UML y el lenguaje OWL (Web Ontology Language) con diferentes objetivos, aunque pueden ser clasificados en dos categorías principales. La primera se enfoca hacia la modelación visual de ontologías mediante un entorno visual basado en UML, mientras que la segunda categoría se focaliza en la reutilización del conocimiento representado en un diagrama de clases UML. Este trabajo se enmarca en la segunda categoría, junto a otros trabajos similares como (Falkovych et al., 2003, Na et al., 2006, Xu et al., 2009, Leinhos, 2006, Evermann, 2009). Todos los autores concuerdan en que las ontologías y los diagramas de clases UML no son estructuras isomorfas por lo que se puede perder información en la transformación de una estructura otra. Las implementaciones propuestas por los trabajos mencionados no todas están disponibles, otras realizan transformaciones con errores semánticos, o no todas las transformaciones se realizan como se esperan. Por tanto el objetivo general de este trabajo es extraer automáticamente ontologías en OWL a partir de diagramas de clases UML, preservando la semántica del modelo. Para alcanzar este objetivo se proponen los siguientes objetivos específicos: 1. Analizar las herramientas disponibles que generan ontologías OWL a partir de diagramas de clases UML, para determinar sus principales fortalezas y debilidades. 2. Implementar una herramienta dinámica que permita crear diferentes escenarios, para ejecutar traductores que generen ontologías en OWL a partir de diagramas de clases UML. 3. Sobre la base de las debilidades encontradas en los trabajos analizados, proponer un método que garantice la preservación de la semántica del modelo en la transformación automática de los diagramas de clases UML, de modo que pueda ser revertida. Este trabajo está estructurado en tres capítulos, en el primero se hace una breve introducción a las ontologías, su clasificación y principales características; se exponen similitudes diferencias entre las ontologías de dominio y los esquemas conceptuales. Se mencionan aspectos importantes sobre la extracción de ontologías automáticamente, la calidad de la extracción y sobre el lenguaje OWL, 2.

(9) Introducción. estándar para su representación. El capítulo dos se centra en el estudio de la extracción de ontologías desde diagramas de clases UML y se analizan varios trabajos similares con el objetivo de evaluar sus capacidades y deficiencias. En el capítulo tres se presenta la herramienta implementada y se propone un método para garantizar la preservación del significado de las construcciones del modelo en la transformación automática, de modo que pueda ser revertida. Se termina con las conclusiones generales y las recomendaciones para la continuidad del trabajo.. 3.

(10) Capítulo I. Generación Automática de Ontologías. CAPÍTULO I.. GENERACIÓN AUTOMÁTICA DE ONTOLOGÍAS. Las ontologías de dominio son estructuras que permiten representar el acuerdo semántico de un universo de discurso, son similares a los esquemas de datos conceptuales en que ambos definen conceptos, relaciones conceptuales y restricciones; de modo que algunos investigadores han propuesto reusar metodologías y herramientas conceptuales para modelar ontologías. En este capítulo se hace una breve introducción a las ontologías, se mencionan en el epígrafe 1.2 la clasificación según el tipo y por ser de especial interés las ontologías de dominio, se exponen en el epígrafe 1.3 sus principales características. En el epígrafe 1.4 se hace una sintetizada comparación entre las ontologías y los modelos conceptuales. El epígrafe 1.5 se abordan temas importantes sobre la generación automática de ontologías desde diferentes fuentes de información y sobre la calidad de las ontologías generadas se habla en el epígrafe 1.6. En el epígrafe 1.7 se expone el lenguaje OWL para representar las ontologías y finalmente se ofrecen las conclusiones del capítulo.. 1.1 Introducción a las ontologías Las ontologías cada vez son más usadas en la ciencia de la computación, si bien es un término que se ha tomado prestado del campo de la filosofía, actualmente juega un papel importante en las teorías de Bases de Datos y Sistemas de Información, Inteligencia Artificial, Bioinformática y otras disciplinas. En particular se reconoce su aplicabilidad en áreas de investigación tan diversas como la modelación de datos (Shanks et al., 2003), el diseño de bases de datos (Sugumaran and Storey, 2006), integración de información (Bergamaschi et al., 1998, Yugyung et al., 2006), ingeniería del conocimiento (Uschold and Gruninger, 1996, van Heijst et al., 1997), particularmente en la representación del conocimiento (Guarino, 1995, Schreiber, 2007, Stevens et al., 2000), y procesamiento del lenguaje natural (Graeme, 2003, Buitelaar and Cimiano, 2008, Bateman et al., 2010). Por otro lado, las áreas de aplicaciones incluyen la integración de esquemas de datos (Hakimpour and Geppert, 2001), medicina (Guizzardi et al., 2002), Sistemas de Información geográficos (Fonseca et al., 2002) y Sistemas de Información de modo general. Una de las razones que justifican la amplia aplicabilidad de las ontologías es que constituyen un recurso para representar el acuerdo semántico de un dominio dado y a diferencia de los modelos de datos, el valor fundamental de las ontologías radica en que son relativamente independientes de 4.

(11) Capítulo I. Generación Automática de Ontologías. aplicaciones particulares; ya que su objetivo principal es establecer un consenso del universo de discurso para que puedan ser reusadas por diferentes aplicaciones o tareas. Las ontologías contienen el vocabulario, la definición de los conceptos y sus interrelaciones para un dominio dado. Probablemente la definición de ontología más citada en la literatura sea la definición de Gruber: “Una ontología es una especificación formal y explícita de una conceptualización” (Gruber, 1993a), mientras que desde el punto de vista de los Sistemas de Información (SI) “una ontología es un artefacto del software (o lenguaje formal) diseñado para un conjunto específico de usos y ambientes computacionales” (Guarino, 1998). Existen diversas definiciones de ontologías en la literatura científica, sin embargo algunos elementos son comunes a todas ellas y generalmente se basan en el concepto de conceptualización. En (Cabrera-González et al., 2011) se puede encontrar un estudio de cómo este concepto es tratado en la literatura.. 1.2 Tipos de ontologías Frecuentemente se establecen debates donde se intenta dar una definición informal y simplificada de las ontologías como estructuras muy genéricas que son aplicables y son compartidas por disímiles dominios, o también como especificaciones para un dominio concreto similar a una base de conocimiento (Mizoguchi, 2003); ambas interpretaciones son correctas porque se refieren a distintos tipos de ontologías. Existen diferentes criterios de clasificación como el que propone (Uschold and Gruninger, 1996) según la rigurosidad del formalismo en la representación: (i) informales, (ii) semi-informales, (iii) semi-formales y (iv) rigurosamente formales. Otros dos criterios se presentan en (van Heijst et al., 1997): uno, el tipo y cantidad de estructuras utilizadas para representar la conceptualización; dos, el objetivo de la conceptualización. Para el primer criterio se distinguen tres categorías: . Ontologías terminológicas, como diccionarios que especifican los términos usados para representar el conocimiento en el universo de discurso.. . Ontologías de información, especifican la estructura de los registros de bases de datos, por ejemplo los esquemas de bases de datos.. . Ontologías para la modelación de conocimiento, definen conceptualizaciones de un dominio. Si se comparan con las ontologías de información, tienen una estructura mucho más rica.. 5.

(12) Capítulo I. Generación Automática de Ontologías. Para el segundo criterio propone: . Ontologías de aplicación, contienen todas las definiciones que son necesarias para modelar el conocimiento requerido para una aplicación particular. Típicamente, son una mezcla de conceptos que son tomados de ontologías de dominio y de ontologías genéricas (descritas a continuación). No suelen ser reutilizables porque ellas se crean partiendo de bibliotecas de ontologías que se redefinen para representar los métodos y tareas específicas de una aplicación concreta.. . Ontologías de dominio, expresan conceptualizaciones que son específicas para dominios particulares. La diferencia entre conocimiento del dominio y ontología de dominio radica, en que el primero describe situaciones para un cierto dominio y las segundas imponen restricciones sobre la estructura e información del conocimiento del dominio.. . Las ontologías genéricas son similares a ontologías de dominio, pero los conceptos que se definen son muy generales. Típicamente definen conceptos como: estado, evento, proceso, acción, componente, etc. Generalmente los conceptos en ontologías de dominio son especializaciones de conceptos en ontologías genéricas.. . Las ontologías de representación, pretenden ser neutras con respecto a entidades globales (Guarino and Boldrin, 1993). Las ontologías de dominio y las ontologías genéricas se describen usando primitivas de ontologías de representación. Un ejemplo en esta categoría es el marco ontológico usado en Ontolingua (Gruber, 1993b).. Ambos criterios son analizados en (Guarino, 1997) señalando que el primero introduce confusiones, por ejemplo la especificación de la estructura de los registros de una base de datos no puede ser considerada una ontología porque pertenece al nivel de símbolos, por tanto, un esquema de bases de datos se considera una ontología de información sólo si es un esquema conceptual. También critica la diferenciación entre ontologías para la modelación de conocimiento y ontologías de dominio, mucho más si son consideradas como el vocabulario formalizado para describir un universo de discurso, porque entraría en contradicción con las ontologías terminológicas. En resumen, opina que no hay razón alguna para suponer una clasificación sobre la base de la cantidad y el tipo de la estructura de su conceptualización, sino que se puede establecer diferencias entre ontologías sobre la base del grado de detalle usado para caracterizar una conceptualización. Una ontología muy detallada estará cercana a la especificación intencionada de una conceptualización y puede ser usada como consenso para compartir una base de conocimiento 6.

(13) Capítulo I. Generación Automática de Ontologías. particular; una ontología muy simple, por otra parte, se puede desarrollar para establecer un consenso entre usuarios que luego particularizarán según sus objetivos. Otra de la clasificación más citada es la propuesta por (Steve et al., 1997): ontologías (i) genéricas, (ii) de dominio y (iii) de aplicación. Al igual que la encontrada en (Guarino, 1998): ontologías (i) de alto nivel, (ii) de dominio, (iii) de tarea y (iv) de aplicación; relacionadas según se muestra en la Figura I-1.. Metanivel. Dominio. Tarea. Aplicación. Figura I-1. Tipos de ontologías según el nivel de dependencia de una tarea particular o punto de vista. Tomada de (Guarino, 1998).. . Ontologías de alto nivel, describen conceptos muy generales como espacio, tiempo, materia, objetos, eventos, etc., los cuales son independientes de un problema o dominio específico; o sea, lo que otros autores consideran ontologías genéricas o superiores.. . Ontologías de tareas, describen las tareas o actividades propias del dominio (Mizoguchi, 2003); especializando los términos que se introducen en una ontología de alto nivel.. . Ontologías de aplicación, describe conceptos que dependen tanto de dominios como de tareas particulares. Estos conceptos a menudo se corresponden con el rol que desempeña una entidad del dominio que realiza o está involucrada en cierta tarea.. Guarino hace una aclaración importante sobre la diferencia entre una ontología de aplicación y una base de conocimiento, plantea que el objetivo de una ontología es describir hechos que se asumen verdaderos por una comunidad de usuarios en virtud de un vocabulario acordado. Una base de conocimiento genérica, en cambio, también puede describir hechos y aseveraciones sobre una situación específica y dentro de ellas se distinguen dos componentes: la ontología (describe cierta información independiente de los estados particulares) y la propia base de conocimiento (describe informaciones dependientes de los posibles estados).. 7.

(14) Capítulo I. Generación Automática de Ontologías. 1.3 Principales características de las ontologías de dominio Las ontologías de dominio según (Sowa, 2000), estudia las categorías de las cosas que existen o pueden existir en un universo de discurso. Informalmente, una ontología de dominio describe la terminología o vocabulario del dominio, todos los conceptos esenciales, su clasificación, la taxonomía, las relaciones entre ellos y los axiomas o restricciones del dominio. Formalmente, Guarino (Guarino, 1998) define las ontologías de dominio como una estructura capaz de describir los conceptos de un dominio D usando un lenguaje L, la ontología proporciona el catálogo de los términos que pueden existir en dicho dominio D y lo hace a través de conceptos, relaciones y predicados sobre el lenguaje L. Para representar el conocimiento de un dominio, las ontologías precisan de los siguientes componentes (Barchini et al., 2007): . Conceptos: son las ideas básicas que se intentan formalizar. Los conceptos pueden ser clases de objetos, métodos, planes, estrategias, procesos de razonamiento, etc.. . Relaciones: representan la interacción y enlace entre los conceptos, formando la taxonomía del dominio. Las interrelaciones básicas son: sub-clase-de, parte-de, conectada-a.. . Funciones: son un tipo concreto de relación donde se identifica un elemento mediante el cálculo de una función que considera varios elementos de la ontología.. . Instancias: se utilizan para representar objetos determinados de un concepto.. . Axiomas: son teoremas que se declaran sobre relaciones que deben cumplir los elementos de la ontología. Especifican las definiciones de los términos en la ontología y las restricciones de sus interpretaciones. Los axiomas deben formularse para definir la semántica o el significado de los términos.. En muchos casos, las instancias de un dominio de aplicación son incluidas en la ontología así como las reglas del dominio (identidad, obligatoriedad, rigidez) implicadas por el significado de los conceptos. Las reglas del dominio restringen la semántica de los conceptos y de las relaciones conceptuales en una conceptualización específica de un dominio de aplicación particular; estas reglas deben ser satisfechas por todas las aplicaciones que deseen usar o comprometerse con una interpretación de una ontología. Mediante una ontología se representa lo que existe en un dominio, y mediante la semántica de los conceptos, se describe ese dominio. A continuación se describen de manera general algunos de 8.

(15) Capítulo I. Generación Automática de Ontologías. estos conceptos relacionados con reglas de dominio abstractas, una mayor formalización y amplitud puede encontrarse en (Welty and Guarino, 2001): . Identidad se relaciona con el problema de distinguir una instancia específica de una cierta clase, de otras instancias de la misma clase por medio de las propiedades y características. . Unicidad, se relaciona con el problema de distinguir las partes de una instancia del resto de la realidad, por medio de una relación unificadora que enlaza solo las partes. Ejemplo. Localizar un perro es un problema de identidad, mientras que delimitar si el collar forma parte de la descripción de un perro es un problema de unicidad.. . Rigidez. Esta es una propiedad menos intuitiva, en su formalización se usan otras propiedades que permiten precisarla con todo rigor; y tiene como base un reflejo de lo esencial en la existencia de las instancias. Por ejemplo, es fácil comprender que Persona cumple la propiedad, si x es una instancia de persona, lo es en todo “mundo” posible; mientras que Estudiante no lo es, pues un individuo puede ser estudiante, no serlo, volver a serlo, y es el mismo individuo, no refleja lo esencial de la existencia de un individuo.. Al igual que las ontologías de dominio los esquemas conceptuales se construyen para capturar el significado de un dominio de aplicación tal y como es percibido por sus usuarios (Wand et al., 1999, Meersman, 1999).. 1.4 Las ontologías y los modelos conceptuales La modelación de datos se ha trabajado desde la década del 70 para asistir al diseño de bases de datos, en particular para bases de datos relacionales; en la medida que las técnicas ganaron en madurez se fueron convirtiendo en herramientas para analizar la semántica de una organización, o sea, la estructura de la información en la organización y como esta es usada para llevar a cabo su misión. La idea básica de la modelación conceptual es muy simple, es la actividad de describir un esquema para un dominio de aplicación en términos de conceptos que son familiares a los actores en el dominio del mundo real y no en términos técnicos como ficheros, estrategias de acceso, etc. Todos esos tecnicismos son importantes pero se deben tener en cuenta solamente en las fases posteriores a la modelación conceptual, durante el diseño e implementación. La modelación conceptual es la actividad de crear representaciones abstractas de determinados aspectos de una organización y su entorno en el mundo que nos rodea. La abstracción es un recurso 9.

(16) Capítulo I. Generación Automática de Ontologías. intelectual para explorar regularidades cuando organizamos un conocimiento, una realidad compleja se analiza de acuerdo a propósitos específicos, de forma típica se analizan los requerimientos que debe satisfacer un sistema que se desea desarrollar y se crea un esquema que recoja esos aspectos de la realidad que son relevantes al sistema y se descartan los demás. Es importante también distinguir entre mundo real y universo del discurso, ya que este último es la visión que del mundo real tiene el diseñador. Esto implica que el primer paso en la concepción de una base de datos es definir el universo del discurso, fijando para ello una serie de objetivos sobre el mundo real que se va a analizar; así, por ejemplo, de un mismo mundo real como puede ser el que constituye un hospital, podemos definir dos universos de discurso tan distintos como el relativo a los doctores con sus especialidades, enfermeras, pacientes con sus historias clínicas, medicamentos, etc., o el concerniente a la gestión de empleados, nóminas, contabilidad, facturación, etc. Es decir, el mundo real es el mismo, pero el objetivo en el primer caso es de gestión médica, mientras que en el segundo es de pura gestión empresarial. Los modelos conceptuales modelan información para un universo de discurso, mientras que las ontologías se proponen abarcar una realidad dada lo más completa posible. Las ontologías generalmente se usan para especificar y comunicar conocimiento de un dominio de una manera genérica y son muy útiles para estructurar y definir el significado de los términos. A diferencia de los modelos de datos, una característica distintiva de las ontologías es su relativa independencia de aplicaciones particulares, o sea, una ontología representa conocimiento relativamente genérico que puede ser reusado por diferentes tipos de aplicaciones. Aunque existen múltiples definiciones del término ontología (Cabrera-González et al., 2011), todas tienen algunos elementos en común como: un acuerdo sobre una conceptualización compartido, formal, explícito y parcialmente consensuado. Además, (Spyns et al., 2002) enfatiza que las ontologías contienen el vocabulario (términos y etiquetas), definiciones de los conceptos y las relaciones entre ellos, para un dominio dado. En muchos casos las instancias del dominio se incluyen mediante reglas que se implican por el significado de los conceptos. Las reglas del dominio restringen la semántica de los conceptos y las relaciones de ellos en una conceptualización específica de una aplicación en el dominio. Estas reglas deben satisfacerse por todas las aplicaciones que deseen utilizar una ontología (Gruber, 1993a). Un modelo de datos por el contrario, representa la estructura e integridad de los datos que interesan para alguna aplicación. En principio la conceptualización y el vocabulario de un modelo de datos no 10.

(17) Capítulo I. Generación Automática de Ontologías. se concibe para que sea compartido con otras aplicaciones (Sheth and Kashyap, 1992). Por ejemplo considere una ontología para el dominio de una biblioteca, con una regla que identifica cada libro por el valor único del ISBN, todas las aplicaciones que se comprometan con la ontología deben satisfacer la regla de identificación. Sin embargo, no toda aplicación para una librería concibe un ISBN para cada libro, por lo que no puede usar la ontología y si dos aplicaciones no comparten el mismo vocabulario y reglas del dominio no están en primera instancia habilitadas para comunicarse entre sí. Los modelos de datos especifican la estructura e integridad de un conjunto de datos del universo de discurso pero usualmente dependen de las necesidades o tareas específicas de las aplicaciones. Por otro lado, la semántica de los datos que se capta en un esquema conceptual, por lo general es un acuerdo informal entre usuarios y desarrolladores; muchas veces se captura como por nuevos requerimientos funcionales que solicitan los usuarios. En el contexto de ambientes de desarrollo abiertos como en la Web Semántica las ontologías representan el conocimiento que formalmente especifican el acuerdo entre las aplicaciones del dominio (Guarino, 1998). Es válido destacar la opinión de (Uschold and King, 1995) sobre las teorías ontológicas como un conjunto de formulaciones intencionales que deben ser siempre verdaderas de acuerdo con cierta conceptualización, o sea, la especificación de un conjunto de reglas del dominio que individualizan o aproximan el significado de una conceptualización. En este punto las ontologías y los modelos de datos, ambos constituyen un acuerdo parcial de una conceptualización (Guarino and Giaretta, 1995) si se consideran como la estructura y las reglas del dominio que deben ser modeladas. Sin embargo, a diferencia de las tareas específicas y la orientación hacia la implementación de los modelos de datos, en las ontologías (al menos por definición) deben ser mucho más genéricas e independientes de tareas específicas. En (Spyns et al., 2002) se discute cómo las reglas del dominio formalmente expresadas influyen en la genericidad de conocimiento. Los autores introducen algunos aspectos que permiten diferenciar las ontologías de los modelos de datos: nivel de operación, capacidad expresiva, usuarios y extensibilidad. . Nivel de operación: Las reglas del dominio pueden ser expresadas a bajo nivel u orientadas a implementación como son la especificación de tipos de datos o valores nulos, especificación de unicidad, etc. Mientras que reglas más abstractas que expresen totalidad, rigidez, identificación (Guarino and Welty, 2002) operan a alto nivel, independientes de la 11.

(18) Capítulo I. Generación Automática de Ontologías. forma de implementación. Mientras más abstractas sean las reglas del dominio más genéricas serán. . Capacidad expresiva: los lenguajes como SQL (Structured Query Language) están orientados a mantener la integridad de un conjunto de datos y disponen de recursos como las llaves foráneas. En general las reglas del dominio deben ser formuladas de modo que se puedan expresar no solo para garantizar la integridad sino la conceptualización del dominio. Por consiguiente los lenguajes para representar las reglas del dominio deben incluir construcciones que expresen otros tipos de restricciones y soporten la inferencia.. . Usuarios, objetivos y propósitos: Prácticamente es inevitable que los objetivos y aspiraciones de los usuarios determinen cómo modelar los requerimientos del dominio, por ejemplo, la granularidad del propio proceso de modelación, la decisión de modelar algo como una clase o atributo, el tipo de dato, etc. Las reglas del dominio operan sobre las construcciones del modelo y por consiguiente dependen de ellas.. . Extensibilidad: A diferencia de los modelos de datos donde generalmente el diseñador sólo tiene en cuenta el universo de discurso que interesa para una aplicación específica, la conceptualización de una ontología de dominio debe tener en cuenta los objetos del dominio independientemente de los problemas o tareas. Por eso es que usualmente se limitan a identificar el vocabulario que será compartido, pero (Spyns et al., 2002) insiste en que las reglas del dominio determinan cómo se usará el vocabulario.. Las ontologías son un tipo de esquema conceptual, define categorías de datos y su naturaleza gráfica ofrece una excelente base para discutir y negociar el significado de dichas categorías. Los esquemas generalmente se complementan con un análisis de reglas de negocio. El punto de vista de la modelación de datos se basa en el enfoque de asumir un mundo cerrado (closed world assumption): Solo lo que se puede asegurar es conocido. (Only that which is asserted is known). Por su parte, las ontologías se basan en el enfoque de asumir un mundo abierto (open world assumption): Todas las aseveraciones se asumen ciertas, hasta que se pruebe lo contrario. (All assertions are assumed to be true until proven otherwise). Los criterios mencionados ayudan a comprender las principales diferencias entre las ontologías y los modelos de datos, pero como señala (Spyns et al., 2002) el principal problema radica en que no existe una línea estricta entre el conocimiento genérico y específico, por lo que determinar cuántas reglas o restricciones comprometen la interoperabilidad es un tema subjetivo que queda en manos. 12.

(19) Capítulo I. Generación Automática de Ontologías. del diseñador. A pesar de lo mencionado, algunos investigadores han propuesto reusar metodologías y herramientas conceptuales para modelar ontologías.. 1.5 Extracción de ontologías En la literatura científica se pueden encontrar varias metodologías (Fernandez-Lopez et al., 1997, Corcho et al., 2003, Nicola et al., 2009, Sure et al., 2003) para la construcción de ontologías que mejoran el proceso de desarrollo, sin embargo, construir ontologías manualmente es una tarea laboriosa y consumidora de tiempo, que requiere el esfuerzo de ingenieros ontológicos entrenados. Este es uno de los principales problemas que se identifican en la construcción de ontologías manualmente, el cuello de botella (bottleneck) que se produce al intentar representar toda la información relevante de un universo de discurso y el tiempo que dicha tarea requiere. Lo anterior ha posibilitado el desarrollo de dos líneas de investigación (Shamsfard and Barforoush, 2003): el desarrollo de métodos, metodologías, herramientas y algoritmos para (1) integrar y reutilizar ontologías existentes, y (2) para la adquisición o aprendizaje de ontologías semiautomáticamente. Este trabajo se enmarca dentro de la segunda línea de investigación. La generación automática de ontologías se basa en métodos tomados prestados de otras áreas de investigación tales como aprendizaje reforzado, representación del conocimiento, procesamiento del lenguaje natural, estadística y recuperación de información. Algunas investigaciones usan el término de “aprendizaje ontológico” en lugar de “extracción de ontología”, primeramente porque los conceptos y sus relaciones se obtienen a través de un proceso de aprendizaje. Sin embargo, ya que muchas herramientas para la mezcla de ontologías también operan con un proceso de aprendizaje y además algunas herramientas para extracción de ontologías se basan solamente en un análisis lingüístico en lugar de proceso de aprendizaje, en lo siguiente el autor asume la generación automática de ontologías como “extracción de ontología” por las características del método que se propone. Maedche y Staab distinguen en (Maedche and Staab, 2001) diferentes categorías para la generación automática de ontologías según sea la fuente de conocimiento de la que se parte, por ejemplo, texto libre, diccionarios, bases de conocimientos, información semi-estructurada y esquemas de bases de datos. Particularmente UML es el estándar para modelación de aplicaciones en la ingeniería de software, es un lenguaje visual para modelación de propósitos generales. Actualmente muchas fuentes de 13.

(20) Capítulo I. Generación Automática de Ontologías. datos son modeladas a través de diagramas de clases UML, en el cual se especifica conocimiento del dominio. Los diagramas de clases UML permiten modelar de manera declarativa la estructura estática de un dominio de aplicación. Algunos trabajos como (Cranefield, 2001, Djurić et al., 2005, Baclawski et al., 2001, Gaševic et al., 2007) han investigado las correspondencias entre ontologías y diagramas de clases UML, pero la mayoría de estos trabajos están enfocados a extender UML a través de perfiles de modo que se proporciona un método visual para modelar ontologías. Como resultado, los diseñadores deben modelar los diagramas de clases UML de manera no familiar y no permite extraer ontologías a partir de los diagramas de clases tradiciones. Otros trabajos como (Falkovych et al., 2003, Na et al., 2006, Leinhos, 2006, Xu et al., 2009) se enfocan en el problema de reutilizar conocimientos representados en diagramas de clases UML para construir ontologías. Sin embargo, estos métodos se enfocan en una extracción limitada sin hacer énfasis en la preservación de la semántica en la traducción. En el siguiente epígrafe se exponen algunas técnicas para evaluar la calidad de las ontologías.. 1.6 Calidad de las ontologías Algunos esfuerzos se han hecho para evaluar la calidad de una ontología construida (Burton-Jones et al., 2005, Gangemi et al., 2005, Köhler et al., 2006, Orme et al., 2007). En (Janez et al., 2005, Janez, 2006) se agrupan varias técnicas evaluadoras en cuatro categorías. La primera se basa en un patrón, intenta evaluar la calidad de una ontología utilizando una ontología como paradigma, la cual se considera una ontología bien formada. Esta puede ser una ontología ya existente para el dominio, construida a partir de un corpus textual o por un experto del dominio. Los conceptos de la nueva ontología se comparan con los conceptos de la ontología estándar, la cual se considera una buena representación del dominio. Generalmente este esta técnica se utiliza para evaluar ontologías que se obtienen a través de procesos de aprendizaje reforzado. El segundo grupo es basado en aplicaciones, donde la calidad de una ontología se determina por el desempeño de una aplicación real que use la ontología. La salida de una aplicación o su rendimiento puede ser mejor o peor dependiendo del uso de la ontología; por tanto las ontologías pueden ser evaluadas simplemente por adicionarlas a la aplicación y evaluar los resultados de tal aplicación. Aunque sí la ontología es solo un pequeño componente de la aplicación, es difícil juzgar la calidad de la ontología con esta técnica porque su influencia tanto en el rendimiento como en la salida puede ser de manera indirecta (Janez, 2006). 14.

(21) Capítulo I. Generación Automática de Ontologías. La tercera categoría son controladoras de datos, porque esta evalúa la calidad de una antología cuantificando cuán adecuadamente la ontología representa el dominio referido en el corpus. Se cuantifican los solapamientos entre los términos específicos del dominio en el corpus y los términos que aparecen en la ontología. Una ontología tienen una estructura medianamente compleja, por lo que puede ser evaluada a nivel léxico, semántico, sintáctico y contextual; en la categoría controladora de datos, una ontología solo se evalúa a nivel léxico. La cuarta categoría depende del criterio de expertos, aquí la evaluación la hacen expertos del dominio, quienes intentan estimar cuán buena es la ontología teniendo un conjunto de criterios predefinidos, estándares y requerimientos. Aunque esta evaluación requiere mayor tiempo permite evaluar la ontología en varias perspectivas, incluyendo los niveles léxico, semántico, sintáctico y contextual.. 1.7 Lenguaje OWL para representar ontologías La representación de las ontologías depende del tipo y nivel de abstracción. Típicamente se almacenan en ficheros XML (Extensible Markup Language) o usando un lenguaje lógico. Como modelan conceptos y relaciones entre ellos pueden representarse a través de alguna estructura de grafos. También pueden expresarse como un conjunto de sentencias declarativas en lenguaje natural, pero el procesamiento del lenguaje natural puede ser computacionalmente costoso. Varios autores han propuesto diferentes estructuras matemáticas, con menor o mayor grado de complejidad, para la representación de ontologías, en (Cabrera González et al., 2011) se presenta un estudio formal, sobre diferentes representaciones matemáticas para las ontologías. Zhuoming Xu presenta un trabajo matemáticamente riguroso en (Xu et al., 2009) para establecer un mapeo entre la estructura de ontologías en OWL, el lenguaje estándar para representar ontologías, con los diagramas de clases UML. El autor formaliza las ontologías OWL como un par O = (OS, OI) = (ID0, Axiom0), donde: (1). ID0=CID0IID0DRID0OPID0DPID0 es un conjunto de identificadores particionado en: a. un subconjunto CID0 de identificadores de clases, incluyendo los identificadores definidos por los usuarios además de owl:Thing y owl:Nothing; b. un subconjunto IID0 de identificadores para instancias o individuos; c. un subconjunto DRID0de identificadores de rangos de datos; cada identificador de rango es un valor de los tipos de datos en los esquemas XML; 15.

(22) Capítulo I. Generación Automática de Ontologías. d. un subconjunto OPID0 de identificadores de propiedades de objetos, estas propiedades conectan a instancias de clases; e. un subconjunto DPID0 de identificadores de propiedades de datos, estas propiedades establecen los atributos. (2). Axiom0 es un conjunto finito particionado en: un subconjunto de axiomas de clases/propiedades usando referencias a la estructura de la ontología y un subconjunto de axiomas de individuos, usadas para representar las instancias de la ontología.. Conclusiones del capítulo Las ontologías en la ciencia de la computación constituyen un recurso importante para representar el acuerdo semántico de un dominio dado. Existen varias metodologías y herramientas para la construcción de ontologías, sin embargo, construir ontologías manualmente es una tarea que requiere el esfuerzo de ingenieros ontológicos entrenados. Los esquemas de datos conceptuales y ontologías son muy similares porque ambos definen conceptos, relaciones conceptuales y reglas; de modo que algunos autores han propuesto reusar metodologías y herramientas conceptuales para modelar ontologías. El reúso de técnicas de modelación conceptual para ingeniería ontológica es beneficioso porque favorece a que las ontologías sean más comprensibles, fáciles de adoptar, construir y visualizar.. 16.

(23) Capítulo I. Generación Automática de Ontologías. CAPÍTULO II.. ONTOLOGÍAS OWL Y DIAGRAMAS DE CLASES. UML. La comparación, mapeo y reglas de transformación entre los diagramas de clases UML y las ontologías, son temas sobre los que se ha escrito bastante en la literatura científica. En este capítulo se analizan algunos trabajos en los que se proponen soluciones, para reutilizar la información representada en diagramas de clases UML con el objetivo de construir ontologías OWL. Primero en el epígrafe 2.1 se expone un conjunto representativo de trabajos investigativos que abordan el tema de ontologías y diagramas de clases UML. Para este trabajo interesan las investigaciones que proponen soluciones para extraer ontologías desde diagramas de clases UML por lo que se analizan en el epígrafe 2.2, 2.3 y 2.4 las propuestas de (Leinhos, 2006), (Evermann, 2009) y (Xu et al., 2009), respectivamente. También se analiza en el epígrafe 2.5 la propuesta de (Gaševic et al., 2007) aunque se basa en la extensión de UML para modelar ontologías. Se exponen las conclusiones del capítulo.. 2.1 Diagramas de clases UML y ontologías OWL En la literatura científica se puede encontrar varios trabajos que investigan las correspondencias entre los diagramas de clases UML y las ontologías con diferentes objetivos, aunque pueden ser clasificados en dos categorías principales. La primera enfocada hacia la modelación visual de ontologías mediante un entorno visual basado en UML. Cranefield (Cranefield, 2001) fue el primero que introdujo esta idea, con un método donde los expertos del dominio, primero crean una ontología en una herramienta UML y luego la exportan a un fichero basado en XMI (XML Metadata Interchange), finalmente con un XSLT (Extensible Stylesheet Language Transformations) se traduce el código XMI en el esquema RDF (Resource Description Framework) correspondiente a una ontología. Baclawski y otros investigadores (Baclawski et al., 2001) proponen un método para extender UML de modo que soporte ingeniería ontológica, resume similaridades y diferencias entre UML y DAML, una de las primeras normativas del lenguaje OWL, y propone extensiones a UML para resolver las diferencias, luego propone un mapeo entre el UML extendido y DAML. El programa. 17.

(24) Capítulo I. Generación Automática de Ontologías. CODIP1 (Components for Ontology Driven Information Push) desarrolló una herramienta llamada Duet que brinda un entorno basado en UML para desarrollar ontologías. La última versión de la herramienta Duet permite conversiones entre UML y OWL. Como el estándar UML no puede traducirse completamente a OWL,(Djurić et al., 2005, Gaševic et al., 2007) introducen un Metamodelo de Definición de Ontologías (ODM), en su investigación y definen un perfil basado en OWL para UML con el objetivo de integrar Ingeniería de Software en el desarrollo de ontologías. En resumen, la solución de Cranefield, usa RDFS como lenguaje, sin embargo su método tiene el inconveniente de que RDFS no tiene suficiente expresividad para capturar restricciones del dominio representado en los diagramas de clases UML. Todas las otras soluciones usan estereotipos para extender UML, para establecer las correspondencias entre los elementos no comunes de UML y lenguajes de ontologías (en lenguaje DAML u OWL). Como resultado, el mapeo no se corresponde con el estándar de UML sino con cada solución que tiene sus propias reglas para crear los diagramas de clases UML. La segunda categoría se focaliza en la reutilización del conocimiento mediante la extracción de conceptos de un dominio y sus relaciones. Los trabajos representativos de esta categoría entre otros son: las investigaciones de Falkovych (Falkovych et al., 2003), Na (Na et al., 2006), Leinhos (Leinhos, 2006), Evermann (Evermann, 2009) y Xu (Xu et al., 2009). Falkovych propone una traducción del diagrama de clases estándar UML a DAML+OIL, el predecesor de OWL. Este método convierte clases UML en clases DAML+OIL, atributos en propiedades de tipos de datos y asociaciones binarias en propiedades de objetos, teniendo en cuenta los atributos de asociaciones. Para convertir asociaciones UML, primero definen cuatro tipos especiales de propiedades de objetos en DAML+OIL: “Binary”, “Unidirectional”, “Aggregation” y “Composition”; de acuerdo a las características de las asociaciones binarias, luego mapean las asociaciones como subpropiedades de una de estas propiedades, según corresponda. La propuesta de (Na et al., 2006) es un método para construir ontologías de dominio mediante la extracción de conceptos de diagramas de clases UML diseñados previamente. Ellos comparan los elementos del modelo UML con los de OWL y derivan reglas de transformación. Además algunas restricciones importantes en el diagrama de clases UML, como la restricción de disyunción y. 1. codip.projects.semwebcentral.org. 18.

(25) Capítulo I. Generación Automática de Ontologías. cubrimiento en los conjuntos de generalización. Introducen un algoritmo y herramienta basada en XSLT, no disponible para usarla. Las soluciones más comunes son implementadas con XSLT, como en los trabajos mencionados y (Leinhos, 2006, Evermann, 2009) que serán analizados en los epígrafes siguientes.. 2.2 Ontologías OWL para describir UML Uno de los resultados parciales de la tesis de maestría de Sebastian Leinhos (Leinhos, 2006) fue la creación de un XSLT para transformar diagramas de clases UML a OWL. El autor propone un script llamado “OWLfromUML.xsl” cuyo objetivo es generar una ontología donde se preserven todos los elementos modelados en un diagrama de clases UML. Dado que cada elemento UML debe ser transformado define un metamodelo y un conjunto de reglas de transformación para garantizarlo, que se muestran en la Tabla II-1. Tabla II-1. Reglas de transformación para OWL desde UML. Tomado parcialmente de http://diplom.ooyoo.de. UML Class Package Abstract Class. OWL. Multiplicity. owl:Class Prefix owl:DatatypeProperty owl:Class with restriction owl:Class, rdfs:subClassOf rdfs:subClassOf owl:ObjectProperty owl:ObjectProperty owl:ObjectProperty owl:ObjectProperty owl:Class owl:DatatypeProperty owl:ObjectProperty owl:ObjectProperty owl:ObjectProperty rdfs:subPropertyOf owl:DatatypeProperty owl:ObjectProperty owl:ObjectProperty owl:ObjectProperty rdfs:subPropertyOf owl:cardinality owl:minCardinality owl:maxCardinality. much values, [*] Minimum, [1..*] Equal named associations or attributes Stereotype <<DataType>>. owl:minCardinality First-Class-Concept owl:unionOf XML Schema Datatype. Interface Generalization. Association. unnamed, unidirectional unnamed, bidirectional named, unidirectional named, bidirectional Association Class. Roles Attributes. Data type as value Class as value. Dependencies Especial dependencies number, e.g. [3] interval e.g. [1..5]. Notas (1) (2) (3) (4) (5). (6). (7) (8) (9). (10). (11) (12). 19.

(26) Capítulo I. Generación Automática de Ontologías. También propone un segundo script llamado “OWLwithUML.xsl” para modelar cada concepto de una ontología con la ayuda de construcciones UML, pero en este trabajo solo interesa el primer script. A continuación se ofrecen algunas notas del referido autor sobre las descripciones o restricciones de la Tabla II-1: 1. A cada clase de UML le corresponde una clase en OWL, con la característica que en OWL el nombre de la clase será el nombre de la clase UML precedido por el nombre del diagrama al que pertenece. 2. Cuando una clase pertenezca a un paquete se le adiciona como prefijo al nombre de la clase, el nombre de dicho paquete separado por dos puntos “:”. 3. Una clase abstracta en UML se transforma en OWL en una clase con una DatatypeProperty nombrada “isAbtract” con valor true como único posible valor. 4. Una interfaz se transforma en una clase y todas las clases que la implementen serán subclase de esta. 5. La relación de generalización se transforma en relación de subclase. 6. En principio, las asociaciones son transformadas en una propiedad de objeto, a la que se le crea automáticamente una propiedad de objeto inversa con el nombre “inverseOf” seguido del nombre de la asociación. El nombre de la propiedad de objeto es el nombre que tiene la asociación. En caso de que sea una asociación anónima se le generara un nombre automáticamente basado en los últimos cuatro números del ID XMI. El dominio y el rango, se definen por la dirección de la flecha en el caso que sea bidireccional, en caso contrario se definirá por el orden de aparición. 7. Los roles se definen como una propiedad de objeto del cual se deriva una sub propiedad que es la encargada de describirlo. 8. Un atributo se transforma en una propiedad con el mismo nombre y el rango se determina por los valores predefinidos en el esquema XML (ver Tabla II-2). Si tiene una clase como valor, entonces se transforma en una propiedad de tipo objeto cuyo rango va a ser la propia clase.. 20.

(27) Capítulo I. Generación Automática de Ontologías. 9. Las dependencias se transforman en propiedades de objeto con el nombre Dependency. El dominio y el rango de esta propiedad se determinan por todas las clases que son parte de una dependencia, en caso de ser necesario son combinadas por la estructura “owl:unionOf”. 10. Según sea el tipo de multiplicidad se define la cardinalidad correspondiente: a. Cuando la multiplicidad es exacta, un solo valor posible. Por ejemplo, si la multiplicidad es seis se define la cardinalidad exactly 6. b. Cuando la multiplicidad es un intervalo como puede ser [1..5], la cardinalidad se define con las restricciones MinCardinality y MaxCardinality, quedando explícito el intervalo. En caso de que el mínimo sea cero solo habría que expresar la cardinalidad máxima. c. Cuando la multiplicidad es mucho, sin un valor mínimo ni máximo definido (*), no es necesario definir restricciones de cardinalidad ya que esta no existen, por lo tanto esta multiplicidad no necesita ser transformada. d. Cuando en la multiplicidad solo está definido el mínimo como puede ser [2..*], se crea la restricción MinCardinality ya que no existe un máximo. 11. Cuando existan dos o más asociaciones con el mismo nombre, se crea una sola propiedad de objeto en la cual se determinará el dominio y el rango con todas las clases que formen parte de las asociaciones según corresponda. 12. En caso de que existan dos o más atributos con el mismo nombre y tipo, se transforma en una sola propiedad de tipo dato.. 21.

(28) Capítulo I. Generación Automática de Ontologías. Tabla II-2. Transformaciones de los tipos de datos. Tomado de http://diplom.ooyoo.de. Datatype String, Char, Character normalizedString Boolean Decimal Float Double, Real, Number Integer nonNegativeInteger positiveInteger nonPositiveInteger negativeInteger Long Int Short Byte unsignedLong unsignedInt unsignedShort. XML Schema Datatype xsd:string xsd:normalizedString xsd:boolean xsd:decimal xsd:float xsd:double xsd:integer xsd:nonNegativeInteger xsd:positiveInteger xsd:nonPositiveInteger xsd:negativeInteger xsd:long xsd:int xsd:short xsd:byte xsd:unsignedLong xsd:unsignedInt xsd:unsignedShort. Datatype unsignedByte hexBinary, Binary Base64Binary dateTime Time Date gYearMonth gYear gMonthDay gDay gMonth anyURI, URI, URL Token Language NMTOKEN Name NCName. XML Schema Datatype xsd:unsignedByte xsd:hexBinary xsd:base64Binary xsd:dateTime xsd:time xsd:date xsd:gYearMonth xsd:gYear xsd:gMonthDay xsd:gDay xsd:gMonth xsd:anyURI xsd:token xsd:language xsd:NMTOKEN xsd:Name xsd:NCName. El estudio e implementación que propone Sebastian Leinho en (Leinhos, 2006) puede considerarse bastante completo y cercano al propósito de este trabajo. Sin embargo, se identifican algunas deficiencias que pueden conllevar a la pérdida de información importante para la traducción en el sentido inverso. Por ejemplo, cuando las clases abstractas se modelan en OWL con una propiedad llamada “isAbstract” con rango booleano, la propiedad es heredada por todas las subclases que hereden de ella. Por tanto, cuando se tenga una clase que tenga como concepto general una clase abstracta estará forzada a ser vista como una clase abstracta también. Por otro lado, las dependencias no tienen una representación distintiva para cada una por separado. Como se mencionó, el autor propone crear una propiedad objeto llamada “Dependency” con dominio todos los conceptos correspondientes a clases dominantes y por rango todos los conceptos correspondientes a clases subordinadas. De esta manera sólo se distingue entre clases dependientes y subordinadas pero no se tiene el par de clases (dependiente, subordinada) de una dependencia en particular. De manera similar sucede con la solución propuesta para tratar el conflicto que puede generar la modelación de dos asociaciones con el mismo nombre. Se tiene la asociación y de ella se conoce cuáles son las clases que involucra, pero no se puede distinguir entre los pares de clases que son afectadas directamente por una de las asociaciones.. 22.

(29) Capítulo II. Ontologías OWL y Diagramas de Clases UML. Estas fueron las principales deficiencias halladas al trabajo de Leinhos desde el punto de vista teórico, mientras que al evaluar el XSLT “OWLfromUML.xsl” se encontraron otras deficiencias, por ejemplo, el tratamiento de las multiplicidades. Cuando la multiplicidad se define por un intervalo se propone transformarla en dos restricciones, una restricción mínima y otra máxima, de las cuales el XSLT solo genera las restricciones mínimas. Mientras que para la multiplicidad mucho (*) se crea una restricción de cardinalidad mínima igual a uno, cuando esta multiplicidad no debe ser transformada en ninguna restricción. Por defecto todas las propiedades de objeto tiene esta cardinalidad de tipo mucho. Este problema se extiende a la multiplicidad mínima de manera general, aun cuando el valor especificado sea otro distinto de uno siempre se crea una restricción de cardinalidad mínima igual a uno. A pesar de estas deficiencias encontradas, la propuesta es rigurosa y eficiente.. 2.3 Descripción en UML y OWL para la metaontología Bunge La ontología de alto nivel propuesta por Mario Bunge (Bunge, 1977, Bunge, 1979) es muy utilizada en investigaciones sobre el análisis de los Sistemas de Información. Sin embargo, no ha tenido igual popularidad en la web semántica y en la modelación conceptual, aunque en esta última se ha utilizado más que en la primera. La causa fundamental que la limita a ser más aplicada en estas dos áreas, a pesar de lo mucho que puede aportar, es que la ontología de Bunge esta especificada en lenguaje natural. Por esta razón en (Evermann, 2008) se propone describir la ontología de Bunge tanto en lenguaje OWL, estándar para la descripción de ontologías, como en UML, estándar para la modelación conceptual. Para lograr este objetivo en (Evermann, 2008) se analizan tres posibilidades: 1. Desarrollar y mantener la ontología tanto en UML como OWL por separado, aprovechando las potencialidades que cada uno de estos modelos brindan. 2. Desarrollar y mantener la ontología en OWL y crear automáticamente el modelo UML a partir de este, reduciendo en esfuerzo de modelado, pero perdiendo las potencialidades del UML ya que se reducirían a las que el OWL pueda tener. 3. Desarrollar y mantener la ontología en UML y crear automáticamente el modelo OWL a partir de este, que tendría las mismas ventajas y desventajas que el segundo caso pero a la inversa.. 23.

(30) Capítulo II. Ontologías OWL y Diagramas de Clases UML. El autor se decide por la tercera opción, porque a pesar de que tanto UML como OWL tienen construcciones que no están presentes en el otro, lo que dificulta establecer correspondencias entre ambos lenguajes y esto no es un problema crítico para representar la ontología de Bunge, UML ha sido utilizado satisfactoriamente no sólo para el modelado conceptual, sino también para la modelación de ontología. También porque existe mucha más experiencia en UML que en OWL, por ejemplo para UML existen muchas más herramientas que lo soportan y con más experiencia que OWL. En particular, la ontología de Bunge, ha sido mayormente utilizada en la modelación conceptual por lo que se impone la modelación en UML. En la Figura II-1 se muestra la propuesta del autor, primero una interpretación de la ontología de Bunge se modela con una herramienta UML y se exporta el modelo al formato XMI. Sobre la base de correspondencias preestablecidas entre los estándares UML y OWL, construyen un documento XSLT que aplican al XMI para generar el modelo OWL. De esta manera solo tienen que garantizar la modelación correcta y mantenimiento del modelo UML.. Figura II-1. De la ontología de Bunge al modelo OWL. Tomado de (Evermann, 2009).. Las correspondencias establecidas por el autor entre UML y OWL se muestran en la Tabla III-3, donde se puede apreciar las construcciones de OWL que no tienen equivalentes en el lenguaje UML y viceversa.. 24.

(31) Capítulo II. Ontologías OWL y Diagramas de Clases UML. Tabla II-3. Correspondencias entre los lenguajes UML y OWL. Tomado de (Evermann, 2009). UML Class Attribute Association AssociationClass Generalization between Classes Generalization between Associations Multiplicities (Generalization) (Generalization) AssociationEnd isNavigable. (Objects) AssociationEnd participant AssociationEnd changeability Attribute typedFeature Attribute changeability and initial value Mutual generalization Mutual generalization (Multiplicity constraint). OWL Class DatatypeProperty ObjectProperty Class and ObjectProperties SubClassOf SubPropertyOf Cardinalities UnionOf IntersectionOf ComplementOf InverseOf TransitiveProperty SymmetricProperty OneOf (class deﬁnition by enumeration) ObjectProperty value constraint “allValuesFrom” ObjectProperty value constraint “someValuesFrom” ObjectProperty value constraint “hasValue” DatatypeProperty value constraint “allValuesFrom” DatatypeProperty value constraint “someValuesFrom” DatatypeProperty constraint “hasValue” EquivalentClass DisjointWith EquivalentProperty FunctionalProperty SameAs DifferentFrom AllDifferent. Aggregation kind. En (Evermann, 2009) se propone una correspondencia entre las asociaciones y las propiedades de objetos, pero en UML las asociaciones pueden involucrar más de dos clases, mientras que las ObjectProperty en OWL representan únicamente predicados binarios. En este caso se omiten las representaciones n-arias, aunque pueden modelarse como conceptos en OWL. No existe en OWL una construcción equivalente para la clase asociativa (AssociationClass) de UML. Las clases asociativas son especializaciones de asociaciones, por tanto, se representan como un nuevo concepto con propiedades objetos que la conecten con los conceptos correspondientes a las clases que participan en la clase asociativa. Tampoco existen construcciones equivalentes a la agregación y composición de UML. Estas construcciones describen comportamiento dinámico de las clases, definiendo cuándo se crean o destruyen instancias, mientras que en las ontologías se hacen representaciones estáticas y por. 25.

(32) Capítulo II. Ontologías OWL y Diagramas de Clases UML. tanto la agregación no ofrece semántica adicional a las asociaciones comunes. Los tipos de propiedades de objetos simétricas y transitivas, muy utilizadas en OWL, no pueden ser representadas con las construcciones de UML. De modo general estas son las observaciones a la propuesta teórica de (Evermann, 2009), el autor implementó la transformación en lenguaje XSLT. Se pudo utilizar dos versiones disponibles de dicha implementación, ambas tienen la particularidad que sólo transforma diagramas de clases UML en formato XMI generados por Poseidon2. No existen diferencias sustanciales entre ambas versiones del traductor propuesto, salvo a pesar que ambos generan información adicional como una estructura DatatypeProperty vacía, y uno de ellos además genera una estructura de clase vacía. Estas deficiencias pueden ser eliminadas, incluso automáticamente mediante un preprocesamiento del modelo OWL generado. Luego de eliminar estas estructuras vacías es posible abrir el modelo OWL con algún editor para ontología, por ejemplo: Protégé3 3.2.1 y 4.0, e incluso utilizar herramientas para la manipulación de múltiples ontologías como el plug-in Prompt4. En un análisis más profundo se pudo observar que ambas implementaciones no realizan todas las transformaciones propuestas por el autor. Por ejemplo, las relaciones de asociación no se transforman como se esperan. Tampoco se obtienen buenos resultados cuando se intenta utilizar estos XSLT para transformar otros diagramas de clases UML además del de Bunge. En la Figura II-2 se muestra un fragmento de diagrama de clases UML modelado con Poseidon, y en la Figura II-3(A) el fragmento de ontología correspondiente generada con el XSLT de (Evermann, 2009). Se puede observar que en dicha transformación la descripción del concepto círculo (Circle) no está completa, falta la información correspondiente al punto medio (atributo middle), además todas las restricciones que esta transformación conlleva. Mientras que en la Figura II-3(B) se presenta la transformación generada por el XSLT de (Leinhos, 2006) con resultados más cercanos a los esperados.. 2. www.gentleware.com protege.stanford.edu 4 protege.cim3.net/cgi-bin/wiki.pl?Prompt 3. 26.

(33) Capítulo II. Ontologías OWL y Diagramas de Clases UML. Figura II-2. Fragmento de diagrama de clases Fomas&Figuras.. Figura II-3. Descripción del concepto Circle del diagrama Formas&Figuras.. En resumen, la propuesta de (Evermann, 2009) tiene como objetivo transformar un diagrama de clases UML que represente la ontología de Bunge para generar automáticamente un modelo OWL de ella, pero no fue construida para trasformar diagramas de clases UML cualesquiera como la propuesta de (Leinhos, 2006). En el siguiente epígrafe se analiza la propuesta de (Xu et al., 2009) donde propone una solución no basada en XSLT.. 2.4 Preservación semántica de algunas construcciones UML Aunque las ontologías y diagramas de clases UML tienen muchas características en común, existen construcciones que solo pertenecen a uno de los dos modelos. El trabajo de (Xu et al., 2009) solo se enfoca hacia las construcciones del diagrama de clases UML que permiten representar información ontológica, como clases, asociaciones entre clases, atributos, rol, multiplicidad, generalización entre clases, se descarta la generalización entre asociaciones, y restricciones de disjuntos o cubrimiento presentes en la generalización. Otras construcciones de UML se ignoran porque el objetivo de los lenguajes ontológicos como OWL DL no tienen suficiente expresividad para soportar o construcción apropiada para capturar su semántica. 27.