cenidet
Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Generación de ontologías en OWL a partir de diagramas de clases de UML mediante MDA (Arquitectura Dirigida por
Modelos)
presentada por
Juan Antonio Galindo García Ing. en Sistemas Computacionales por el I. T. de Cuautla
como requisito para la obtención del grado de:
Maestría en Ciencias en Ciencias de la Computación
Director de tesis: Dr. Hugo Estrada Esquivel
Co-Director de tesis:
Dra. Alicia Martínez Rebollar
Jurado:
Dr. Javier Ortiz Hernández– Presidente Dr. Juan Gabriel González Serna– Secretario
Dra. Azucena Montes Rendón – Vocal Dr. Hugo Estrada Esquivel – Vocal Suplente
Cuernavaca, Morelos, México. 13 de enero de 2011
DEDICATORIA
A mi padre
Antonio, por todo el amor, confianza y apoyo que siempre he recibido,
has estado siempre a mi lado, éste logro es también tuyo.
A mi esposa
Jenifer por tu apoyo y cariño incondicionales.
A mi hijo
Ian por ser el motivo que me impulsa.
A mis hermanos
Minerva y Arturo.
A toda mi familia a todos los que formamos ese núcleo,
una base sobre la que sabemos que podemos apoyarnos en todo momento.
AGRADECIMIENTOS A CONACYT y DGEST por el apoyo económico otorgado para la realización de este trabajo de maestría. Al Centro Nacional de Investigación y Desarrollo Tecnológico por brindarme la oportunidad para seguir en esta formación continua. A mi director de tesis, el Dr. Hugo Estrada Esquivel por brindarme su consejo y ayuda para terminar este trabajo de tesis. A mi codirectora de tesis, la Dra. Alicia Martínez Rebollar por sus valiosos comentarios y consejos. A los revisores de este trabajo de tesis de investigación, la Dra. Azucena Montes Rendón, el Dr. Juan Gabriel González Serna y el Dr. Javier Ortiz Hernández, por su tiempo dedicado, observaciones y comentarios para mejorar este trabajo, y su apoyo personal para culminar esta meta. A las personas que me han rodeado en mi vida. Mi esposa Jenifer, por tu compañía, cariño y confianza, y porque estamos cumpliendo esta meta que nos propusimos desde un principio. A mi hijo Ian por ser la razón de que ahora todo tenga sentido, mi padre Antonio porque sin tí nada de esto sería posible, mis hermanos Minerva y Arturo, y a todos mis amigos por su apoyo incondicional. Mil gracias a todos.
Juan Antonio Galindo García.
Resumen Hoy en día, uno de los grandes retos en las ciencias computacionales es tratar de organizar la enorme cantidad de información contenida en la Web para permitir que los usuarios puedan encontrar, en forma rápida y precisa, la información que desean. Los buscadores actuales son incapaces de explorar a profundidad la Web debido a la falta de información que indique si un dato de una página o portal Web es relevante para la búsqueda realizada. Para resolver esta problemática surge la Web semántica de la mano del creador de la Web, como un esfuerzo para dar significado a los datos almacenados en la Web. Sin embargo, uno de los problemas de la Web semántica es la carencia de métodos simples y precisos para generar ontologías, que son el mecanismo que permite implementar la semántica en recursos Web. En este proyecto se propone un método para generar ontologías a partir de la técnica de modelado conceptual más popular en la actualidad, que es UML. El método implementará reglas de transformación automática basadas en MDA (desarrollo dirigido por modelos) para asegurar la precisión y rigor en la traducción entre modelos. Con el trabajo propuesto se dará un gran avance en la definición de sitios semánticos (definidos por ontologías) que hagan de la Web semántica una realidad.
Abstract Today, one of the greatest challenges in computer science is to try to organize the vast amount of information contained on the Web to allow users to find, quickly and accurately the information they want. The current search engines are unable to explore in depth the Web due to lack of information indicating whether data of a page or Web site is relevant to their search. To solve this problem the Semantic Web comes the hand of the creator of the Web, in an effort to give meaning to data stored on the Web. However, one problem of the Semantic Web is the lack of simple and accurate methods to generate ontologies, which are the mechanism to implement the semantic Web resources. In this project we propose a method for generating ontologies from one of the most popular conceptual modeling technique more, which is UML. The method implements automatic transformation rules based on MDA (Model Driven Architecture) to ensure the accuracy and precision in translation between models. With the proposed work will be a breakthrough in the definition of semantic Websites (defined by ontologies) to make the Semantic Web a reality.
pág. i
Contenido CAPÍTULO 1. INTRODUCCIÓN ........................................................................................................................................... I
1.1. ANTECEDENTES ........................................................................................................................................................... 2 1.2. DESCRIPCIÓN DEL PROBLEMA ................................................................................................................................... 3 1.3. OBJETIVO...................................................................................................................................................................... 3 1.4. JUSTIFICACIÓN Y BENEFICIOS .................................................................................................................................... 4 1.5. ALCANCES .................................................................................................................................................................... 4 1.6. LIMITACIONES ............................................................................................................................................................. 4 1.7. ORGANIZACIÓN DEL DOCUMENTO ............................................................................................................................ 4
CAPÍTULO 2. MARCO TEÓRICO ....................................................................................................................................... 6
2.1. WEB SEMÁNTICA ......................................................................................................................................................... 7 2.2. ONTOLOGÍAS................................................................................................................................................................ 7 2.3. OWL (WEB ONTOLOGY LANGUAGE) ...................................................................................................................... 8 2.4. ARQUITECTURA DIRIGIDA POR MODELOS MDA ................................................................................................... 8 2.5. ATL (ATLAS TRANSFORMATION LANGUAGE) ....................................................................................................... 9 2.6. OCL (OBJECT CONSTRAINT LANGUAGE).............................................................................................................. 10 2.7. UML (UNIFIED MODELING LANGUAGE) ............................................................................................................... 11 2.8. ECLIPSE MODELING FRAMEWORK (EMF)............................................................................................................. 11 2.9. SINTAXIS XML/RDF ................................................................................................................................................ 12
CAPÍTULO 3. ESTADO DEL ARTE.................................................................................................................................... 13
3.1. REPRESENTACIÓN DE MODELOS DE ACTIVIDAD DE UML COMO ONTOLOGÍAS................................................ 14 3.2. CONVIRTIENDO UML A ONTOLOGÍAS OWL......................................................................................................... 14 3.3. UN ENFOQUE DIRIGIDO POR MODELOS PARA LA CONSTRUCCIÓN DE ONTOLOGÍAS OWL DL Y FULL ......... 15 3.4. TWOUSE: INTEGRANDO MODELOS UML Y ONTOLOGÍAS OWL ........................................................................ 16 3.5. INGENIERÍA DIRIGIDA POR MODELOS PARA ONTOLOGÍAS ................................................................................... 17 3.6. COMPARATIVO DE TRABAJOS RELACIONADOS...................................................................................................... 17
CAPÍTULO 4. MÉTODO PARA LA GENERACIÓN DE ONTOLOGÍAS OWL A PARTIR DE DIAGRAMAS DE CLASES DE UML ..................................................................................................................................................................... 19
4.1. ARQUITECTURA GENERAL DE LA SOLUCIÓN PROPUESTA .................................................................................... 20 4.1.1. Fase 1. Generación del diagrama de clases de UML. .............................................................................. 20 4.1.2. Fase 2. Aplicación de reglas de transformación UML a OWL ................................................................ 20 4.1.3. Fase 3. Generación de ontología OWL....................................................................................................... 20 4.1.4. Fase 4. Aplicación de reglas de transformación OWL a XML/RDF........................................................ 21 4.1.5. Fase 7. Generación de archivo OWL con formato XML/RDF .................................................................. 21
4.2. EL METAMODELO OWL ........................................................................................................................................... 22 4.2.1.1. Ontologías y espacios de nombres . ........................................................................................................24 4.2.1.2. Propiedades ............................................................................................................................................24 4.2.1.3. Clases y restricciones ..............................................................................................................................25 4.2.1.4. Tipos de datos .........................................................................................................................................27
4.3. CATÁLOGO DE REGLAS DE TRANSFORMACIÓN ..................................................................................................... 27 4.3.1. Inicialización de la ontología ....................................................................................................................... 30
4.3.1.1. Regla 1: Inicialización de la ontología en Ecore ......................................................................................30 4.3.2. Encabezado de ontología ............................................................................................................................. 32 4.3.3. Clases de una ontología OWL ...................................................................................................................... 34 4.3.4. Subclases de una ontología OWL................................................................................................................ 35 4.3.5. Enumeración de valores de datos y literales enumeradas. .................................................................... 38 4.3.6. Propiedades en OWL..................................................................................................................................... 42
4.3.6.1. Propiedad de objeto. ..............................................................................................................................42 4.3.6.2. Propiedad de tipo de dato. .....................................................................................................................44
pág. ii
4.3.7. Cardinalidad ................................................................................................................................................... 47 4.3.7.1. Cardinalidad simple.................................................................................................................................47 4.3.7.2. Cardinalidad mínima ...............................................................................................................................49 4.3.7.3. Cardinalidad máxima ..............................................................................................................................52
4.3.8. Restricción todos los valores de clase ........................................................................................................ 55 4.3.9. Propiedad simétrica ...................................................................................................................................... 57 4.3.10. Propiedad funcional ................................................................................................................................. 59 4.3.11. Propiedad funcional inversa ................................................................................................................... 61
CAPÍTULO 5. DISEÑO E IMPL EMENTACIÓN................................................................................................................ 64
5.1. DISEÑO........................................................................................................................................................................ 65 5.1.1. Diagramas de casos de uso .......................................................................................................................... 65
5.2. CARACTERÍSTICAS DE LA IMPLEMENTACIÓN ........................................................................................................ 68 5.2.1. Arquitectura del prototipo ........................................................................................................................... 68
5.2.1.1. Módulo de interfaz gráfica......................................................................................................................69
CAPÍTULO 6. PRUEBAS.................................................................................................................................................... 71
6.1 INTRODUCCIÓN .......................................................................................................................................................... 72 6.1.1. HIPÓTESIS ..................................................................................................................................................................... 72 6.2 CASO DE ESTUDIO ONTOLOGÍA DE DBPEDIA ....................................................................................................... 72 6.3 CASO DE ESTUDIO PROGRAMA PAP ....................................................................................................................... 75 6.4 CASO DE ESTUDIO ORDEN DE RESTAURANT.......................................................................................................... 77 6.5. CASO DE ESTUDIO DE UNA AEROLÍNEA .................................................................................................................. 79 6.6. CASO DE ESTUDIO JUEGO SAPIENS ......................................................................................................................... 82 6.7. CASO DE ESTUDIO ESTUDIANTE .............................................................................................................................. 85 6.8. CASO DE ESTUDIO DE UN BANCO Y LA GESTIÓN DE TARJETAS DE CRÉDIT O ..................................................... 87 6.9. CASO DE ESTUDIO INFORMATIZACIÓN DE UNA BIBLIOTECA ............................................................................... 90 6.5 RESULTADOS OBTENIDOS DE LA EJECUCIÓN DE LOS CASOS DE ESTUDIO.......................................................... 93 6.5. ANÁLISIS DE RESULTADOS.......................................................................................................................................... 94
7 CONCLUSIONES ............................................................................................................................................................. 95
7.1 CONCLUSIONES.......................................................................................................................................................... 96 7.2 APORTACIONES.......................................................................................................................................................... 97 7.3 TRABAJOS FUTUROS.................................................................................................................................................. 97 7.4 LECCIONES APRENDIDAS.......................................................................................................................................... 99
REFERENCIAS .......................................................................................................................................................................... 101
ANEXO A .................................................................................................................................................................................. 105
pág. iii
Índice de figuras FIGURA 2-1. DIFERENCIA ENTRE LA WEB ACTUAL Y LA WEB SEMÁNTICA [CASTELLS, 2004]................................................................ 7 FIGURA 2-2. TRANSFORMACIÓN DE MODELOS. ................................................................................................................................. 9 FIGURA 2-3: EJEMPLO DE REGLA ATL............................................................................................................................................. 10 FIGURA 2-4: EJEMPLO EXPRESIÓN EN OCL. .................................................................................................................................... 10 FIGURA 3-1. SOLUCIÓN PROPUESTA PARA EL MAPEO DE DIAGRAMAS DE ACTIVIDAD EN UML A OWL............................................... 14 FIGURA 3-2. PRINCIPIO XSLT PARA EL DESARROLLO DE ONTOLOGÍAS............................................................................................... 15 FIGURA 3-3. MAPEO ENTRE CONSTRUCTORES DE UML Y OWL [BROCKMAS, 2006]....................................................................... 15 FIGURA 3-4. CAPAS DE METAMODELOS Y ESPACIOS DE MODELADO DEL ENFOQUE “TWOUSE”.......................................................... 16 FIGURA 3-5. ARQUITECTURA DEL SISTEMA DE INGENIERÍA DE ONTOLOGÍAS BASADO EN EMF. .......................................................... 17 FIGURA 4-1 ARQUITECTURA GENERAL DE LA SOLUCIÓN ................................................................................................................... 20 FIGURA 4-2 ONTOLOGÍA EN LENGUAJE ECORE. ............................................................................................................................... 21 FIGURA 4-3. EJEMPLO DE ARCHIVO OWL CON FORMATO XML/RDF.............................................................................................. 21 FIGURA 4-4. CONTEXTO OPERACIONAL DE ATL............................................................................................................................... 22 FIGURA 4-5. DIAGRAMA DE CLASES DEL METAMODELO OWL......................................................................................................... 23 FIGURA 4-6. ONTOLOGÍAS Y ESPACIO DE NOMBRES......................................................................................................................... 24 FIGURA 4-7. PROPIEDADES ............................................................................................................................................................ 25 FIGURA 4-8. CONSTRUCTORES DE CLASES Y AXIOMAS...................................................................................................................... 25 FIGURA 4-9. RESTRICCIONES EN OWL. .......................................................................................................................................... 26 FIGURA 4-10. TIPOS DE DATOS. ..................................................................................................................................................... 27 FIGURA 4-11. ESPACIO DE NOMBRES DE XML................................................................................................................................ 30 FIGURA 4-12: FORMALIZACIÓN DE REGLA 1. .................................................................................................................................. 31 FIGURA 4-13. REGLA DE INICIALIZACIÓN DE DOCUMENTO OWL...................................................................................................... 31 FIGURA 4-14: FORMALIZACIÓN DE REGLA 2. .................................................................................................................................. 31 FIGURA 4-15. REGLA DOCUMENTOOWL_EN_XML/RDF ............................................................................................................. 32 FIGURA 4-16. ENCABEZADO DE ONTOLOGÍA. .................................................................................................................................. 32 FIGURA 4-17. FORMALIZACIÓN DE REGLA 3.................................................................................................................................... 33 FIGURA 4-18. REGLA PAQUETE_A_ONTOLOGÍA. ........................................................................................................................... 33 FIGURA 4-19: FORMALIZACIÓN DE REGLA 4. .................................................................................................................................. 33 FIGURA 4-20. REGLA ONTOLOGÍAOWL A XML/RDF..................................................................................................................... 33 FIGURA 4-21. CLASES EN OWL. .................................................................................................................................................... 34 FIGURA 4-22: FORMALIZACIÓN DE REGLA 5. .................................................................................................................................. 34 FIGURA 4-23. REGLA CLASEUML_A_CLASEOWL. .......................................................................................................................... 34 FIGURA 4-24: FORMALIZACIÓN DE REGLA 6. .................................................................................................................................. 35 FIGURA 4-25. REGLA CLASE OWL A XML/RDF. ............................................................................................................................ 35 FIGURA 4-26. SUBCLASE EN OWL. ................................................................................................................................................ 36 FIGURA 4-27: FORMALIZACIÓN DE REGLA 7. .................................................................................................................................. 36 FIGURA 4-28. REGLA PARA LA GENERACIÓN DE SUBCLASES EN OWL. .............................................................................................. 36 FIGURA 4-29: FORMALIZACIÓN DE REGLA 8. .................................................................................................................................. 37 FIGURA 4-30. REGLA SUBCLASE OWL A XML/RDF....................................................................................................................... 37 FIGURA 4-31. ENUMERACIÓN DE DATOS EN OWL.......................................................................................................................... 38 FIGURA 4-32: FORMALIZACIÓN DE REGLA 9. .................................................................................................................................. 38 FIGURA 4-33. REGLA ENUMERACIÓN_A_CLASEENUMERADA......................................................................................................... 38 FIGURA 4-34. FORMALIZACIÓN DE REGLA 10. ................................................................................................................................ 39 FIGURA 4-35. CLASE ENUMERADA A XML/RDF............................................................................................................................. 40 FIGURA 4-36: FORMALIZACIÓN DE REGLA 11. ................................................................................................................................ 40 FIGURA 4-37. REGLA LITERALENUMERADA_A_VALOR DE DATO...................................................................................................... 41 FIGURA 4-38: FORMALIZACIÓN DE REGLA 12. ................................................................................................................................ 41 FIGURA 4-39. REGLA VALOR DE DATO OWL A XML/RDF. ............................................................................................................. 41 FIGURA 4-40. PROPIEDAD OBJETO. ................................................................................................................................................ 42
pág. iv
FIGURA 4-41: FORMALIZACIÓN DE REGLA 13. ................................................................................................................................ 43 FIGURA 4-42. REGLA PROPIEDADUML_A_PROPIEDADOBJETO. .................................................................................................... 43 FIGURA 4-43: FORMALIZACIÓN DE REGLA 14. ................................................................................................................................ 44 FIGURA 4-44. REGLA PROPIEDAD DE OBJETO A XML/RDF. ............................................................................................................ 44 FIGURA 4-45. TIPOS DE DATOS EN OWL........................................................................................................................................ 44 FIGURA 4-46: FORMALIZACIÓN DE REGLA 15. ................................................................................................................................ 45 FIGURA 4-47. REGLA PROPIEDADUML_A_PROPIEDADTIPODEDATO............................................................................................. 45 FIGURA 4-48. FORMALIZACIÓN DE REGLA 16. ................................................................................................................................ 46 FIGURA 4-49. REGLA PROPIEDAD TIPO DE DATO OWL A XML/RDF. .............................................................................................. 47 FIGURA 4-50. RESTRICCIÓN DE CARDINALIDAD EN OWL................................................................................................................. 47 FIGURA 4-51. FORMALIZACIÓN DE REGLA 17. ................................................................................................................................ 48 FIGURA 4-52. REGLA RESTRICCIÓN DE CARDINALIDAD. .................................................................................................................... 48 FIGURA 4-53. FORMALIZACIÓN DE REGLA 18. ................................................................................................................................ 49 FIGURA 4-54. REGLA RESTRICCIÓN DE CARDINALIDAD A XML/RDF. ............................................................................................... 49 FIGURA 4-55. RESTRICCIÓN DE CARDINALIDAD MÍNIMA EN OWL.................................................................................................... 50 FIGURA 4-56. FORMALIZACIÓN DE REGLA 19. ................................................................................................................................ 50 FIGURA 4-57. REGLA RESTRICCIÓN DE CARDINALIDAD MÍNIMA. ....................................................................................................... 50 FIGURA 4-58. FORMALIZACIÓN DE REGLA 20. ................................................................................................................................ 51 FIGURA 4-59. REGLA CARDINALIDAD MÍNIMA A XML/RDF. ........................................................................................................... 52 FIGURA 4-60. RESTRICCIÓN DE CARDINALIDAD MÁXIMA EN OWL. .................................................................................................. 52 FIGURA 4-61. FORMALIZACIÓN DE REGLA 21. ................................................................................................................................ 53 FIGURA 4-62. REGLA RESTRICCIÓN DE CARDINALIDAD MÁXIMA....................................................................................................... 53 FIGURA 4-63. FORMALIZACIÓN DE REGLA 22. ................................................................................................................................ 54 FIGURA 4-64. REGLA CARDINALIDAD MÁXIMA A XML/RDF. .......................................................................................................... 55 FIGURA 4-65. RESTRICCIÓN TODOS LOS VALORES DE CLASE EN OWL............................................................................................... 55 FIGURA 4-66. FORMALIZACIÓN DE REGLA 23. ................................................................................................................................ 56 FIGURA 4-67. REGLA RESTRICCIÓN TODOS LOS VALORES DE CLASE. .................................................................................................. 56 FIGURA 4-68. FORMALIZACIÓN DE REGLA 24. ................................................................................................................................ 57 FIGURA 4-69. REGLA CLASE RESTRICCIÓN TODOS LOS VALORES DE CLASE......................................................................................... 57 FIGURA 4-70. PROPIEDAD SIMÉTRICA EN OWL. ............................................................................................................................. 57 FIGURA 4-71. FORMALIZACIÓN DE REGLA 25. ................................................................................................................................ 58 FIGURA 4-72. REGLA DE PROPIEDAD SIMÉTRICA. ............................................................................................................................ 58 FIGURA 4-73. FORMALIZACIÓN DE REGLA 26. ................................................................................................................................ 58 FIGURA 4-74. REGLA PROPIEDAD DE OBJETO A XML/RDF. ............................................................................................................ 59 FIGURA 4-75. PROPIEDAD FUNCIONAL EN OWL............................................................................................................................. 59 FIGURA 4-76. FORMALIZACIÓN DE REGLA 27. ................................................................................................................................ 60 FIGURA 4-77. REGLA PROPIEDAD FUNCIONAL................................................................................................................................. 60 FIGURA 4-78. FORMALIZACIÓN DE REGLA 28. ................................................................................................................................ 60 FIGURA 4-79. REGLA PROPIEDAD FUNCIONAL A XML/RDF. ........................................................................................................... 61 FIGURA 4-80. PROPIEDAD FUNCIONAL INVERSA.............................................................................................................................. 61 FIGURA 4-81. FORMALIZACIÓN DE REGLA 29. ................................................................................................................................ 62 FIGURA 4-82. REGLA PROPIEDAD FUNCIONAL INVERSA. .................................................................................................................. 62 FIGURA 4-83. FORMALIZACIÓN DE REGLA 30. ................................................................................................................................ 62 FIGURA 4-84. REGLA PROPIEDAD FUNCIONAL INVERSA A XML/RDF. .............................................................................................. 63 FIGURA 5-1. PROCESO DE SOLUCIÓN.............................................................................................................................................. 65 FIGURA 5-2. PROCESO DE SOLUCIÓN.............................................................................................................................................. 65 FIGURA 5-3. DIAGRAMA DE ACTIVIDAD DEL CASO DE USO CU_1: GENERAR DIAGRAMA DE CLASES EN UML...................................... 66 FIGURA 5-4. DIAGRAMA DE ACTIVIDAD DEL CASO DE USO CU_2: GENERAR ONTOLOGÍA EN FORMATO ECORE. ................................. 67 FIGURA 5-5. DIAGRAMA DE ACTIVIDAD DEL CASO DE USO CU_3: GENERAR ARCHIVO OWL EN FORMATO XML/RDF. ..................... 67 FIGURA 5-6. ARQUITECTURA DEL PROTOTIPO. ................................................................................................................................ 69 FIGURA 5-7. INTERFAZ GRÁFICA DEL PROTOTIPO. ............................................................................................................................ 70 FIGURA 6-1. ONTOLOGÍA DE DBPEDIA (FRAGMENTO). ................................................................................................................... 73 FIGURA 6-2. GENERACIÓN DE LA ONTOLOGÍA DE DBPEDIA MEDIANTE LA HERRAMIENTA PROPUESTA (FRAGMENTO). ........................ 73
pág. v
FIGURA 6-3. FRAGMENTO DEL ARCHIVO OWL DEL CASO DE ESTUDIO DBPEDIA. .............................................................................. 74 FIGURA 6-4. REPRESENTACIÓN GRÁFICA DEL ARCHIVO OWL GENERADO POR EL PROTOTIPO (FRAGMENTO). ..................................... 74 FIGURA 6-5. MODELO CONCEPTUAL DEL PROGRAMA PAP. ............................................................................................................. 75 FIGURA 6-6. FRAGMENTO DEL ARCHIVO OWL PARA EL CASO DE ESTUDIO PAP................................................................................ 76 FIGURA 6-7.ONTOLOGÍA PAP EN PROTÉGÉ INCLUYE RELACIONES TAXONÓMICAS............................................................................. 76 FIGURA 6-8. RELACIONES NO TAXONÓMICAS DEL PROGRAMA PAP. ................................................................................................ 77 FIGURA 6-9. DIAGRAMA DE CLASES DE UN SISTEMA DE RESTAURANT. .............................................................................................. 77 FIGURA 6-10. DIAGRAMA DE CLASES DEL CASO DE ESTUDIO REPLICADO POR EL PROTOTIPO PROPUESTO............................................ 78 FIGURA 6-11. FRAGMENTO DEL ARCHIVO OWL GENERADO PARA EL CASO DE ESTUDIO DEL RESTAURANT.......................................... 78 FIGURA 6-12. RELACIONES TAXONÓMICAS DEL LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DEL RESTAURANT...................................... 79 FIGURA 6-13. RELACIONES NO TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DEL RESTAURANT.................................. 79 FIGURA 6-14. MODELO CONCEPTUAL PARA EL CASO DE ESTUDIO DE UNA AEROLÍNEA. ...................................................................... 80 FIGURA 6-15. DIAGRAMA DE CLASES DEL CASO DE ESTUDIO REPLICADO POR EL PROTOTIPO PROPUESTO............................................ 80 FIGURA 6-16. FRAGMENTO DEL ARCHIVO OWL GENERADO PARA EL CASO DE ESTUDIO DE LA AEROLÍNEA.......................................... 81 FIGURA 6-17. RELACIONES TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DE LA AEROLÍNEA. ...................................... 81 FIGURA 6-18. RELACIONES NO TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DE LA AEROLÍNEA.................................. 82 FIGURA 6-19. MODELO CONCEPTUAL PARA EL CASO DE ESTUDIO DEL JUEGO SAPIENS....................................................................... 82 FIGURA 6-20. DIAGRAMAS DE CLASES DEL CASO DE ESTUDIO REPLICADO POR EL PROTOTIPO PROPUESTO. ......................................... 83 FIGURA 6-21. FRAGMENTO DEL ARCHIVO OWL GENERADO PARA EL CASO DE ESTUDIO DEL JUEGO SAPIENS. ..................................... 83 FIGURA 6-22. RELACIONES TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DEL JUEGO SAPIENS. ................................... 84 FIGURA 6-23. RELACIONES NO TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DEL JUEGO SAPIENS. ............................. 84 FIGURA 6-24. MODELO CONCEPTUAL PARA EL CASO DE ESTUDIO DE UN ESTUDIANTE. ...................................................................... 85 FIGURA 6-25. DIAGRAMA DE CLASES DEL CASO DE ESTUDIO REPLICADO POR EL PROTOTIPO PROPUESTO............................................ 85 FIGURA 6-26. FRAGMENTO DEL ARCHIVO OWL GENERADO PARA EL CASO DE ESTUDIO DEL ESTUDIANTE........................................... 86 FIGURA 6-27. RELACIONES TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DEL ESTUDIANTE. ....................................... 86 FIGURA 6-28. RELACIONES NO TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO ESTUDIANTE. ........................................ 87 FIGURA 6-29. MODELO CONCEPTUAL PARA EL CASO DE ESTUDIO DE UN BANCO Y LA GESTIÓN DE TARJETAS DE CRÉDITO..................... 87 FIGURA 6-30. DIAGRAMA DE CLASES DEL CASO DE ESTUDIO DE UN BANCO REPLICADO POR EL PROTOTIPO PROPUESTO. ..................... 88 FIGURA 6-31. FRAGMENTO DEL ARCHIVO OWL GENERADO PARA EL CASO DE ESTUDIO DEL BANCO. ................................................. 89 FIGURA 6-32. RELACIONES TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DE UN BANCO. ........................................... 89 FIGURA 6-33. RELACIONES NO TAXONÓMICAS DE LA ONTOLOGÍA PARA EL CASO DE ESTUDIO DE UN BANCO....................................... 90 FIGURA 6-34. MODELO CONCEPTUAL PARA EL CASO DE ESTUDIO DE INFORMATIZACIÓN DE UNA BIBLIOTECA ..................................... 90 FIGURA 6-35. DIAGRAMA DE CLASES DEL CASO DE ESTUDIO DE INFORMATIZACIÓN DE UNA BIBLIOTECA............................................. 91 FIGURA 6-36. FRAGMENTO DEL ARCHIVO OWL PARA EL CASO DE ESTUDIO DE INFORMATIZACIÓN DE UNA BIBLIOTECA ...................... 91 FIGURA 6-37. RELACIONES TAXONÓMICAS PARA EL CASO DE ESTUDIO INFORMATIZACIÓN DE UNA BIBLIOTECA................................... 92 FIGURA 6-38. RELACIONES NO TAXONÓMICAS PARA EL CASO DE ESTUDIO INFORMATIZACIÓN DE UNA BIBLIOTECA. ............................ 92 FIGURA 7-1. INTERSECCIÓN DE LA REPRESENTACIÓN DE MODELOS Y ONTOLOGÍAS [ATKINSON, 2004]............................................. 99
Índice de tablas
TABLA 1. COMPARACIÓN DE HERRAMIENTAS DEL ESTADO DEL ARTE. ................................................................................................ 18 TABLA 2. EQUIVALENCIA ENTRE PRIMITIVAS DE UML Y OWL.......................................................................................................... 29 TABLA 3. TIPOS DE DATOS OWL. ................................................................................................................................................... 45 TABLA 4. PROPIEDADES DE CU-1 GENERAR DIAGRAMA DE CLASES EN UML .................................................................................... 66 TABLA 5. PROPIEDADES DE CU-2 GENERAR ONTOLOGÍA OWL........................................................................................................ 66 TABLA 6. PROPIEDADES DE CU-3 SERIALIZAR ONTOLOGÍA AL FORMATO XML/RDF ......................................................................... 67 TABLA 7. PROPIEDADES DE CU-4 GENERARA ARCHIVO OWL .......................................................................................................... 68 TABLA 8. RESUMEN DE RESULTADOS DE LA EJECUCIÓN DE LOS CASOS DE ESTUDIO............................................................................. 93 TABLA 9. ELEMENTOS DE UML EXCLUIDOS DE LA TRANSFORMACIÓN............................................................................................... 98
pág. 1
Capítulo 1. Introducción En el presente capítulo se expone el problema que dio origen al proyecto de investigación propuesto en esta tesis; se definen los objetivos de la presente investigación, sus alcances, limitaciones y los beneficios que aporta a los usuarios potenciales. Finalmente, en el último apartado se describe la forma en la que está estructurado este documento.
≈ Introducción
pág. 2
1.1. Antecedentes
Uno de los grandes retos en las ciencias computacionales es tratar de poner orden y organización en la Web. Debido a la cantidad de información almacenada en este medio, hoy en día tenemos información que es prácticamente inaccesible con los buscadores actuales y que bien podría ser la información que busca un usuario. Esta información, que se denomina formalmente, la Web oculta crece día con día a medida que el Internet se ha vuelto el canal de comunicación por excelencia. En sus inicios la Web se reducía a un pequeño grupo de información científica, sin embargo hoy en día en ella podemos encontrar información de prácticamente cualquier tema. El incremento de esta información a límites nunca imaginados ocasiona que la búsqueda de datos concretos sea una tarea muy compleja, ya que los buscadores actuales no pueden responder con efectividad a la Web. Actualmente, la Web semántica pretende enriquecer a la Web tradicional con información semántica para permitir a los sistemas el acceso y uso más eficiente de la enorme cantidad de información acumulada en la Web. La Web semántica busca que la información contenida en la Web pueda ser anotada semánticamente con la finalidad que sistemas de software (agentes de software, por ejemplo) puedan saber cuál es el signif icado de cada dato o información que aparece en una página Web. El concepto clave en el desarrollo de la Web semántica son las ontologías que permiten crear, interpretar y comparar el contenido semántico de un recurso Web. De acuerdo con Gruber [Gruber, 1993] una ontología es una “especificación formal de una conceptualización compartida” las cuales pueden ser representadas textualmente utilizando el lenguaje de ontologías Web (OWL) [W3C OWL 2004]. Sin embargo, una vez que se ha determinado que las ontologías son el camino apropiado para dar semántica a la Web, surge el reto de crear las ontologías para cada sitio que deseemos anotar semánticamente. Actualmente, en casi la totalidad de las herramientas actuales para la generación de ontologías un analista debe construir las ontologías con un lenguaje textual muy formal y árido y solamente al final del proceso obtiene una representación gráfica de la ontología. Este enfoque de creación de ontologías está restringido, por tanto, a un reducido grupo de expertos que conozcan el formalismo necesario utilizar estas herramientas de edición de ontologías [Djuric, 2005]. El objetivo de este proyecto de investigación está centrado en facilitar la construcción de ontologías a partir de modelos gráficos. Existen varias propuestas de investigación en esta línea, sin embargo muchas de estas propuestas utilizan lenguajes de representación que creemos resultan ser igual de complicados que la misma construcción textual de la ontología. En este sentido proponemos la utilización de una notación ampliamente utilizada en el mundo de desarrollo de software, como es UML, para crear ontologías, con el fin último de poblar la Web semántica. Por lo tanto, es este proyecto se propone construir de manera automática una ontología teniendo como punto de inicio un modelo conceptual descrito con diagramas de clases de UML. El enfoque propuesto permitirá que la comunidad en ciencias computacionales que utiliza extensivamente UML para diseño de sistemas de información pueda utilizarlo para crear modelos que sean traducidos, en forma transparente y automática, en ontologías descritas en OWL. Uno de los requisitos que se busca en este proyecto es realizar este proceso de transformación en forma rigurosa y precisa, para lo cual se utiliza el enfoque de desarrollo dirigido por modelos (MDA) [Brown, 2004] y el Meta-modelo de Definición de Ontologías (ODM) [ODM, 2004] con el fin de realizar transformaciones entre modelos y poder explotar la disponibilidad y características de las herramientas de UML para la creación de ontologías en un lenguaje específico como lo es OWL. Es importante comentar que desde 2004 se han realizado trabajos con nuestro mismo objetivo, en este sentido encontramos los trabajos de [Gásevic, 2004] y más recientemente [Pan, 2006], [Hanzala, 2007]
≈ Introducción
pág. 3
los cuales únicamente realizan las transformaciones a partir de UML en XMI a OWL aprovechando las sintaxis en común de XML. Otros métodos como [Brockmas, 2006] y [Silva, 2007] realizan la transformación entre modelos con soporte MDA utilizando el lenguaje de transformación QVT [QVT-RFP, 2002].
1.2. Descripción del problema
Las ontologías se han convertido en uno de los componentes clave para la realización de la Web semántica [Berners-Lee, 2001], éstas han traído consigo un amplio rango de actividades de desarrollo que se pueden agrupar en lo que se conoce como Ingeniería de ontologías. Las prácticas de Ingeniería ontológica presentan muchas similitudes con las técnicas del campo de la ingeniería de software, por lo que ha habido diferentes adaptaciones de los principios de la Ingeniería de software hacia el dominio de las ontologías [Fernández-López, 1997]. De estos principios, la tarea de conceptualización de ontologías es la que mayores problemas representa, al tratar de producir un modelo conceptual de la ontología partiendo de un glosario de términos que contienen el conocimiento del dominio. El problema de conceptualización se debe en gran medida a que las herramientas para la generación de ontologías ofrecen muy pocas ayudas a usuarios no experimentados, y usualmente ofrecen una representación gráfica sólo al finaliza el modelado de la misma, cuando en realidad lo que el desarrollador necesita es poder representar conceptualmente desde el principio aquellos términos del glosario que serán modelados como clases, propiedades, valores de la propiedades e instancias. La ausencia de una sintaxis visual que ayude al usuario en la formulación de una ontología ha sido nuestra motivación para proponer un método de creación de ontologías OWL a partir de modelos gráficos. Para esto hemos decidido utilizar UML como lenguaje de modelado. Este lenguaje tiene como ventajas: a) este lenguaje de modelado ha demostrado durante muchos años ser una notación gráfica para el análisis y diseño de software, b) es un estándar abierto mantenido por la OMG, c) ha sido ampliamente aceptado en la industria y d) es enseñado como materia en universidades. Podemos establecer que UML es de uso común para los desarrolladores de software mientras que las herramientas actuales para el desarrollo de ontologías requieren de mayor experiencia para su uso efectivo. En este trabajo se propone el uso de modelos conceptuales de UML y más específicamente diagramas de clases como un lenguaje de representación y modelado de conocimiento para ontologías en OWL. Con este enfoque se pretende ofrecer una notación visual al inicio del desarrollo de las ontologías aprovechando la amplia aceptación de UML y en particular de los diagramas de clases mediante una aproximación sistemática de generación de ontologías utilizando técnicas de MDA.
1.3. Objetivo
La Web semántica se fundamenta en ontologías que son una manera formal de organizar el conocimiento de tal manera que permiten compartir dicho conocimiento entre diferentes aplicaciones. La OMG (Object Management Group), un consorcio para la estandarización de varios aspectos de la ingeniería de software, estableció un Metamodelo para la Definición de Ontologías (Ontology Definition Metamodel) [OMG, 2003] con la intención de proveer metamodelos que soporten el desarrollo de ontologías utilizando herramientas de modelado de UML y su transformación a ontologías escritas en un lenguaje específico como lo es OWL. Esta especificación proporciona un conjunto de guías que permitan estructurar especificaciones expresadas como modelos, lo que constituye la base de la filosofía MDA.
≈ Introducción
pág. 4
La presente investigación tiene como objetivo generar ontologías en OWL a partir de diagramas de clases de UML mediante transformaciones de los metamodelos de UML y ODM el cual define al lenguaje OWL en el enfoque MDA, utilizando el lenguaje de transformación entre modelos ATL (Atlas Transformation Language).
1.4. Justificación y beneficios La Web semántica se fundamenta en ontologías, las cuales son una manera formal de organizar el conocimiento de tal manera que permiten compartir dicho conocimiento entre diferentes aplicaciones. Como ya se mencionó, las técnicas y herramientas para la creación de ontologías son desconocidas por una amplia población de ingenieros de software [Djuric, 2005]. Con el fin de cerrar la brecha entre el proceso de desarrollo de ontologías y la población de ingenieros de software, se propone el uso de técnicas de ingeniería de software, en especial UML como método de inicio para la creación de una ontología. De esta manera al usar la sintaxis de UML los desarrolladores de ontologías podrán usar una notación gráfica para el desarrollo de las mismas. Con esto se evita el uso de nuevas herramientas para la generación de ontologías y su respectiva curva de aprendizaje.
1.5. Alcances En esta sección se presentan los alcances del trabajo de investigación desarrollado en esta tesis.
Se establece la correspondencia entre los modelos de UML y una ontología descrita en
lenguaje OWL. Esta correspondencia entre modelos se establece a través de reglas que han
sido formalizadas con lógica de primer orden.
Las reglas de transformación se implementan mediante el lenguaje de transformación entre
modelos ATL.
Las ontologías generadas se realizan en archivos OWL en su versión 1.0.
1.6. Limitaciones
Se listan los puntos que delimitan el alcance de este trabajo.
Se hace uso del Framework de Modelado Eclipse (EMF) para la obtención de ontologías en OWL.
Los modelos de UML utilizados en esta tesis se limitan a diagramas de clases.
Se utiliza UML en su versión 2.0 debido a la compatibilidad con (EMF).
1.7.Organización del documento
En esta tesis se presenta el método para la generación de ontologías en OWL a partir de diagramas de clases de UML mediante un enfoque dirigido por modelos. El trabajo está organizado en 7 secciones las cuales se listan a continuación.
Capítulo 2. Marco teórico. En este capítulo se presentan los conceptos fundamentales que son
utilizados en el método propuesto.
≈ Introducción
pág. 5
Capítulo 3. Estado del arte . Este capítulo presenta un resumen de los trabajos relacionados
que sirven como punto de referencia y comparación con el trabajo propuesto.
Capítulo 4. Método para la generación de ontologías OWL a partir de diagramas de
clases de UML. En este capítulo se presentan las reglas de transformación necesarias para
generar ontologías en OWL a partir de diagramas de clases de UML. Estas reglas son la base
del trabajo de investigación presentado en esta tesis.
Capítulo 5. Diseño e implementación. Este capítulo presenta la implementación del método
propuesto utilizando el Framework Eclipse. El capítulo muestra también la Interfaz Gráfica del
Usuario (GUI).
Capítulo 6. Pruebas. En este capítulo se desarrollan los casos de prueba para la herramienta
desarrollada.
Capítulo 7. Conclusiones. Este capítulo proporciona los resultados y observaciones finales de
este trabajo de investigación.
pág. 6
Capítulo 2. Marco teórico En este capítulo se presentan los conceptos fundamentales que son utilizados en el método propuesto.
≈ Capitulo 2. Marco teórico
pág. 7
2.1. Web semántica
La Web semántica aboga por clasificar, dotar de estructura y anotar los recursos con semántica explicita procesable por máquinas [Castells 2004]. En la Figura 2-1, se ilustra la diferencia entre la Web actual y la Web semántica. Actualmente la Web se asemeja a un grafo formado por nodos del mismo tipo, y arcos donde por ejemplo, no se hace distinción entre la página personal de un profesor y el portal de una tienda on-line, como tampoco se distinguen explícitamente los enlaces a las asignaturas que imparte un profesor de los enlaces a sus publicaciones. Por el contrario, en la Web semántica cada nodo (recurso) tiene un tipo (profesor, tienda, pintor, libro), y los arcos representan relaciones explícitamente diferenciadas (pintor – obra, profesor – departamento, libro – editorial).
Figura 2-1. Diferencia entre la Web actual y la Web semántica [Castells, 2004]
Para construir la Web semántica se necesita poder representar el conocimiento de forma que sea legible por las computadoras, esté consensuado, y sea reutilizable. Las ontologías proporcionan la vía para representar este conocimiento.
2.2. Ontologías El término „ontología‟ (utilizado en filosofía para hablar acerca de una „teoría sobre la existencia‟) ha sido adoptado por la comunidad de investigadores de inteligencia artificial para definir una categorización y las relaciones entre sus términos [Berners-Lee, 2001]. [Borst, 1997] Establece que, "Una ontología es una especificación formal de una conceptualización compartida. Es una especificación porque está formada por conceptos, propiedades, relaciones, funciones, restricciones y axiomas. Se considera formal porque puede ser computable. Una ontología es explícita por que el tipo de conceptos así como sus restricciones de uso son definidos explícitamente. La conceptualización se refiere a que es un modelo abstracto de un cierto fenómeno real que identifica sus componentes (conceptos) más importantes. Finalmente, se considera compartida ya que plasma un conocimiento consensuado. Una ontología representa una taxonomía y un conjunto de reglas de inferencia. La taxonomía define las clases de objetos y de relaciones entre ellos. Clases, subclases y relaciones entre entidades son herramientas de gran potencia para usarlas en la Web. Las reglas de inferencias por su parte ofrecen la
≈ Capitulo 2. Marco teórico
pág. 8
posibilidad de que una ontología pueda expresar condiciones. Un programa puede deducir cosas, no es que realmente las entienda, pero puede manipular los términos de forma efectiva, lo que es útil e importante para las personas. Existe un lenguaje de marcado para publicar y compartir datos usando ontologías, el “Web Ontology Language” [W3C OWL 2004], el cual se describe en el siguiente punto.
2.3. OWL (Web Ontology Language)
El Lenguaje de Ontologías Web (OWL) [W3C OWL 2004] está diseñado para ser usado en aplicaciones que necesitan procesar el contenido de la información en lugar de únicamente representar información para los humanos. OWL facilita un mejor mecanismo de interoperabilidad de contenido Web que los mecanismos admitidos por XML, RDF, y esquema RDF (RDF-S) proporcionando vocabulario adicional junto con una semántica formal. OWL tiene tres sub-lenguajes, con un nivel de expresividad creciente: OWL Lite, OWL DL, y OWL Full. OWL proporciona más vocabulario que RDF para describir propiedades y clases tales como: relaciones entre clases (por ejemplo “clases disjuntas”), cardinalidad (por ejemplo “exactamente uno”) e igualdad. OWL también proporciona más tipos para las propiedades, características de las propiedades (por ejemplo “simetría”), y clases enumeradas.
OWL Lite está diseñado para aquellos usuarios que necesitan principalmente una clasificación
jerárquica y restricciones simples.
OWL DL está diseñado para aquellos usuarios que requieren la máxima expresividad
conservando completitud computacional (se garantiza que todas las conclusiones sean
computables), y decibilidad (todos los cálculos acaban en un tiempo finito). OWL DL es
denominado de esta forma debido a su correspondencia con la lógica de descripción
(Description Logics, en inglés), un campo de investigación que estudia la lógica que compone
la base formal de OWL.
OWL Full está diseñado a usuarios que quieren máxima expresividad y libertad sintáctica de
RDF sin garantías computacionales. Por ejemplo, en OWL Full una clase puede ser
considerada simultáneamente como una colección de clases individuales y como una clase
individual propiamente dicha.
2.4. Arquitectura Dirigida por Modelos MDA El OMG (Object Managment Group) adopta a la Arquitectura Dirigida Por Modelos (Model Driven Architecture, MDA) como un enfoque para usar modelos en el desarrollo de software [OMG.2003]. MDA establece una separación entre el modelado y los detalles de implementación, haciendo una distinción entre modelos independientes de plataforma (Platform Independent Model, PIM) y modelos específicos de plataforma (Platform Specific Model, PSM). El modelo PIM expresa el comportamiento o funcionalidad de un sistema, es un modelo que no tiene ninguna información de implementación sobre una tecnología específica. El modelo PSM especifica detalles de implementación como: lenguaje de codificación, tipos de datos, etc. Las técnicas de transformación convierten modelos independientes de plataforma que especifican las operaciones de los sistemas, en modelos específicos de plataforma [Meth, 2003].
≈ Capitulo 2. Marco teórico
pág. 9
Una especificación MDA completa consiste de un modelo base PIM y uno más PSM junto a un conjunto de definiciones de interfaz. Cada una de las interfaces describe cómo el modelo base se implementa en una plataforma diferente. Una de las características fundamentales del enfoque MDA es la noción de transformación. Una transformación es un conjunto de reglas y técnicas usadas para modificar un modelo y conseguir otro modelo [OMG01]. Se pueden realizar diferentes transformaciones, como las que se muestran en la Figura 2-2 y que se explican a continuación:
PIM a PIM: esta transformación es usada cuando los modelos son refinados, filtrados o
especializados durante el desarrollo de ciclo de vida.
PIM a PSM: esta transformación es usada cuando el PIM es suficientemente refinado para ser
proyectado en la infraestructura de ejecución. La proyección está basada en las características
de la plataforma.
PSM a PSM: esta transformación se necesita para la realización de componentes e
implementación. El mapeo de PSM a PSM está relacionado generalmente al refinamiento de
modelos dependientes de plataforma.
PSM a PIM: esta transformación es requerida para abstraer modelos de implementaciones existentes en una tecnología particular en un modelo independiente de plataforma. Idealmente, el resultado de este mapeo se comparará con el mapeo de PIM a PSM.
Figura 2-2. Transformación de modelos.
El lenguaje utilizado para la transformación entre los modelos utilizados en esta tesis es ATL, el cual se detalla en la sección 2.5.
2.5.ATL (Atlas Transformation Language) ATL es un lenguaje de transformación de modelos que permite especificar cómo uno o más modelos objetivo pueden ser producidos desde un conjunto de modelos fuente. Es un lenguaje especificado como un metamodelo y que cuenta con una sintaxis concreta de texto. ATL es la respuesta a la propuesta por petición (RFP por sus siglas en inglés) de la OMG MOF QVT RFP [ATLAS, 2006], para la transformación de modelo a modelo. Las operaciones de transformación pueden ser especificadas por medio de módulos ATL. El lenguaje también permite desarrollar librerías ATL independientes para ser importadas. El lenguaje ATL es un híbrido entre programación declarativa e imperativa. El estilo preferido de transformación escrita es la declarativa, ya que permite expresar simplemente mapeos entre los elementos del modelo fuente y destino. Un programa de transformación ATL está compuesto de reglas
PIM PIM
PIM
PIM
PSM PSM PSM PSM
≈ Capitulo 2. Marco teórico
pág. 10
que definen como los elementos del modelo fuente son mapeados para crear los elementos del modelo destino. Un ejemplo de regla ATL se muestra en la Figura 2-3:
Figura 2-3: Ejemplo de regla ATL.
En la regla Author (Figura 2-3) se realiza una transformación de los elementos del modelo fuente a hacia los elementos del modelo objetivo p. En este ejemplo el elemento Author del modelo a se transformará al elemento Person del modelo p asignando el nombre y apellido del elemento Author al nombre y apellido del elemento Person en el modelo p. El lenguaje ATL es el lenguaje oficial del proyecto Eclipse M2M. ATL se enfoca principalmente a la transformación de modelo a modelo, y está basado en OCL. Aplicando la serie de reglas al modelo fuente se obtiene el modelo resultante en un archivo XMI.
2.6.OCL (Object Constraint Language)
Es un lenguaje formal usado para describir expresiones en modelos UML. Estas expresiones especifican condiciones invariantes que deben mantenerse en el sistema que es modelado. Las expresiones OCL pueden ser usadas para especificar operaciones / acciones que no alteran el estado del sistema cuando se ejecutan. OCL es un lenguaje de especificación pura, por lo tanto, cuando una expresión OCL es evaluada, simplemente regresa un valor pero no puede cambiar nada en el modelo. No es un lenguaje de programación, no es posible escribir lógica de programa o control de flujo, y tampoco se pueden invocar procesos, ya que es un lenguaje de modelado. Cada expresión OCL está escrita en el contexto de una instancia de un tipo específico (un tipo se refiere a un clasificador, como una clase). En una expresión OCL, la palabra reservada self es usada para referirse a la instancia contextual. Por ejemplo, si el contexto es Compañía, entonces self se refiere a una instancia de tipo Compañía. Un ejemplo de expresión OCL puede ser el que se observa en la Figura 2-4. Este ejemplo muestra una expresión invariante en el contexto de una Compañía de un modelo UML, especificando que el número de empleados siempre debe exceder 50 para las instancias de tipo Compañía.
Figura 2-4: Ejemplo expresión en OCL. El lenguaje de restricciones OCL, sólo permite especificar y detallar modelos, pero no realiza ningún tipo de transformación.
rule Author {
from
a : MMAuthor!Author
to
p : MMPerson!Person ( name < a .name, surname < a.surname) }
context Compañia inv :
self.numerodeEmpleados > 50
≈ Capitulo 2. Marco teórico
pág. 11
2.7. UML (Unified Modeling Language)
UML fue adoptado por OMG (Object Management Group) como una de sus especificaciones y desde entonces se ha convertido en un estándar de facto para visualizar, especificar y documentar los modelos que se crean durante la aplicación de un proceso software. UML ha ejercido un gran impacto en la comunidad software, tanto a nivel de desarrollo como de investigación. Su éxito ha sido enorme, como lo prueban, por una parte, su utilización en todo el mundo para construir aplicaciones en todos los dominios y de todos los tamaños y por otra, que los entornos de desarrollo más extendidos --como son los de Borland, Microsoft e IBM-- integran herramientas para el modelado con UML. Otras dos especificaciones de OMG relacionadas con UML son el lenguaje OCL (Object Constraint Language) y XMI (XML Metadata Interchange). Con la iniciativa MDA (Model Driven Architecture), promovida por el OMG, ha surgido un nuevo paradigma de desarrollo, no centrado en el código sino en los modelos, que se denomina desarrollo dirigido por modelos. Con esta nueva visión, se puede obtener código a partir de modelos centrados en el dominio del problema e independientes de cualquier aspecto relacionado con la plataforma, mediante transformaciones de modelos.
2.8.Eclipse Modeling Framework (EMF)
El Eclipse Modeling Framework (EMF) es un framework de modelado para Eclipse. Un modelo en EMF, a diferencia de un modelo definido con UML, es menos general y no requiere una metodología diferente o alguna herramienta sofisticada de modelado. El metamodelo núcleo de EMF es llamado Ecore, usado para representar modelos en EMF. Ecore es en sí un modelo EMF y por lo tanto su propio metamodelo. Hay cuatro clases Ecore que se usan para representar modelos [Budi, 2003]:
Eclass: es usado para representar una clase modelada. Tiene un nombre, cero o más atributos y
cero o más referencias.
EAttribute: es usado para representar un atributo modelado. Los atributos tienen un nombre y
un tipo.
EReference: es usado para representar el fin de una asociación entre clases. Tiene un nombre,
una bandera boleana para indicar si representa contención y un tipo de objetivo de referencia,
el cual es otra clase.
EDatatype: es usado para representar el tipo de un atributo. Un tipo de dato puede ser
primitivo, como int o float o bién un tipo de objeto.
Los nombres de las clases corresponden estrechamente a los términos de UML, esto es porque Ecore es un pequeño subconjunto simplificado de UML [Budi, 2003]. El modelo EMF permite especificar los datos de la aplicación representándolos en un diagrama de clases. A partir de una especificación del modelo, EMF puede generar código de implementación eficiente, correcto y fácilmente adaptable. EMF proporciona soporte para Java, UML y XML, además de contar con soporte de varias herramientas dentro del framework Eclipse. EMF está relacionado con UML en un solo aspecto, el modelado de clases. Además, evita algunas complejidades por lo que resulta en una implementación optimizada ampliamente aplicable.
≈ Capitulo 2. Marco teórico
pág. 12
2.9.Sintaxis XML/RDF
Es una sintaxis utilizada para representar metadatos en OWL [W3C, 1999] , así como una sintaxis para codificar y transmitir estos metadatos de tal forma que maximicen la interoperabilidad de servidores y clientes web desarrollados independientemente. La sintaxis XML/RDF utiliza el Extensible Markup Language [Lenguaje de Marcado Extensible] (XML): uno de los objetivos de OWL es hacer posible especificar la semántica para las bases de datos en XML de una forma normalizada e interoperable. OWL y XML son complementarios: OWL es un modelo de metadatos y sólo dirige por referencia muchos de los aspectos de codificación que requiere el almacenamiento y transferencia de archivos (tales como internacionalización, conjuntos de caracteres, etc.). Para estos aspectos, RDF cuenta con el soporte de XML. Es importante también entender que esta sintaxis XML es sólo una sintaxis posible para OWL y que pueden surgir formas alternativas para representar el mismo modelo de datos OWL.
pág. 13
Capítulo 3. Estado del Arte En el presente capítulo se exponen los trabajos relacionados con el presente trabajo de investigación. Se presenta una comparación entre los distintos trabajos relacionados y el método propuesto en este trabajo de investigación.
≈ Capitulo 3. Estado del Arte
pág. 14
3.1.Representación de modelos de actividad de UML como ontologías
El método propuesto en [Hanzala, 2007] para generar ontologías a partir de diagramas de actividad de UML utiliza reglas de mapeo para establecer las correspondencias entre un diagrama de actividad en UML y una ontología. Los diagramas de actividad son modelados en herramientas de UML como Poseidón donde la herramienta exporta un XMI el cual sirve de entrada en la aplicación Las reglas de mapeo están descritas en formato XSLT (XML Style sheet Language Transformation) el cual es un lenguaje de transformación entre modelos que transforma un documento en XML a otro documento también en XML. De esta manera tanto XSLT como el XMI del diagrama de actividades son usados como entrada en la aplicación para realizar el mapeo. La salida es la ontología en OWL que expresa el conocimiento representado por el diagrama de actividades. La Figura 3-1 muestra de forma detallada una vista de la solución propuesta por [Hanzala, 2007].
Figura 3-1. Solución propuesta para el mapeo de diagramas de actividad en UML a OWL.
3.2.Convirtiendo UML a ontologías OWL
En los trabajos de Gásevic [Gásevic, 2004] se propone una estrategia para la generación automática de ontologías en OWL a partir de un modelo en UML. Este trabajo se basa en una arquitectura definida por MDA para el desarrollo de ontologías y el perfil de UML para ontologías (OUP, Ontology UML Profile). La conversión propuesta en este trabajo transforma una ontología en OWL a partir de la definición del OUP (es decir con el XMI). La ontología generada puede ser compartida con herramientas de generación de ontologías como Protégé. Al utilizar el estándar XMI para la compartición de modelos, metamodelos y metametamodelos de MDA basados en XML, se puede emplear XSLT para transformar documentos en XMI a documentos basados en XML como puede ser OWL siguiendo el procedimiento especificado en la Figura 3-2.
≈ Capitulo 3. Es tado del Arte
pág. 15
Figura 3-2. Principio XSLT para el desarrollo de ontologías.
3.3. Un enfoque dirigido por modelos para la construcción de ontologías
OWL DL y Full En los trabajo de Brockmas [Brockmas, 2006] se presenta un enfoque para el modelado visual de ontologías en OWL DL y OWL Full basado en el lenguaje de modelado UML. Los autores presentan un metamodelo basado en MOF (Meta Object Facility) con el cual instanciar el lenguaje OWL, un perfil asociado a UML y las transformaciones entre ambos. El trabajo presentado soporta el desarrollo dirigido por modelos de las ontologías en OWL. El perfil de UML propuesto es cognitivamente más adecuado para gente familiarizada con UML y OWL ya que utiliza la máxima intersección de características de UML y OWL, de ahí que las clases son descritas como clases, propiedades como asociaciones n-arias e individuos como objetos de UML. Las transformaciones se llevan a cabo utilizando el lenguaje de transformación entre modelos QVT y son de carácter bidireccional. La herramienta propuesta Visual Ontology Modeler (VOM) se desarrolló por la compañía Sandpiper e implementada como extensión en Rational Rose de IBM. El mapeo de constructores que los autores proponen se muestra en la Figura 3-3.
Figura 3-3. Mapeo entre constructores de UML y OWL [Brock mas, 2006].
≈ Capitulo 3. Es tado del Arte
pág. 16
3.4.TwoUse: Integrando modelos UML y ontologías OWL
El Framework “TwoUse” (Transforming and Weaving Ontologies and UML in Software Engineering ) lo utilizan los autores de [Silva, 2007] para el desarrollo de modelos integrados que comprenden los beneficios de modelos de UML y ontologías en OWL. Con este Framework los autores permiten el uso de modelos de UML y de ontologías al mismo tiempo. Las ideas principales del Framework “TwoUse” son:
1. Provee un metamodelo integrado basado en MOF como columna vertebral para el modelado de
UML (incluyendo OCL) y OWL.
2. Utiliza un perfil de UML como su base sintáctica integrada, soporta mecanismos de extensión
de UML2 y mapeo entre los perfiles hacia los modelos de TwoUse.
3. Provee un conjunto de reglas de transformación canónicas con el fin de lidiar con la
integración a niveles semánticos.
4. Extiende la librería básica provista para la especificación de OCL a la cual los autores llaman
OCL-DL.
Para llevar a cabo la composición del Framework “TwoUse”, se adoptó el metamodelo ODM (Ontology Definition Metamodel) para OWL de la OMG. Además “TwoUse” usa otros dos metamodelos, el de UML el cual permite especificar una clase con sus características estructurales y de comportamiento, así como también el metamodelo de OCL, el cual hace posible especificar expresiones y operaciones pre-construidas de las clases. A continuación se presenta la Figura 3-4 en la cual se exponen los espacios tecnológicos de los cuales el Framework “TwoUse” hace uso.
Figura 3-4. Capas de metamodelos y es pacios de modelado del enfoque “TwoUse”.
Como se puede apreciar en la Figura 3-4, las cuatro columnas UML, TwoUse, OWL y Java son agrupadas en tres espacios de modelado MOF, RDF(S) y EBNF. Para cada columna se muestran 3 niveles de modelado de acuerdo a la arquitectura de 4 capas de metamodelado de la OMG: el nivel de metametamodelado (M3), el nivel de metamodelado (M2) y el nivel de modelado (M1). Las relaciones dentro de cada cuadrante muestran dependencia, las que cruzan las líneas de frontera verticales son transformaciones, las que cruzan las líneas de frontera horizontales significan instanciación, las cajas dentro de cada cuadrante representan paquetes.
≈ Capitulo 3. Es tado del Arte
pág. 17
3.5. Ingeniería dirigida por modelos para ontologías El método propuesto por Pan en [Pan, 2006] describe la estructura de sistema de ingeniería de ontologías y el mapeo entre UML y OWL para la transformación entre modelos. Se hace uso de EODM (EMF-based ODM) el cual es el modelo de objetos generado a partir de ODM utilizando EMF (Eclipse Modeling Framework) para la transformación entre modelos de UML a OWL.
Figura 3-5. Arquitectura del sistema de ingeniería de ontologías basado en EMF.
Como se puede observar en la Figura 3-5, la base del sistema es el EMF que permite la entrada y salida de ontología en OWL y los manipula mediante objetos Java que proporcionan clases y métodos útiles para acceder a las ontologías en OWL y sus instancias. El parseador de OWL provee una herramienta para transformar ontologías en OWL a modelos EODM y serializar estos modelos EODM en archivos estándar de RDF/XML. El motor de inferencias toma un modelo EODM como entrada y ejecuta consultas por parte del usuario, razona acerca de las instancias y relaciones entre las instancias y clases. La transformación de modelos, en esta parte se importan modelos conceptuales como UML que son transformados en modelos EODM. El Editor OWL provee un editor gráfico de ontologías que son serializadas en formato XML. Finalmente el editor de OWL presenta una interfaz gráfica el cual permite crear visualmente un archivo OWL mediante la utilización del GEF (Graphic Editor Framework) de Eclipse como base gráfica.
3.6. Comparativo de trabajos relacionados
En esta sección se describe un comparativo con los puntos de interés interrelacionados con los trabajos relacionados y el proyecto de tesis. Se detallan en la Tabla 1, los criterios de comparación:
Diagramas de UML: En este punto de interés se especifica a partir de cuáles diagramas de
UML se obtienen las ontologías en OWL.
Ontologías obtenidas: En este punto de interés se especifica el tipo de archivo OWL para
ontologías que se obtiene a partir del mapeo con los diagramas de UML.
Lenguaje de transformación: Este punto de interés especifica el lenguaje utilizado para el
mapeo y transformación necesario para la obtención de la ontología en OWL.
Espacio tecnológico: un espacio tecnológico es un contexto de trabajo con un conjunto de
conceptos asociados, cuerpo de conocimiento y habilidades requeridas. Se pueden identificar
como XML, DBMS, MDA, etc.
Plataforma de desarrollo: Este punto de interés especifica la plataforma de desarrollo
utilizada para llevar a cabo las transformaciones entre los diagramas de UML y las ontologías
en OWL.
En los apartados en los que aparezca el signo “¿” es debido a que hasta el momento no se ha podido obtener dicha información.
≈ Capitulo 3. Es tado del Arte
pág. 18
Nombre
Diagramas
UML
Ontologías
obtenidas
Lenguaje de
Transformación
Espacio
Tecnológic
o
Plataforma
de Desarrollo
[Hanzala,
2007] Actividad OWL XSLT XML ¿
[Gásevic, 2004]
Clases OWL XSLT XML ¿
[Brockmas,
2006] Clases OWL DL/Full QVT MDA ¿
[Silva, 2007] Clases OWL Java MDA EMF
[Pan, 2006] Clases OWL XSLT XML EMF
Tesis Clases OWL ATL MDA, XML EMF
Tabla 1. Comparación de herramientas del estado del arte.
A diferencia de los trabajos relacionados, en nuestra investigación decidimos utilizar el lenguaje de transformación entre modelos ATL basándonos en los siguientes argumentos:
Es un software de código abierto.
Tiene la comunidad más grande de usuarios en comparación a otros lenguajes de
transformación entre modelos.
Cuenta un soporte sólido de desarrolladores.
Tiene una gran base de conocimiento acerca de ejemplos y proyectos sobre transformación
entre modelos.
Cuenta con un soporte bastante maduro para los espacios tecnológicos como por ejemplo
XML, EMF y MOF.
A su vez, a diferencia de los trabajos relacionados, se hace uso de dos espacios tecnológicos y las respectivas transformaciones entre ellos. El primer espacio tecnológico corresponde a MDA al utilizar el lenguaje de modelado estándar UML y las reglas que definen los niveles de abstracción entre los modelos. El segundo espacio tecnológico corresponde a XML ya que OWL conforma a una sintaxis XML/RDF por lo que obliga a serializar nuestro resultado a la misma sintaxis XML/RDF con lo cual se provee una compatibilidad completa con herramientas de desarrollo de ontologías como es el caso de Protégé.
pág. 19
Capítulo 4. Método para la generación de ontologías
OWL a partir de diagramas de clases de UML
En este capítulo se presenta la arquitectura general de la solución propuesta para la generación de ontologías mediante diagramas de clases de UML. Se explican las fases que componen la arquitectura, se hace hincapié en el metamodelo del lenguaje OWL así como en las reglas de transformación necesarias para llevar a cabo la ejecución del método propuesto en esta investigación.
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 20
4.1. Arquitectura general de la solución propuesta
Para llevar a cabo el proceso de generación de ontologías en OWL a partir de diagramas de UML mediante MDA, se muestra la arquitectura general de la solución propuesta la cual está compuesta de 5 fases como se puede observar en la Figura 4-1. Cada una de las fases se explica brevemente. Las fases 2, y 4 se explican a mayor detalle en la sección 4.3 referente al catálogo de reglas de transformación que son la base central del método propuesto para esta investigación.
Figura 4-1 Arquitectura general de la solución
4.1.1. Fase 1. Generación del diagrama de clases de UML.
Esta fase consiste en generar un diagrama de clases de UML por parte del usuario. Una interfaz Gráfica de Usuario (GUI) permite al autor de la ontología la creación visual de la misma. Se hace uso del Framework de Modelado Eclipse (EMF) con el soporte de UML 2.0 para utilizar los diagramas de clases que Eclipse provee.
4.1.2. Fase 2. Aplicación de reglas de transformación UML a OWL
Esta fase consiste en la ejecución de las reglas de transformación necesarias para la obtención de una ontología en OWL a partir de un diagrama de clases de UML. En esta fase las reglas de transformación son descritas en lenguaje ATL (Atlas Transformation Language). La ejecución de las reglas de transformación se lleva automáticamente por e l prototipo propuesto. En la sección 4.3 se explican a mayor detalle estas reglas de transformación.
4.1.3. Fase 3. Generación de ontología OWL
El resultado de la ejecución de las reglas de transformación que se lleva a cabo en la fase 2, genera un nuevo modelo en lenguaje Ecore el cual corresponde a una ontología en OWL con formato Ecore. Debido a que el lenguaje Ecore es exclusivo del Framework Eclipse es necesario implementar una segunda transformación que se lleva a cabo en la fase 4 para poder darle “formato” XML/RDF característico de los archivos OWL. Un ejemplo de una ontología representada en el lenguaje Ecore se muestra en la Figura 4-2 y cuya equivalencia en formato XML/RDF se muestra en la Figura 4-3. En la ontología OWL con formato Ecore de la Figura 4-2 se aprecian los espacios de nombres que integran toda ontología para definir variables, igualmente se observa el nombre de la ontología cuyo valor es “Librería” y que cuenta con una URI con valor igual a “http://www.cenidet.edu.mx/Librería#Novela”.
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 21
Figura 4-2 Ontología en lenguaje Ecore.
4.1.4. Fase 4. Aplicación de reglas de transformación OWL a XML/RDF
En esta fase se ejecuta otro conjunto de reglas de transformación con el fin de serializar la ontología en OWL con formato Ecore a una ontología OWL con formato XML/RDF, dichas reglas de transformación son definidas mediante el lenguaje ATL y ejecutadas automáticamente por el prototipo. Estas reglas se describen en la sección 4.3.
4.1.5. Fase 7. Generación de archivo OWL con formato XML/RDF
En esta fase se obtiene el archivo OWL con formato XML/RDF el cual se originó a partir del diagrama de clases de UML generado en la fase 1. El formato XML/RDF del archivo OWL garantiza que la ontología puede ser importada y refinada por herramientas para la generación de ontologías como los son Protégé o TopBraid composer, o bien que pueda ser utilizada directamente para poblar la Web semántica. En la Figura 4-3 se muestra el resultado de la serialización al formato XML/RDF de la ontología OWL que se muestra en la Figura 4-2 de la fase 3. En este archivo OWL se aprecian los espacios de nombres utilizados por la ontología para definir variable así como también el nombre de la ontología cuyo valor es “http://www.cenidet.edu.mx/Librería#” y el nombre de la clase de nombre “#Novela”
Figura 4-3. Ejemplo de archivo OWL con formato XML/RDF.
Antes de definir las reglas de transformación es necesario explicar el metamodelo OWL del cual dependen las reglas de transformación para su funcionamiento. Este metamodelo representa la estructura de los archivos OWL que se pretenden obtener como resultado de este trabajo de investigación.
<?xml version="1.0" encoding="ISO-8859-1"?>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:owl="http://w3.org/2002/owl">
<espacionombres prefijo="rdfs" URI="http://www.w3.org/2000/01/rdf-schema#"/>
<espacionombres prefijo="Biblioteca" URI="http://www.cenidet.edu.mx/Librería#"/>
<espacionombres prefijo="xsd" URI="http://www.w3.org/2001/XMLSchema#"/>
<espacionombres prefijo="owl" URI="http://www.w3.org/2002/07/owl#"/>
<espacionombres prefijo="rdf" URI="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> <ontologia URI="http://www.cenidet.edu.mx/Biblioteca#" nombreLocal="Librería">
<contenidoOntologia xsi:type="owl:ClaseOWL" nombreLocal="Novela"
URI="http://www.cenidet.edu.mx/Librería#Novela"/>
</ontologies>
1.<rdf:RDF
2. xmlns:rdfs = 'http://www.w3.org/2000/01/rdf-schema#'
3. xmlns:xsd = 'http://www.w3.org/2001/XMLSchema#'
4. xmlns:owl = 'http://www.w3.org/2002/07/owl#'>
5. <owl:Ontology rdf:about = 'http://www.cenidet.edu.mx/Librería#'/>
6. <owl:Class rdf:about = '#Novela'>
7. <rdfs:label>Novela</rdfs:label>
8. </owl:Class>
9.</rdf:RDF>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 22
4.2.El metamodelo OWL
Para poder llevar a cabo transformaciones entre modelos de acuerdo a los estándares de MDA, es necesario contar con los metamodelos de los modelos fuente y destino, esto se puede observar en la Figura 4-4. MMa es el metamodelo fuente y MMb es el metamodelo destino. Ambos metamodelos deben estar presentes para que se lleve a cabo la transformación entre el modelo fuente Ma (en esta investigación corresponde a un modelo de clases de UML) y el modelo destino Mb (en esta investigación corresponde a una ontología OWL).
Figura 4-4. Contexto operacional de ATL
El metamodelo OWL en su versión 1.1 (el cual es utilizado en este trabajo de investigación) está definido en el lenguaje Ecore, este metamodelo es similar al metamodelo MOF. El metamodelo propuesto utiliza el soporte MDA de herramientas de modelado como UML y está basado en las especificaciones del Metamodelo para la Definición de Ontologías (ODM [OMG, 2003]) lo que permite un mapeo normativo entre ODM y UML. El diagrama de clases obtenido a partir de la especificación del metamodelo OWL se presenta en la Figura 4-5.
Las partes que componen el metamodelo OWL utilizado en esta investigación se presentan en las siguientes subsecciones.
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 23
Figura 4-5. Diagrama de clases del Metamodelo OWL.
cla
ss
MM
OW
L
Cla
se
OW
L
Re
str
icc
ion
Re
str
icc
ion
De
Ca
rdin
ali
da
d
- ca
rdin
ali
da
d:
in
t
Re
str
icc
ion
Ca
rdin
ali
da
dM
ax
ima
- ca
rdin
ali
da
dM
axim
a:
in
t
Re
str
icc
ion
Ca
rdin
ali
da
dM
inim
a
- ca
rdin
ali
da
dM
inim
a:
in
t
Re
str
icc
ion
To
do
sL
os
Va
lore
sD
e
Pro
pie
da
d
- e
sDe
pre
ca
da
: b
oo
lea
n
- e
sFu
ncio
na
l:
bo
ole
an
Pro
pie
da
dD
eO
bje
to
- e
sFu
ncio
na
lIn
ve
rsa
: b
oo
lea
n
- e
sSim
etr
ica
: b
oo
lea
n
Ele
me
nto
Co
nN
om
bre
- n
om
bre
Lo
ca
l:
Str
ing
On
tolo
gia
Es
pa
cio
De
No
mb
res
- p
refi
jo:
Str
ing
- U
RI:
S
trin
g
Do
cu
me
nto
OW
LE
lem
en
toC
on
UR
I
- U
RI:
S
trin
g
Va
lorD
eD
ato
- va
lor:
S
trin
g
De
fin
icio
nD
eC
las
e
Ele
me
nto
De
On
tolo
gia
Ind
ivid
uo
Cla
se
En
um
era
da
Va
lorD
eP
rop
ied
ad
De
Ob
jeto
Re
str
iTo
do
sV
alo
res
Cla
se
Ra
ng
oD
eD
ato
Pro
pie
da
dTip
oD
eD
ato
Va
lorD
eP
rop
ied
ad
Va
lPro
pie
da
dTip
oD
ato
Ra
ng
oD
eD
ato
En
um
era
do
Tip
oD
eD
ato
sub
Cla
se
sub
Cla
seD
e
ob
jeto
1..
1
ob
jeto
De
cla
seE
nu
me
rad
a
co
nte
nid
oO
nto
log
ia
on
tolo
gia
esp
acio
nN
om
bre
s
pro
pie
da
dD
eR
an
go
ran
go
un
oD
e
1..
*
gra
ph1
..1
pro
pie
da
dD
om
inio
do
min
io
pro
pe
rtyR
est
ricti
on
on
Pro
pe
rty
1..
1
typ
e
1..
1
suje
toD
e
suje
to1
..1
rest
riccio
nT
od
osL
osV
alo
resD
e
tod
osL
osV
alo
resD
eC
lase
un
oD
e
ob
jeto
De ob
jeto
1..
1
pro
pie
da
dR
an
go
ran
go
tip
o
1..
1
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 24
4.2.1.1. Ontologías y espacios de nombres. Un componente inicial de cada ontología incluye un conjunto de declaraciones de “Espacio de nombres de XML
1”, dentro de una etiqueta rdf:RDF. Estos espacios de nombres permiten interpretar
sin ambigüedades los identificadores y hacer del resto de la representación de la ontología mucho más fácil de leer.
En la Figura 4-6 se observa que un Documento OWL contiene las ontologías así como también una serie de espacios de nombres caracterizados por un prefijo y una URI. Las ontologías son elementos en el metamodelo OWL las cuales contienen un URI con el cual se identifican todos los elementos en OWL, las ontologías también se considera un elemento con nombre caracterizado por un nombre local dentro de la ontología.
Figura 4-6. Ontologías y es pacio de nombres
4.2.1.2. Propiedades Las propiedades representan asociaciones binarias en el dominio del modelado. OWL distingue dos clases de propiedades: las propiedades de objetos y las propiedades de tipos de datos. Ambas propiedades son un subconjunto de la metaclase Property. Las propiedades pueden ser funcionales (su rango contiene como máximo un elemento). Los dominios de las propiedades son siempre clases. Esto se muestra en la Figura 4-7. Las propiedades de objetos pueden ser del tipo funcional, inversa, transitivas, simétricas o inversas a otra propiedad. El rango de una propiedad de objeto es una clase mientras que el rango de una propiedad de tipo de dato es un tipo de dato el cual en nuestro metamodelo se especifica con la metaclase DataRange. PropiedadTipoDeDato. Una propiedad de tipo de dato relaciona individuos a valores de datos. Las propiedades de tipo de dato proporcionan relaciones entre instancias de clases y las instancias de los rangos de datos. PropiedadDeObjeto. Una propiedad de objeto relaciona individuos con individuos, por lo que proporcionan relaciones entre las instancias de dos clases. Atributos:
1 Un espacio de nombres es una recomendación W3C para proporcionar elementos y atributos con nombre único
en una instancia XML.
class Class Model
DocumentoOWL
EspacioDeNombres
- URI: String
OntologiaElementosDeOntologia
ElementoConURI
- URI: String
ElementoConNombre
- nombre: String
elementos
espacioDeNombres
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 25
esFuncionalInversa:boolean. Este atributo especifica si la propiedad es funcional inversa. Una
propiedad inversa funcional es una propiedad de objeto cuyo valor determina únicamente
algunos individuos. Las propiedades inversas funcionales son equivalentes a la noción de llave
principal en las bases de datos.
esSimétrica:boolean. Este atributo especifica si la propiedad es simétrica. Una propiedad
simétrica es una propiedad de objeto para la cual se establece que si el par (x, y) es una
instancia de la propiedad, entonces el par (y, x) es también una instancia de la propiedad.
Propiedad. Una propiedad relaciona individuos a valores de datos o individuos. La clase Propiedad es una clase abstracta.
Atributos:
esFuncional:boolean. Esta propiedad especifica si la propiedad es funcional. Una
propiedad funcional es una propiedad que puede tener un único valor para cada uno de los
individuos.
RangoDeDatos. Un rango de datos representa un rango de valores de datos, los cuales pueden ser un conjunto de valores de datos o bien un tipo de datos.
Figura 4-7. Propiedades
4.2.1.3. Clases y restricciones El diagrama de las clases que componen a OWL se muestra en la Figura 4-8, mientras que el diagrama de las restricciones de OWL se muestra en la Figura 4-9. Estos dos diagramas se encuentran lógicamente relacionados, por lo cual se agruparon en esta sección para su discusión.
Figura 4-8. Constructores de clases y axiomas.
class Class Model
propiedad
- esFuncional: boolean
PropiedadDeObjeto
- esFuncionalInversa: boolean
- esSimétrica: boolean
PropiedadTipoDeDato
ClaseOWL
TipoDeDato
rangorango
dominio
class Class Model
ClaseOWL
ClaseEnumeradaRestriccion
Indiv iduo
unoDe
subClaseDe
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 26
Figura 4-9. Restricciones en OWL.
RestrcciónTodosLosValoresDeclase. Es un tipo específico de valor de restricción que describe una clase de todos los individuos para los cuales todos los valores de una propiedad en consideración son miembros de la clase especificada. RestricciónCardinalidad. Es un tipo específico de restricción de cardinalidad que describe a una clase de todos los individuos que tienen exactamente N distintos valores semánticos (individuos o valores de datos) para la propiedad en consideración, donde N es el valor de la restricción de cardinalidad. RestricciónCardinalidadMáxima Es un tipo específico de restricción de cardinalidad que describe a la clase de todos los individuos que tienen a lo más N distintos valores semánticos (individuos o valores de datos) para la propiedad en consideración, donde N es el valor de la restricción de cardinalidad. RestricciónCardinalidadMínima. Es un tipo de restricción de cardinalidad que describe una clase de todos los individuos que tienen al menos N distintos valores semánticos (individuos o valores de datos) para la propiedad en cuestión, donde N es el valor de la restricción de cardinalidad. ClaseOWL. Las clases proporcionan un mecanismo de abstracción para agrupar individuos con características similares. Cada clase está asociada con otro conjunto de individuos llamados extensión de clase. Los individuos en la extensión de clase son llamados instancias de la clase. Las clases son descritas a través de “descripciones de clase” las cuales se pueden combinar en “axiomas de clases”. Existen seis tipos de descripciones de clase.
1. Un identificador de clase.
2. Una enumeración exhaustiva de los individuos.
3. Una restricción de propiedad.
4. El complemento de una descripción de clase.
5. La intersección de dos o más descripciones de clase.
6. La unión de dos o más descripciones de clase.
Restricción. Una restricción es un tipo especial de clase. Frecuentemente es anónima pero no siempre debe serlo, y representa a la clase de todos los individuos que satisfacen cierta restricción de propiedad. Existen dos tipos de restricciones de propiedad: restricciones de valor y restricciones de cardinalidad. Una restricción de valor pone restricciones al rango de la propiedad cuando se aplica este tipo de restricción de clase. Una restricción de cardinalidad pone restricciones al número de valores que una propiedad puede tomar en el contexto de esta descripción de clase en particular
class Class Model
Restriccion
RestCard RestCardMin
RestCardMax
Propiedad
RestTodosValClase
ClaseOWL
PropTipoDato
TipoDeDato
aClase enPropiedad
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 27
4.2.1.4. Tipos de datos El sistema de tipos de datos en OWL se provee por parte del XML Schema, que aporta un conjunto predefinido de tipos de datos (tipos primitivos) por ejemplo para el caso de una cadena el tipo primitivo es xsd:string. Los usuarios pueden especificar tipos de datos enumerados (Enumerated Datatype) los cuales consisten de varios valores de datos de los elementos (DataValue). Los tipos de datos deben contener una URI que los identifique. El diagrama que compone los tipos de datos en OWL se muestra en la Figura 4-10.
Figura 4-10. Tipos de datos.
4.3. Catálogo de reglas de transformación
Las siguientes reglas especifican los mecanismos estructurados para analizar diagramas de clases de UML con el fin de generar una ontología en OWL. Aunque no es posible generar una equivalencia completa entre todas las primitivas del modelo de OWL y UML, ya que algunos conceptos de OWL no pueden ser representados en un diagrama de clases de UML, el archivo resultante representa la estructura básica de un documento OWL suficiente para un a) un desarrollador de ontologías novato desarrolle sus ontologías[Brockmas, 2006] (ya que la mayoría de las herramientas para la generación de ontologías son poco conocidas fuera del área de inteligencia artificial [Kogut, 2002]) y b) un desarrollador experto pueda crear sus ontologías bases que pueda posteriormente refinar con herramientas para el desarrollo de ontologías como es Protégé. El catálogo de reglas de transformación se organiza al agrupar las reglas de acuerdo al tipo de resultado que producen. La organización del catálogo se muestra en la Tabla 2 en donde las dos primeras columnas muestran el constructor UML y las otras dos columnas muestran la correspondencia en OWL para los constructores UML soportados en esta tesis. El número de primitivas de UML que se presentan en la Tabla 2 es menor que el número total de reglas de transformación ya que por cada primitiva soportada se llevan a cabo dos transformaciones, lo que equivale a la ejecución de dos reglas de transformación distintas.
class Class Model
Propiedad
PropiedadTipoDeDatoRangoDeDato
TipoDeDato RangoDeDatoEnumeradoValorDeDato
ElementoConURI
- URI: String
ClaseOWL
tipounoDe
propiedadDeRango
rango
dominio
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 28
Constructor UML Constructor OWL OWL (XML/RDF) Paquete Ontología <rdf:RDF xmlns:Ontología = 'http://www.cenidet.edu.mx/Ontología#'>
<owl:Ontology rdf:about = 'http://www.cenidet.edu.mx/Ontología#'/> </rdf:RDF>
Clase Clase <owl:Class rdf:about = '#Clase_en_UML'> <rdfs:label>Clase_en_UML</rdfs:label> </owl:Class>
Clase de asociación Clase <owl:Class rdf:about = '#Clase_Asociación_UML'> <rdfs:label>Clase_Asociación_UML</rdfs:label>
</owl:Class>
Asociación
Propiedad objeto <owl:ObjectProperty rdf:about = '#src'> <rdfs:domain rdf:resource = '#Clase_UML_2'/>
<rdfs:range rdf:resource = '#Clase_en_UML'/> </owl:ObjectProperty>
Propiedad funcional <owl:ObjectProperty rdf:about = '#src'>
<rdfs:domain rdf:resource = '#Clase_en_UML_2'/> <rdfs:range rdf:resource = '#Clase_en_UML'/> <rdf:type rdf:resource =
'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:ObjectProperty>
Propiedad funcional inversa
<owl:ObjectProperty rdf:about = '#dst '> <rdfs:domain rdf:resource = '#Clase_en_UML'/> <rdfs:range rdf:resource = '#Clase_en_UML_2'/> <rdf:type rdf:resource =
'http://www.w3.org/2002/07/owl#InverseFunctionalProperty'/> </owl:ObjectProperty>
Propiedad todos los
valores de
<owl:Restriction>
<owl:onProperty rdf:resource = '#src'/> <owl:allValuesFrom rdf:resource = '#Clase_en_UML'/> </owl:Restriction> <owl:Restriction>
<owl:onProperty rdf:resource = '#src2'/> <owl:allValuesFrom rdf:resource = '#Clase_en_UML'/> </owl:Restriction>
Propiedad simétrica <owl:ObjectProperty rdf:about = '#src'> <rdfs:domain rdf:resource = '#Clase_en_UML'/> <rdfs:range rdf:resource = '#Clase_en_UML'/> <rdf:type rdf:resource =
'http://www.w3.org/2002/07/owl#SymmetricProperty'/> </owl:ObjectProperty>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 29
Atributo (tipo primitivo)
Propiedad tipo de dato <owl:DatatypeProperty rdf:about = '#atributo'> <rdfs:domain rdf:resource = '#Clase_en_UML'/>
<rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> </owl:DatatypeProperty>
Atributo (tipo de dato)
Propiedad tipo de dato <owl:DatatypeProperty rdf:about = '#boolean'> <rdfs:domain rdf:resource = '#Clase_en_UML'/>
<rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#boolean'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty>
Multiplicidad
Cardinalidad <owl:Restriction> <owl:onProperty rdf:resource = '#dst '/> <owl:cardinality rdf:datatype =
'http://www.w3.org/2001/XMLSchema#integer'>1</owl:cardinality > </owl:Restriction>
Multiplicidad
mínima
Cardinalidad mínima <owl:Restriction> <owl:onProperty rdf:resource = '#dst '/> <owl:minCardinality rdf:datatype =
'http://www.w3.org/2001/XMLSchema#integer'>1</owl:minCardinality > </owl:Restriction>
Multiplicidad
máxima
Cardinalidad máxima <owl:Restriction> <owl:onProperty rdf:resource = '#dst '/>
<owl:maxCardinality rdf:datatype = 'http://www.w3.org/2001/XMLSchema#integer'>2</owl:maxCardinality > </owl:Restriction>
Generalización Subclase de <owl:Class rdf:about = '#Clase_en_UML'> <rdfs:label>Clase_en_UML</rdfs:label>
</owl:Class> <owl:Class rdf:about = '#Subclase_en_UML'> <rdfs:subClassOf rdf:resource = '#Clase_en_UML'/> <rdfs:label>Subclase_en_UML</rdfs:label>
</owl:Class>
Composición Propiedad objeto <owl:ObjectProperty rdf:about = '#src'> <rdfs:domain rdf:resource = '#Clase_en_UML_2'/> <rdfs:range rdf:resource = '#Clase_en_UML'/> </owl:ObjectProperty>
Agregación Propiedad objeto <owl:ObjectProperty rdf:about = '#src'> <rdfs:domain rdf:resource = '#Clase_en_UML_2'/> <rdfs:range rdf:resource = '#Clase_en_UML'/> </owl:ObjectProperty>
Tabla 2. Equivalencia entre primitivas de UML y OWL.
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 30
A continuación se presenta el conjunto de reglas de transformación utilizadas en esta tesis. Antes de cada regla se presenta una pequeña explicación tomada de [W3C OWL 2004] del elemento que se quiere obtener en el lenguaje OWL. Por cada regla de transformación se presenta su formalización en lógica de primer orden así como su equivalente en el lenguaje de transformación entre modelos ATL.
4.3.1. Inicialización de la ontología
Un componente inicial de cada ontología incluye un conjunto de declaraciones de “Espacio de nombres de XML”, dentro de una etiqueta rdf:RDF. Estos espacios de nombres permiten interpretar sin ambigüedades los identificadores y hacer más sencillo el resto de la representación de la ontología, lo cual facilita también su lectura. Una ontología típica de OWL comienza con una declaración de espacio de nombres similar a la de la Figura 4-11.
Figura 4-11. Es pacio de nombres de XML.
Las primeras dos declaraciones identifican los espacios de nombres asociados con esta ontología. El primero hace el nombre de espacio por defecto estableciendo que aquellos nombres sin prefijo se refieren a la ontología actual. La segunda identifica el nombre de espacio de la ontología actual con el prefijo vin:. La tercera identifica la URI base de este documento. La cuarta declaración de nombre de espacio establece que en este documento, los elementos con el prefijo owl: se deberán entender como una referencia al nombre de espacio llamado http://w3.org/2002/07/owl#. Ésta es una declaración OWL convencional utilizada para introducir el vocabulario OWL.
Una vez definido lo anterior, la primera regla de transformación con la cual se pueda generar el documento OWL es la siguiente.
4.3.1.1. Regla 1: Inicialización de la ontología en Ecore Con esta regla se inicializa la ontología en OWL al especificar los espacios de nombres que se utilizarán en dicha ontología.
Para cada modelo de UML se inicializa el documento OWL con los espacios de nombres
necesarios para los prefijos rdf, rdfs, owl, xsd.
El valor de cada prefijo es el siguiente:
o “rdf:http://www.w3.org/1999/02/22-rdf-syntax-ns#”
o “rdfs:http://www.w3.org/2000/01/rdf-schema#”
o “owl:http://www.w3.org/2002/07/owl#”
o xsd:http://www.w3.org/2001/XMLSchema”
La formalización de la regla 1 se muestra en la Figura 4-12.
<rdf:RDF
xmlns ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xmlns:vin ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xml:base ="http://www.w3.org/TR/2004/REC-owl-guide-20040210/wine#"
xmlns:owl ="http://www.w3.org/2002/07/owl#"
xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd ="http://www.w3.org/2001/XMLSchema#">
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 31
( _ ) ( _ )
( . ' : ' ' ln ') ( . . )
( . . ' ln ' . . )
x x Documento Ecore y y Documento XmlRdf
y raíz rdf RDF xm s y atributo x ns
y atributo name xm s x ns prefijo
Figura 4-12: Formalización de regla 1.
La traducción de la regla 1 al lenguaje ATL se muestra en la Figura 4-13.
Figura 4-13. Regla de inicialización de documento OWL.
Para convertir el resultado de la ejecución de la regla 1 al formato XML/RDF, es necesario implementar la siguiente regla de transformación:
Regla 2: Inicializar ontología en XML/RDF. Esta regla serializa al formato XML/RDF los espacios de nombres creados por la regla 1.
Para cada documento OWL en el modelo Ecore, el nodo raíz es la cadena „rdf:RDF‟ seguida
por los espacios de nombres obtenidos, concatenando al inicio de cada espacio de nombres la
cadena „xmlns‟.
Cada nombre de espacios es un atributo en el modelo de XML, el nombre del atributo debe ser
igual a „xmlns:‟ seguido del prefijo del nombre de espacio.
El valor del atributo debe ser igual a la URI del nombre de espacio en el modelo de OWL.
La formalización de la regla 2 se muestra en la Figura 4-14.
Figura 4-14: Formalización de regla 2. La traducción de la regla 2 al lenguaje ATL se muestra en la Figura 4-15.
' : : / / . 3. /1999 / 02 / 22 #'
' : : / / . 3. / 2000 / 01/ #'
' : : / / . 3. / 2002 / 07 / #'
Sea
rdf rdf http www w org df syntas ns
rdfs rdfs http www w org rdf schema
owl owl http www w org owl
( _ ) ( _ )
( . ( , , )
x x Modelo UML y y Documento Ecore
y ns rdf rdfs owl
rule DocumentoOWL() {
to documentoOWL :OWL!DocumentoOWL (
espacioNombres<- thisModule.mapeoEspacioNombres.getKeys()->collect(e | thisModule.agregaEspacionNombres(e)))}
Lazyrule agregaEspacionNombres {
from cadena : String to espacioNombresOwl : OWL!EspacioNombres (prefijo<- cadena, URI<- thisModule.mapeoEspacioNombres.get(cadena))}
helperdef: mapeoEspacioNombres: Map(String, String) = Map { ('rdf', 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'),('rdfs', 'http://www.w3.org/2000/01/rdf-schema#'), ('owl', 'http://www.w3.org/2002/07/owl#'),('xsd', 'http://www.w3.org/2001/XMLSchema#')}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 32
Figura 4-15. Regla DocumentoOWL_en_XML/RDF
4.3.2. Encabezado de ontología
Una vez que los espacios de nombres se establecieron, normalmente se incluye una colección de argumentos relativos a la ontología. Estos argumentos deben estar agrupados dentro de la etiqueta owl:Ontology. Esta etiqueta provee el soporte de comentarios, control de versiones e inclusión de otras ontologías como se muestra en la Figura 4-16
Figura 4-16. Encabezado de ontología.
El atributo rdf:about provee un nombre o referencia para la ontología. El valor del atributo en este caso es “” pero el caso estándar es cuando el nombre de la ontología es la URI base del elemento owl:ontology. Por lo general ésta es la URI del documento que contiene la ontología. El encabezado de la ontología se cierra con la etiqueta </owl:Ontology> y finalmente la ontología completa se cierra con la etiqueta </rdf:RDF>. La regla con la cual generamos la ontología a partir de un paquete de UML es la siguiente.
Regla 3: De paquete de UML a ontología en Ecore .
Esta regla permite la transformación de un paquete en UML al nombre de una ontología en OWL con formato Ecore.
Para cada paquete en el modelo de UML le corresponde una ontología en el modelo Ecore.
o El nombre de la ontología corresponde al nombre del paquete en UML.
o El URI de la ontología es la concatenación de la cadena
“http://www.cenidet.edu.mx/”, concatenado el nombre del paquete y agregando al
final de la cadena el signo “#”.
La formalización de la regla 3 se muestra en la Figura 4-17.
rule DocumentoOWL_en_XML/RDF {
from documentoOWL : owl!DocumentoOWL
to root_rdfRdf : XML!Root (name <- 'rdf:RDF', children <- Sequence { documentoOWL.espacioNombres}) }
rule EspacionNombres_A_Atributo {
from enOWL : owl!espacioNombres
to atributoXmlns : XML!Attribute ( name <-'xmlns:'+enOWL.prefijo, value <- esOWL.URI)}
<owl:Ontology rdf:about="">
<rdfs:comment>An example OWL ontology</rdfs:comment>
<owl:priorVersion rdf:resource="http://www.w3.org/TR/2003/PR-owl-
guide-20031215/wine"/>
<owl:imports rdf:resource="http://www.w3.org/TR/2004/REC-owl-guide-
20040210/food"/>
<rdfs:label>Wine Ontology</rdfs:label>
...
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 33
( _ ) ( log _ )
( . . )
( . ' : / / . det . . / ') ( . '#')
x x paquete UML y y onto ía Ecore
y nombre x nombre
y uri http www ceni edu mx y nombre
( log _ ) ( _ )
( . ' : log ')
( _ ) ( _ )
( . ' : ')
( . . )
x x onto ía Ecore y y Documento XmlRdf
y nombre owl Onto y
y y Documento XmlRdf z z atributo XmlRdf
z nombre rdf about
z valor x uri
Figura 4-17. Formalización de regla 3. La traducción de la regla 3 al lenguaje ATL se muestra en la Figura 4-18.
Figura 4-18. Regla Paquete_A_Ontología.
Para convertir el resultado de la ejecución de la regla 3 al formato XML/RDF, es necesario implementar la siguiente regla de transformación:
Regla 4: De ontología en Ecore a ontología en OWL ( XML/RDF) Con esta regla serializamos al formato XML/RDF el resultado de la regla 3.
Para cada ontología en el modelo OWL se crea un nodo de tipo elemento en el modelo de
XML
o El nombre del elemento debe ser “owl:Ontology”.
o El elemento debe tener el atributo de nombre “rdf:about” cuyo valor es el URI de la
ontología en el modelo OWL.
La formalización de la regla 4 se muestra en la Figura 4-19.
Figura 4-19: Formalización de regla 4. La traducción de la regla 4 al lenguaje ATL se muestra en la Figura 4-20.
Figura 4-20. Regla ontologíaOWL a XML/RDF
rule Paquete_a_Ecore {
from paqueteUML : UML!Package (paqueteUML.oclIsTypeOf(UML!Package))
to ontologiaOWL : OWL!Ontologia ( nombreLocal<-paqueteUML.name, URI <- paqueteUML.asignaURI(),}
helpercontext UML!Package def: asignaURI() : String = 'http://www.cenidet.edu.mx/'+self.name+'#';
rule Ontologia_A_XML/RDF{
from ontologiaOWL : owl!Ontologia
to ontology : XML!Element ( name <- 'owl:Ontology', children <-Sequence{atributo_rdfabout} }), atributo_rdfabout : XML!Attribute (name<- 'rdf:about ', value<- ontologiaOWL.URI)}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 34
, [( _ _ )] ( _ )
( . . )
( . ' : / / . det . . ') ( . '#') ( . )
x y x paquete UML y clase UML z z clase Ecore
z nombreLocal y nombre
z uri http www ceni edu mx x nombre y nombre
4.3.3. Clases de una ontología OWL
Cada individuo en OWL es un miembro de la clase owl:Thing, por lo tanto cada clase definida por el usuario es simplemente una subclase de owl:Thing. Las clases raíz específicas de un dominio se definen simplemente declarando un nombre de clase. Una manera de definir una clase puede ser la que se muestra en la Figura 4-21.
Figura 4-21. Clases en OWL.
Nótese que sólo se dice que existen clases las cuales tienen nombre indicado por el atributo
rdf:ID=”…”. La sintaxis rdf:ID=”Región” se usa para introducir un nombre como parte de la
definición de la clase. Para referirse a la clase Región se utiliza „#Región‟, por ejemplo
rdf:resource=‟# Región‟.
Una vez definido lo anterior, la regla para crear una clase OWL a partir de una clase de UML es la
siguiente:
Regla 5: De clases en UML a clase en Ecore. Con esta regla se transforma una clase en el modelo de UML a una clase en el modelo OWL con formato Ecore.
Para cada clase en el modelo de UML se genera una clase en el modelo de OWL (Ecore).
o El nombre local de la clase en el modelo OWL es el nombre de la clase en el modelo
de UML.
o El URI de la clase en el modelo OWL es la concatenación de la cadena
“http://www.cenidet.edu.mx/” más el nombre del paquete en el modelo de UML más el
signo “#” más el nombre de la clase en el modelo de UML.
La formalización de la regla 5 se muestra en la Figura 4-22.
Figura 4-22: Formalización de regla 5. La traducción de la regla 5 al lenguaje ATL se muestra en la Figura 4-23
Figura 4-23. Regla ClaseUml_A_ClaseOwl.
rule ClaseUml_A_ClaseOwl {
from claseUML : UML!Class ((claseUML.oclIsTypeOf(UML!Class) )
to claseOWL : OWL!ClaseOWL ( nombreLocal<- claseUML.name, URI <- 'http://www.cenidet.edu.mx/'+self.name+'#' + claseUML.name )}
<owl:Class rdf:ID="Viñero"/>
<owl:Class rdf:ID="Región"/>
<owl:Class rdf:ID="AlgoConsumible"/>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 35
( _ ) ( _ )
( . ' : ')
( _ ) ( _ )
( . ' : ' '#') ( . )
( . . )
( _ ) [( _ )
x x clase Ecore y y elemento XmlRdf
y nombre owl Class
y y elemento XmlRdf z z atributo XmlRdf
z nombre rdf about x nombre
z valor x uri
y y elemento XmlRdf q q elemento XmlRdf
]
. ' : '
( _ ) ( _ )[ ]
( . . )
q Y
q nombre rdf label
q q elemento XmlRdf r r texto XmlRdf r Q
r valor x nombre
Para poder convertir el resultado de la ejecución de la regla 5 al formato XML/RDF, es necesario implementar la siguiente regla de transformación:
Regla 6: De clase en Ecore a clase en OWL ( XML/RDF).
Con esta regla se lleva a cabo la serialización al formato XML/RDF del resultado de la regla 5.
Para cada clase en el modelo OWL se crea un elemento en el modelo de XML.
o El nombre del elemento debe ser “owl:Class”
o Al elemento le debe seguir un atributo de nombre “rdf:about” más el signo “#” más
el nombre de la clase OWL.
o El elemento “owl:Class” debe tener un nodo hijo de nombre “rdfs:label” el cual a su
vez tiene como hijo un nodo de tipo texto con valor igual al nombre de la clase OWL.
La formalización de la regla 6 se muestra en la Figura 4-24.
Figura 4-24: Formalización de regla 6. La traducción de la regla 6 al lenguaje ATL se muestra en la Figura 4-25.
Figura 4-25. Regla clase OWL a XML/RDF.
4.3.4. Subclases de una ontología OWL
El constructor taxonómico fundamental para las clases en OWL es rdfs:subClassOf el cual relaciona una clase más específica a una clase más general. Si X es una subclase de Y, entonces cada instancia de X es también una instancia de Y como se muestra en la Figura 4-26.
rule ClaseOWL_A_XML/RDF {
from claseOWL : owl!ClaseOWL ( claseOWL.oclIsKindOf(owl!OWLClass) )
to elementoXML : XML!Element ( name <- 'owl:Class', children <- Sequence{
rdfAbout, rdfsLabel, textoLabel }) rdfAbout : XML!Attribute ( parent <- elementoXML, name <- 'rdf:about ', value <- '#' +
claseOWL.nombreLocal ), rdfsLabel : XML!Element ( parent <- elementoXML, name <- 'rdfs:label', children <- textoLabel ),
textoLabel : XML!Text ( name <- '#text ', value <- claseOWL.nombreLocal)}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 36
, , [( _ ( ))] , [( _ ) ( )]
( . . )
( . ' : / / . det . , / ' '#') ( . )
( . . )
x y z x clase UML y X z q z clase Ecore q Z
y nombre q nombre
q uri http www ceni edu mx x nombre
x general nombre
Figura 4-26. Subclase en OWL.
En esta regla de ejemplo se define que PotableLiquid (líquido potable) es una subclase de ConsumableThing (algo consumible). Una vez definido lo anterior, la regla para crear una subclase OWL a partir de una subclase de UML es
la siguiente:
Regla 7: De subclases en UML a subclases en Ecore.
Con esta regla se permite la transformación de subclases en un modelo de UML a subclases en un modelo OWL.
Para cada subclase del modelo UML, se debe crear una clase en el modelo OWL.
o El nombre ambas clases debe ser el mismo.
o El URI de la clase generada estará formado por la concatenación de la cadena
http://www.cenidet.edu.mx/ más el nombre del paquete en el modelo de UML más el
signo “#” más el nombre de la clase en el modelo de UML.
o Se debe especificar el nombre de la clase de la cual se genera la subclase en el
modelo de UML
La formalización de la regla 7 se muestra en la Figura 4-27. .
Figura 4-27: Formalización de regla 7. La traducción al lenguaje ATL de la regla 7 se muestra en la Figura 4-28
Figura 4-28. Regla para la generación de subclases en OWL.
Para poder convertir el resultado de la ejecución de la regla 7 al formato XML/RDF, es necesario implementar la siguiente regla de transformación:
rule ClaseUml_A_ClaseOwl {
from claseUML : UML!Class (claseUML.oclIsTypeOf(UML!Class)
to claseOWL : OWL!ClaseOWL (nombreLocal <- claseUML.name,URI <- claseUML.asignaURI() +
claseUML.name,subClassOf <-claseUML.general})}
<owl:Class rdf:ID="PotableLiquid">
<rdfs:subClassOf rdf:resource="#ConsumableThing" />
...
</owl:Class>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 37
Regla 8: De subclases en Ecore a subclases en OWL (XML/RDF)
Esta regla permite la serialización al formato XML/RDF del resultado de la regla 7
Para cada clase en el modelo OWL se crea un elemento en el modelo de XML
o El nombre del elemento debe ser “owl:Class”,
o El nodo elemento debe tener un atributo de nombre “rdf:about” como nodo hijo cuyo
valor es el signo “#” seguido del nombre de la clase.
En el caso de existir subclases, estas se toman como nodos hijos del elemento de nombre
“owl:Class”.
o las subclases son nodos de tipo elemento de nombre “rdfs:subClassOf”.
o Cada elemento de subclase debe tener un atributo de nombre “rdf:resource” y de
valor igual al signo “#” seguido por el nombre de la subclase en el modelo de UML.
o Se debe agregar un nodo de tipo texto con el valor igual al nombre de la subclase.
La formalización de la regla 8 se muestra en la Figura 4-29.
Figura 4-29: Formalización de regla 8. La traducción de la regla 1 al lenguaje ATL se muestra en la Figura 4-30.
Figura 4-30. Regla Subclase OWL a XML/RDF.
( _ ) ( _ )
( . ' : ')
( _ ) ( _ ( ))
( . ' : ')
( . '#' . )
, , [( _ ( ))] , [( _
x x clase Ecore y y elemento XmlRdf
y nombre owl Class
y y elemento XmlRdf z z atributo XmlRdf z Y
z nombre rdf about
z valor x nombre
x y z x clase UML y X z q z clase Ecor
) ( )]
, [( _ ) ( )] ( _ ( ))
. ' : '
( _ ( )) ( _ )
( . ' : ')
( . '#' . )
, [( _
e q Z
z q z clase Ecore q Z r r elemento XmlRdf r Y
r nombre rdfs subClassOf
r r elemento XmlRdf r Y z z atributo XmlRdf
z nombre rdf resource
z valor y nombre
z q z clase
) ( )] ( _ ( ))
, ( _ ) ( _ )
. .
Ecore q Z r r elemento XmlRdf r Y
x y x clase Ecore y X z z texto XmlRdf
z nombre y nombre
rule Clase_A_XML/RDF {
from claseOWL : owl!ClaseOWL ( claseOWL.oclIsKindOf(owl!ClaseOWL) ) to elementoXML : XML!Element ( name <- 'owl:Class', children <- Sequence{
claseOWL.subClassOf->select( e | e.oclIsTypeOf(owl!ClaseOWL) )->collect( e | thisModule.obtieneSubClase(claseOWL,e) ),elementoXML : XML!Element ( ), atribXML : XML!Attribute ( parent <- e, name <- 'rdf:about ', value <- '#' + claseOWL.nombreLocal ), etiqueta : XML!Element ( parent <- e, name <- 'rdfs:label', children <- texto ), texto : XML!Text ( name <- '#text ', value <-
claseOWL.nombreLocal )}
lazy rule obtieneSubClase { from claseOWL : owl!ClaseOWL, claseOWL2 : owl!ClaseOWL
to elementoXML : XML!Element ( name <- 'rdfs:subClassOf', children <- subClassAttr, parent <- claseOWL ), subClassAttr : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOWL2.nombreLocal )}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 38
( _ ) ( _ )
( . . )
x x enumeración UML y y rangoDato Ecore
y oneOf x ownedLiteral
4.3.5. Enumeración de valores de datos y literales enumeradas.
Un rango de valores de datos se puede definir como un tipo de dato enumerado. Por ejemplo, el rango de la propiedad marcadorDelJuegoDeTennis con los valores enteros {0,15,30, 40} se pueden especificar tal y como se muestra en la Figura 4-31.
Figura 4-31. Enumeración de datos en OWL.
Una vez definido lo anterior, la regla para crear una enumeración de valores de datos en OWL a partir
de una clase enumerada de UML es la siguiente:
Regla 9: De enumeración UML a enumeración en Ecore . Con esta regla se lleva a cabo la transformación de un elemento numerado en el modelo de UML a una enumeración en el modelo OWL.
Para cada enumeración (tipo de dato definido por el usuario) en el modelo de UML se crea un
rango de datos enumerado en el modelo de OWL.
o La propiedad “oneOf” del la clase de rango de datos enumerados debe tener el valor
de las literales enumeradas en el modelo de UML.
La formalización de la regla 9 se muestra en la Figura 4-32.
Figura 4-32: Formalización de regla 9.
La traducción al lenguaje ATL de la regla 9 se muestra en la Figura 4-33.
Figura 4-33. Regla Enumeración_A_ClaseEnumerada.
Para poder convertir el resultado de la ejecución de la regla 9 al formato XML/RDF, es necesario implementar la siguiente regla de transformación:
rule Enumeracion_A_ClaseEnumerada{
from enumeracionUML : UML!Enumeration
to rangoDatosEnumeradoOWL: OWL!RangoDatosEnumerados ( oneOf <- enumeracionUML.ownedLiteral)}
<owlx:DatatypeProperty owlx:name="tennisGameScore"> <owlx:range>
<owlx:OneOf> <owlx:DataValue owlx:datatype="&xsd;integer">0</owlx:DataValue> <owlx:DataValue owlx:datatype="&xsd;integer">15</owlx:DataValue> <owlx:DataValue owlx:datatype="&xsd;integer">30</owlx:DataValue>
<owlx:DataValue owlx:datatype="&xsd;integer">40</owlx:DataValue> </owlx:OneOf> </owlx:range> </owlx:DatatypeProperty
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 39
( Pr _ ) ( _ )
( . ' : Pr ')
( _ ) ( _ )
( . ' : ')
( . "#" . )
( _ ) (
x x opiedadTipoDeDato Ecore y y elemento XmlRdf
y nombre owl Datatype operty
y y elemento XmlRdf z z atributo XmlRdf
z nombre rdf about
z valor x nombre
y y elemento XmlRdf q q
_ ( ))
( . ' : ')
( _ ) ( _ )
. ' : '
. .
( _ ) ( _ ( ))
( . ' : ')
elemento XmlRdf q Y
q nombre rdfs domain
q q elemento XmlRdf r r atributo XmlRdf
r nombre rdfs resource
r valorx nombre
y y elemento XmlRdf s s elemento XmlRdf s Y
s nombre rdfs range
( _ ) ( _ ( ))
( . ' : ')
( _ ) ( _ ( ))
( . ' : ')
( _ ) ( _ ( ))
.
s s elemento XmlRdf t t elemento XmlRdf t Y
t nombre owl DataRange
t t elemento XmlRdf u u elemento XmlRdf t Y
u nombre owl OneOf
u u elemento XmlRdf v v elemento XmlRdf v Y
v val
.or EnumeratedDataRange value
Regla 10: De enumeración en Ecore a Enumeración OWL (XML/RDF)
Esta regla permite la serialización a XML/RDF del resultado del la ejecución de la regla 9.
Para cada propiedad de tipo de dato (DatatypeProperty) en el modelo de OWL, se crea un
elemento en el modelo de XML.
o El nombre del elemento debe ser “owl:DatatypeProperty”.
o El elemento debe tener un atributo de nombre “rdf:about” cuyo valor es el signo “#”
seguido del nombre de la propiedad de tipo de dato.
o El elemento “owl:DatatypeProperty” debe tener un nodo hijo de tipo elemento de
nombre “rdfs:domain”
o El elemento “rdfs:domain” debe tener un atributo de nombre “rdf:resource” con
valor igual al nombre de la clase OWL de la cual se obtiene la propiedad.
o El elemento “owl:DatatypeProperty” debe tener otro nodo hijo de tipo elemento de
nombre “rdfs:range”.
o El elemento “rdfs:range” debe tener como nodo hijo un elemento de XML de nombre
“owl:DataRange”.
o El elemento “owl:DataRange” debe tener otro hijo de tipo elemento de nombre
“owl:oneOf”
o El elemento “owl:oneOf” debe tener como nodos hijos a los elementos enumerados de
la clase Rango de Datos Enumerados (EnumeratedDataRange) en el modelo de OWL.
La formalización de la regla 10 se muestra en la Figura 4-34. .
Figura 4-34. Formalización de regla 10.
La traducción de la regla 10 al lenguaje ATL se muestra en la Figura 4-35.
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 40
( _ ) ( _ )
( . . )
( . . )
( . . ' : / / . 3. / 2001/ # ')
x x literalEnumerada UML y y valorDeDato Ecore
y valor x nombre
y tipo x valor
y y tipo y tipo http www w org XMLSchema string
Figura 4-35. Clase enumerada a XML/RDF
Regla 11: De Literal enumerada a valor de dato en Ecore Esta regla permite convertir una literal enumerada en el modelo de UML a un valor de dato en el modelo OWL
Para cada literal enumerada en el modelo de UML debe existir un valor de dato en el modelo
OWL.
o El valor del dato debe corresponder al nombre de la literal enumerada en el modelo
UML.
o El tipo de dato depende del tipo de valor que tenga la literal enumerada en caso de
que no exista algún valor automáticamente se asigna el valor:
http://www.w3.org/2001/XMLSchema#string.
La formalización de la regla 11 se muestra en la Figura 4-36. .
Figura 4-36: Formalización de regla 11. La traducción al lenguaje ATL de la regla 11 se muestra en la Figura 4-37.
rule PropiedadTipoDeDato_A_XML/RDF{
from ptd : owl!PropiedadTipoDeDato
to elementoXML : XML!Element (
name <- 'owl:DatatypeProperty', children <- Sequence{ ID, ptd.dominio->collect( e | thisModule.DominioTipoDato(ptd,e)),
ptd.range->collect( e | (e.oclIsTypeOf(owl!RangoDatosEnumerados). thisModule.RangoDatoDeTipoDatoEnumerado(ptd,e)}),
ID : XML!Attribute ( name <- 'rdf:about ', value <- '#' + ptd.nombreLocal )}
lazy rule DominioTipoDato {
from ptd : owl!PropiedadTipoDeDato, claseOWL : owl!OWLClass
to domain : XML!Element ( name <- 'rdfs:domain', children <- domain_attr, parent <- ptd ),
domain_attr : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOWL.nombreLocal ) } lazy rule RangoDatoDeTipoDatoEnumerado {
from ptd : owl!PropiedadTipoDeDato, edr : owl!RangoDatoEnumerado
to range : XML!Element ( name <- 'rdfs:range', children <- range_attr, parent <- ptd), range_attr : XML!Element ( name <- 'owl:DataRange', children <- oneOf ),
oneOf : XML!Element ( name <- 'owl:oneOf', children <- edr.oneOf)}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 41
( _ ) ( _ )
( . ' : ')
( _ ) ( _ )
( . ' : ')
( . . )
( _ ) ( _ )
( .
x x valorDeDato Ecore y y elemento XmlRdf
y nombre owl DataValue
y y elemento XmlRdf z z atributo XmlRdf
z nombre rdf datatype
z valor x uri
y y elemento XmlRdf q q texto XmlRdf
q val
.or x valor
Figura 4-37. Regla LiteralEnumerada_A_valor de dato.
Para poder convertir el resultado de la ejecución de la regla 11 al formato XML/RDF, es necesario implementar la siguiente regla de transformación: Regla 12: De valor de dato en Ecore a valor de dato OWL ( XML/RDF) Esta regla permite la serialización al formato XML/RDF del resultado de la ejecución de la regla 11.
Para cada valor de dato (DataValue) en el modelo OWL se crea un elemento de XML.
o El nombre del elemento debe ser “owl:DataValue” .
o El elemento “owl:DataValue” debe tener un atributo de nombre “rdf:datatype” cuyo
valor corresponde al URI del tipo de dato en el modelo de OWL.
o El elemento “owl:DataValue” debe tener otro nodo hijo de tipo texto cuyo valor es
igual al valor del dato en el modelo OWL.
La formalización de la regla 12 se muestra en la Figura 4-38.
Figura 4-38: Formalización de regla 12. La traducción de la regla 12 al lenguaje ATL se muestra en la Figura 4-39.
Figura 4-39. Regla valor de dato OWL a XML/RDF.
rule LiteralEnumerada_A_TipoDeDato {
from literalEnumerada : UML!EnumerationLiteral
to valorDeDatoOWL : OWL!ValorDeDato ( value <- literalEnumerada.name, type <- thisModule.T ipoDatoUML_A_TipoDatoOWL(thisModule.tiposPrimitivos->any(e | e.name = 'String')),)
} lazy rule TipoDatoUML_A_TipoDatoOWL {
from t ipoDatoUML : UML!DataType
to t ipoDatoOWL : OWL!TipoDeDato ( URI <-
if (t ipoDatoUML.name.oclIsUndefined()) then 'http://www.w3.org/2001/XMLSchema#string' endif)}
rule ValorDeDato_A_Elemento {
from
valorDato : owl!ValorDeDato
to
elementoXML : XML!Element (
name <- 'owl:DataValue',children <- Sequence{ atributoXML, textoXML }),
atributoXML : XML!Attribute ( name <- 'rdf:datatype',value <- valorDato.tipo.URI),
textoXML : XML!Text ( name <- '#text',value <- valorDato.valor)}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 42
4.3.6. Propiedades en OWL.
Una propiedad en OWL es una relación binaria. Se distinguen dos tipos de propiedades:
Propiedades de objeto (Object Properties) que son aquellas relaciones entre instancias de dos
clases.
Propiedades de tipo de dato (Datatype Properties) que son aquellas relaciones entre instancias
de clases y literales de RDF y esquemas de tipo de dato de XML.
4.3.6.1. Propiedad de objeto. Cuando se define una propiedad existen varias maneras de restringir la relación. El dominio y el rango se especifican. La propiedad se puede definir como una especialización (subpropiedad) de una propiedad existente.
Figura 4-40. Propiedad objeto. La propiedad madeFromGrape (hechoDeUva-Figura 4-40) tiene como dominio a Wine (vino) y como rango a WineGrape (UvaDeVino) con lo cual se relaciona las instancias de la clase Wine con las instancias de la clase WineGrape. Una vez definido lo anterior, la regla para crear una propiedad de objeto en OWL a partir de relación
entre clases de UML es la siguiente:
Regla 13: De propiedad UML a propiedad de objeto en Ecore Con esta regla de transformación es posible la obtención de una propiedad en el modelo de UML a una propiedad de objeto de OWL
Para cada asociación entre clases del modelo de UML se crea una propiedad de objeto en el
modelo OWL.
o La propiedad de objeto tiene como nombre el mismo nombre que la asociación en el
modelo de UML.
o El URI de la propiedad de objeto es igual al URI de la clase de la cual se origina la
asociación agregando el nombre de la asociación.
o La propiedad es funcional cuando la cardinalidad en ambos extremos de la asociación
es igual a 1.
o La propiedad es inversa funcional cuando la cardinalidad máxima en la asociación es
igual a 1.
o La propiedad es simétrica si el dominio y el rango son los mismos.
La formalización de la regla 13 se muestra en la Figura 4-41.
<owl:ObjectProperty rdf:ID="madeFromGrape"> <rdfs:domain rdf:resource="#Wine"/> <rdfs:range rdf:resource="#WineGrape"/>
</owl:ObjectProperty>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 43
Figura 4-41: Formalización de regla 13. La traducción al lenguaje ATL de la regla 13 se muestra en la Figura 4-42.
Figura 4-42. Regla PropiedadUML_A_PropiedadObjeto.
Para poder convertir el resultado de la ejecución de la regla 13 al formato XML/RDF, es necesario implementar la siguiente regla de transformación:
Regla 14: De propiedad de objeto en Ecore a propiedad de objeto OWL (XML/RDF) Con esta regla se lleva a cabo la serialización al formato XML/RDF del resultado de la ejecución de la regla 13.
Para cada propiedad de objeto en el modelo de OWL se genera un nodo elemento en el
modelo de XML.
o El nombre del elemento creado es „owl:ObjectProperty‟ seguido de un atributo de
nombre “rdf:about” cuyo valor es el signo “#” seguido por el nombre de la propiedad
de objeto.
o El elemento “owl:ObjectProperty” debe tener un elemento de nombre “rdfs:domain”
más un atributo de nombre “rdf:resource” cuyo valor es el signo “#” seguido del
nombre de la clase OWL origen.
o El elemento “owl:ObjectProperty” debe tener otro nodo elemento de XML de nombre
“rdfs:range” junto con un atributo de nombre “rdf:resource” cuyo valor es el signo
“#” seguido del nombre de la Clase OWL destino.
La formalización de la regla 14 se muestra en la Figura 4-43.
( _ ) ( _ )
( . . )
( . . . '#' . )
( . ) [( . 1 . 1)]
( . ) [( . 1 . 1)
( .
x x propiedad UML y y propiedadObjeto Ecore
y nombre x nombre
y uri x general uri x nombre
y esFuncional x upper x lower
y esFuncionalInversa x upper x lower
y esSimetri
) [( . )ca x tipo
rule PropiedadUML_A_PropiedadObjeto {
from propiedadUML : UML!Property
using { uri : String =
if (thisModule.mapeoPropiedadDominio.get(propiedadUML).oclIsTypeOf(UML!Class)) then thisModule.mapeoPropiedadDominio.get(propiedadUML). asignaURI() + propiedadUML.name
endif;}
to propiedadObjetoOWL : OWL!PropiedadDeObjeto ( nombreLocal <- propiedadUML.name, URI <- uri, esFuncional <- ((propiedadUML.upper = 1) and (propiedadUML.lower = 1)),
esFuncionalInversa <- propiedadUML.esFuncionalInversa(),
esSimetrica <- propiedadUML.esSimetrica()}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 44
rule PropiedadObjeto_A_XML/RDF {
from po : owl!PropiedadDeObjeto (po.oclIsTypeOf(owl!PropiedadDeObjeto) )
to e lemento: XML!Element ( name <- 'owl:ObjectProperty', children <- Sequence{ID,po.domain->collect( e | thisModule.DominioDeObjecto(po,e)),
po.range->collect( e | thisModule.RangoDeObjeto(po,e) )}),ID : XML!Attribute ( name <- 'rdf:about ', value <- '#' +p o.nombreLocal )} lazy rule DominioDeObjecto {
from op : owl!PropiedadDeObjeto, c laseOwl: owl!ClaseOWL
to dominio : XML!Element ( name <- 'rdfs:domain', children <- dominio _attr, parent <- op ), dominio _attr : XML!Attribute ( name <- 'rdf:resource', value <- '#' + laseOwl.nombreLocal )} lazy rule RangoDeObjeto {
from op : owl!PropiedadDeObjeto, claseOwl : owl!ClaseOWL
to rango : XML!Element ( name <- 'rdfs:range', children <- rango _attr, parent <- op ),
rango _attr : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOwl.nombreLocal )}
Figura 4-43: Formalización de regla 14. La traducción de la regla 14 al lenguaje ATL se muestra en la Figura 4-44.
Figura 4-44. Regla propiedad de objeto a XML/RDF.
4.3.6.2. Propiedad de tipo de dato. Es posible distinguir las propiedades de acuerdo a si relacionan clases a clases (propiedades de objeto) o si relacionan clases a tipos de datos (propiedades de tipos de datos). Las propiedades de tipo de datos abarcan literales RDF o tipos simples definidos de acuerdo al esquema de tipo de datos de XML (XML Schema datatypes) tal como se muestra en la Figura 4-45.
Figura 4-45. Tipos de datos en OWL.
La propiedad valorDeAño relaciona a AñosDeCosecha a un valor entero positivo. La Tabla 3 muestra los tipos de datos utilizados en este proyecto de investigación.
( _ ) , ( _ _ )
( . ' : Pr ') ( . ' : ')
( . '#' . )
( _ ) , (( _
x x propiedadObjeto Ecore y z y elemento XmlRdf z atributo XmlRdf
y nombre owl Object operty z nombre rdf about
z valor x nombre
y y elemento XmlRdf q r q elemento XmlRdf r atribut
_ ) ( , )
( . ' : ') ( . ' : ')
( . "#" . )
( _ ) , (( _ _ ) ( , )
( . ' : ') ( . ' :
o XmlRdf q r Y
q nombre rdfs domain r nombre rdf resource
r valor y domain
y y elemento XmlRdf s t s elemento XmlRdf t atributo XmlRdf s t Y
s nombre rdfs range t nombre rdf
')
( . "#" . )
resource
t valor y range
<owl:Class rdf:ID="AñoDeCosecha" /> <owl:DatatypeProperty rdf:ID="valorDeAño"> <rdfs:domain rdf:resource="#AñoDeCosecha" /> <rdfs:range rdf:resource="&xsd;positiveInteger"/>
</owl:DatatypeProperty>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 45
Tipo dato en UML URI en el modelo OWL String http://www.w3.org/2001/XMLSchema#String
Integer http://www.w3.org/2001/XMLSchema#nonNegativeInteger
Boolean http://www.w3.org/2001/XMLSchema#boolean
UnlimitedNatural http://www.w3.org/2001/XMLSchema#integer
Byte http://www.w3.org/2001/XMLSchema#byte
Currency http://www.w3.org/2001/XMLSchema#decimal
Date http://www.w3.org/2001/XMLSchema#date
Double http://www.w3.org/2001/XMLSchema#double
Long http://www.w3.org/2001/XMLSchema#long
Single http://www.w3.org/2001/XMLSchema#short
Variant http://www.w3.org/2001/XMLSchema#string
Tabla 3. Tipos de datos OWL.
Una vez que se ha definido lo anterior, la regla para crear una propiedad de tipo de dato en OWL a
partir de un atributo de UML es la siguiente:
Regla 15: De propiedad UML a propiedad de tipo de dato en Ecore
Con esta regla de transformación se obtiene un tipo de dato en el modelo de OWL a partir de una propiedad en el modelo de UML.
Para cada atributo en la clase del modelo de UML se crea una propiedad de tipo de dato en el
modelo de OWL.
o El nombre de la propiedad es el nombre del atributo en la clase de UML.
o El URI de la propiedad en el modelo OWL se obtiene al concatenar la cadena
“http://www.cenidet.edu.mx” más el nombre de la propiedad en el modelo de UML.
La formalización de la regla 15 se muestra en la Figura 4-46.
Figura 4-46: Formalización de regla 15. La traducción al lenguaje ATL de la regla 15 se muestra en la Figura 4-47.
Figura 4-47. Regla PropiedadUML_A_PropiedadTipoDeDato.
Para poder convertir el resultado de la ejecución de la regla anterior en formato XML/RDF, es necesario implementar la siguiente regla de transformación:
( _ ) ( _ )
. .
. ' : / / . det . . ' "#" .
x x propiedad UML y y propiedadTipoDeDato Ecore
y nombre x nombre
y uri http www ceni edu mx x nombre
rule PropiedadUML_A_PropiedadTipoDeDato{
from propiedadUML : UML!Property (
to propiedadTipodatoOWL : OWL!PropiedadTipoDeDato (
nombreLocal <- propiedadUML.name,
URI <- propiedadUML. asignaURI() + propiedadUML.name,)}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 46
( _ ) ( _ )
( _ ) ( _ )
( . ' : Pr ') ( . ' : ')
( . "#" . )
( _ ) ,
x x propiedadTipoDeDato Ecore y y elemento XmlRdf
y y elemento XmlRdf z z atributo XmlRdf
y nombre owl Datatype operty z nombre rdf about
z valor x nombre
y y elemento XmlRdf q r
(( _ _ ) ( , )
( . ' : ') ( . ' : ')
( . "#" . )
( _ ) , (( _ _ ) ( , )
( .
q elemento XmlRdf r atributo XmlRdf q r Y
q nombre rdfs domain r nombre rdfs resource
r valor y domain
y y elemento XmlRdf s t s elemento XmlRdf t atributo XmlRdf s t Y
s nombre
' : ') ( . ' : ')
( . _ . )
rdfs range t nombre rdfs resource
r valor rangoDato Ecore uri
Regla 16: De propiedad de tipo de dato en Ecore a OWL (XML/RDF)
Con esta regla se lleva a cabo la serialización al formato XML/RDF del resultado de la ejecución de la regla 15.
Para cada propiedad de tipo de dato en el modelo de OWL se genera un elemento en el
modelo de XML
o El nombre del elemento debe ser „owl:DatatypeProperty‟.
o El elemento „owl:DatatypeProperty‟ debe tener un atributo de nombre “rdf:about”
cuyo valor es el signo “#” seguido del nombre de la propiedad de tipo de dato.
o El elemento „owl:DatatypeProperty‟ tiene como nodos hijos un elemento de nombre
“rdfs:domain” y otro de nombre “rdfs:range”.
o El elemento “rdfs:domain” debe tener un atributo de nombre “rdfs:resource” cuyo
valor es el signo “#” seguido del nombre de la clase OWL de la cual depende la
propiedad de tipo de dato.
o El elemento“rdfs:range” debe tener un atributo de nombre “rdfs:resource” y cuyo
valor es el URI de la clase rango de dato (DataRange) del modelo OWL.
o Los elementos “rdfs:domain” y “rdfs:range” deben tener como nodo padre la
propiedad al elemento “owl:DatatypeProperty”.
La formalización de la regla 16 se muestra en la Figura 4-48.
Figura 4-48. Formalización de regla 16.
La traducción de la regla 16 al lenguaje ATL se muestra en la Figura 4-49.
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 47
rule PropiedadTipoDeDato_A_XML/RDF {
from propiedadDato : owl!PropiedadTipoDeDato
to elementoXML : XML!Element (name <- 'owl:DatatypeProperty',children <- Sequence{
atributoXML, propiedadDato.dominio->collect( e | thisModule.DominioTipoDato(propiedadDato,e)), propiedadDato.range->collect( e | thisModule.RangoTipoDato(propiedadDato,e)) } ), atributoXML : XML!Attribute ( name <- 'rdf:about ', value <- '#' + propiedadDato.nombreLocal )}
lazy rule DominioTipoDato { from propiedadDato : owl!PropiedadTipoDeDato, claseOwl : owl!ClaseOWL
to dominio : XML!Element ( name <- 'rdfs:domain', children <- dominio_attr, parent <- propiedadDato ), dominio_attr : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOwl.nombreLocal )} lazy rule RangoTipoDato {
from propiedadDato : owl!PropiedadTipoDeDato, rangoDatos : owl!RangoDeDatos
to rangoElemento : XML!Element ( name <- 'rdfs:range', children <- rango_atributo, parent <- propiedadDato),
rango_atributo : XML!Attribute ( name <- 'rdf:resource', value <- rangoDatos.URI )}
Figura 4-49. Regla propiedad tipo de dato OWL a XML/RDF.
4.3.7. Cardinalidad
En OWL así como en RDF se asume que una instancia de una clase puede tener un número arbitrario (cero o más) de valores para una propiedad en particular. Para hacer que una propiedad requiera especificar un número de valores para esa propiedad se utilizan las restricciones de cardinalidad. OWL proporciona tres constructores (cardinalidad simple, mínima y máxima) para restringir la cardinalidad de las propiedades.
4.3.7.1. Cardinalidad simple La restricción de cardinalidad owl:cardinality permite la especificación de “exactamente” el número de elementos en la relación. Por ejemplo, la clase Cosecha tiene exactamente un AñoDeCosecha como se muestra en la Figura 4-50.
Figura 4-50. Restricción de cardinalidad en OWL. Al usar la restricción de cardinalidad se afirma que cada Cosecha tiene exactamente un AñoDeCosecha.
Una vez definido lo anterior, la regla para crear una restricción de cardinalidad en OWL a partir de una
relación con cardinalidad simple en UML es la siguiente:
Regla 17: De multiplicidad simple en UML a cardinalidad en Ecore
Con esta regla de transformación se obtiene una restricción de cardinalidad en OWL a partir de una restricción de cardinalidad en el modelo de UML
<owl:Class rdf:ID="Cosecha"> <rdfs:subClassOf> <owl:Restriction>
<owl:onProperty rdf:resource="#tieneAñoDeCosecha"/> <owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf>
</owl:Class>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 48
( _ ) ( _ )
. Pr .
. .
x x propiedad UML y y restriccionCardinalidad Ecore
y en opiedad x nombre
y cardinalidad x upper
Para cada clase en el modelo de UML con alguna propiedad (atributo o relación) se genera
una restricción de cardinalidad en el modelo de OWL .
o La restricción de cardinalidad debe hacer relación al nombre de la propiedad en el
modelo de UML, se debe especificar el origen de la propiedad en el modelo de UML,
la propiedad cardinality de la restricción creada tiene el valor entero de la
multiplicidad de mayor valor en la propiedad.
La formalización de la regla 16 se muestra en la Figura 4-51.
Figura 4-51. Formalización de regla 17.
La traducción al lenguaje ATL de la regla 17 se muestra en la Figura 4-52.
Figura 4-52. Regla restricción de cardinalidad.
Para poder convertir el resultado de la ejecución de la regla 17 al formato XML/RDF, es necesario implementar la siguiente regla de transformación:
Regla 18: De cardinalidad en Ecore a cardinalidad en OWL (XML/RDF) Con esta regla de transformación se lleva a cabo la serialización al formato XML/RDF del resultado de la ejecución de la regla 17.
Para cada clase en el modelo de OWL se crea un elemento en el modelo de XML.
o El nombre del elemento debe ser “owl:Class”
o El elemento debe tener un atributo de nombre “rdf:about” cuyo valor es el signo “#”
seguido del nombre de la clase en el modelo de OWL.
o Se debe crear otro nodo de tipo elemento en el modelo XML de nombre
“rdfs:subClassOf”.
o Un nodo de hijo de tipo elemento se debe crear para el elemento “owl:Class” el
nombre de este elemento debe ser “owl:Restriction”.
rule ClaseUml_A_ClaseOwl {
from claseUML : UML!Class ((claseUML.oclIsTypeOf(UML!Class))
using {cardinalidad : Sequence(UML!Property) = claseUML.attribute->select(e | e.esCardinalidad) }
to claseOWL : OWL!ClaseOWL (nombreLocal<- claseUML.name,URI <- claseUML asignaURI() + claseUML.name,
subClaseDe<- Sequence{claseUML.general,cardinalidad->collect(e | thisModule.restriccionDeCardinalidad(e)), })} lazyrule restriccionDeCardinalidad {
from propiedadUML: UML!Property
to restriccionCardinalidadOWL : OWL!RestriccionCardinalidad( enPropiedad<- hisModule.mapeoDePropiedades.getKeys()->any(e | e.name = propiedadUML.name), subClase<- thisModule.mapeoPropiedadDominio.get(propiedadUML),cardinalidad<-
propiedadUML.upper)}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 49
( _ ) , ( , _ )
( _ ) ( _ )
( . ' : ')
( _ ) ( _ )
. ' : '
( . '#' .
w w clase Ecore x y x y elemento XmlRdf
z z restriccionCardinalidad Ecore q q elemento XmlRdf
x nombre owl Class
x x elemento XmlRdf r r atributo XmlRdf
r nombre rdf about
r valor w
)
. ' : '
( _ ) ( _ ( ))
( . ' : Re ')
( _ ) , ( , _ ( , ))
, ( , _ ) , ( ,
nombre
y nombre rdfs subClassOf
x x elemento XmlRdf s s elemento XmlRdf s X
s nombre owl striction
s s elemento XmlRdf t u t u elemento XmlRdf t u S
t u t u elemento XmlRdf o p o p
_ )
( . ' : Pr ') ( . ' : ') ( . '#' . Pr )
( . ' : ') ( . ' : ') ( . . )
( _
atributo XmlRdf
t nombre owl on operty o nombre rdf resource o valor x on operty
u nombre owl cardinality p nombre rdf datatype p valor x uri
z z restriccionCardinalidad Ecore
) ( _ )
( . . )
v v texto XmlRdf
v valor z cardinality
o El elemento “owl:Restriction” tiene a su vez otros nodos hijos de nombre
“owl:onProperty” junto con un atributo de nombre “rdf:resource” cuyo valor es el
signo “#” seguido por el nombre de la propiedad.
o Otro elemento hijo del nodo “owl:Restriction” es un elemento de nombre
“owl:cardinality” seguido del atributo de nombre “rdf:datatype” cuyo valor es el URI
de la propiedad.
o Se debe agregar un nodo de tipo texto cuyo valor es la cardinalidad de la propiedad.
La formalización de la regla 18 se muestra en la Figura 4-53
Figura 4-53. Formalización de regla 18.
La traducción de la regla 18 al lenguaje ATL se muestra en la Figura 4-54.
Figura 4-54. Regla restricción de cardinalidad a XML/RDF.
4.3.7.2. Cardinalidad mínima La expresión owl:minCardinality enlaza una restricción a un valor de dato perteneciente a un valor del espacio de nombres del esquema de tipo de datos de XML nonNegativeInteger (entero no negativo).
rule ClaseOWL_A_XML/RDF {
from claseOWL : owl!ClaseOWL ( claseOWL.oclIsKindOf(owl! ClaseOWL) )
to elementoXML : XML!Element ( name <- 'owl:Class', children <- Sequence{ rdfAbout, rdfsLabel, textoLabel}
claseOWL.subClaseDe->select( subclase | subclase.oclIsTypeOf(owl!RestriccionCardinalidad) )->collect( restCard| thisModule.hacerRestriccionDeCardinalidad(claseOWL,restCard) ),})
rdfAbout : XML!Attribute ( parent <- elementoXML, name <- 'rdf:about ', value <- '#' + claseOWL.nombreLocal ), rdfsLabel : XML!Element ( parent <- elementoXML, name <- 'rdfs:label', children <- textoLabel ), textoLabel : XML!Text ( name <- '#text ', value <- claseOWL.nombreLocal ) }
lazy rule hacerRestriccionDeCardinalidad {
from claseOwl : owl!ClaseOWL, restCard : owl!RestriccionCardinalidad
to elementoXML : XML!Element ( name <- 'rdfs:subClassOf', children <- elementoXML2, parent <- claseOwl),
elementoXML2 : XML!Element ( name <- 'owl:Restriction', children <- Sequence{on, card} ), elemOnproperty : XML!Element ( name <- 'owl:onProperty', children <- atribOnpropert ),
atribOnpropert : XML!Attribute ( name <- 'rdf:resource', value <- '#' + restCard.onProperty.nombreLocal ), elemCard : XML!Element ( name <- 'owl:cardinality ', children <- Sequence{atribCard ,textoCard } ), atribCard : XML!Attribute ( name <- 'rdf:datatype', value <- restCard.obtieneURITipodato() ), textoCard : XML!Text ( name <- '#text ', value <- restCard.cardinalidad.toString() )}
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 50
Owl:minCardinality puede ser utilizada para especificar un límite inferior en la restricción de cardinalidad. En la Figura 4-55 se muestra una clase de individuos que tienen al menos dos padres:
Figura 4-55. Restricción de cardinalidad mínima en OWL. Una vez que se ha definido la cardinalidad mínima en OWL la siguiente regla es utilizada para crear restricciones de cardinalidad mínima a partir de restricciones de cardinalidad mínima en UML.
Regla 19: De multiplicidad mínima en UML a cardinalidad Mínima en Ecore Con esta regla de transformación se obtiene una restricción de cardinalidad mínima en el modelo OWL a partir de una restricción de cardinalidad mínima en el modelo de UML
Para cada clase en el modelo de UML con alguna propiedad (atributo o relación) se genera
una restricción de cardinalidad en el modelo de OWL . La restricción de cardinalidad debe
hacer relación al nombre de la propiedad en el modelo de UML, se debe especificar el origen
de la propiedad en el modelo de UML, la propiedad mincardinality de la restricción creada
tiene el valor entero de la multiplicidad de menor valor en la propiedad.
La formalización de la regla 19 se muestra en la Figura 4-56.
Figura 4-56. Formalización de regla 19.
La traducción al lenguaje ATL de la regla 19 se muestra en la Figura 4-57.
Figura 4-57. Regla restricción de cardinalidad mínima.
rule ClaseUml_A_ClaseOwl {
from claseUML : UML!Class (claseUML.oclIsTypeOf(UML!Class) using {cardinalidadMinima : Sequence(UML!Property) = atributos->select(e | e.esCardinalidadMinima())->union(referencias->select(e | e.esCardinalidadMinima())); }
To claseOWL : OWL!ClaseOWL ( nombreLocal<- claseUML.name, URI <- claseUML.refImmediateComposite().asignaURI() + claseUML.name,subClaseDe<- Sequence{claseUML.general, cardinalidadMinima->collect(e| thisModule.restriccionCardinalidadMinima(e)),
cardinalidad->collect(e | thisModule.restriccionDeCardinalidadMinima(e)), referencias->collect(e | thisModule.todosValoresDeRestriccionDeClase(e))})} lazyrule restriccionCardinalidadMinima {
from propiedadUML : UML!Property
to restriccionCardinalidadMinimaOWL : OWL!RestriccionCardinalidadMinima(
enPropiedad<- thisModule.mapeoDePropiedades.getKeys()->any(e | e.name = propiedadUML.name), subClase<- thisModule.mapeoPropiedadDominio.get(propiedadUML), cardinalidadMinima<- propiedadUML.lower}
<owl:Restriction>
<owl:onProperty rdf:resource="#hasParent" /> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:minCardinality> </owl:Restriction>
( _ ) ( _ )
. Pr .
. .
x x propiedad UML y y restriccionCardinalidadMinima Ecore
y en opiedad x nombre
y cardinalidad x lower
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 51
( _ ) , ( , _ )
( _ ) ( _ )
( . ' : ')
( _ ) ( _ )
. ' : '
( .
w w clase Ecore x y x y elemento XmlRdf
z z restriccionCardinalidadMinima Ecore q q elemento XmlRdf
x nombre owl Class
x x elemento XmlRdf r r atributo XmlRdf
r nombre rdf about
r valor
'#' . )
. ' : '
( _ ) ( _ ( ))
( . ' : Re ')
( _ ) , ( , _ ( , ))
, ( , _ ) ,
w nombre
y nombre rdfs subClassOf
x x elemento XmlRdf s s elemento XmlRdf s X
s nombre owl striction
s s elemento XmlRdf t u t u elemento XmlRdf t u S
t u t u elemento XmlRdf o
( , _ )
( . ' : Pr ') ( . ' : ') ( . '#' . Pr )
( . ' : min ') ( . ' : ') ( . . )
(
p o p atributo XmlRdf
t nombre owl on operty o nombre rdf resource o valor x on operty
u nombre owl cardinality p nombre rdf datatype p valor x uri
z z restriccionCardinali
_ ) ( _ )
( . .min )
dadMinima Ecore v v texto XmlRdf
v valor z cardinality
A continuación se muestra la regla necesaria en el lenguaje ATL con el fin de serializar al formato XML/RDF una clase que se relacione con otra clase mediante una cardinalidad mínima en el modelo OWL en formato “Ecore”.
Regla 20: De cardinalidad mínima en Ecore a cardinalidad mínima OWL (XML/RDF) Con esta regla de transformación se lleva a cabo la serialización al formato XML/RDF del resultado de la ejecución de la regla 19.
Para cada clase en el modelo de OWL se crea un elemento en el modelo de XML.
o El nombre del elemento debe ser “owl:Class”
o El elemento debe tener un atributo de nombre “rdf:about” cuyo valor es el signo “#”
seguido del nombre de la clase en el modelo de OWL.
o Se debe crear otro nodo de tipo elemento en el modelo XML de nombre
“rdfs:subClassOf”.
o Un nodo de hijo de tipo elemento se debe crear para el elemento “owl:Class” el
nombre de este elemento debe ser “owl:Restriction”.
o El elemento “owl:Restriction” tiene a su vez otros nodos hijos de nombre
“owl:onProperty” junto con un atributo de nombre “rdf:resource” cuyo valor es el
signo “#” seguido por el nombre de la propiedad.
o Otro elemento hijo del nodo “owl:Restriction” es un elemento de nombre
“owl:minCardinality” seguido del atributo de nombre “rdf:datatype” cuyo valor es el
URI de la propiedad.
o Se debe agregar un nodo de tipo texto cuyo valor es la cardinalidad mínima de la
propiedad.
La formalización de la regla 20 se muestra en la Figura 4-58.
Figura 4-58. Formalización de regla 20.
La traducción de la regla 20 al lenguaje ATL se muestra en la Figura 4-59.
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 52
Figura 4-59. Regla cardinalidad mínima a XML/RDF.
4.3.7.3. Cardinalidad máxima La expresión owl:maxCardinality enlaza una restricción a un valor de dato perteneciente a un valor del espacio de nombres del esquema de tipo de datos de XML nonNegativeInteger (entero no negativo). Owl:maxCardinality puede ser utilizada para especificar un límite superior en la restricción de cardinalidad. La Figura 4-60 muestra un ejemplo que describe una clase de individuos que tienen a lo más dos padres:
Figura 4-60. Restricción de cardinalidad máxima en OWL.
Una vez que se ha definido la cardinalidad máxima en OWL la siguiente regla es utilizada para crear restricciones de cardinalidad máxima a partir de restricciones de multiplicidad máxima en UML.
Regla 21: De multiplicidad máxima en UML a cardinalidad máxima en Ecore Con esta regla de transformación se obtiene una restricción de cardinalidad máxima en el modelo OWL a partir de una restricción de cardinalidad máxima en el modelo de UML
Para cada clase en el modelo de UML con alguna propiedad (atributo o relación) se genera
una restricción de cardinalidad máxima en el modelo de OWL .
o La restricción de cardinalidad máxima debe hacer relación al nombre de la
propiedad en el modelo de UML, se debe especificar el origen de la propiedad en el
modelo de UML, la propiedad maxCardinality de la restricción creada tiene el valor
entero de la multiplicidad de mayor valor en la propiedad.
rule ClaseOWL_A_XML/RDF {
from claseOWL : owl!ClaseOWL ( claseOWL.oclIsKindOf(owl!ClaseOWL) )
to elementoXML : XML!Element ( name <- 'owl:Class', children <- Sequence{ rdfAbout, rdfsLabel, textoLabel
claseOWL.subClaseDe->select( subclase | subclase.oclIsTypeOf(owl!RestriccionCardinalidadMinima) )->collect( restCardMin| thisModule.hacerRestriccionDeCardinalidadMinima(claseOWL,restCardMin) ),}) rdfAbout : XML!Attribute ( parent <- elementoXML, name <- 'rdf:about ', value <- '#' + claseOWL.nombreLocal ),
rdfsLabel : XML!Element ( parent <- elementoXML, name <- 'rdfs:label', children <- textoLabel ), textoLabel : XML!Text ( name <- '#text ', value <- claseOWL.nombreLocal ) } lazyrule hacerRestriccionDeCardinalidadMinima {
from claseOWL : owl!ClaseOWL, restriccionCardinalidadMinima : owl!RestriccionCardinalidadMinima
to elementoRdfsSubclassOf : XML!Element ( name <- 'rdfs:subClassOf', children <- elementoOwlRestriction, parent <- claseOWL ),
elementoOwlRestriction : XML!Element ( name <- 'owl:Restriction', children <- Sequence{elementoOwlOnProperty, elementoOwlMinCardinality} ), elementoOwlOnProperty : XML!Element ( name <- 'owl:onProperty', children <- atributoOnProperty ), atributoOnProperty : XML!Attribute ( name <- 'rdf:resource', value <- '#' + restriccionCardinalidadMinima.onProperty.nombreLocal ),
elementoOwlMinCardinality : XML!Element ( name <- 'owl:minCardinality ', children <- Sequence{atributoMinCardinalityDatatype, textoMinCardinality} ), atributoMinCardinalityDatatype : XML!Attribute ( name <- 'rdf:datatype', value <-
restriccionCardinalidadMinima.obtieneURITipodato() ), textoMinCardinality : XML!Text ( name <- '#text ', value <- restriccionCardinalidadMinima.cardinalidaMinima.toString() )}
<owl:Restriction> <owl:onProperty rdf:resource="#tienePadres" />
<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">2</owl:maxCardinality> </owl:Restriction>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 53
La formalización de la regla 21 se muestra en la Figura 4-61.
Figura 4-61. Formalización de regla 21. La traducción al lenguaje ATL de la regla 21 se muestra en la Figura 4-62.
Figura 4-62. Regla Restricción de cardinalidad máxima.
Con el fin de serializar al formato XML/RDF el resultado de la ejecución de la regla 21, se estableció la siguiente regla de transformación.
Regla 22: De cardinalidad máxima en Ecore a cardinalidad Máxima en OWL (XML/RDF) Con esta regla de transformación se lleva a cabo la serialización al formato XML/RDF del resultado de la ejecución de la regla 21.
Para cada clase en el modelo de OWL se crea un elemento en el modelo de XML.
o El nombre del elemento debe ser “owl:Class”
o El elemento debe tener un atributo de nombre “rdf:about” cuyo valor es el signo “#”
seguido del nombre de la clase en el modelo de OWL.
o Se debe crear otro nodo de tipo elemento en el modelo XML de nombre
“rdfs:subClassOf”.
o Un nodo de hijo de tipo elemento se debe crear para el elemento “owl:Class” el
nombre de este elemento debe ser “owl:Restriction”.
rule ClaseUml_A_ClaseOwl {
from claseUML : UML!Class (claseUML.oclIsTypeOf(UML!Class)
using { cardinalidadMinima
cardinalidadMaxima : Sequence(UML!Property) = atributos->select(e | e.esCardinalidadMaxima())->union(referencias->select(e | e.esCardinalidadMaxima())); }
to claseOWL : OWL!ClaseOWL ( nombreLocal<- claseUML.name, URI <- claseUML.refImmediateComposite().asignaURI() + claseUML.name, subClaseDe<- Sequence{claseUML.general, cardinalidadMinima->collect(e|
thisModule.restriccionCardinalidadMaxima(e)),cardinalidadMaxima->collect(e | thisModule.restriccionCardinalidadMaxima(e)),)})
}
lazyrule restriccionCardinalidadMaxima {
from propiedadUML : UML!Property
to restriccionCardinalidadMaxOWL : OWL!RestriccionCardinalidadMaxima (
enPropiedad<- thisModule.mapeoDePropiedades.getKeys()->any(e | e.name = propiedadUML.name), subClase<- thisModule.mapeoPropiedadDominio.get(propiedadUML), cardinalidadMaxima<- propiedadUML.upper)}
( . . ) ( _ )
. .
. .
x x ClaseUML atributo x ClasesUML relacion y y restriccionCardinalidadMaxima Ecore
y domain x nombre
y cardinalidad x upper
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 54
o El elemento “owl:Restriction” tiene a su vez otros nodos hijos de nombre
“owl:onProperty” junto con un atributo de nombre “rdf:resource” cuyo valor es el
signo “#” seguido por el nombre de la propiedad.
o Otro elemento hijo del nodo “owl:Restriction” es un elemento de nombre
“owl:maxCardinality” seguido del atributo de nombre “rdf:datatype” cuyo valor es el
URI de la propiedad.
o Se debe agregar un nodo de tipo texto cuyo valor es la cardinalidad máxima de la
propiedad.
La formalización de la regla 22 se muestra en la Figura 4-63.
Figura 4-63. Formalización de regla 22.
La traducción de la regla 22 al lenguaje ATL se muestra en la Figura 4-64.
( _ ) , ( , _ )
( _ ) ( _ )
( . ' : ')
( _ ) ( _ )
. ' : '
( .
w w clase Ecore x y x y elemento XmlRdf
z z restriccionCardinalidadMaxima Ecore q q elemento XmlRdf
x nombre owl Class
x x elemento XmlRdf r r atributo XmlRdf
r nombre rdf about
r valor
'#' . )
. ' : '
( _ ) ( _ ( ))
( . ' : Re ')
( _ ) , ( , _ ( , ))
, ( , _ ) ,
w nombre
y nombre rdfs subClassOf
x x elemento XmlRdf s s elemento XmlRdf s X
s nombre owl striction
s s elemento XmlRdf t u t u elemento XmlRdf t u S
t u t u elemento XmlRdf o
( , _ )
( . ' : Pr ') ( . ' : ') ( . '#' . Pr )
( . ' : max ') ( . ' : ') ( . . )
(
p o p atributo XmlRdf
t nombre owl on operty o nombre rdf resource o valor x on operty
u nombre owl cardinality p nombre rdf datatype p valor x uri
z z restriccionCardinali
_ ) ( _ )
( . .max )
dadMaxima Ecore v v texto XmlRdf
v valor z cardinality
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 55
Figura 4-64. Regla cardinalidad máxima a XML/RDF.
4.3.8. Restricción todos los valores de clase
A diferencia de los tipos de restricción vistos anteriormente, la propiedad AllValuesFrom es local a la clase que la contiene. Tal restricción requiere que para cada instancia de la clase que tenga instancias de la propiedad especificada, los valores de la propiedad son todos miembros de la clase indicada por la cláusula. El siguiente ejemplo establece que el fabricante de un Vino debe ser un Viñero. La restricción allValuesFrom aplica en la propiedad tieneFabricante únicamente para la clase Vino como se muestra en la Figura 4-65.
Figura 4-65. Restricción todos los valores de clase en OWL.
Una vez que se ha definido la propiedad AllValuesFrom la siguiente regla es utilizada para crear restricciones de clase a partir de asociaciones en UML.
Regla 23: De propiedad UML a restricción todos los valores de clase en Ecore
Con esta regla de transformación se obtiene una restricción de todos los valores de clases (AllValuesFromClass Restriction) en el modelo de OWL a partir de un modelo de UML.
rule ClaseOWL_A_XML/RDF {
from claseOWL : owl!ClaseOWL ( claseOWL.oclIsKindOf(owl!ClaseOWL) )
to elementoXML : XML!Element ( name <- 'owl:Class', children <- Sequence{ rdfAbout, rdfsLabel,
textoLabel,claseOWL.subClassOf->select( subclase | subclase.oclIsTypeOf(owl!RestriccionCardinalidadMaxima) )->collect( restCardMax| thisModule.hacerRestriccionDeCardinalidadMaxima(claseOWL,restCardMax) ),})
rdfAbout : XML!Attribute ( parent <- elementoXML, name <- 'rdf:about ', value <- '#' + claseOWL.nombreLocal ),
rdfsLabel : XML!Element ( parent <- elementoXML, name <- 'rdfs:label', children <- textoLabel ), textoLabel : XML!Text ( name <- '#text ', value <- claseOWL.nombreLocal ) } lazyrule hacerRestriccionDeCardinalidadMaxima {
from claseOWL : owl!ClaseOWL, restriccionMaxCardinalidad : owl!RestriccionCardinalidadMaxima
to elementoRdfsSubclassOf : XML!Element ( name <- 'rdfs:subClassOf', children <- elementoOwlRestriction, parent
<- claseOWL ), elementoOwlRestriction : XML!Element ( name <- 'owl:Restriction', children <- Sequence{elementoOwlOnProperty, elementoOwlMaxCardinality} ), elementoOwlOnProperty : XML!Element ( name <- 'owl:onProperty', children <- atributoOnProperty ),
atributoOnProperty : XML!Attribute ( name <- 'rdf:resource', value <- '#' +restriccionMaxCardinalidad.onProperty.nombreLocal ), elementoOwlMaxCardinality : XML!Element ( name <- 'owl:maxCardinality ', children <-
Sequence{atributoMaxCardDataType, textoMaxCardinality} ), atributoMaxCardDataType : XML!Attribute ( name <- 'rdf:datatype', value <- restriccionMaxCardinalidad.obtieneURITipodato() ), textoMaxCardinality : XML!Text ( name <- '#text ', value <-
restriccionMaxCardinalidad.cardinalidadMaxima.toString() )}
<owl:Class rdf:ID="Vino">
<rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#tieneFabricante" /> <owl:allValuesFrom rdf:resource="#Viñero" />
</owl:Restriction> </rdfs:subClassOf> ... </owl:Class>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 56
Para cada propiedad en el modelo de UML se crea una restricción de todos los valores de
clase (AllValuesFromClassRestriction) en el modelo OWL.
o El nombre de la propiedad depende del nombre de la propiedad UML.
o Se especifica el nombre de la clase de la cual se deriva la relación.
o Se especifica mediante la propiedad “allValuesFromClass” el nombre de la clase
objetivo de la relación.
La formalización de la regla 23 se muestra en la Figura 4-66.
Figura 4-66. Formalización de regla 23.
La traducción al lenguaje ATL de la regla 23 se muestra en la Figura 4-67.
Figura 4-67. Regla restricción todos los valores de clase.
Regla 24: De todos los valores de clase en Ecore a todos los valores de clase en OWL (XML/RDF) Esta regla de transformación permite la serialización al formato XML/RDF del resultado de la ejecución de la regla 23.
Para cada clase en el modelo de OWL y cada Restricción de todos los valores de clase en el
modelo de OWL se genera una serie de elementos hijos en el modelo de XML.
o El primer elemento tendrá de nombre „rdfs:subClassOf‟.
o El segundo elemento tiene el nombre “owl:Restriction” el cual a su vez tiene como
hijos un nodo elemento de nombre “owl:onProperty” seguido de un atributo de
nombre “rdf:Resource” cuyo valor es el signo “#” seguido del nombre de la
propiedad “onProperty” de la clase OWL “AllValuesFromClassRestriction”.
o Un elemento hijo del elemento “owl:Restriction” tiene el nombre
“owl:allValuesFrom” seguido de un atributo de nombre “rdf:resource” cuyo valor es
el signo “#” seguido del nombre de la propiedad “allValuesFromClass” de la clase
OWL “AllValuesFromClassRestriction.
La formalización de la regla 24 se muestra en la Figura 4-68.
Lazy rule todosValoresDeRestriccionDeClase {
from propiedadUML : UML!Property
to todosValoresDeRestriccionDeClaseOWL: OWL!RestriccionTodosLosValoresDeClase
(enPropiedad <- thisModule.mapeoDePropiedades.getKeys()->any(e | e.name = propiedadUML.name), subClase <- thisModule.mapeoPropiedadDominio.get(propiedadUML), todosLosValoresDeClase<-
thisModule.mapeoPropiedadRango.get(propiedadUML),)}
( _ ) ( _ )
. Pr .
. .
x x propiedad UML y y restriccionTodosLosValoresDeClase Ecore
y en opiedad x nombre
y allValuesFromClass x ownedAssociationEnd
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 57
Figura 4-68. Formalización de regla 24.
La regla necesaria en el lenguaje ATL con el fin de serializar al formato XML/RDF una restricción de valor de clase en el modelo OWL en formato “Ecore” se muestra en la Figura 4-69.
Figura 4-69. Regla Clase restricción todos los valores de clase.
4.3.9. Propiedad simétrica
Una propiedad simétrica es una propiedad para la cual se establece que si el par (x,y) es una instancia de P, entonces el par (y, x) es también una instancia de P. Sintácticamente, una propiedad se define simétrica al hacerla una instancia de la clases integrada en OWL owl:SymmetricProperty, una subclase de owl:ObjectProperty. Un ejemplo muy popular de una propiedad simétrica es la relación amigoDe, donde el dominio y rango de una propiedad simétrica son los mismos.
Figura 4-70. Propiedad simétrica en OWL.
Una vez que se ha definido la propiedad owl:SymmetricProperty (Figura 4-70), la siguiente regla es utilizada para crear restricciones de una propiedad simétrica a partir de asociaciones en UML.
abstract rule Clase_A_XML/RDF {
from claseOwl : owl!OWLClass (claseOwl.oclIsKindOf(owl!ClaseOWL) )
to elementoXML : XML!Element ( name <- 'owl:Class', children <- Sequence{ claseOwl.subClaseDe->select ( e | e.oclIsTypeOf(owl!RestriccionTodosLosValoresDeClase) )->collect ( e | thisModule.RestriccionTodosLosValoresDeClase(claseOwl,e) ),} )}
lazy rule RestriccionTodosLosValoresDeClase{
from claseOwl : owl!ClaseOWL,
avfcr : owl! RestriccionTodosLosValoresDeClase
to elementoXML : XML!Element ( name <- 'rdfs:subClassOf', children <- elementoXML2, parent <- claseOwl), elementoXML2 : XML!Element ( name <- 'owl:Restriction', children <- Sequence{ elemenOnProp, elemenAllVal } ),
elemenOnProp: XML!Element ( name <- 'owl:onProperty', children <- onProp_Att ), onProp_Att : XML!Attribute ( name <- 'rdf:resource', value <- '#' + avfcr.onProperty.nombreLocal ), elemenAllVal : XML!Element ( name <- 'owl:allValuesFrom', children <- atribAllVal ),
atribAllVal : XML!Attribute ( name <- 'rdf:resource', value <- '#' + avfcr.todosLosValoresDeClase. nombreLocal )}
<owl:SymmetricProperty rdf:ID="friendOf">
<rdfs:domain rdf:resource="#Human"/>
<rdfs:range rdf:resource="#Human"/>
</owl:SymmetricProperty>
, [( _ ) , ( , _ )
( . ' : ')
( . ' : Re ')
( _ ) ( _ ( ))
( _
x y x clase Ecore y restriccionTodosValoresClase z q z q elemento XmlRdf
z nombre rdfs subClassOf
q nombre owl striction
z z elemento XmlRdf s s elemento XmlRdf s Z
s s elemento XmlR
( )) ( _ )
( . ' : Pr ') ( . ' : Re ')
( . "#" . Pr )
( _ ) ( _ ( ))
( _ ( )) (
df s Z t t atributo XmlRdf
s nombre owl On operty t nombre rdf source
t valor y on operty
z z elemento XmlRdf u u elemento XmlRdf u Z
u u elemento XmlRdf u Z v v atributo
_ )
( . ' : ') ( . ' : Re ')
. "#" . )
XmlRdf
u nombre owl allValuesFrom v nombre rdf source
v valor y allValuesFromClass
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 58
Regla 25: De asociación simétrica en UML a propiedad simétrica en Ecore .
Esta regla de transformación permite la generación de una propiedad simétrica en el modelo de OWL a partir de una asociación de una asociación simétrica en el modelo de UML.
Para cada propiedad en el modelo de UML se genera una propiedad de objeto, en la cual la
propiedad “isSymmetric” es verdadera si el dominio y el rango de la asociación en el modelo
de UML son el mismo.
La formalización de la regla 25 se muestra en la Figura 4-71.
Figura 4-71. Formalización de regla 25.
La traducción al lenguaje ATL de la regla 25 se muestra en la Figura 4-72.
Figura 4-72. Regla de propiedad simétrica.
A continuación se muestra la regla necesaria en el lenguaje ATL con el fin de serializar al formato XML/RDF una propiedad simétrica en el modelo OWL en formato “Ecore”. Regla 26: De propiedad simétrica en Ecore a propiedad simétrica en OWL (XML/RDF)
Esta regla de transformación permite la serialización al formato XML/RDF del resultado de la ejecución de la regla 25.
Para cada propiedad de objeto de las cuales el dominio y el rango son la misma clase en el
modelo de OWL, se crea un elemento de XML.
o El nombre del elemento creado es “owl:ObjectProperty” al cual se agrega otro
elemento de XML de nombre “rdf:type” seguido de un atributo de nombre
“rdf:resource” cuyo valor corresponde a la cadena constante:
http://www.w3.org/2002/07/owl#SymmetricProperty.
La formalización de la regla 26 se muestra en la Figura 4-73.
Figura 4-73. Formalización de regla 26.
rule PropiedadUML_A_PropiedadObjeto {
from propiedadUML : UML!Property (if (propiedadUML)then propiedadUML.esAsociacion() else false endif)
to propiedadObjetoOWL : OWL!PropiedadDeObjeto ( esSimetrica<- propiedadUML.esSimetrica()) } helper def: esSimetrica() : Boolean =self.type = self.association.memberEnd->asSequence()->
any( x | x.oclIsTypeOf(UML!Property) and not (x = self)).type;
( _ ) ( _ )
. ( . )
x x propiedad UML y y propiedadObjeto Ecore
y esSimetrica x tipo
[( _ ( . . ))]
, , ( , _ _ )
( . ' : Pr ') ( . ' : ') ( . ' : Re ')
( . '
x x propiedadObjeto Ecore x ownedAttribute x navigableEnd
y z q y z elemento XmlRdf q atributo XmlRdf
y nombre owl Object operty z nombre rdf type q nombre rdf source
q valor ht
: / / . 3. / 2002 / 07 / # Pr ')tp www w org owl Symmetric operty
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 59
La traducción de la regla 26 al lenguaje ATL se muestra en la Figura 4-74.
Figura 4-74. Regla Propiedad de objeto a XML/RDF.
4.3.10. Propiedad funcional
Si una propiedad P se etiqueta como funcional (Functional), entonces para toda x, y y z
P(x, y) y P(x, z) implica que y=z. En la ontología del vino, la propiedad tieneAñoDeCosecha es funcional. Un vino tiene un único año de cosecha. Eso es, dada una cosecha individual sólo se puede asociar con un sólo año mediante la propiedad tieneAñoDeCosecha como se muestra en la Figura 4-75. No se requiere que todos los elementos de una propiedad funcional en el dominio tengan valores.
Figura 4-75. Propiedad funcional en OWL.
Una vez que se ha definido la propiedad functionalProperty, la siguiente regla es utilizada para crear propiedades funcionales a partir de asociaciones en UML.
Regla 27: De asociación en UML a Propiedad Funcional en Ecore Esta regla de transformación permite la generación de una propiedad funcional en el modelo de OWL a partir de una asociación en el modelo de UML.
Para cada propiedad en el modelo de UML que sea de tipo asociación, se crea una propiedad
de objeto en el modelo de OWL. La propiedad es funcional si la cardinalidad mínima y
máxima del extremo de la asociación son igual a 1.
La formalización de la regla 27 se muestra en la Figura 4-76.
rule PropiedadObjeto_A_XML/RDF {
from propObj : owl!PropiedadDeObjeto (propObj.oclIsTypeOf(owl! PropiedadDeObjeto) )
to elementoXML : XML!Element ( name <- 'owl:ObjectProperty', children <- Sequence{ID,o.domain->collect( e | thisModule.DominioDeObjecto(o,e)),
propObj.rango->collect( e | thisModule.RangoDeObjeto(o,e) ) }), atribXML : XML!Attribute ( name <- 'rdf:about ', value <- '#' + propObj.nombreLocal ) do {if (propObj.esSimetrica)thisModule.agregarSimetrica(propObj); }}}
rule agregarSimetrica(propObj: owl! PropiedadDeObjeto) {
to elementoXML : XML!Element (name <- 'rdf:type',children <- atriSim,parent <- propObj),
atriSim : XML!Attribute (name <- 'rdf:resource',value <- 'http://www.w3.org/2002/07/owl#SymmetricProperty')}
<owl:Class rdf:ID="AñoDeCosecha" />
<owl:ObjectProperty rdf:ID="tieneAñoDeCosecha"> <rdf:type rdf:resource="&owl;FunctionalProperty" /> <rdfs:domain rdf:resource="#Cosecha" />
<rdfs:range rdf:resource="#AñoDeCosecha" /> </owl:ObjectProperty>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 60
Figura 4-76. Formalización de regla 27.
La traducción al lenguaje ATL de la regla 27 se muestra en la Figura 4-77.
Figura 4-77. Regla propiedad funcional .
A continuación se muestra la regla necesaria en el lenguaje ATL con el fin de serializar al formato XML/RDF una propiedad simétrica en el modelo OWL en formato “Ecore”.
Regla 28: De propiedad funcional en Ecore a propiedad funcional en OWL (XML/RDF) Esta regla de transformación permite la serialización al formato XML/RDF del resultado de la ejecución de la regla 27.
Para cada propiedad de objeto cuya propiedad funcional sea verdadera, se crea un nodo
elemento de XML de nombre “rdf:type” junto con un atributo de nombre “rdf:resource” cuyo
valor es la cadena constante http://www.w3.org/2007/07/owl#FuncionalProperty.
La formalización de la regla 28 se muestra en la Figura 4-78.
Figura 4-78. Formalización de regla 28.
La traducción de la regla 28 al lenguaje ATL se muestra en la Figura 4-79.
rule PropiedadUML_A_PropiedadObjeto {
from propiedadUML : UML!Property (if (propiedadUML) then propiedadUML.esAsociacion()else false endif)
using {uriOWL : String = propiedadUML.asignaURI() + propiedadUML.name}
to propiedadObjetoOWL : OWL! PropiedadDeObjeto ( nombreLocal<- propiedadUML.name,URI <- uriOWL,
esFuncional <-propiedadUML.esFuncional(),dominio <- dominio,rango <- rango)} helper def: esFuncional() : Boolean = self.association.memberEnd->asSequence()->any( x | x.oclIsTypeOf(UML!Property) and (x = self)).upper = 1and self.association.memberEnd->asSequence()->any( x | x.oclIsTypeOf(UML!Property) and t (x = self)).lower = 1;
( _ . ) ( _ )
( . ( . . 1 . . 1)
x x propiedad UML x asociación y y propiedadObjeto Ecore
y esFuncional x memberEnd upper x memberEnd lower
[( _ . )
, ( _ _ )
( . ' : ') ( . ' : Re ')
( . ' : / / . 3. / 2007 / 07 / # Pr ')
x x propiedadObjeto Ecore x esFuncional
y z y elemento XmlRdf z atributo XmlRdf
y name rdf type z nombre rdf source
z valor http www w org owl Functional operty
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 61
Figura 4-79. Regla propiedad funcional a XML/RDF.
4.3.11. Propiedad funcional inversa
Si una propiedad P se etiqueta como funcional inversa (InverseFunctional), entonces para toda X,Y y Z:
P(y, x) y P(z, x) implica que y=z
Nótese que, por ejemplo, la propiedad produceVino es funcional inversa. La razón es que la inversa de una propiedad funcional debe ser inversa funcional como se muestra en la Figura 4-80.
Figura 4-80. Propiedad funcional inversa.
Los elementos del rango en una propiedad funcional inversa pueden ser vistos como una llave única en el sentido de las bases de datos. owl:InverseFunctional implica que los elementos del rango proporcionan un identificador único para cada elemento en el dominio. Una vez que se ha definido la propiedad owl:InverseFunctional, la siguiente regla es utilizada para crear propiedades funcionales inversas a partir de asociaciones en un modelo de UML.
Regla 29 De asociación de UML a Propiedad funcional inversa en Ecore Esta regla de transformación permite genera una propiedad funcional inversa en el modelo de OWL a partir de una asociación en el modelo de UML
rule PropiedadObjeto_A_XML/RDF {
from propObj : owl!PropiedadDeObjeto (propObj.oclIsTypeOf(owl!PropiedadDeObjeto) ) to elementoXML : XML!Element (name <- 'owl:ObjectProperty',children
<- Sequence{ atribPropFunc,propObj.dominio->collect( e | thisModule.DominioDeObjecto(propObj,e)), propObj.rango->collect( e | thisModule.RangoDeObjeto(propObj,e) ) }),
atribPropFunc : XML!Attribute ( name <- 'rdf:about ', value <- '#' + propObj.nombreLocal ) do {if (propObj.esFuncional) thisModule.agregaFuncional(propObj); }}}
rule agregarFuncional( propObj : owl!PropiedadDeObjeto ) {
to elementoXML : XML!Element (name <- 'rdf:type', children <- atribPropFun,,parent <- propObj),
atribPropFun : XML!Attribute ( name <- 'rdf:resource',value <- 'http://www.w3.org/2002/07/owl#FunctionalProperty')}
lazy rule DominioDeObjecto {
from propObj : owl!PropiedadDeObjeto, claseOwl : owl!ClaseOWL to elemDominio : XML!Element ( name <- 'rdfs:domain', children <- atribDominio, parent <- propObj ),
atribDominio : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOwl.nombreLocal )} lazy rule RangoDeObjeto {
from propObj : owl!PropiedadDeObjeto, claseOwl : owl!ClaseOWL to range : XML!Element ( name <- 'rdfs:range', children <- range_attr, parent <- propObj ),
range_attr : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOwl.nombreLocal )}
<owl:ObjectProperty rdf:ID="tieneFabricante" /> <owl:ObjectProperty rdf:ID="produceVino"> <rdf:type rdf:resource="&owl;InverseFunctionalProperty" />
<owl:inverseOf rdf:resource="#tieneFabricante" /> </owl:ObjectProperty>
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 62
Para cada propiedad en el modelo de UML que sea de tipo asociación, se crea una propiedad
de objeto en el modelo de OWL. La propiedad es funcional inversa si la cardinalidad mínima y
máxima del extremo de la asociación no son igual a 1.
La formalización de la regla 29 se muestra en la Figura 4-81.
Figura 4-81. Formalización de regla 29.
La traducción al lenguaje ATL de la regla 29 se muestra en la Figura 4-82. .
Figura 4-82. Regla propiedad funcional inversa.
A continuación se muestra la regla necesaria en el lenguaje ATL con el fin de serializar al formato XML/RDF una propiedad simétrica en el modelo OWL en formato “Ecore”.
Regla 30: De propiedad funcional inversa en Ecore a propiedad funcional inversa en OWL
(XML/RDF) Esta regla de transformación permite la serialización al formato XML/RDF del resultado de la ejecución de la regla 29.
Para cada propiedad de objeto cuya propiedad funcional inversa es verdadera, se crea un
nodo elemento de XML de nombre “rdf:type” junto con un atributo de nombre “rdf:resource”
cuyo valor es la cadena constante http://www.w3.org/2007/07/owl#InverseFuncionalProperty.
La formalización de la regla 30 se muestra en la Figura 4-83.
Figura 4-83. Formalización de regla 30.
La traducción de la regla 30 al lenguaje ATL se muestra en la Figura 4-84.
rule PropiedadUML_A_PropiedadObjeto {
from propiedadUML : UML!Property (if (propiedadUML)then propiedadUML.esAsociacion() else false endif)
to propiedadObjetoOWL : OWL!PropiedadDeObjeto ( nombreLocal<- propiedadUML.name, URI <- uriOWL, esFuncionalInversa<- propiedadUML.esFuncionalInversa())
} helper def: esFuncionalInversa() : Boolean = self.association.memberEnd->asSequence()->any( x | x.oclIsTypeOf(UML!Property) and not (x= self)).upper = 1and
self.association.memberEnd->asSequence()->any( x | x.oclIsTypeOf(UML!Property) and not (x = self)).lower = 1;
[( _ . )
, ( _ _ )]
( . ' : ') ( . ' : Re ')
( . ' : / / . 3. / 2007 / 07 / # Pr
x x propiedadObjeto Ecore x esFuncionalInversa
y z y elemento XmlRdf z atributo XmlRdf
y name rdf type z nombre rdf source
z valor http www w org owl InverseFunctional op
')erty
( _ . ) ( _ )
( . ( . . 1 . . 1)
x x propiedad UML x asociación y y propiedadObjeto Ecore
y esFuncionalInversa x memberEnd upper x navigableEnd upper
≈ Capitulo 4. Método para la generación de ontologías OWL a partir de diagramas de clases de UML
pág. 63
Figura 4-84. Regla propiedad funcional inversa a XML/RDF.
rule PropiedadObjeto_A_XML/RDF {
from propObj : owl!PropiedadDeObjeto (propObj.oclIsTypeOf(owl!PropiedadDeObjeto) )
to elementoXML : XML!Element (name <- 'owl:ObjectProperty',children <- Sequence{ atribPropFunc,propObj.dominio->collect( e | thisModule.DominioDeObjecto(propObj,e)), propObj.rango->collect( e | thisModule.RangoDeObjeto(propObj,e) )}), atribPropFunc : XML!Att ribute ( name <- 'rdf:about ', value <- '#' + propObj.nombreLocal )do {if (propObj.esFuncionalInversa) thisModule.agregaInversaFuncional(propObj); }}}
rule agregarInversaFuncional(propObj : owl!PropiedadDeObjeto ) {
to elementoXML : XML!Element (name <- 'rdf:type', children <- atribPropFunc,parent <- propObj),
atribPropFunc : XML!Attribute (name <- 'rdf:resource',value <- http://www.w3.org/2002/07/owl#InverseFunctionalProperty')}
lazy rule DominioDeObjecto {
from propObj : owl!PropiedadDeObjeto, claseOwl : owl!ClaseOWL
to elemDominio : XML!Element ( name <- 'rdfs:domain', children <- atribDominio, parent <- propObj ), atribDominio : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOwl.nombreLocal )}
lazy rule RangoDeObjeto {
from propObj : owl!PropiedadDeObjeto, claseOwl : owl!ClaseOWL
to rango : XML!Element ( name <- 'rdfs:range', children <- atrib_rango, parent <- propObj ), atrib_rango : XML!Attribute ( name <- 'rdf:resource', value <- '#' + claseOwl.nombreLocal )}
pág. 64
Capítulo 5. Diseño e implementación En este capítulo se describen las características de implementación de las reglas de transformación necesarias para la generación de ontologías en OWL utilizando los diagramas de clases de UML. La implementación se llevó a cabo utilizando el Framework de Modelado Eclipse (EMF). También se incluyó el API de Protégé para verificar la correcta importación de los archivos OWL generado por la herramienta.
≈ Capitulo 5. Diseño e implementación
pág. 65
5.1. Diseño Esta sección muestra los casos de uso de la herramienta y sus especificaciones derivadas del proceso de solución y arquitectura del prototipo generado.
Se propone como hipótesis que dada una herramienta que permite implementar en forma precisa reglas de transformación entre modelos UML y especificaciones OWL será posible reducir el tiempo y esfuerzo que dedica un usuario novato en el uso de ontologías para producir una especificación de este tipo, al proporcionarle una notación visual con la cual conceptualizar la ontología. El proceso de solución se compone de 7 fases (Figura 5-1) las cuales fueron descritas en el capítulo 4.
Figura 5-1. Proceso de Solución
Es importante mencionar que debido a que no se hace uso del algún lenguaje de programación orientado a objetos (ya que se utiliza el lenguaje ATL para transformación de modelos), no se presentaron los diagramas de clases del prototipo generado.
5.1.1. Diagramas de casos de uso
De acuerdo a la solución propuesta, los diagramas de casos de uso se muestran en la Figura 5-2.
Figura 5-2. Proceso de Solución
uc Use Case Model
Generación de ontologías en OWL
CU_1 Generar
diagrama de clases
en UML
CU_2 Generar
Ontología OWL
CU_3 Serializar
ontología al formato
XML/RDF
CU_4 Generar archiv o
OWL
Usuario
Framework Eclipse
«include»
«include»
«include»
≈ Capitulo 5. Diseño e implementación
pág. 66
Se observa como primer caso de uso la generación manual de un diagrama de clases de UML que representará una ontología. El Framework Eclipse se encarga de realizar los casos de uso restantes (utilizando las reglas que fueron definidas en este trabajo) al aplicar las reglas de transformación que en la primera fase generará una ontología en OWL, el segundo conjunto de reglas de transformación generará la ontología en formato XML/RDF. Como caso de uso 4 se obtiene el archivo OWL con formato XML/RDF con el cual ya es posible poblar la Web semántica o bien refinar la ontología con una herramienta como Protégé.
Tabla 4. Propiedades de CU-1 Generar diagrama de clases en UML
ID: CU-1 Generar diagrama de clases en UML
Actores: Usuario.
Descripción: Permite al usuario crear un nuevo diagrama de clases que represente una ontología.
Precondiciones: 1. El usuario deberá tener conocimientos básicos de modelado en UML.
Poscondiciones: 1. Se obtiene una ontología en formato “Ecore”.
Escenario de éxito 1: 1. Se abre la ap licación
2. El usuario modela una ontología mediante diagramas de clases de UML.
Suposición: Supone que la ontología OWL para este diagrama de clases ha sido creada.
Figura 5-3. Diagrama de actividad del caso de uso CU_1: generar diagrama de clases en UML
Tabla 5. Propiedades de CU-2 Generar ontología OWL
ID: CU-2 Generar ontología OWL.
Actores: Framework Eclipse.
Descripción: El Framework Eclipse generará una ontología OWL a partir del diagrama de clases
generado por el usuario. Precondiciones: Diagrama de clases en UML generado por el usuario.
Poscondiciones: Se generará una ontología compatib le con el metamodelo de defin ición de
ontologías (ODM) en formato Ecore (Eclipse).
Escenario de éxito 1: 1. El usuario inicia la aplicación.
2. El usuario modela una ontología mediante diagramas de clases de UML.
3. El sistema genera la ontología en OWL.
Incluye CU_1: Generar d iagrama de clases en UML
Suposición: Se supone que la ontología se serializó al fo rmato XML/RDF.
uc Use Case Model
Sis
tem
aU
su
ari
o
Iniciar aplicación Usuario genera
diagrama de clasesutil iza diagrama de clases
No
Generar Ontología OWL
Sí
≈ Capitulo 5. Diseño e implementación
pág. 67
Figura 5-4. Diagrama de actividad del caso de uso CU_2: Generar ontología en formato Ecore.
Tabla 6. Propiedades de CU-3 Serializar ontología al formato XML/RDF
ID: CU-3 Serializar ontología al formato XML/RDF
Actores: Framework Eclipse.
Descripción: El Framework Eclipse serializará una ontología en OWL al formato XML/RDF..
Precondiciones: Ontología en formato Ecore.
Poscondiciones: El usuario podrá hacer uso del archivo OW L generado.
Escenario de éxito 1: 1. El usuario inicia la aplicación.
2. El usuario genera un diagrama de clases de UML.
3. El sistema genera la ontología OWL en formato Ecore .
4. El sistema serializa la ontología OWL al formato XML/RDF.
Incluye CU_2 Generar ontología OW L.
Suposición: Se supone que el archivo OW L con fo rmato XML/RDF se creó.
Figura 5-5. Diagrama de actividad del caso de uso CU_3: Generar archivo OWL en formato XML/RDF.
uc Use Case Model
Sist
ema
Usua
rio
Generación de diagrama
de clasesDiagrama de clases válido
Generación de ontología
OWL
Serialización de ontología
a XML/RDF
No
Sí
uc Use Case Model
Sis
tem
aU
su
ari
o
Genera ontología OWL Serilización de ontología a
XML/RDFSerialización correcta
Generación de archiv o
OWL
Sí
No
≈ Capitulo 5. Diseño e implementación
pág. 68
Tabla 7. Propiedades de CU-4 Generara archivo OWL
ID: CU-4 Generar archivo OW L
Actores: Framework Eclipse.
Descripción: El sistema modifica la sintaxis XML de la ontología OWL en formato Ecore para
poder transformar la sintaxis al formato XML/RDF y poder ser leída por otras
herramientas como Protégé.
Precondiciones: Ontología OW L en formato Ecore.
Poscondiciones: Se generará un archivo OWL en formato XML/RDF.
Escenario de éxito 1: 1. El usuario inicia la aplicación.
2. El usuario modela una ontología mediante diagramas de clases de UML.
3. El sistema genera la ontología en OWL en formato Ecore.
El sistema modifica correctamente la sintaxis XML de la ontología.
Incluye CU_3: Generar ontología en OW L.
Suposición: El usuario obtiene con éxito el arch ivo OW L con formato XML/RDF.
5.2. Características de la implementación
Para la comprobación del método de generación de ontologías en OWL a partir de diagramas de clases de UML fue necesario implementar un prototipo con el fin de ejecutar cada una de las etapas del método propuesto. El prototipo de modelado se desarrolló utilizando el Framework Eclipse V. 3.3 utilizando el lenguaje de transformación ATL. El prototipo permite modelar mediante diagramas de clases de UML 2.0 y de manera automática ejecutar las reglas de transformación necesarias para la obtención de la ontología en formato XML/RDF. Para llevar a cabo la implementación se utilizaron las siguientes herramientas:
Para el desarrollo de la aplicación se utilizó el Framework Eclipse en su versión 3.3.
Se utilizó Java J2SE Development Kit en su versión 1.6.0, soportado sobre Microsoft
Windows. Esta versión proporciona un compilador y un conjunto de herramientas para crear
programas independientes y java applets.
Se utilizó el plugin de lenguaje de transformación ATL para permitir su integración en Eclipse.
Se utilizó el plugin de UML 2.0 para poder generar los diagramas de clases de UML.
La importación de la ontología generada fue posible al integrar el API de Protégé en el
Framework Eclipse.
Se utilizó la API (Application Programming Interface) de Protégé.
5.2.1. Arquitectura del prototipo
De acuerdo al proceso de solución presentado en la sección 5.1, la arquitectura del prototipo generado para probar la solución propuesta es la siguiente.
≈ Capitulo 5. Diseño e implementación
pág. 69
Figura 5-6. Arquitectura del prototipo.
Nuestra implementación utiliza como base los proyectos de Eclipse los cuales le proporcionan funcionalidades esenciales a nuestro prototipo como se puede observar en la Figura 5-6 (1). Estos componentes son el Framework de Modelado Eclipse (EMF), el Framework de Modelado Gráfico (GMF) y finalmente Eclipse el cual funge como IDE (Integrated Development Environment). En este prototipo incluimos el API (Application Programming Interface) de Protégé con el cual un usuario avanzado en la generación de ontologías puede refinar la ontología obtenida al final del proceso. Los componentes dentro de la Figura 5-6 (2) comprenden la interfaz gráfica para la creación de los metamodelos utilizados durante la transformación así como el editor de las reglas de transformación en el lenguaje ATL. Los componentes de la Figura 5-6 (3) comprenden la interfaz gráfica para generar el modelo conceptual de la ontología mediante diagramas de clases de UML el cual sirve como entrada para el motor de transformación ATL que junto con los metamodelos y las reglas de transformación genera el archivo OWL que se esperaba obtener. El componente mostrado en la Figura 5-6 (4) corresponde al archivo OWL generado cuya sintaxis corresponde a XML/RDF y el cual puede ser importado y refinado por el API de Protégé.
5.2.1.1. Módulo de interfaz gráfica En esta sección se presenta la interfaz gráfica (Figura 5-7) correspondiente a los componentes del prototipo mostrados en la arquitectura de la Figura 5-6.
≈ Capitulo 5. Diseño e implementación
pág. 70
Figura 5-7. Interfaz gráfica del prototipo.
a) Este componente presenta una interfaz gráfica para la generación del diagrama de clases que es
utilizado como entrada de la herramienta.
b) En el editor de mapeo se construyen las reglas de transformación en el lenguaje ATL. Las
reglas de mapeo están directamente relacionadas a la descripción de los metamodelos, los
cuales se construyen en el componente C.
c) En este componente se permite la generación de metamodelos de OWL y XML en el lenguaje
Ecore.
d) El archivo OWL generado por las transformaciones realizadas se observa en este módulo. Este
componente permite visualizar el código en formato XML/RDF con su sintaxis resaltada.
e) Este componente permite la importación del archivo OWL por parte del API de Protégé con la
finalidad de poder refinar la ontología en caso de ser necesario.
a) b)
c)
e)
d)
pág. 71
Capítulo 6. Pruebas El presente capítulo describe el plan de pruebas ejecutado para verificar la funcionalidad de las reglas de transformación en la generación de ontologías en OWL a partir de diagramas de clases de UML
≈ Capitulo 6. Pruebas
pág. 72
6.1 Introducción
Con el fin de realizar la evaluación del prototipo creado y los resultados de su aplicación, se llevó a cabo una evaluación empírica sobre el proceso de generación de ontologías a partir de diagramas de clases de UML. Las evaluaciones empíricas son de tres tipos: experimental, quasi-experimental y mediante casos de estudios. Para la evaluación del método propuesto en esta investigación se utilizaron los casos de estudio ya que son más factibles una vez que el método se ha implementado. Se determinó utilizar los casos de estudio ya que como se establece en [Rosso, 2001], las evaluaciones experimentales y quasi-experimentales requieren un número elevado de muestra y aleatoriedad de las mismas, además de que se utilizan para las primeras etapas del desarrollo del método con el fin de demostrar sus beneficios. Para la realización de las pruebas se utilizaron casos de estudio en los cuales se tomaron diagramas de clases de distintas páginas Web con el fin de replicar dichos esquemas conceptuales (con el prototipo propuesto en esta tesis) y poder obtener sus respectivas ontologías en OWL. El primer caso de estudio corresponde a la ontología de DBPedia (http://wiki.dbpedia.org/Ontology), un segundo caso de estudio corresponde al modelo conceptual del Programa de Formación Profesional en Ingeniería de Software [Montilva et al, 2007], el tercer caso de estudio corresponde al modelo conceptual del sistema de información de un restaurante, el cuarto caso de estudio corresponde al modelo conceptual de una aerolínea y la venta de boletos de avión. El quinto caso de estudio corresponde al modelo conceptual del Juego Sapiens dedicado al aprendizaje de conocimientos generales. El sexto caso de estudio toma un diagrama de clases el cual representa el modelo conceptual de las funciones de una persona dentro de una universidad. El séptimo caso de estudio toma un diagrama de clases que representa el modelo conceptual de un banco y la gestión de tarjetas de crédito. El octavo caso de estudio toma el modelo conceptual para la informatización de una biblioteca. En la explicación de cada caso de estudio se presenta el diagrama original en UML y los diagramas que muestran la correcta importación por parte de Protégé del archivo OWL generado por el sistema. Los diagramas se muestran completos en la sección de anexos, mientras que los códigos generados se encuentran en el CD que acompaña esta tesis representados por archivos OWL.
6.1.1. Hipótesis
La hipótesis de este trabajo de investigación es la siguiente: dada una herramienta que permite implementar en forma precisa reglas de transformación entre modelos UML y especificaciones OWL es posible reducir el esfuerzo que dedica un usuario novato para la generación de ontologías, al proporcionarle una notación visual mediante diagramas de clases de UML con la cual representar gráficamente la ontología al inicio de la creación de la misma.
6.2 Caso de estudio Ontología de DBPedia
La ontología de DBPedia (http://wiki.dbpedia.org/Ontology) es una ontología entre dominios creada de manera manual y que se basa en los temas más comúnmente utilizados en Wikipedia. La ontología cubre 256 clases relacionadas taxonómicamente. La ontología de DBPedia se muestra en la Figura 6-1. Este es el único caso de estudio que replica una ontología ya existente. Los demás casos de estudio parten de un diagrama de clases para construir la ontología OWL. La Figura 6-2 muestra un fragmento de la replicación de la ontología de DbPedia llevada a cabo mediante el prototipo propuesto.
≈ Capitulo 6. Pruebas
pág. 73
Figura 6-1. Ontología de DBPedia (fragmento).
Figura 6-2. Generación de la ontología de DBPedia mediante la herramienta propuesta (fragmento).
≈ Capitulo 6. Pruebas
pág. 74
La Figura 6-3 muestra un fragmento del archivo OWL generado para el caso de estudio. El código completo se encuentra en el CD que acompaña a esta tesis. Una vez que se llevó a cabo la transformación se pudo realizar la importación mediante la herramienta Protégé del archivo OWL generado. Mediante la visualización del archivo OWL en Protégé se pudo verificar que el grafo generado es idéntico al de la ontología original que se pretendió replicar pero utilizando los diagramas de clases de UML. Dicho grafo se muestra en la Figura 6-4.
Figura 6-3. Fragmento del archivo OWL del caso de estudio DBPedia.
Figura 6-4. Representación gráfica del archivo OWL generado por el prototipo (fragmento).
<?xml version = '1.0' encoding = 'ISO-8859-1' ?> <rdf:RDF xmlns:rdfs = 'http://www.w3.org/2000/01/rdf-schema#' xmlns:xsd = 'http://www.w3.org/2001/XMLSchema#'
xmlns:owl = 'http://www.w3.org/2002/07/owl#' xmlns:rdf = 'http://www.w3.org/1999/02/22-rdf-syntax-ns#' xmlns:DBPedia = 'http://www.cenidet.edu.mx/DBPedia#'> <owl:Ontology rdf:about = 'http://www.cenidet.edu.mx/DBPedia#'/> <owl:Class rdf:about = '#Species'>
<rdfs:label>Species</rdfs:label> </owl:Class> <owl:Class rdf:about = '#Place'> <rdfs:label>Place</rdfs:label>
</owl:Class> <owl:Class rdf:about = '#Person'> <rdfs:label>Person</rdfs:label> </owl:Class>
<owl:Class rdf:about = '#Organization'> <rdfs:label>Organization</rdfs:label> </owl:Class>
<owl:Class rdf:about = '#MeanOfTransportation'> <rdfs:label>MeanOfTransportation</rdfs:label> </owl:Class> <owl:Class rdf:about = '#Device'>
<rdfs:label>Device</rdfs:label> </owl:Class> <owl:Class rdf:about = '#AnatomicalStructure'> <rdfs:label>AnatomicalStructure</rdfs:label>
</owl:Class>
≈ Capitulo 6. Pruebas
pág. 75
6.3 Caso de estudio Programa PAP
El Programa de Actualización Profesional en Ingeniería de Software (PAP) es un programa de extensión universitaria dirigido a profesionales de la Informática, la Computación y otras áreas afines, que estén interesados en mejorar y actualizar sus conocimientos y competencias en Ingeniería de Software.
El modelo conceptual ilustrado en la Figura 6-5 muestra los componentes fundamentales de un Programa de Actualización Profesional (PAP). Un programa de esta naturaleza persigue un conjunto de objetivos curriculares previamente establecidos. Para alcanzar estos objetivos se diseña e implanta una estructura curricular compuesta por una colección de cursos en línea interrelacionados. Estos cursos son implementados usando una plataforma tecnológica apoyada en Internet. El hardware que integra esta plataforma está compuesto por un servidor conectado a Internet y un número cualquiera de máquinas PC que acceden al programa a través de la dirección IP del servidor. El software de la plataforma está integrado por el sistema de gestión de cursos (LMS o CMS), un conjunto de herramientas multimedia y software de oficina, los cuales son usados para la elaboración y publicación de contenidos instruccionales. El programa es operado, administrado y actualizado por un conjunto de actores, en los que se incluyen los estudiantes que cursan el programa y el personal encargado de administrar el programa y mantener actualizado los cursos que lo conforman.
Figura 6-5. Modelo conceptual del programa PAP.
Una vez que el modelo conceptual del Programa PAP se ha generado en la herramienta diseñada para la presente investigación, se lleva a cabo la transformación la cual genera el archivo OWL cuyo contenido se muestra a continuación con el fin de identificar las clases y relaciones en OWL a partir del diagrama de clases del Programa PAP. En la Figura 6-6 se muestra un fragmento del archivo OWL generado para el caso de estudio PAP. El código completo se muestra en el CD que acompaña a esta tesis.
≈ Capitulo 6. Pruebas
pág. 76
Figura 6-6. Fragmento del archivo OWL para el caso de estudio PAP.
El archivo OWL obtenido después de la transformación se pudo importar mediante la herramienta Protégé la cual nos permite visualizar la ontología. En la Figura 6-7 se muestran las clases con relaciones taxonómicas y que corresponden a aquellas presentes en el modelo conceptual representado mediante el diagrama de clases de la Figura 6-5. Las relaciones no taxonómicas que determinan un dominio y rango de la propiedad que las relaciona, fueron igualmente identificadas por Protégé y esto se muestra en la Figura 6-8.
Figura 6-7.Ontología PAP en Protégé incluye relaciones taxonómicas.
<?xml version = '1.0' encoding = 'ISO-8859-1' ?> <rdf:RDF xmlns:rdfs = 'http://www.w3.org/2000/01/rdf-schema#' xmlns:PAP = 'http://www.cenidet.edu.mx/PAP#' xmlns:xsd = 'http://www.w3.org/2001/XMLSchema#' xmlns:owl = 'http://www.w3.org/2002/07/owl#' xmlns:rdf = 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<owl:Ontology rdf:about = 'http://www.cenidet.edu.mx/PAP#'/> <owl:Class rdf:about = '#Programa_De_Actualización_Profesional'> <owl:Restriction> <owl:onProperty rdf:resource = '#tiene_Hardware'/>
<owl:minCardinality rdf:datatype = 'http://www.w3.org/2001/XMLSchema#integer'>0</owl:minCardinality > </owl:Restriction> </rdfs:subClassOf>
<rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource = '#utilizadoEn'/> <owl:allValuesFrom rdf:resource = '#Programa_De_Actualización_Profesional'/>
</owl:Restriction> <owl:Class rdf:about = '#Experto_En_Contenido'> <rdfs:subClassOf rdf:resource = '#Personal'/> <rdfs:label>Experto_En_Contenido</rdfs:label>
</owl:Class>
≈ Capitulo 6. Pruebas
pág. 77
Figura 6-8. Relaciones no taxonómicas del programa PAP.
6.4 Caso de estudio Orden de restaurant
El siguiente caso de estudio toma un diagrama de clases que pretende establecer un ejemplo en la creación de diagramas de clases tomando como ejemplo el modelo conceptual para un sistema computacional de un restaurante. En la URL siguiente http://www.osmosislatina.com/lenguajes/uml/clasesob.htm se puede encontrar la referencia del diagrama de clases de UML presentado en la Figura 6-9.
Figura 6-9. Diagrama de clases de un sistema de restaurant.
Mediante el prototipo propuesto se replicó el mismo diagrama de clases como se puede observar en la Figura 6-10.
≈ Capitulo 6. Pruebas
pág. 78
Figura 6-10. Diagrama de clases del caso de estudio replicado por el prototipo propuesto.
Un fragmento del archivo OWL generado por el prototipo propuesto en esta tesis se muestra en la Figura 6-11. El código completo se presenta en el CD que acompaña a esta tesis.
Figura 6-11. Fragmento del archivo OWL generado para el caso de estudio del restaurant.
Una vez obtenido el archivo OWL, fue posible importarlo con la herramienta Protégé con el fin de poder visualizar la ontología identificando las relaciones taxonómicas y no taxonómicas correspondientes al modelo conceptual del caso de estudio del restaurant.
<owl:ObjectProperty rdf:about = '#tienePlatillo'> <rdfs:domain rdf:resource = '#Orden'/>
<rdfs:range rdf:resource = '#Platillo'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#InverseFunctionalProperty'/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:about = '#numTdeCredito'>
<rdfs:domain rdf:resource = '#Credito'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#nonNegativeInteger'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#mesero'> <rdfs:domain rdf:resource = '#Orden'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about = '#tieneBebidas'>
<rdfs:domain rdf:resource = '#Orden'/> <rdfs:range rdf:resource = '#Bebida'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#InverseFunctionalProperty'/> </owl:ObjectProperty>
<owl:ObjectProperty rdf:about = '#incluidaEn'> <rdfs:domain rdf:resource = '#Bebida'/> <rdfs:range rdf:resource = '#Orden'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:ObjectProperty>
≈ Capitulo 6. Pruebas
pág. 79
Las relaciones taxonómicas del modelo conceptual para el caso de estudio del restaurant se observan en la Figura 6-12. Las relaciones no taxonómicas del modelo conceptual para el caso de estudio del restaurant se observan en la Figura 6-13.
Figura 6-12. Relaciones taxonómicas del la ontología para el caso de estudio del restaurant.
Figura 6-13. Relaciones no taxonómicas de la ontología para el caso de estudio del restaurant.
6.5. Caso de estudio de una aerolínea El siguiente caso de estudio toma un diagrama de clases que pretende establecer un ejemplo para la reservación de un boleto de avión. El modelo conceptual original se puede encontrar en la URL http://www.ibiblio.org/pub/linux/docs/LuCaS/Tutoriales/doc-modelado-sistemas-UML/multiple-html/x219.html y se muestra en la Figura 6-14.
≈ Capitulo 6. Pruebas
pág. 80
Figura 6-14. Modelo conceptual para el caso de estudio de una aerolínea.
Mediante el prototipo propuesto se replicó el mismo diagrama de clases como se puede observar en la Figura 6-15.
Figura 6-15. Diagrama de clases del caso de estudio replicado por el prototipo propuesto.
Un fragmento del archivo OWL generado por el prototipo propuesto en esta tesis se muestra en la Figura 6-16. El código completo se presenta en el CD que acompaña a esta tesis.
≈ Capitulo 6. Pruebas
pág. 81
Figura 6-16. Fragmento del archivo OWL generado para el caso de estudio de la aerolínea.
Una vez obtenido el archivo OWL fue posible importarlo con la herramienta Protégé con el fin de poder visualizar la ontología identificando las relaciones taxonómicas y no taxonómicas correspondientes al modelo conceptual del caso de estudio de la aerolínea. Las relaciones taxonómicas del modelo conceptual para el caso de estudio de la aerolínea se observan en la Figura 6-17. Las relaciones no taxonómicas del modelo conceptual para el caso de estudio de la aerolínea se observan en la Figura 6-18.
Figura 6-17. Relaciones taxonómicas de la ontología para el caso de estudio de la aerolínea.
<owl:DatatypeProperty rdf:about = '#destination'> <rdfs:domain rdf:resource = '#Flight '/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#flight_Number'>
<rdfs:domain rdf:resource = '#Flight '/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#nonNegativeInteger'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#airlineAddress'> <rdfs:domain rdf:resource = '#AirlineTicketVendor'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#passenger_Name'> <rdfs:domain rdf:resource = '#Passenger'/>
<rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty>
<owl:DatatypeProperty rdf:about = '#passenger_Adress'> <rdfs:domain rdf:resource = '#Passenger'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#vendor_Name'> <rdfs:domain rdf:resource = '#TravelAgent '/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty>
≈ Capitulo 6. Pruebas
pág. 82
Figura 6-18. Relaciones no taxonómicas de la ontología para el caso de estudio de la aerolínea.
6.6.Caso de estudio Juego Sapiens
El siguiente caso de estudio toma un diagrama de clases que representa un sistema computacional dedicado al aprendizaje de conocimientos generales. El modelo conceptual original se puede encontrar en la URL http://forja.rediris.es/frs/?group_id=575 y se muestra en la Figura 6-19.
Figura 6-19. Modelo conceptual para el caso de estudio del juego sapiens.
≈ Capitulo 6. Pruebas
pág. 83
Figura 6-20. Diagramas de clases del caso de estudio replicado por el prototipo propuesto.
Mediante el prototipo propuesto se replicó el mismo diagrama de clases como se puede observar en la Figura 6-20. Un fragmento del archivo OWL generado por el prototipo propuesto en esta tesis se muestra en la Figura 6-21. El código completo se presenta en el CD que acompaña a esta tesis.
Figura 6-21. Fragmento del archivo OWL generado para el caso de estudio del juego sapiens.
<owl:DatatypeProperty rdf:about = '#categorias'> <rdfs:domain rdf:resource = '#Torneo'/>
<rdfs:domain rdf:resource = '#Clasificacion'/> <rdfs:domain rdf:resource = '#Partida'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#nonNegativeInteger'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#sugerencia'> <rdfs:domain rdf:resource = '#Sugerencia'/>
<rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#fecha'>
<rdfs:domain rdf:resource = '#PartidaFinalizada'/> <rdfs:domain rdf:resource = '#Clasificacion'/> <rdfs:domain rdf:resource = '#Veto'/> <rdfs:domain rdf:resource = '#FuturaPregunta'/>
<rdfs:domain rdf:resource = '#Sugerencia'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#date'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty>
≈ Capitulo 6. Pruebas
pág. 84
Una vez obtenido el archivo OWL fue posible importarlo con la herramienta Protégé con el fin de poder visualizar la ontología identificando las relaciones taxonómicas y no taxonómicas correspondientes al modelo conceptual del caso de estudio del juego sapiens. Las relaciones taxonómicas del modelo conceptual para el caso de estudio del juego sapiens se observan en la Figura 6-22. Las relaciones no taxonómicas del modelo conceptual para el caso de estudio del juego sapiens se observan en la Figura 6-23.
Figura 6-22. Relaciones taxonómicas de la ontología para el caso de estudio del juego sapiens.
Figura 6-23. Relaciones no taxonómicas de la ontología para el caso de estudio del juego sapiens.
≈ Capitulo 6. Pruebas
pág. 85
6.7.Caso de estudio estudiante
El siguiente caso de estudio toma un diagrama de clases que representa el modelo conceptual de una persona dentro de una universidad. El modelo conceptual original se puede encontrar en la URL http://forja.rediris.es/frs/?group_id=575 y se muestra en la Figura 6-24.
Figura 6-24. Modelo conceptual para el caso de estudio de un estudiante.
Mediante el prototipo propuesto se replicó el mismo diagrama de clases como se puede observar en la Figura 6-25.
Figura 6-25. Diagrama de clases del caso de estudio replicado por el prototipo propuesto.
≈ Capitulo 6. Pruebas
pág. 86
Un fragmento del archivo OWL generado por el prototipo propuesto en esta tesis se muestra en la Figura 6-26. El código completo se presenta en el CD que acompaña a esta tesis.
Figura 6-26. Fragmento del archivo OWL generado para el caso de estudio del estudiante.
Una vez obtenido el archivo OWL fue posible importarlo con la herramienta Protégé con el fin de poder visualizar la ontología identificando las relaciones taxonómicas y no taxonómicas correspondientes al modelo conceptual del caso de estudio del juego sapiens. Las relaciones taxonómicas del modelo conceptual para el caso de estudio del juego sapiens se observan en la Figura 6-27. Las relaciones no taxonómicas del modelo conceptual para el caso de estudio del juego sapiens se observan en la Figura 6-28.
Figura 6-27. Relaciones taxonómicas de la ontología para el caso de es tudio del estudiante.
<owl:DatatypeProperty rdf:about = '#CI'>
<rdfs:domain rdf:resource = '#Persona'/> <rdfs:domain rdf:resource = '#Estudiante'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#nonNegativeInteger'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty> <owl:ObjectProperty rdf:about = '#estudiaEn'> <rdfs:domain rdf:resource = '#Estudiante'/>
<rdfs:range rdf:resource = '#Universidad'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about = '#tieneProfporDepartamento'>
<rdfs:domain rdf:resource = '#Trabajador'/> <rdfs:range rdf:resource = '#PDI'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#InverseFunctionalProperty'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:ObjectProperty> <owl:ObjectProperty rdf:about = '#trabajadorAdmin'> <rdfs:domain rdf:resource = '#PAS'/> <rdfs:range rdf:resource = '#Trabajador'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#InverseFunctionalProperty'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:ObjectProperty>
≈ Capitulo 6. Pruebas
pág. 87
Figura 6-28. Relaciones no taxonómicas de la ontología para el caso de estudio estudiante.
6.8. Caso de estudio de un banco y la gestión de tarjetas de crédito El siguiente caso de estudio toma un diagrama de clases que representa el modelo conceptual de un banco y la gestión de tarjetas de crédito. El modelo conceptual original se puede encontrar en la URL http://banalpes.wikispaces.com/levantamiento_informacion y se muestra en la Figura 6-29.
Figura 6-29. Modelo conceptual para el caso de estudio de un banco y la gestión de tarjetas de crédito.
≈ Capitulo 6. Pruebas
pág. 88
Mediante el prototipo propuesto se replicó el mismo diagrama de clases como se puede observar en la Figura 6-30.
Figura 6-30. Diagrama de clases del caso de estudio de un banco replicado por el prototipo propuesto.
Un fragmento del archivo OWL generado por el prototipo propuesto en esta tesis se muestra en la Figura 6-31. El código completo se presenta en el CD que acompaña a esta tesis.
≈ Capitulo 6. Pruebas
pág. 89
Figura 6-31. Fragmento del archivo OWL generado para el caso de estudio del banco.
Una vez obtenido el archivo OWL fue posible importarlo con la herramienta Protégé con el fin de poder visualizar la ontología identificando las relaciones taxonómicas y no taxonómicas correspondientes al modelo conceptual del caso de estudio de un banco y la gestión de tarjetas de crédito. Las relaciones taxonómicas del modelo conceptual para el caso de estudio de un banco y la gestión de tarjetas de crédito se observan en la Figura 6-32. Las relaciones no taxonómicas del modelo conceptual para el caso de estudio de un banco y la gestión de tarjetas de crédito se observan en la Figura 6-33.
Figura 6-32. Relaciones taxonómicas de la ontología para el caso de estudio de un banco.
<owl:DatatypeProperty rdf:about = '#valor'> <rdfs:domain rdf:resource = '#Cargo'/>
<rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#cancelada'>
<rdfs:domain rdf:resource = '#TarjetaCredito'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#firmaDigital'> <rdfs:domain rdf:resource = '#EstadoSolicitud'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#canalEntrada'> <rdfs:domain rdf:resource = '#Solicitud'/>
<rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about = '#poseeTarjeta'>
<rdfs:domain rdf:resource = '#Cliente'/> <rdfs:range rdf:resource = '#TarjetaCredito'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#InverseFunctionalProperty'/>
</owl:ObjectProperty>
≈ Capitulo 6. Pruebas
pág. 90
Figura 6-33. Relaciones no taxonómicas de la ontología para el caso de estudio de un banco.
6.9.Caso de estudio informatización de una biblioteca
El siguiente caso de estudio toma un diagrama de clases que representa el modelo conceptual para la informatización de una biblioteca. El modelo conceptual original se puede encontrar en la URL http http://jairmorenouml.blogspot.com/2009_06_01_archive.html y se muestra en la Figura 6-34.
Figura 6-34. Modelo conceptual para el caso de estudio de informatización de una biblioteca
Mediante el prototipo propuesto se replicó el mismo diagrama de clases como se puede observar en la Figura 6-35.
≈ Capitulo 6. Pruebas
pág. 91
Figura 6-35. Diagrama de clases del caso de estudio de informatización de una biblioteca.
Un fragmento del archivo OWL generado por el prototipo propuesto en esta tesis se muestra en la Figura 6-36. El código completo se presenta en el CD que acompaña a esta tesis.
Figura 6-36. Fragmento del archivo OWL para el caso de estudio de informatización de una biblioteca
<owl:DatatypeProperty rdf:about = '#valor'> <rdfs:domain rdf:resource = '#Cargo'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#cancelada'>
<rdfs:domain rdf:resource = '#TarjetaCredito'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty>
<owl:DatatypeProperty rdf:about = '#firmaDigital'> <rdfs:domain rdf:resource = '#EstadoSolicitud'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:about = '#canalEntrada'> <rdfs:domain rdf:resource = '#Solicitud'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty> <owl:ObjectProperty rdf:about = '#poseeTarjeta'>
<rdfs:domain rdf:resource = '#Cliente'/> <rdfs:range rdf:resource = '#TarjetaCredito'/> <rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#InverseFunctionalProperty'/> </owl:ObjectProperty>
<owl:DatatypeProperty rdf:about = '#fecha'> <rdfs:domain rdf:resource = '#Cargo'/> <rdfs:domain rdf:resource = '#EstadoSolicitud'/> <rdfs:range rdf:resource = 'http://www.w3.org/2001/XMLSchema#string'/>
<rdf:type rdf:resource = 'http://www.w3.org/2002/07/owl#FunctionalProperty'/> </owl:DatatypeProperty>
≈ Capitulo 6. Pruebas
pág. 92
Una vez obtenido el archivo OWL fue posible importarlo con la herramienta Protégé con el fin de poder visualizar la ontología identificando las relaciones taxonómicas y no taxonómicas correspondientes al modelo conceptual del caso de estudio de informatización de una biblioteca. Las relaciones taxonómicas del modelo conceptual para el caso de estudio de informatización de una biblioteca se observan en la Figura 6-37. Las relaciones no taxonómicas del modelo conceptual para el caso de estudio de informatización de una biblioteca se observan en la Figura 6-38.
Figura 6-37. Relaciones taxonómicas para el caso de estudio informatización de una biblioteca.
Figura 6-38. Relaciones no taxonómicas para el caso de estudio informatización de una biblioteca.
≈ Capitulo 6. Pruebas
pág. 93
6.5 Resultados obtenidos de la ejecución de los casos de estudio.
Como se puede muestra en la Tabla 8, al aplicar las reglas de transformación se obtuvieron los archivos OWL con sintaxis XML/RDF correspondientes a las pruebas realizadas. El tiempo de ejecución no es directamente proporcional al número de clases y/o relaciones en los modelos de entrada ya que para un modelo de entrada con 21 clases el tiempo de ejecución es de un segundo mientras que para un modelo con 256 clases (12 veces más grande), el tiempo de ejecución fue de únicamente dos segundos.
Ca
so d
e e
stu
dio
Mo
delo
de
en
tra
da
Gen
era
ció
n d
e
arc
hiv
o O
WL
Nú
mero
de
cla
ses
Nú
mero
de
sub
cla
ses
Nú
mero
de
rela
cio
nes
Rela
cio
nes
taxo
nó
mic
as
Rela
cio
nes
no
taxo
nó
mic
as
Tie
mpo
de
eje
cu
ció
n (
seg.)
Impo
rta
do p
or
Pro
tégé
1 Ontología
DBPedia Sí 256 228 228 228 0 2 Sí
2
Modelo
conceptual PAP
Sí 21 10 20 10 10 1 Sí
3
Modelo
conceptual
Restaurant
Sí 7 2 6 2 4 1 Sí
4 Modelo
conceptual
Aerolínea
Sí 8 2 5 2 3 1 Sí
5
Modelo
conceptual
JuegoSapiens
Sí 14 6 16 6 10 1 Sí
6
Modelo
conceptual
Estudiante
Sí 10 3 13 3 10 1 Sí
7
Modelo
Conceptual
Banco
Sí 12 3 14 3 11 1 Sí
8
Modelo
conceptual
Biblioteca
Sí 5 0 4 0 4 1 Sí
Tabla 8. Resumen de resultados de la ejecución de los casos de estudio.
≈ Capitulo 6. Pruebas
pág. 94
6.5. Análisis de resultados
En todas las pruebas funcionales de la herramienta desarrollada en esta tesis se generaron los documentos esperados (.Ecore y .owl). Las pruebas aplicadas en el prototipo fueron evaluadas de acuerdo a la cantidad de ontologías esperadas, a la validación de que el documento OWL pudiera ser abierto con la herramienta Protégé para su visualización y que la ontología resultante representara la misma semántica en ambos espacios tecnológicos es decir, que el nombre de las clases y relaciones fuera el mismo en ambos modelos, de la misma forma que las relaciones fueran equivalentes en los modelos fuente y destino. De acuerdo a los resultados obtenidos, es posible generar ontologías formadas tanto por relaciones taxonómicas (que es el caso más común en el diseño de ontologías) como no taxonómicas. La presencia o ausencia de una u otra de estas relaciones no afecta el rendimiento de la herramienta, de igual forma, el desempeño no se ve afectado por la adición de atributos en el modelo de clases de UML. La robustez de la herramienta se puso a prueba al introducir un modelo de clases de UML con 256 clases pudiéndolo convertir en aproximadamente dos segundos, lo que garantiza que la herramienta es estable. Los problemas encontrados fueron que el Framework Eclipse no permitió el uso de clases de asociación para el caso de estudio de la aerolínea, lo que consideramos una limitante de dicho Framework.
pág. 95
7 Conclusiones Este capítulo resume las conclusiones obtenidas como resultado de la investigación, las aportaciones y propuestas de trabajos que podrían derivarse en el futuro a partir de l presente trabajo de investigación. Finalmente se presenta un apartado acerca de las lecciones aprendidas durante el proceso de investigación.
≈ Capitulo 7. Conclusiones
pág. 96
7.1 Conclusiones
Una de las tareas fundamentales en el desarrollo de la Web Semántica es la construcción de ontologías, que permiten representar el conocimiento necesario para etiquetar semánticamente el contenido de las páginas Web. Sin embargo, esta tarea es uno de los principales obstáculos para la adopción de la Web Semántica. Ahora, para poder tener una página o portal semántico es necesario anotar semánticamente el sitio utilizando ontologías, sin embargo este es un proceso no trivial para usuarios no expertos en Web Semántica, ya que actualmente el proceso de creación de una ontología requiere la utilización de herramientas tales como Protégé o Top Braid que presentan un medio complejo para crear ontologías para usuarios no expertos en el dominio. Es necesario hacer notar que la especificación formal de una ontología ha sido desarrollada para ser entendible por sistemas de software, por lo que los lenguajes de ontologías como RDFS, OWL, etc. no son de dominio general de los ingenieros de software, al menos no de aquellos no expertos en el manejo de ontologías. El objetivo principal de esta investigación fue desarrollar un proceso sistemático para la generación de ontologías OWL a partir de diagramas de clases de UML. Consideramos que UML es una buena opción para iniciar el proceso de conceptualización de una ontología debido que UML es fácil de entender debido a su naturaleza gráfica [Kabilan, 2005]. Con la finalidad de contar con un proceso sistemático y riguroso, la metodología propuesta para la generación de ontologías considera un enfoque MDA que involucra el manejo de varias tecnologías y especificaciones que la OMG (Object Management Group) acepta y reconoce por su factibilidad. Es importante hacer notar que el objetivo de la tesis consiste en intentar reducir la complejidad en la construcción de ontologías y no solamente dar un medio gráfico para la creación de ontologías. De hecho, aunque por ejemplo Protégé proporcionara un medio para crear las ontologías de manera visual de la misma forma que se visualiza las ontologías al final del proceso, eso sólo resolvería la creación de clases y relaciones taxonómicas pero no de relaciones no taxonómicas ni de de propiedades de clase ni de objeto, para los cuales Protegé no tiene ni siquiera un medio jerárquico de visualización. Lo complejo de esta investigación reside en el manejo de varias tecnologías y especificaciones así como también el trabajar en distintos espacios tecnológicos como lo son MDA, XML y OWL. El resultado obtenido es confiable permitiendo un trabajo que cumple con las características deseadas tanto para los usuarios novatos en el desarrollo de ontologías como para las usuarios expertos en el desarrollo de ontologías ya que se permite que la ontología obtenida pueda ser refinada por herramientas tales como Protégé, la cual se incluyó en el IDE de Eclipse con el fin de asegurar contar con un entorno completo de generación de ontologías basado en Eclipse. El uso de MDA enfatiza el rol del modelado conceptual como medio para conectar y capturar las demandas de los usuarios en el desarrollo de sistemas en una forma sistemática y rigurosa. Es importante hacer notar que existen algunos trabajos que tienen nuestro mismo objetivo, sin embargo estos trabajos no realizan la transformación entre modelos utilizando MDA con lo cual no es posible asegurar que las reglas de transformación sean totalmente confiables. El uso de MDA también permite que el significado de las reglas de transformación sea claro y pueda ser interpretada por otros desarrolladores que desean extender la herramienta presentada en esta tesis. Las pruebas realizadas permitieron evaluar que la herramienta generada es estable y que escala perfectamente a un número creciente de clases y relaciones en el modelo UML.
≈ Capitulo 7. Conclusiones
pág. 97
Las transformaciones entre modelos llevadas a cabo en esta tesis se realizaron mediante el lenguaje de transformación ATL [ATLAS, 2006] el cual es un lenguaje híbrido ya que trabaja con construcciones declarativas e imperativas. Como consecuencia de esta investigación, se conocieron las características, ventajas y limitaciones del lenguaje ATL. Ventajas como el hecho de que cuenta con la comunidad más grande de desarrolladores en ese lenguaje en comparación a otro lenguaje de transformación entre modelos como lo es QVT, lo que significa mayor documentación. Además cuenta con un soporte maduro de los espacios tecnológicos de XML, EMF y MOF. Como desventajas se puede mencionar que las transformaciones llevadas a cabo sólo se realizan en una dirección es decir del modelo fuente al modelo destino pero no a la inversa por lo que puede haber elementos en el modelo de entrada que no tengan un elemento correspondiente en el modelo de salida con la consecuente pérdida de estructura y trazabilidad [Colomb, 2004].
7.2 Aportaciones El trabajo que se presenta en esta tesis ofrece las siguientes aportaciones: a) el uso de un proceso sistemático para la generación de ontologías mediante MDA que garantiza la confiabilidad en la generación de las mismas b) proporciona una notación visual para la generación de ontologías al conceptualizarlas mediante diagramas de clases de UML c) evitar la curva de aprendizaje de herramientas para la generación de ontologías aprovechando el uso masivo de las herramientas de UML. El uso del modelado conceptual a través de los diagramas de clases de UML para representar ontologías resuelve problemas tales como la falta de un lenguaje estándar para la representación de ontologías. El uso de los diagramas de clases de UML para la representación de ontologías resuelve este problema ya que es ampliamente aceptado y su uso continúa aumentando. La especificación formal de una ontología no es entendible por humanos. Los lenguajes de ontologías como RDFS, OWL, etc. pueden ser entendibles por las máquinas pero no por humanos al menos fuera del dominio de los expertos de las ontologías. UML por otro lado es fácil de entender debido a su naturaleza gráfica [Kabilan, 2005].
7.3 Trabajos futuros El trabajo de investigación presentado comprende la generación de ontologías en OWL a partir de diagramas de clases de UML mediante MDA, algunas propuestas de trabajos que podrían desprenderse de esta tesis se listan a continuación:
Diseñar el metamodelo que conforme las especificaciones de ODM (Ontology Definition
Metamodel) para dar soporte al lenguaje OWL en su versión 2.0.
El uso de más elementos o primitivas de los diagramas de UML a los cuales no se les pudo dar
soporte en esta investigación ya sea porque existen algunos elementos en los diagramas que no
tienen correspondencia con los elementos de las ontologías en OWL o bien porque no se
consideraron esenciales en la tesis. En la Tabla 9 se listan los elementos excluidos en la
investigación.
≈ Capitulo 7. Conclusiones
pág. 98
Constructor
UML
Descripción Primitiva
Diagramas de
estructura
compuesta
Un diagrama de estructura
compuesta muestra la estructura
interna de un clasificador,
incluyendo sus puntos de
interacción a otras partes del
sistema.
Puerto
Un Puerto puede especificar los
servicios que un clasificador
provee así como también los
servicios que este requiere de su
entorno.
Interfaces
Las interfaces son clases
abstractas, esto es, que no se
pueden crear instancias
directamente a partir de ellas.
Realización
La realización significa que una
clase implementa los atributos y
operaciones especificados por la
interfaz.
Operaciones
Las operaciones o métodos
representas las acciones
realizadas por las clases.
Clases
parametrizadas
Una clase en la cual se
especifican los parámetros que deben ser pasados a la clase para
que esta pueda ser instanciada.
Plantillas
Las clases pueden tener plantillas,
un valor usado para una clase no
especificada o un tipo.
Dependencias
Es una relación para denotar la
dependencia que tiene una clase
de otra, como por ejemplo una
aplicación grafica que instancia una ventana
Tabla 9. Elementos de UML excluidos de la transformación.
Utilizar otros diagramas de UML como pueden ser los diagramas de actividades con el fin de
generar una ontología más completa
≈ Capitulo 7. Conclusiones
pág. 99
7.4 Lecciones aprendidas El desarrollo dirigido por modelos representado por MDA y la representación del conocimiento basado en ontologías representado por la Web semántica, son la visión primaria en la industria de las tecnologías de la información (TI) para el desarrollo del software y la Web respectivamente. Sin embargo, ya que las aplicaciones de software se están volviendo cada vez más basadas en Web y las aplicaciones Web requieren cada vez más de “inteligencia”, es claro que estas tecnologías necesitarán trabajar más y más a la par en el futuro. La OMG propuso un metamodelo para la definición de ontologías (ODM) [OMG, 2003] dentro del Framework de MDA con las siguientes características:
1. La definición de un nuevo metamodelo o perfil como una instancia de MOF.
2. Extensión directa del metamodelo de UML a través de la especialización de metaclases.
3. Extensión indirecta de UML al utilizar mecanismos de perfiles (ej. Estereotipos, etiquetas, etc.)
La idea central de esta tesis es que las características principales en la representación de los lenguajes de ontologías como OWL puedan agregarse a la suite de estándares de MDA al extender UML en una de estas tres formas.
Enumerando lo aprendido en la presente investigación tenemos:
1. Ambos paradigmas (UML y OWL) representan espacios tecnológicos diferentes con
mecanismos diferentes de implementación, sin embargo aún no se ha establecido si estas
diferencias son consecuencias fundamentalmente de los requerimientos para la representación
de modelos y ontologías o bien son el reflejo de sus historias de desarrollo y antecedentes.
2. Es posible aprovechar la intersección semántica que existe entre el espacio tecnológico de
UML y el espacio tecnológico OWL teniendo en cuenta que comparten conceptos similares
como por ejemplo, que las ontologías incluyen jerarquías del tipo clase/subclase, relaciones
entre las clases, definición de atributos de clases las cuales pueden ser modeladas con
diagramas de clases de UML utilizando constructores como generalización, asociaciones y
atributos.
Figura 7-1. Intersección de la representación de Modelos y Ontologías [Atkinson, 2004].
3. UML surgió específicamente como una herramienta de modelado de sistemas de software,
mientras que las ontologías tienen un dominio más amplio, al haber nacido como una
herramienta de modelado de conocimiento. Sin embargo, conceptualmente no existen limitante
≈ Capitulo 7. Conclusiones
pág. 100
para que UML pueda ser utilizada para modelar conocimiento y para que OWL pueda ser
utilizado para modelar un sistema de software [Atkinson, 2004]. De esta forma, nosotros
utilizamos esta característica para utilizar UML para modelar el conocimiento de un cierto
dominio.
4. En la práctica, si una ontología sólo contiene información taxonómica es conocida como
“ontología ligera” y si ésta ontología agrega información adicional acerca de su propiedades y
relaciones entonces se conoce como “ontología pesada” [Atkinson, 2004]. En ambos casos, un
usuario de UML instantáneamente reconocería una ontología como un modelo conceptual o de
dominio que puede expresarse con diagramas de clases de UML. La parte taxonómica sería
interpretada como una organización jerárquica mientras que las características de los atributos
y relaciones como varias formas de asociación y/o dependencias.
5. Una de las conclusiones interesantes de este trabajo es que la generación de modelos UML y
ontologías OWL comparte procesos muy similares Un ejemplo de esto es la guía para el
desarrollo de ontologías [Noy, 2004] cuyo proceso es idéntico al proceso que uno encuentra en
los libros de ingeniería de software para desarrollar modelos conceptuales utilizando diagramas
de clases de UML [Larman, 2002].
6. Las transformaciones entre modelos llevadas a cabo en esta tesis se realizaron mediante el
lenguaje de transformación ATL [ATLAS, 2006] el cual es un lenguaje híbrido ya que trabaja
con construcciones declarativas e imperativas. Como consecuencia de esta investigación, se
conocieron las características, ventajas y limitaciones del lenguaje ATL. Ventajas como el
hecho de que cuenta con la comunidad más grande de desarrolladores en ese lenguaje en
comparación a otro lenguaje de transformación entre modelos como lo es QVT, lo que
significa mayor documentación. Además cuenta con un soporte maduro de los espacios
tecnológicos de XML, EMF y MOF. Como desventajas se puede mencionar que las
transformaciones llevadas a cabo sólo se realizan en una dirección es decir del modelo fuente
al modelo destino pero no a la inversa por lo que puede haber elementos en el modelo de
entrada que no tengan un elemento correspondiente en el modelo de salida con la consecuente
pérdida de estructura y trazabilidad [Colomb, 2004].
Referencias
pág. 101
Referencias [Atkinson, 2004] Atkinson, C. “Unifying MDA and Knowledge Representation
Technologies", The Model-Driven Semantic Web Workshop (MDSW 2004), September, Monterey California, 2004.
[ATLAS, 2006] ATLAS group LINA & INRIA, ATL: Atlas Transformation Language
ATL. User Manual; Versión 9.7. 2006. [Berners-Lee, 2001] Berners-Lee T, Hendler J, Lassila O (2001) The semantic Web.
Scientific American. [Borst, 1997] Borst, W. N., Akkermans, J. M., and Top, J. L. 1997. Engineering
Ontologies. International Journal of Human-Computer Studies, 46: 365-406.
[Brockmas, 2004] Brockmans, S., Volz, R., Eberhart, A., and Loeffler, P. (2004). Visual
Modeling of OWL DL Ontologies us-ing UML. In (van Harmelen et al., 2004), pages 198–213.
[Brockmas, 2006] Brockmans, S., Colomb, R. M., Kendall, E. F., Wallace, E. K., Welty,
C. & Xie, G. T. (2006). A model driven approach for building OWL DL and OWL Full ontologies. In 5th International Semantic Web Conference (ISWC2006) (pp. 187–200) Springer LNCS 4273.
[Brown, 2004] Brown, “An introduction to Model Driven Architecture – Part I: MDA
and today‟s sys-tems”, http://www-106.ibm.com/developerworks/rational/library/3100.html, 2004.
[Budi, 2003] Bieberstein, Norbert, Bose Sanjay, Walker Lance, Lynch Angela:
Impact of service-oriented architecture on enterprise systems, organizational structures, and individuals. IBM SYSTEMS JOURNAL, 2005: 691-708.
[Castells, 2004] Castells Pablo, “La Web Semantica”, Escuela Politécnica Superior
Universidad Autónoma de Madrid, 2004. [Colomb, 2004] Colomb, R.M., Gerber, A., et al., Issues in Mapping Metamodels in the
Ontology Development Metamodel Using QVT. in The 1st International Workshop on the Model Driven Semantic Web (MSDW 2004), (Monterey, California,USA, 2004).
[Dean, 2004] M. Dean and G. Schreiber. OWL Web Ontology Language Reference.
Technical report, World Wide Web Consortium (W3C), Feb 2004. W3C Recommendation.
[Djuric, 2005] Dragan Djuric, Dragan Gasevic, Vladan Devedzic: “Ontology
Modeling and MDA”, in Journal of Object Technology, vol. 4, no. 1, January-February 2005, pp. 109-128. http://www.jot.fm/issues/issue_2005_01/article3.
Referencias
pág. 102
[Eclipse, 2009] The Eclipse Project. http://www.eclipse.org/ [EMF, 2004] EMF
(Eclipse Modeling Framework), http://www.eclipse.org/emf, 2004. [EMF, 2003] Budinsky, F., Steinberg, D., Merks, E., Ellersick, R. and Grose, T.
Eclipse Modeling Framework. Addison Wesley Professional, 2003. [Fernandez-Lopez, 1997] Fernandez-Lopez M, Gomez-Perez A, Juristo N (1997)
METHONTOLOGY: From Ontological Art Towards Ontological Engineering. Spring Symposium on Ontological Engineering of AAAI. Stanford University, California, pp 33-40.
[García-Magariño, 2007] García-Magariño, I., Gómez-Sanz, J.J., Pavón, J.: Representación de
las relaciones en los metamodelos con el lenguaje Ecore. In: Desarrollo de Software Dirigido por Modelos, DSDM 2007 (2007)
[Gásevic, 2004] Gásevic, D. et al: Converting UML to OWL ontologies, In
Proceedings of the 13th International WWW Conference, NY, USA (2004) forthcoming.
[Gruber, 1993] Gruber, T. R. 1993. A translation approach to portable ontology
specifications. Knowledge Acquisition, 5: 199-220. [Guizzardi, 2002] Guizzardi, G., Herre, H., Wagner, G. (2002). Towards Ontological
Foundations for UML Conceptual Models, 1st Int. Conf. on Ontologies, Databases and Applications of Semantics (ODBASE 2002), Springer LNCS 2519.
[Hanzala, 2007] Ali Khan Hanzala, Minhas, Abid Ali, “Representation of UML Activity Models as OWL Ontology”, Stockholm University, Department of Computer and Systems Sciences, http://su.diva-portal.org/smash/record.jsf?pid=diva2:178627.
[Insfrán, 2003] César Emilio Insfrán Pelozo, A Requirments Engineering Approach
for Object-Oriented Conceptual Modeling, Universidad Politécnica de Valencia, Information Systems and Computation Department, 2003.
[Jouault, 2005] Jouault, F, Kurtev, I: Transforming Models with ATL. In: Proceedings
of the Model Transformations in Practice Workshop at MoDELS 2005, Montego Bay, Jamaica.
[Jouault, 2006] Jouault, F, and Kurtev, I: On the Architectural Alignment of ATL and
QVT. In: Proceedings of ACM Symposium on Applied Computing (SAC 06), model transformation track, Dijon, Bourgogne, France. 2006.
[Kabilan, 2005] Kabilan V, Johannesson P. UML for Ontology Modeling and Interoperability. First International Workshop on Enterprise Modeling and Interoperability (INTEROP-EMOI 2004) collocated with Caise 2004, Riga. Proceedings available at CEUR workshop proceedings ISSN-1613-0073, Vol 125.
Referencias
pág. 103
[ [Kogut, 2002] P. Kogut, S. Cranefield, L. Hart, M. Dutra, K. Baclawski, M. Kokar, J.
Smith, UML for ontology development,The Knowledge Engineering Review 17 (1) (2002) 61–64.
[Larman, 2002] Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition), Prentice Hall.
[Marín, 2007] Marín B., Giachetti G., Pastor O. (2007). Intercambio de Modelos
UML y OO-Method. X Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes de Software (IDEAS‟07), pp. 283–296.
[Meth, 2003] Methods & Tools. Understanding the Model Driven Architecture
(MDA). Global knowledge source for software development profesionals. Otoño 2003 (Vol. 11, Nº 3).
[MOF, 2002] MOF: Meta Object Facility (MOF) Specification. OMG-Meta Object
Facility, V1.4, 2002. [Montilva, 2007] Montilva J.; Barrios, J.; Rivero, M.; Besembel, I.; Martínez, A.; B.
Sandia (2007); “Dinsoft: un programa de actualización profesional en ingeniería de software”. Actas de las VI Jornadas Científico-Técnicas de la Facultad de Ingeniería, Universidad de Los Andes, Mérida, Venezuela, 8-11 de Octubre, 2007. Área: Ingeniería de Sistemas-Ingeniería de Software, Artículo No. JI-IS-030, pp-1027-1035.
[Montilva, 2008] Montilva Jonás, Rivero Milagro, Barrios Judith, Martínez Ana,
Besembel Isabel, Sandia Beatriz. Un modelo organizacional holónico para la gestión de programas de formación profesional. Espacios. Vol. 29(3), 2008. Pag. 3.
[Noy, 2004] Noy, N.F. and McGuinness, D.L. (2004). A Guide to Creating Your
First Ontology, Knowledge Systems Laboratory, Stanford University. [ODM, 2004] ODM: Ontology Definition Metamodel,
http://www.omg.org/docs/ontology/04-08-01.pdf, 2004. [OMG, 2001] OMG. MDA® Specifications. [En línea] Object Management Group,
Inc. [Citado el: 13 de Febrero de 2008]. http://www.omg.org/mda/specs.htm#MDAGuide; http://www.omg.org/docs/ormsc/01-07-01.pdf.
[OMG, 2003] Object Management Group. Ontology Definition Metamodel -Request
For Proposal, March 2003. http://www.omg.org/docs/ontology/03-03-01.rtf.
[OMG, 2003] OMG, MDA Guide Version 1.0.1, June 2003, p.A-2 and p.2-2. [OMG, 2005] Object Management Group. Unified Modeling Language:
Superstructure. Technical Report Version 2.0, August 2005.
Referencias
pág. 104
[Pan, 2006] Y. Pan, G. Xie, L. Ma, Y. Yang, Z. Qiu, and J. Lee. Model-Driven
Ontology Engineering. Journal on Data Semantics, pages 57–78, 2006. [QVT-RFP, 2002] OMG, MOF 2.0 Query/Views/Transformations RFP, OMG document
ad/2002-04-10 (2002). [Rosso, 2001] P. Rosso. Diseño, desarrollo y evaluación de un Sistema de Decisión y
Soporte: La Metodología MAKAVAS. Revista Colombiana de Computación – RCC. Vol 2, No. 1. 2001.
[Silva, 2007] F. Silva Parreiras, S. Staab, and A. Winter. TwoUse: Integrating UML
models and OWL ontologies. Technical Report 16/2007, Universit¨at Koblenz-Landau, Fachbereich Informatik, 4 2007.
[W3C OWL 1999] W3C, “Resource Description Framework (RDF) especificación del
modelo y la sintaxis” http://www.w3.org/TR/1999/REC-rdf-syntax-
19990222, 1999. [W3C OWL 2002] W3C, “XML Extensible Markup Language”
http://www.w3.org/XML/, 2002. [W3C OWL 2004] W3C, “OWL Web Ontology Language Overview”, W3C
Recommendation 10 February 2004. http://www.w3.org/TR/owl-features.
Anexo
pág. 105
Anexo A Ontología DBPedia (original)
Anexo
pág. 106
Ontología DbPedia representada mediante el prototipo propuesto
Anexo
pág. 107
Anexo
pág. 108
Ontología DBPedia representada por Protégé a partir del archivo generado por el prototipo.
Anexo
pág. 109
Anexo
pág. 110