TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx20Juan%20... · cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE

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


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].


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


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


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.


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].


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.


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.


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”.


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>


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.


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


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


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


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


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


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>


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.


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#">


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.


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#')}


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 “#”.


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>

...


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.



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)}


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.


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"/>


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.



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)}


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.



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>


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.



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 )}


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.


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.


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


pág. 39

( Pr _ ) ( _ )

( . ' : Pr ')

( _ ) ( _ )

( . ' : ')

( . "#" . )

( _ ) (

x x opiedadTipoDeDato Ecore y y elemento XmlRdf

y nombre owl Datatype operty


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.


Figura 4-34. Formalización de regla 10.



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.


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)}


pág. 41

( _ ) ( _ )

( . ' : ')

( _ ) ( _ )

( . ' : ')

( . . )

( _ ) ( _ )

( .

x x valorDeDato Ecore y y elemento XmlRdf

y nombre owl DataValue


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.



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)}


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.


<owl:ObjectProperty rdf:ID="madeFromGrape"> <rdfs:domain rdf:resource="#Wine"/> <rdfs:range rdf:resource="#WineGrape"/>

</owl:ObjectProperty>


pág. 43


Figura 4-42. Regla PropiedadUML_A_PropiedadObjeto.


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.


( _ ) ( _ )

( . . )

( . . . '#' . )

( . ) [( . 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()}


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-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"/>



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.



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,)}


pág. 46

( _ ) ( _ )

( _ ) ( _ )

( . ' : Pr ') ( . ' : ')

( . "#" . )

( _ ) ,

x x propiedadTipoDeDato Ecore y y elemento 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”.





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>


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.




Figura 4-52. Regla restricción de cardinalidad.


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.



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”.


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)}


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-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).


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() )}


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


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.




Figura 4-57. Regla restricción de cardinalidad mínima.


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 {


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 cardinalidad x lower


pág. 51

( _ ) , ( , _ )

( _ ) ( _ )

( . ' : ')

( _ ) ( _ )

. ' : '

( .


z z restriccionCardinalidadMinima Ecore q q elemento XmlRdf

x nombre owl Class


r nombre rdf about

r valor

'#' . )

. ' : '

( _ ) ( _ ( ))

( . ' : Re ')

( _ ) , ( , _ ( , ))

, ( , _ ) ,

w nombre





t u t u elemento XmlRdf o

( , _ )

( . ' : Pr ') ( . ' : ') ( . '#' . Pr )

( . ' : min ') ( . ' : ') ( . . )

(

p o p atributo XmlRdf



z z restriccionCardinali

_ ) ( _ )

( . .min )

dadMinima Ecore v v texto XmlRdf


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.













“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.





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


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.


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>


pág. 53


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.










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 {


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


pág. 54





“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.




( _ ) , ( , _ )

( _ ) ( _ )

( . ' : ')

( _ ) ( _ )

. ' : '

( .


z z restriccionCardinalidadMaxima Ecore q q elemento XmlRdf

x nombre owl Class


r nombre rdf about

r valor

'#' . )

. ' : '

( _ ) ( _ ( ))

( . ' : Re ')

( _ ) , ( , _ ( , ))

, ( , _ ) ,

w nombre





t u t u elemento XmlRdf o

( , _ )

( . ' : Pr ') ( . ' : ') ( . '#' . Pr )

( . ' : max ') ( . ' : ') ( . . )

(

p o p atributo XmlRdf



z z restriccionCardinali

_ ) ( _ )

( . .max )

dadMaxima Ecore v v texto XmlRdf



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.


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>


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.




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.


Lazy rule todosValoresDeRestriccionDeClase {


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 allValuesFromClass x ownedAssociationEnd


pág. 57


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


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.




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.




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


pág. 59


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.



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>


pág. 60



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.





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


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


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>


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 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.





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


pág. 63

Figura 4-84. Regla propiedad funcional inversa 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»


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.


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í


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


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.


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


pág. 68

Tabla 7. Propiedades de CU-4 Generara archivo OWL

ID: CU-4 Generar archivo OW L


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.



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.


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.


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.

http://wiki.dbpedia.org/Ontology

http://wiki.dbpedia.org/Ontology


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).


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>


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.


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>


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.


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'/>



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.


pág. 80

Figura 6-14. Modelo conceptual para el caso de estudio de una aerolínea.





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>


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.


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'/>



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.


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.




pág. 86


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'/>



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.


pág. 88


Figura 6-30. Diagrama de clases del caso de estudio de un banco replicado por el prototipo propuesto.



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'/>



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



pág. 91

Figura 6-35. Diagrama de clases del caso de estudio de informatización de una biblioteca.


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>


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.


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.


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.


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.


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


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


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.

http://su.diva-portal.org/smash/record.jsf?pid=diva2:178627

http://su.diva-portal.org/smash/record.jsf?pid=diva2:178627

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.

http://www.w3.org/TR/owl-features

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

Documents

TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx20Juan%20... · cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE