• Like
Generador semiautomático de perfiles de usuario mediante OWL
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Generador semiautomático de perfiles de usuario mediante OWL

  • 240 views
Published

La identificación de las preferencias del usuario en función de su perfil (su edad, …

La identificación de las preferencias del usuario en función de su perfil (su edad,
gustos, nivel socioeconómico, nivel cultural, y de conocimientos en un área
específica), permitirá a la siguiente generación de aplicaciones Web 3.0 y de
sistemas de recomendación contextuales, por un lado, personalizar los contenidos
Web de acuerdo al perfil del usuario y por otro, presentar resultados pertinentes
para el mismo.
Los perfiles de usuarios son una importante herramienta para personalizar
respuestas y entornos. Por lo anterior, en este documento se presenta una
metodología innovadora basada en el uso de ontologías definidas con lenguaje
OWL y agrupamientos de secciones de información en clústeres y mecanismos de
deducción que minimizan de manera significativa el atosigamiento e intrusión en
el proceso de extracción de información personal del usuario.
Esta metodología permite identificar, clasificar y agrupar componentes del perfil
del usuario en una base de datos semántica que permitirá a diversas aplicaciones
explotar esta información para la personalización de contenidos Web.
Además, esta base de datos semántica también podrá ser utilizada para la
selección de resultados pertinentes en búsquedas contextuales de servicios.

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
240
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
6
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias ComputacionalesTESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN Generador semiautomático de perfiles de usuario mediante OWL presentada por Christian Eloy Rojas Roldán Ing. en Sistemas Computacionales por el I. T. de Acapulco como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación Director de tesis: Dr. Juan Gabriel González Serna Jurado: Dr. Javier Ortiz Hernández – Presidente Dra. Azucena Montes Rendón – Secretario M.C. Hugo Estrada Esquivel – Vocal Dr. Juan Gabriel González Serna – Vocal SuplenteCuernavaca, Morelos, México. 15 de Septiembre de 2009Rojas, Christian i
  • 2. DEDICATORIA A Dios, por todas las bendiciones otorgadas A mis padres: Dr. Eloy Mario Rojas Nava y Dra. Aida Roldán Monroy, como insignificante retribución a todo lo que sin reparos me han puesto en las manos. A mi novia Xiomara, por todo el apoyo y alegría. A mi hermano, por apoyarme en lo que necesité, este triunfo también es tuyo.Rojas, Christian ii
  • 3. AGRADECIMIENTOSA Dios. Siempre primero.A mis padres, por tanta paciencia, apoyo, y por enseñarme con amor y ejemploque todo es posible cuando te lo propones. A mi hermano que nunca dijo un no,cuando lo necesité. Sin ellos nunca lo hubiera logrado.A mi novia Xiomara, que con su sonrisa alegró cada día desde el principio hasta elfin. Por contagiarme de su paciencia y ser mi compañera.Al Centro Nacional de Investigación y Desarrollo Tecnológico por permitirme un lugarentre sus alumnos y obtener mis estudios de maestría.Al Consejo Nacional de Ciencia y Tecnología por la beca para manutención otorgaday por permitirme conocer el viejo continente con excelente compañía.A mi director de tesis Dr. Juan Gabriel González Serna, por haberme elegido como sutesista, por todas esas horas de paciencia otorgadas, por la amabilidad yrespetuosidad que lo caracterizan y sobre todo por ser un buen amigo.A mis revisores de tesis: Dr. Hugo Estrada Esquivel, Dra. Azucena Montes Rendón,Dr. Javier Ortíz Hernández, por todas las recomendaciones, apoyo y tiempo dedicadoA mi gente de Acapulco, abuelos, tíos, primos, amigos, que siempre me obsequiaronánimos, oraciones, suerte y bienestar cada vez que partía de regreso a mis labores.A esos compañeros de generación que ahora son amigos: Israel, Rubi, Omar, Yanet,Jose Luis e Itzel por todos los buenos ratos que pasamos juntos y en especial porhaber mitigado la tristeza de no pasar navidad y fin de año con la familia, cuandoEspaña fue nuestro hogar.Aunque me resulta imposible agradecer en solo este espacio a todas esas personasque hicieron posible éste logro. A todos ellos:Rojas, Christian iii
  • 4. RESUMENLa identificación de las preferencias del usuario en función de su perfil (su edad,gustos, nivel socioeconómico, nivel cultural, y de conocimientos en un áreaespecífica), permitirá a la siguiente generación de aplicaciones Web 3.0 y desistemas de recomendación contextuales, por un lado, personalizar los contenidosWeb de acuerdo al perfil del usuario y por otro, presentar resultados pertinentespara el mismo.Los perfiles de usuarios son una importante herramienta para personalizarrespuestas y entornos. Por lo anterior, en este documento se presenta unametodología innovadora basada en el uso de ontologías definidas con lenguajeOWL y agrupamientos de secciones de información en clústeres y mecanismos dededucción que minimizan de manera significativa el atosigamiento e intrusión enel proceso de extracción de información personal del usuario.Esta metodología permite identificar, clasificar y agrupar componentes del perfildel usuario en una base de datos semántica que permitirá a diversas aplicacionesexplotar esta información para la personalización de contenidos Web.Además, esta base de datos semántica también podrá ser utilizada para laselección de resultados pertinentes en búsquedas contextuales de servicios.Rojas, Christian iv
  • 5. ÍNDICELista de figuras ................................................................................................................................. ixLista de tablas.................................................................................................................................... xLista de Gráficos ............................................................................................................................... xGlosario de términos y siglas ......................................................................................................... xi1. Capítulo I. Introducción ............................................................................................................ 1 1.1 Introducción ......................................................................................................................... 2 1.2 Descripción del problema .................................................................................................... 2 1.3 Objetivo ............................................................................................................................... 3 1.4 Justificación ......................................................................................................................... 4 1.5 Beneficios ............................................................................................................................ 8 1.6 Trabajos relacionados ......................................................................................................... 8 1.6.1 Principios de marketing ............................................................................................... 8 1.6.2 Improving Ontology-Based User Profiles .................................................................... 9 1.6.3 Learning implicit user interest hierarchy for context in personalization ..................... 10 1.6.4 Need for Context-Aware Topographic Maps in Mobile Devices................................ 11 1.6.5 Matching Users Semantics with Data Semantics in Location-Based Services ........ 11 1.6.5.1 Perfil de usuario ..................................................................................................................................11 1.6.5.2 Perfiles de datos .................................................................................................................................12 1.6.6 Exploiting Hierarchical Relationships in Conceptual search ..................................... 12 1.6.7 SOUPA: Standard ontology for ubiquitous and pervasive applications .................... 12 1.6.7.1 SOUPA Core.......................................................................................................................................13 1.6.7.2 SOUPA Extensión ...............................................................................................................................13 1.6.8 A MDD strategy for developing context-aware pervasive systems ........................... 13 1.6.9 Categorizaciones independientes de un Usuario. ..................................................... 14 1.6.9.1 GEEK ..................................................................................................................................................14 1.6.9.2 AKTORS .............................................................................................................................................15 1.6.9.3 Amigo de un amigo (FOAF: FRIEND Of A Friend)...............................................................................15 1.7 Alcance del proyecto de tesis ............................................................................................ 17 1.8 Organización del documento ............................................................................................. 17Capítulo II. Marco teórico ............................................................................................................... 18 2.1 Conceptos semánticos ...................................................................................................... 20 2.1.1 OWL........................................................................................................................... 20 2.1.2 RDF ........................................................................................................................... 20 2.1.3 W3C ........................................................................................................................... 21 2.1.4 Ontología ................................................................................................................... 21 2.2 Conceptos generales ........................................................................................................ 22 2.2.1 XSD ........................................................................................................................... 22Rojas, Christian v
  • 6. 3. Capítulo III. Análisis y diseño ................................................................................................. 23 3.1 Análisis .............................................................................................................................. 24 3.1.1 Análisis de operación con clases .............................................................................. 25 3.1.2 Estructura de URI´s (Uniform Resource Indicator). .................................................. 37 3.1.2.1 Árbol de abstracción de nombres ........................................................................................................38 3.1.3 Manejo de tipos ......................................................................................................... 40 3.1.4 Análisis de la interfaz................................................................................................. 42 3.1.4.1 Dominio Básico. ..................................................................................................................................43 3.1.4.2 Dominio Médico ..................................................................................................................................43 3.1.4.3 Dominio Familiar .................................................................................................................................43 3.1.4.4 Dominio Profesional ............................................................................................................................44 3.1.4.5 Dominio Educativo ..............................................................................................................................44 3.2 Diseño ............................................................................................................................... 44 3.2.1 Actividades del proyecto............................................................................................ 48 3.2.1.1 Conexión con ontología.......................................................................................................................48 3.2.1.2 Usuario nuevo .....................................................................................................................................49 3.2.1.3 Usuario existente ................................................................................................................................50 3.2.1.4 Guardado en ontología........................................................................................................................51 3.2.1.5 Modificar en ontología .........................................................................................................................53 3.2.1.6 Eliminado de ontología ........................................................................................................................54 3.2.1.7 Elección de dominio ............................................................................................................................55 3.2.1.8 Elección de operación en ontología.....................................................................................................554. Capítulo IV. Desarrollo de la solución ................................................................................... 55 4.1 Recopilación, discriminación e integración de datos ........................................................ 58 4.2 Estructura de la ontología ................................................................................................. 61 4.2.1 Núcleo........................................................................................................................ 62 4.2.2 Extensibilidad ............................................................................................................ 62 4.2.2.1 Extensibilidad satelital .........................................................................................................................63 4.2.2.1.1 Ejemplo .......................................................................................................... 64 4.2.2.1.2 Formalización de extensibilidad satelital........................................................ 65 4.2.2.2 Extensibilidad parcial ..........................................................................................................................66 4.2.2.2.1 Ejemplo .......................................................................................................... 67 4.2.2.2.2 Formalización de extensibilidad parcial ......................................................... 69 4.2.2.3 Extensibilidad nuclear .........................................................................................................................70 4.2.2.3.1 Ejemplo .......................................................................................................... 71 4.2.2.3.2 Formalización de extensibilidad nuclear. ....................................................... 725. Capítulo V. Implementación ................................................................................................... 75 5.1 Conexión con ontología ..................................................................................................... 76 5.2 Usuario nuevo y usuario existente .................................................................................... 77Rojas, Christian vi
  • 7. 5.3 Volcado de ontología ......................................................................................................... 79 5.4 Guardado de ontología ...................................................................................................... 80 5.5 Lectura y modificación de ontología .................................................................................. 82 5.6 Eliminar ontología .............................................................................................................. 826. Capítulo VI. Pruebas................................................................................................................ 85 6.1 Introducción ....................................................................................................................... 86 6.2 Descripción del Plan .......................................................................................................... 86 6.2.1 Características a ser probadas ................................................................................. 86 6.2.2 Características excluidas de las pruebas .................................................................. 87 6.2.3 Enfoque ..................................................................................................................... 87 6.2.4 Criterio pasa/ no pasa de casos de prueba. ............................................................. 87 6.2.5 Criterios de suspensión y requerimientos de reanudación. ...................................... 87 6.2.6 Tareas de pruebas. ................................................................................................... 87 6.2.7 Liberación de pruebas. .............................................................................................. 88 6.2.8 Requisitos ambientales. ............................................................................................ 88 6.2.9 Responsabilidades. ................................................................................................... 88 6.2.10 Riesgos y contingencias. ........................................................................................... 88 6.3 Casos de Pruebas. ............................................................................................................ 89 6.3.1 Características a probar ............................................................................................ 89 6.3.2 Grupos de pruebas .................................................................................................... 89 6.3.2.1 Operación con la ontología .................................................................................................................89 6.3.2.2 Estructuración ontológica ....................................................................................................................89 6.3.2.3 Enlace con ontología ...........................................................................................................................89 6.3.2.4 Elección de dominio de la aplicación ...................................................................................................89 6.3.3 Procedimiento de Pruebas ........................................................................................ 89 6.4 USOG-101 Pruebas de operación con la ontología .......................................................... 90 6.4.1 Propósito ................................................................................................................... 90 6.4.2 Entorno de prueba. .................................................................................................... 90 6.4.3 USOG-101-001 Lectura de la ontología .................................................................... 90 6.4.3.1 Propósito.............................................................................................................................................90 6.4.3.2 Entorno de prueba. .............................................................................................................................90 6.4.3.3 Proceso...............................................................................................................................................90 6.4.3.4 Resultado esperado. ...........................................................................................................................90 6.4.4 USOG-101-002 Escritura en ontología ..................................................................... 91 6.4.4.1 Propósito.............................................................................................................................................91 6.4.4.2 Entorno de prueba. .............................................................................................................................91 6.4.4.3 Proceso...............................................................................................................................................91 6.4.4.4 Resultado esperado. ...........................................................................................................................91 6.4.5 USOG-101-003 Eliminado de la ontología ................................................................ 91Rojas, Christian vii
  • 8. 6.4.5.1 Propósito.............................................................................................................................................91 6.4.5.2 Entorno de prueba. .............................................................................................................................91 6.4.5.3 Proceso...............................................................................................................................................91 6.4.5.4 Resultado esperado. ...........................................................................................................................91 6.4.6 USOG-201 Pruebas de estructuración ontológica .................................................... 91 6.4.6.1 Propósito.............................................................................................................................................91 6.4.6.2 Entorno de prueba. .............................................................................................................................92 6.4.7 USOG-201-001 Estructuración de individualizaciones ............................................. 92 6.4.7.1 Propósito.............................................................................................................................................92 6.4.7.2 Entorno de prueba. .............................................................................................................................92 6.4.7.3 Proceso...............................................................................................................................................92 6.4.7.4 Resultado esperado. ...........................................................................................................................92 6.4.8 USOG-301 Prueba de enlace con ontología ............................................................. 92 6.4.8.1 Propósito.............................................................................................................................................92 6.4.8.2 Entorno de prueba. .............................................................................................................................92 6.4.9 USOG-301-001 Conexión con ontología................................................................... 93 6.4.9.1 Propósito.............................................................................................................................................93 6.4.9.2 Entorno de prueba. .............................................................................................................................93 6.4.9.3 Proceso...............................................................................................................................................93 6.4.9.4 Resultado esperado. ...........................................................................................................................93 6.4.10 USOG-401 Prueba de elección del dominio de la aplicación ............................... 93 6.4.10.1 Propósito.............................................................................................................................................93 6.4.10.2 Entorno de prueba. .............................................................................................................................93 6.4.11 USOG-401-001 Elección del dominio de la aplicación ............................................. 93 6.4.11.1 Propósito.............................................................................................................................................93 6.4.11.2 Entorno de prueba. .............................................................................................................................93 6.4.11.3 Proceso...............................................................................................................................................94 6.4.11.4 Resultado esperado. ...........................................................................................................................94 6.5 Pruebas ............................................................................................................................. 94 6.4.1 Pruebas Funcionales ................................................................................................. 95 6.4.2 Pruebas operativas .................................................................................................. 106 6.5 Observaciones generales ................................................................................................ 136Capítulo VII. Conclusiones ........................................................................................................... 139 7.1 Conclusiones ................................................................................................................... 140 7.2 Aportaciones .................................................................................................................... 141 7.3 Trabajos futuros............................................................................................................... 142 7.4 Publicaciones .................................................................................................................. 143Bibliografía ..................................................................................................................................... 144Anexo 1 ........................................................................................................................................... 147Anexo 2 ........................................................................................................................................... 148Rojas, Christian viii
  • 9. LISTA DE FIGURASFigura 1.1 Perspectiva de SOUPA + CoBrA para modelar a un usuario. ........................................... 4Figura 1.2 Perspectiva de GEEK para modelar a un usuario ............................................................. 5Figura 1.3 Perspectiva de AKTORS para modelar a un usuario ........................................................ 6Figura 1.4 Perspectiva de FOAF para modelar a un usuario ............................................................. 7Figura 1.5 Mapa del comportamiento del comprador ......................................................................... 9Figura 1.6 Ontologías integrantes de SOUPA .................................................................................. 13Figura 3.1 Diagrama de bloques del proceso general del proyecto ................................................. 24Figura 3.2 Diagrama general de casos de uso ................................................................................. 25Figura 3.3 Diagrama de casos de uso de Operar con la ontología .................................................. 26Figura 3.4 Diagrama de actividad del caso de uso CU-1 Operar con la ontología ........................... 28Figura 3.5 Diagrama de actividad del caso de uso Elegir operación de altas, bajas y consultas .... 30Figura 3.6 Diagrama de actividad del caso de uso Elegir dominio de aplicación ............................. 32Figura 3.7 Diagrama de actividad del caso de uso Enlazar con la ontología ................................... 34Figura 3.8 Diagrama de casos de uso de Estructuración ontológica................................................ 35Figura 3.9 Diagrama de actividad del caso de uso Estructuración ontológica ................................. 36Figura 3.10 Identificador del atributo “nombre” de la ontología en protégé ...................................... 37Figura 3.11 Árbol de elementos de la ontología ............................................................................... 39Figura 3.12 Árbol de elementos de la ontología ............................................................................... 39Figura 3.13 Resultado del método para nombrar individualizaciones .............................................. 40Figura 3.14 Esquema de manejo de los tipos de datos .................................................................... 41Figura 3.15 Diagrama de clases del proyecto ................................................................................... 44Figura 3.16 Diagrama de clases del paquete mx.edu.cenidet.userontology.axiomsinference ......... 45Figura 3.17 Diagrama de clases del paquete mx.edu.cenidet.userontology.Front ........................... 47Figura 3.18 Diagrama de secuencias para la Conexión con la ontología ........................................ 49Figura 3.19 Diagrama de secuencias para ingresar al sistema como usuario nuevo ...................... 50Figura 3.20 Diagrama de secuencias para ingresar al sistema como usuario existente.................. 51Figura 3.21 Diagrama de secuencias del proceso Guardar ontología.............................................. 53Figura 3.22 Diagrama de secuencias del proceso Modificación de ontología .................................. 54Figura 3.23 Diagrama de secuencias del proceso Eliminación de la ontología ............................... 54Figura 4.1. Estructura ontológica ...................................................................................................... 60Figura 4.2. Enfermedades crónico-degenerativas en México ........................................................... 61Figura 4.3. Estructura de la clase “Minusvalía”. ................................................................................ 64Figura 4.4. Estructura de la clase “Ayuda_tecnica” .......................................................................... 64Figura 4.5. Esquema de “Extensibilidad satelital” ............................................................................. 65Figura 4.6. Esquema de extensibilidad parcial ................................................................................ 67Figura 4.7. Estructura de la clase “Contacto” .................................................................................... 68Figura 4.8. Estructura de la clase “Nivel_computo” .......................................................................... 68Figura 4.9. Relación y cobertura entre las clases “Nivel_computo” y “Contacto” ............................. 69Figura 4.10. Estructura de la clase “Personales” .............................................................................. 71Figura 4.11. Estructura de la clase “Origen” ..................................................................................... 71Figura 4.12. Esquema de extensibilidad nuclear .............................................................................. 72Figura 5.1. Conexión con ontología .................................................................................................. 77Figura 5.2. Autenticación de usuario.1 .............................................................................................. 77Figura 5.3. Autenticación de usuario.2 .............................................................................................. 78Figura 5.4. Autenticación de usuario.3 .............................................................................................. 79Figura 5.5. Volcado de datos a la ontología ...................................................................................... 80Figura 5.6. Relación de elementos en la ontología ........................................................................... 81Figura 5.7. Lectura de datos desde la ontología ............................................................................... 82Figura 5.8. Eliminación de datos en la ontología .............................................................................. 83Figura 6.1. Datos de la ontología en protégé .................................................................................... 95Figura 6.2. Autenticación invalida ..................................................................................................... 95Figura 6.3. Autenticación válida y elección de operación con ontología .......................................... 95Rojas, Christian ix
  • 10. Figura 6.4. Datos de la ontología en protégé .................................................................................... 96Figura 6.5. Creación de nuevo usuario y elección del dominio de aplicación .................................. 96Figura 6.6. Introducción de datos en el perfil .................................................................................... 97Figura 6.7. Datos en la ontología después de la operación .............................................................. 97Figura 6.8. Contenido de la instancia de la clase miembro en la ontología ..................................... 98Figura 6.9. Eliminación de un individuals en la ontología ................................................................. 99Figura 6.10. Resultado en la ontología después de la operación ..................................................... 99Figura 6.11. Guardado de datos ontológicos. ................................................................................. 100Figura 6.12. Árbol de abstracción de nombres de la ontología creada. ......................................... 100Figura 6.13. Estructuración ontológica de la ontología en protégé................................................. 101Figura 6.14. Contenido de password en la clase personales de la ontología ................................ 101Figura 6.15. Autenticación en la ontología existente ...................................................................... 102Figura 6.16. Cambio de contraseña en la ontología ....................................................................... 102Figura 6.17. Valores ontológicos posteriores a la operación. ......................................................... 103Figura 6.18. Autenticación y visualización de clases organizadas según el dominio de aplicaciónHospital ............................................................................................................................................ 104Figura 6.19. Dominio de aplicación antes de la operación ............................................................. 104Figura 6.20. Dominio de aplicación después de la operación ........................................................ 105Figura 6.21. visualización de clases organizadas según el dominio de aplicación Universidad .... 105LISTA DE TABLASTabla 1.1. Análisis comparativo del estado del arte.......................................................................... 16Tabla 3.1 Descripción del caso de uso Operar con la ontología ...................................................... 26Tabla 3.2 Descripción del caso de uso Elegir operación de altas, bajas y consultas ....................... 28Tabla 3.3 Descripción del caso de uso Elegir dominio de aplicación ............................................... 31Tabla 3.4 Descripción del caso de uso Enlazar con la ontología ..................................................... 32Tabla 3.5 Descripción del caso de uso Estructuración ontológica .................................................... 35Tabla 4.1. Recopilación de atributos pertinentes para perfilar a un usuario. .................................... 58Tabla 6.1 Tareas a desarrollar a las pruebas ................................................................................... 87Tabla 6.2. Caso de prueba: Lectura de la ontología ......................................................................... 95Tabla 6.3 Caso de prueba: Escritura en ontología............................................................................ 96Tabla 6.4 Caso de prueba: Eliminado de la ontología ...................................................................... 98Tabla 6.5 Caso De Prueba: Estructuración De Individualizaciones ................................................ 100Tabla 6.6 Caso De Prueba: Estructuración De Individualizaciones ................................................ 101Tabla 6.7 Caso De Prueba: Estructuración De Individualizaciones ................................................ 103LISTA DE GRÁFICOSGrafico 1 Clases Accedidas Por El Grupo De Prueba .................................................................... 137Grafico 2 Estadística de salida ........................................................................................................ 138Rojas, Christian x
  • 11. GLOSARIO DE TÉRMINOS Y SIGLASIEEE Institute of Electrical and Electronics Engineers (IEEE). Instituto de Ingenieros Eléctricos y Electrónicos, una asociación técnico-profesional mundial dedicada a la estandarización, entre otras cosas. Es la mayor asociación internacional sin fines de lucro formada por profesionales de las nuevas tecnologías, como ingenieros de telecomunicaciones, ingenieros electrónicos, ingenieros en informática e Ingenieros en computación.URI Un URI es una cadena corta de caracteres que identifica inequívocamente un recurso (servicio, página, documento, dirección de correo electrónico, enciclopedia, etc.). Normalmente estos recursos son accesibles en una red o sistema.Todas las definiciones se tomaron de [wiki09].Rojas, Christian xi
  • 12. 1. CAPÍTULO I. INTRODUCCIÓNEn este capítulo se presenta la descripción del problema que dio origen al presentetrabajo de tesis, su objetivo, justificación y beneficios. También los trabajosrelacionados. Y por último la organización del documento.
  • 13. Introducción1.1 INTRODUCCIÓNDebido a la inexactitud de los sistemas y estudios actuales para perfilar o modelar aun usuario real, se ha visto la necesidad de analizar las posibles categorizaciones delmismo, basadas en áreas como la mercadotecnia, psicología, y computación. Estocon la finalidad de obtener un conjunto de datos que permitan perfilar de un modoeficiente a un usuario en cuestión.Un simple documento legible por una persona y una lista de datos no son suficientes,por lo que se necesita un entorno de diseño en algún lenguaje procesable como lopuede ser (OWL/RDF) y alguna interfaz que permita la captura de estos datos.Uno de los principales intereses de este proyecto es entonces obtener una ontologíaque permita modelar a un usuario, así como sus costumbres, deficiencias, rolescotidianos y características, y poblarla mediante alguna interfaz gráfica de unambiente de desarrollo para poder instanciarla y explotarla.Debido a que la información obtenida del usuario será proporcionada de maneraexplícita, es decir, directamente por el usuario, se investigarán e implementarán unaserie de técnicas para evitar en la medida de lo posible la intrusión excesiva de susdatos, y por consiguiente obtener sólo los necesarios para un cierto dominio deaplicación, sin menoscabar la pertinencia de los mismos.1.2 DESCRIPCIÓN DEL PROBLEMALos perfiles de usuarios son una importante herramienta para personalizarrespuestas, entornos y evitar la intrusión excesiva de datos secundarios, así comopara minimizar costos por manejo de datos impertinentes.En el mercado se pueden encontrar distintas categorizaciones de usuario [Geek09][Akt08] [Miller00], sin embargo aunque cada una de ellas comparte en gran medida suconjunto de datos básico (nombre, edad, sexo, etc.), también poseen datosespecializados, que sólo poseerán aquellos usuarios que estén en el dominio deaplicación de esa categorización.Es entonces necesaria, una depuración de los datos de un usuario, dispuestos porWeb sociales, servicios independientes y estudios de áreas como la computación,mercadotecnia y psicología. [Yu05] [Plans03] [Trajkova04] [Chan07] [Gauch04][Nivala03] Así como la adición de elementos considerados pertinentes. [Issste02][Cif00] [Icf08] [Disc08] [Croja08] [Gzlez08] [Disca08]Rojas, Christian 2
  • 14. IntroducciónUn simple documento legible por una persona y una lista de datos no son suficientes,por lo que se necesita un entorno de diseño en algún lenguaje procesable como lopuede ser OWL/RDF (Ontology Web Language/Resource Description Framework)[W3C04] y una interfaz amigable que permita la captura de estos datos.La necesidad objetiva de este proyecto es entonces obtener una ontología quecumpla con las características citadas, modelando a un usuario y tomando en cuentasus costumbres, deficiencias, roles cotidianos y características, y poblarla medianteuna interfaz gráfica para poder instanciarla y explotarla.Debido a que la información para perfilar al usuario deberá ser directamenteintroducida por el mismo, se investigaron e implementaron una serie de técnicas paraevitar, en la medida de lo posible, la intrusión excesiva de datos del usuario, y porconsiguiente obtener sólo los necesarios para un cierto dominio de aplicación, sinmenoscabar la pertinencia de los mismos.Una de las problemáticas inmersas en el uso de ontologías es nombrarsemánticamente de forma unívoca a los elementos en la ontología, como lo sonatributos, clases e individuals (instancia de una clase); los cuales son representadosmediante una URI (Uniform Resource Indicator) siguiendo un mismo patrón. [W3C04][Protege09].Esto ocasiona que no pueda ser identificado un elemento a partir de su URI, y en elpeor de los casos esta nomenclatura arbitraria ocasionará que se tengan queimplementar heurísticas más complejas para la recuperación de elementos a partir deun conjunto de identificadores conceptuales unívocos.Para resolver estos problemas, en esta tesis se propone una técnica para eltratamiento de los identificadores conceptuales mediante la generación de un árbol deabstracción de nombres a partir de un conjunto de reglas.1.3 OBJETIVOObtener una ontología que modele a un usuario, tomando en cuenta sus costumbres,deficiencias, roles cotidianos y características, y poblarla mediante una interfaz gráficapara poder instanciarla y explotarla.Rojas, Christian 3
  • 15. Introducción1.4 JUSTIFICACIÓNUna gran cantidad de interpretaciones para categorizar a un usuario están disponiblesen el mercado, sin embargo, la mayoría de estas, contemplan una estructurainfluenciada por el domino hacia el cual intencionalmente fueron creadas, es decir,que los datos que consideran capturar son divergentes, debido a que cadacategorización especializa los datos a sus intereses.Aunque muchas de estas categorizaciones son similares en sus datos básicos (datospersonales), existe la variabilidad en su formato, es decir, estos conjuntos de datosestán dispuestos en diferentes formas como por ejemplo: texto plano, bases de datos,lenguaje procesable (OWL), etc.En las siguientes figuras se muestran distintas apreciaciones para categorizar a unusuario.En la figura 1.1 se muestra una perspectiva de acuerdo a SOUPA + CoBrA [Chen04],la cual toma en cuenta datos generales y algunos basados en contacto. • Nombre Información • Género • Edad básica de • Fecha de nacimiento perfil • Correo • Dirección Perspectiva Información • Página personal SOUPA + • Número telefónico de contacto • Mensajería instantanea CoBrA • Id. de chat • Amigos • Dependientes de organizacion Profesional y social Figura 1.1 Perspectiva de SOUPA + CoBrA para modelar a un usuario.Rojas, Christian 4
  • 16. IntroducciónEn la figura 1.2, se aprecia una perspectiva de GEEK [Geek09], en la que se enfatizasobre las preferencias del usuario. Figura 1.2 Perspectiva de GEEK para modelar a un usuarioLa siguiente lista muestra los detalles de algunos elementos marcados con la letraasignada en la figura anterior. A. Pretty Good Privacy o PGP (privacidad bastante buena) es un programa desarrollado por Phil Zimmermann y cuya finalidad es proteger la información distribuida a través de Internet mediante el uso de criptografía de clave pública, así como facilitar la autenticación de documentos gracias a firmas digitales. Fuente: Wikipedia. B. Interesado en otros códigos GEEKS [Geek09], y habido de memorizarlos.En la figura 1.3, se aprecia la perspectiva de AKTORS para perfilar a un usuario,tomando en cuenta datos referentes a su ubicación y preferencias del mismo. [Akt08]Rojas, Christian 5
  • 17. Introducción Figura 1.3 Perspectiva de AKTORS para modelar a un usuarioLa siguiente lista muestra los detalles de algunos elementos marcados con la letraasignada en la figura 1.3. A. Refiere a la ubicación geográfica según el uso horario (GMT) B. Referente al origen de la persona. (Lugar natal) C. Indica cómo le gusta a la persona ser llamada (parte de su nombre) D. Indica el título de la persona en sociedad preferido por la persona (Ing. Sr. Srita. Dr. Lic. etc.) E. Indica bajo qué tipo de contratación trabaja en su dependencia (Honorarios, Confianza, Base, Contrato, Sindicalizado, etc.) F. Indica el tipo de trabajo de la persona de entre una lista proporcionada por AKTORS (Administrador, diseñador multimedia, desarrollador, diseñador grafico, secretario, empleado educacional, soporte académico, interés en investigación, etc.)En la figura 1.4 se muestra la perspectiva de Friend of a Friend (FOAF), para perfilar aun usuario tomando en cuenta que estos datos están inclinados a cuestiones decontacto debido a la naturaleza del proyecto en el que está inmerso, la cual tomacomo base los microformatos [Miller00].Rojas, Christian 6
  • 18. Introducción Figura 1.4 Perspectiva de FOAF para modelar a un usuarioLa siguiente lista muestra los detalles de algunos elementos marcados con la letraasignada en la figura 1.4.A. Organización fundada por un proyecto o personaB. Una imagen utilizada para representar algo en específicoC. Documento que representa un tema principalD. Algo que fue hecho o fabricado por esta personaE. Algún agente que hizo algoF. Liga a las publicaciones de esta personaG. Una muestra en imagen de algo interesante.Como se puede apreciar en las figuras anteriores, las categorizaciones para unusuario son dedicadas a cierto dominio y en algunos casos de gran tamaño, estas sejustifican así mismas en su contenido, y son muy útiles para el contexto deinvestigación, pero tienen el inconveniente de no ser del mismo formato de operación,esto es, que el caso de GEEK, corresponde a un formato de texto plano, mientras quelas demás categorizaciones corresponden a ontologías en lenguaje procesable(OWL), ocasionando una incompatibilidad en la explotación integral de al menos,estas categorías.Rojas, Christian 7
  • 19. Introducción1.5 BENEFICIOSEl principal beneficio que se obtuvo de esta tesis es una herramienta que permitemodelar usuarios basándose en el contexto propio, mediante el uso de ontologías enlenguaje procesable, utilizando una interfaz gráfica. Las aplicaciones que puedenrealizarse con esta herramienta son: Captura personalizada de los datos del usuario. Una interfaz gráfica que permite la captura de datos pertinentes de acuerdo al usuario en cuestión, tomando en cuenta características, atributos, preferencias, y datos almacenados en el perfil. Un esquema ontológico basado en núcleo + extensiones. Este tipo de estructura, permitirá el crecimiento de la ontología dependiendo del contexto del usuario en cuestión. Explotación y reutilización de la ontología resultante. Debido a que el resultado (perfil de usuario) estará dispuesto en un formato liviano bajo un lenguaje procesable (OWL), permitirá a otras aplicaciones o servicios consumidores hacer uso de la información obtenida de manera más intuitiva y ordenada. Detallado de reglas para la obtención de un mapa ontológico. Un método que define un conjunto de reglas bajo un algoritmo específico, que permitirá estandarizar los identificadores conceptuales generados por la ontología y también permitirá presentar el resultado obtenido. De esta manera es posible la explotación de la ontología de una manera más efectiva ya que el mapa generado manualmente a partir de las reglas mencionadas hace innecesario el conocimiento de lenguaje de consultas para la exploración puntual de un elemento en la estructuración de la ontología.1.6 TRABAJOS RELACIONADOSEn primera instancia se describe un estudio del área mercadotécnica, en el cual seperfila a un usuario, denominado técnicamente como “comprador”. Posteriormente semuestra un conjunto de artículos asociados al tema, y por último dos tesis (doctoralesy de maestría) involucradas por igual1.6.1 Principios de marketingEste trabajo representa un estudio basado en la mercadotecnia, el cual maneja elconcepto de cliente (sinónimo con usuario para fines del proyecto de tesis)Aquí se definen dos conceptos muy distintos entre sí, pero que aparentan unasimilitud, estos son: “Cliente” y “Consumidor”, pero contempla no sólo productos sinoservicios por igual en estas definiciones. Debido a esta separación de definiciones,Rojas, Christian 8
  • 20. Introducciónconsideran necesarias las categorizaciones de los comportamientos de estos dosactores, fijando la atención en el comprador (cliente). Véase figura 1.5. Figura 1.5 Mapa del comportamiento del compradorSe especifican también los roles de compra que son diferentes métricas adoptadassegún la(s) rutina(s) en las que se desenvuelve el usuario, así como los tipos decomportamiento del comprador y demás estudios relacionados con el tema.Como se puede apreciar, el tipo de categorización realizada hacia el usuario(denominado comprador) se realiza de modo vectorial, es decir, sin subclasificacionesde datos. De modo que al no explayarse los datos internos de las categorías, solo losgrupos, dejan espacio a ambigüedades. [Plans03]1.6.2 Improving Ontology-Based User ProfilesIntenta clasificar intereses del usuario, siendo su principal objetivo investigar técnicasque implican la construcción de perfiles de usuario basados en ontologías. La idea esconstruir perfiles sin interacción humana, esto es, de manera automática, con elsimple monitoreo de los hábitos del usuario.Toma mucha importancia el definir los conceptos más importantes en la construccióno categorización de estos usuarios al igual que involucran estos conceptos ocaracterísticas de un modo jerárquico y cuestionan firmemente la cantidad de nivelesnecesarios para categorizar al usuario.Rojas, Christian 9
  • 21. IntroducciónSin embargo las principales problemáticas se basan en la elección de los elementospertinentes para la elaboración de dicho perfil y cómo proyectar estos datos en elmismo, ya que se explayan dos técnicas para obtener estos datos, las cuales sonimplícitas (observación y exploración de su actividad) y explicitas (preguntas directas).Direccionando la metodología de este proyecto hacia la explotación implícita.Referente a la alimentación del perfil, esta se lleva a cabo de manera jerárquica y novectorial, esto es, aplicando niveles de abstracción con cierta ponderación.[Trajkova04]1.6.3 Learning implicit user interest hierarchy for context in personalizationEl contenido de este documento presenta una visión de la categorización de unusuario a partir de sus intereses, analizada a partir de la navegación Web del mismo.Utilizan un método de estructuración basado en jerarquías para la creación de unperfil, tomando los niveles de la misma como niveles de abstracción de los conceptos,de modo que si un usuario en diferentes consultas o navegaciones toca temáticasmuy distintas entre sí, puede darse el caso que en un nivel de abstracción no tenganrelación, sin embargo, si se eleva el nivel de abstracción de esas navegaciones, sehace que pertenezcan al mismo concepto.Este artículo utiliza para la generación de un perfil de usuario una estructurajerárquica, denominada por ellos como: UIH (jerarquía de intereses del usuario porsus siglas en inglés).Se propone que la alimentación de las jerarquías y de los conceptos inmersos en ellassean por un medio automático, esto es, dinámicamente, por medio de la navegaciónWeb del usuario, usando la lógica de que los intereses se contemplan como pasivoscuando el nivel de abstracción es más alto y más activos cuando el nivel deabstracción es más bajo, es decir, de más genérico a más específico.La alimentación de la jerarquía utilizada es dinámica al defender el hecho de que losperfiles son constantemente actualizados por el usuario, y no es práctico el definir unperfil como estático ya sea en su contenido o incluso en su estructura.Según este artículo, la manipulación de los intereses de un modo jerárquico es másprecisa que una realizada de un modo vectorial o lineal, sobre todo por cuestionesontológicas. [Chan07]Rojas, Christian 10
  • 22. Introducción1.6.4 Need for Context-Aware Topographic Maps in Mobile DevicesEste trabajo se especializa en servicios que facilitan mapas cartográficos a usuarios, yuno de sus principales factores a tomar en cuenta es la capacidad que se tiene o nopara darle al usuario algo en específico que cumpla con sus expectativas, todo estocon el fin de hacer los productos más usables y comerciales.Los mapas no son un medio de comunicación, pero si, un medio de aproximaciónpara localización de detalles vía espacial, (esto debido a que aplican ontologías parala solución de los mismos) y por lo tanto la exactitud de estos debe de ser por demásprecisa, tomando en cuenta todos los detalles que conlleva.Para la eficiente provisión de los mapas solicitados se emplean las siguientescategorías de acuerdo al momento de la solicitud de los mismos:Contexto de cómputoContexto del usuario: Refiere a habilidades físicas, habilidades perceptuales y cognitivas, y diferentes personalidades del usuario en cuestión.Contexto FísicoContexto de tiempo.Contexto de historiaSin embargo, debido a que el destino final de estos mapas son los dispositivosmóviles, estos términos cambian con base en adaptabilidad. [Nivala03]1.6.5 Matching Users Semantics with Data Semantics in Location-Based ServicesRelación de semántica de usuarios con semántica de datos en LBSPropone cierta flexibilidad a los servicios de información para que puedan entendercorrectamente lo que está siendo solicitado por el usuario, y como seleccionar lainformación que esa relevante para esta solicitud, tomando en cuenta la gestión, eldiseño y los factores humanos. En este artículo se definen los siguientes conceptos:1.6.5.1 Perfil de usuarioSon dinámicos. Dos usuarios en las mismas condiciones, en la misma ubicación yhaciendo la misma petición pueden tener resultados distintos (polimorfismo) deacuerdo a su perfil.Se definen también los perfiles de usuario de tipo estático (explicito), y de tipodinámico (implícito), es decir, alimentados por preguntas directas acerca de suscaracterísticas, hábitos o comportamiento, y alimentada por el análisis constante desu comportamiento mediante su navegación u otro método, respectivamente.Rojas, Christian 11
  • 23. Introducción1.6.5.2 Perfiles de datosLos perfiles de datos describen servicios de datos. Del mismo modo en que unesquema describe una base de datos, un perfil de datos proporciona informaciónacerca de los datos provistos por un servicio. [Yu05]1.6.6 Exploiting Hierarchical Relationships in Conceptual searchDebido al constante crecimiento de sitios Web, la pertinencia de muchas de lasrespuestas arrojadas hacia un usuario que los consulta, dependen de una ciertapersonalización, la cual, no existe al momento, porque a pesar de que losmecanismos son más novedosos en cuestiones de navegación y búsqueda, losprincipios son los mismos, utilizando palabras clave para hacer sus búsquedas.El problema en la actualidad es que si dos usuarios realizan una consulta utilizando lamisma palabra de búsqueda, el motor de búsqueda arroja como resultado el mismoconjunto de respuestas, siendo que es muy probable que cada uno de ellos se hayareferido a un contexto distinto. [Gauch04]La herramienta que ellos desarrollaron denominada KeyConcept toma en cuenta tantoestas palabras clave como los conceptos o temas relacionados de su consulta directay automáticamente de Open Directory. [Odp08]Este artículo entonces, utiliza una estructuración de tipo jerárquica para poder realizarla alimentación de una ontología adoptando los beneficios de este tipo deestructuración en contraste con una de tipo vectorial, además de que toma en cuentaun mejoramiento iterativo, refinándose la jerarquía automáticamente.1.6.7 SOUPA: Standard ontology for ubiquitous and pervasive applicationsEn este artículo se explica a detalle el SOUPA, ésta ontología se diseñó paramodelar y soportar aplicaciones de cómputo pervasivo.Esta ontología está definida en lenguaje OWL, la cual incluye un componente modularde vocabulario para representar agentes inteligentes asociados a intenciones, deseos,creencias, perfiles de usuario, información de contexto, acciones y políticas deseguridad y privacidad, y además se explica cómo puede ser extendida y usada parasoportar aplicaciones de CoBrA [Chen2005] para la construcción de cuartosinteligentes (habitaciones con sensores de radio frecuencia); y MoGATU, un gestor dedatos peer-to-peer para ambientes pervasivos. [Chen04]A continuación se definen los componentes de las ontologías integrantes de SOUPA:Rojas, Christian 12
  • 24. Introducción Figura 1.6 Ontologías integrantes de SOUPA1.6.7.1 SOUPA Core.Define el vocabulario genérico y universal para la construcción de aplicaciones decomputo pervasivas. Este conjunto de ontologías consiste en vocabularios paraexpresar conceptos que son asociados con personas, agentes, intenciones, deseos ycreencias; acciones políticas, tiempo, espacio y eventos. Véase figura 1.61.6.7.2 SOUPA ExtensiónSe extiende de SOUPA Core. Define vocabulario adicional para el soporte de tiposespecíficos de aplicaciones y ejemplos provenientes de la definición de nuevasextensiones de ontología. figura arribaEstas ontologías son definidas con dos propósitos:o Definir y extender el conjunto de vocabularios para soportar tipos específicos de dominios y aplicaciones pervasivas.o Demostrar cómo definir nuevas ontologías por medio de la extensión de las ontologías SOUPA Core.1.6.8 A MDD strategy for developing context-aware pervasive systemsEsta tesis propone un enfoque metodológico al desarrollo de sistemas pervasivosconscientes de los contextos basados en ontologías y normas del MDD (Model-DrivenDevelopment), y ofrece las siguientes contribuciones: 1. Un conjunto de modelos para la captura de datos del contexto en tiempo de modelado. 2. Una ontología de contexto y un repositorio contextual OWL basado en esta ontología para capturar datos del contexto en tiempo de ejecución.Rojas, Christian 13
  • 25. Introducción 3. Un framework para almacenamiento automático, gestión y procesamiento de información del contexto en tiempo de ejecución. 4. Una infraestructura para la adaptación del sistema pervasivo con la finalidad de mejorar la vida del usuarioEstos sistemas no solo deben capturar información del contexto, también debenentenderlo y adaptar su comportamiento acorde a éste a partir de las preferencias delusuario. En esta tesis se define una ontología de contexto y un repositorio contextualOWL como un sistema capaz de almacenar en una máquina de lenguaje procesabletanto la información contextual actual como la información contextual histórica.Este framework automáticamente actualiza el repositorio contextual OWL de acuerdoa los cambios producidos en la información contextual al tiempo de ejecución. Parapoder gestionar la localización del usuario se requiere que cada uno de ellos tenga undispositivo de localización (por ejemplo, un brazalete de identificación por radiofrecuencia) para ser identificados por los propios sensores. [Serral07]1.6.9 Categorizaciones independientes de un Usuario.1.6.9.1 GEEKUn geek es una persona hábil para la informática, la electrónica y la tecnología, yademás tiene interés por los gadgets1 y accesorios digitales y/o novedosos.Tanta fama ha cobrado este término que aquellos que se consideran GEEKS, handesarrollado un código para poder distinguirse de entre las personas que no lo son.Este código carente de sentido a simple vista contiene caracteres que identifican ydescriben no sólo los conocimientos de la persona sobre los temas arriba mostrados,sino también, de ciertas características físicas, de intereses socio-político-económicos, de entretenimiento y más.Cabe mencionar que cada una de las categorías y de las opciones operadas por estacategorización tiene asignado un símbolo univoco (conjunto de caracteres carentes desentido en un contexto habitual), y formando una concatenación de acuerdo al ordende petición, es como se forma el código geek, cuyo análisis y ejemplo cae fuera de losintereses de este documento.1. Gadget (Gizmo)Obtenido de: http://es.wikipedia.org/wiki/Gadget ; Ultima consulta: Julio 2009Es un dispositivo que tiene un propósito y una función específica, generalmente de pequeñas proporciones, práctico y a la vez novedoso. Los gadgets suelentener un diseño más ingenioso que el de la tecnología corriente.Rojas, Christian 14
  • 26. Introducción1.6.9.2 AKTORSAKTORS es una ontología creada por AKT (Advanced Kwnoledge Technologies), elcual es fundado en EPSCR (Engineering and Physical Sciences Research Council)el cual tienen como objetivo desarrollar y extender un rango de tecnologíasprovenientes de métodos y servicios integrados de captura, modelado, publicación,rehúso y gestión del conocimiento. [Akt08]Ellos han creado una ontología para modelar a un usuario tomando en cuenta en granmedida su ubicación física y los datos de geolocalización.1.6.9.3 Amigo de un amigo (FOAF: FRIEND Of A Friend)FOAF es un proyecto para la Web semántica que se inició en el año 2000, utilizandotecnologías desarrolladas dentro de la Web semántica para describir relacionesmediante RDF que puedan ser procesadas fácilmente por máquinas.La idea detrás de FOAF es simple: la Web trata de realizar todas las conexiones entrelas cosas. FOAF proporciona algunos mecanismos básicos para que nos ayuden adecirle a la agentes sobre las conexiones entre las cosas que interesan a los usuariosfinales.FOAF es una tecnología sencilla que facilita el compartir y utilizar la información sobrelas personas y sus actividades (por ejemplo, fotos, calendarios, diarios), paratransferir información entre los sitios Web, y para extender automáticamente, fusionary re-usar en línea. [Miller00]Para representar el lenguaje FOAF se ha descrito una especificación con diccionariosde nombres, propiedades y clases usando tecnología RDF de W3C.En la tabla 1, se muestra el análisis sintético de cada uno de los elementosestudiados anteriormente, reflejando los parámetros más importantes.Rojas, Christian 15
  • 27. Introducción Tabla 1.1. Análisis comparativo del estado del arte. Uso en ambiente Roles de Usuario procesable OWL Retroalimentación o autoaprendizaje Uso de agentes ponderancias Arquitectura Exploración Seguridad / Privacidad Lenguaje domóticoNombre Uso de[PLANS03] Ninguna Ninguna[TRAJKOVA04] Implícita Jerárquica[CHAN07] Implícita Jerárquica[GAUCH04] Implícita Jerárquica[SARJAKOSKI03] N/E Lineal Explicita /[YU05] Ninguno Implícita Núcleo +[CHEN05] Explicita Extensión Núcleo +[CHEN04] Explicita Extensión[SERRAL07] Explicita Lineal[GEEK08] Explicita Lineal[AKTORS08] Explicita Jerárquica[MILLER00] Explicita Lineal Núcleo +Nuestro Enfoque Explicita Extensión N/E= No EspecificadoRojas, Christian 16
  • 28. Introducción1.7 ALCANCE DEL PROYECTO DE TESISEl proyecto de tesis que se dispone en este documento, se conforma de acuerdo a 5puntos importantes: Los perfiles generados serán definidos en un lenguaje procesable (OWL). Los perfiles generados responderán a un árbol de abstracción de nombres para su explotación posterior (Véase 3.1.2) La interfaz gráfica resultante tendrá módulos dinámicos que responderán de acuerdo al contexto de los datos capturados al momento de la operación de dichos módulos. La ontología resultante en cada perfil corresponderá en su tamaño de acuerdo con los datos capturados por el usuario correspondiente, conteniendo el núcleo más las extensiones pertinentes y acordes a cada perfil. La ontología resultante de cada perfil tendrá una correspondencia directa en las clases y datos contenidos de acuerdo a un cierto dominio de aplicación. (Véase 3.1.2.3.1)1.8 ORGANIZACIÓN DEL DOCUMENTOEste documento de tesis ésta estructurado de la siguiente manera: En el capítulo 2 sepresentan los conceptos sobre las tecnologías involucradas en el desarrollo de latesis. En el capítulo 3, se muestran los casos de uso, escenarios, diagramas deactividad, clases y secuencia que representan el análisis y diseño del proyectorealizado. En el capítulo 4, se detalla el procedimiento seguido para la obtención delprototipo. En el capítulo 5, se explica el uso de la aplicación así como segmentos decódigo importantes. En el capítulo 6, se presentan los resultados de las pruebas. En elcapítulo 7, se presentan las aportaciones de la tesis, los trabajos futuros y laspublicaciones realizadas durante el desarrollo de la tesis.Rojas, Christian 17
  • 29. IntroducciónRojas, Christian 18
  • 30. CAPÍTULO II. MARCO TEÓRICOEn este capítulo se presenta la teoría relacionada con el tema semántico aplicado enéste trabajo de tesis. Se inicia describiendo los conceptos relacionados con elproyecto en el ámbito semántico y continúa con los conceptos generales que seutilizaran en el transcurso de este documento.
  • 31. Marco teórico2.1 CONCEPTOS SEMÁNTICOS2.1.1 OWLEl Lenguaje de Ontologías Web (OWL) está diseñado para ser usado en aplicacionesque necesitan procesar el contenido de la información en lugar de únicamenterepresentar información para los humanos. OWL facilita un mecanismo deinteroperabilidad de contenido Web más eficiente que los mecanismos admitidos porXML, RDF, y esquema RDF (RDF-S) proporcionando vocabulario adicional junto conuna semántica formal. OWL tiene tres sub-lenguajes, con un nivel de expresividadcreciente: OWL Lite, OWL DL, y OWL Full.La Web semántica se basará en la capacidad de XML para definir esquemas deetiquetas a medida y en la aproximación flexible de RDF para representar datos. Elprimer nivel requerido por encima de RDF para la Web semántica es un lenguaje deontologías que pueda describir formalmente el significado de la terminología usada enlos documentos Web.OWL añade más vocabulario para describir propiedades y clases: entre otros,relaciones entre clases (por ejemplo, desunión), cardinalidad (por ejemplo, "unoexacto"), igualdad, más tipos de propiedades, características de propiedades (porejemplo, simetría), y clases enumeradas. [OWL09]2.1.2 RDFEl fundamento o base de RDF es un modelo para representar propiedadesdesignadas y valores de propiedades. El modelo RDF se basa en principiosperfectamente establecidos de varias comunidades de representación de datos.Las propiedades RDF pueden recordar a atributos de recursos y en este sentidocorresponden con los tradicionales pares de atributo-valor. Las propiedades RDFrepresentan también la relación entre recursos y por lo tanto, un modelo RDF puedeparecer un diagrama entidad-relación. (De forma más precisa, los esquemas RDF queson objetos específicos de la categoría del modelo de datos RDF) son diagramas ER(Entidad Relación). En la terminología del diseño orientado a objetos, los recursoscorresponden con objetos y las propiedades corresponden con objetos específicos yvariables de una categoría.El modelo de datos de RDF es una forma de sintaxis-neutral para representarexpresiones RDF. La representación del modelo de datos se usa para evaluar laequivalencia en significado. Dos expresiones RDF son equivalentes si y sólo si susrepresentaciones del modelo de datos son las mismas. Esta definición deequivalencia permite algunas variaciones sintácticas en expresiones sin alterar elsignificado.El modelo de datos básico consiste en tres tipos de objetos:Rojas, Christian 20
  • 32. Marco teóricoRecursos Todas las cosas descritas por expresiones RDF se denominan recursos. Un recursos puede ser una página Web completa; tal como el documento HTML "http://www.w3.org/Overview.html" por ejemplo. Un recurso puede ser una parte de una página Web. Un recurso puede ser también una colección completa de páginas o un objeto que no sea directamente accesible vía Web.Propiedades Una propiedad es un aspecto específico, característica, atributo, o relación utilizado para describir un recurso. Cada propiedad tiene un significado específico, define sus valores permitidos, los tipos de recursos que puede describir, y sus relaciones con otras propiedades.Sentencias Un recurso específico junto con una propiedad denominada, más el[declaraciones, valor de dicha propiedad para ese recurso es una sentencia RDFenunciados] [RDF statement]. Estas tres partes individuales de una sentencia se denominan, respectivamente, sujeto, predicado y objeto. El objeto de una sentencia (es decir, el valor de la propiedad) puede ser otro recurso o pude ser un literal; es decir, un recurso (especificado por un URI) o una cadena simple de caracteres [string] u otros tipos de datos primitivos definidos por XML. [RDF09]2.1.3 W3CEs un consorcio que tiene como visión la de guiar la Web a su potencialidad máxima amodo de foro de información, comercio, comunicación y conocimiento colectivo,mediante tecnologías inter-operativas, especificaciones, líneas maestras, software yherramientas. [W3C04]2.1.4 OntologíaExisten varias definiciones sobre éste concepto, entre ellas se encuentran:Una ontología constituye "Una especificación formal y explicita de unaconceptualización compartida”. En esta definición, convertida ya en estándar,conceptualización se refiere a un modelo abstracto de algún fenómeno del mundo delque se identifican los conceptos que son relevantes; hace referencia a la necesidadde especificar de forma consciente los distintos conceptos que conforman unaontología. [Gruber]“Una ontología es una base de datos que describe los conceptos en el mundo yalgunos dominios, algunas de sus propiedades y como los conceptos se relacionanunos con otros”. [Weigand]Rojas, Christian 21
  • 33. Marco teóricoOntología describe una cierta realidad con un vocabulario específico, usando unconjunto de premisas de acuerdo con un sentido intencional de palabras delvocabulario. [Guarino]2.2 CONCEPTOS GENERALES2.2.1 XSDXML Schema es un lenguaje de esquema utilizado para describir la estructura y lasrestricciones de los contenidos de los documentos XML de una forma muy precisa,más allá de las normas sintácticas impuestas por el propio lenguaje XML. Se consigueasí una percepción del tipo de documento con un nivel alto de abstracción. Fuedesarrollado por el World Wide Web Consortium (W3C) y alcanzó el nivel derecomendación en mayo de 2001. [XSD09]Rojas, Christian 22
  • 34. 3. CAPÍTULO III. ANÁLISIS Y DISEÑOEn este capítulo se presentan los diagramas de caso de uso, la definición de escenarios ylos diagramas de actividad que corresponden a la fase de análisis. Así mismo se presentalos diagramas de clase y de secuencia correspondiente a la etapa del diseño.
  • 35. Análisis y diseño3.1 ANÁLISISLa figura 3.1 muestra el proceso de trabajo del proyecto, tomando en cuentabloques de manera abstracta. Figura 3.1 Diagrama de bloques del proceso general del proyectoComo se puede apreciar en la figura 3.1, el proceso de desarrollo se dividió en dossegmentos, los referentes al entorno gráfico de la aplicación denominado “Interfaz”y el referente a la programación inmersa, denominado “Operación con clases”, lascuales se encuentran unidas mediante código.A continuación se presentan los diagramas de caso de uso, la definición deescenarios y los diagramas de actividad que corresponden a la fase de análisis delproyecto, respectivo a la sección de “operación con clases” de acuerdo a figura3.1. Y posteriormente se mostraran las partes importantes de análisis de lasección de “Interfaz” de acuerdo a figura 3.1.Rojas, Christian 24
  • 36. Análisis y diseño3.1.1 Análisis de operación con clasesEn la figura 3.2 se muestra el diagrama general de casos de uso del proyecto y semuestran las funciones principales que ofrece. Figura 3.2 Diagrama general de casos de usoEn la figura 3.2 el usuario accede o crea su ontología previa autenticación y realizamodificaciones en ella mediante el uso de la interfaz. Una vez que se haautenticado y definido si se creará, modificará o eliminará su ontología, el usuarioelegirá cual será el dominio de la aplicación hacia la cual se inclinaran los datos dela captura.Este caso de uso contempla el paquete:mx.edu.cenidet.userontology.axiomsInference y mx.edu.cenidet.userontology.frontRojas, Christian 25
  • 37. Análisis y diseño Figura 3.3 Diagrama de casos de uso de Operar con la ontologíaComo se puede apreciar en la figura 3.3, se introdujeron dos actores más,denominados “API de conexión” referida a OWL API la cual fue únicamenteconsumida por el proyecto y como su nombre lo indica, tiene como funcionalidadla de ofrecer un repositorio hábil para el manejo de una ontología definida; y“Ontología” la cual es operada por la aplicación o creada si es que no existe, en lacual recaerán todas las operaciones realizadas en el proyecto. Tabla 3.1 Descripción del caso de uso Operar con la ontología ID: CU-1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.4Nombre del Operar con la ontologíacaso de usoActores Usuario, API de conexión, OntologíaDescripción Permite al usuario realizar operaciones sobre la ontología, como lo son agregar, modificar y eliminar tanto de manera global como detallada.Precondiciones Requisitos mínimos del sistema comunes para cualquier aplicación.Poscondiciones Se obtendrá la ontología del usuario para poder ser reutilizadaEscenario de 1. El usuario ingresa al sistema para crear una nueva ontologíaéxito 1 2. El proceso de autenticación es univoco y se comienza la captura de datos 3. Se elige el dominio de la aplicación para la captura 4. La ontología es creadaEscenario de 1. El usuario ingresa al sistema para modificar su ontologíaéxito 2 2. El proceso de autenticación es correcto 3. Se realizan las modificaciones pertinentes apropiadamente 4. La ontología es guardadaEscenario de 1. El usuario ingresa al sistema para borrar su ontologíaéxito 3 2. El proceso de autenticación es correctoRojas, Christian 26
  • 38. Análisis y diseño 3. Se realiza el borrado de la ontologíaEscenario de 1. El usuario ingresa al sistema para realizar un agregado,fracaso 1 modificación o borrado de su ontología. 2. El proceso de autenticación no es univoco y se lanza una excepción controlada.Escenario de 1. El usuario ingresa al sistema para realizar un agregado,fracaso 1 modificación o borrado de su ontología. 2. El proceso de autenticación es correcto. 3. El usuario elije incorrectamente el dominio de la aplicación 4. Es necesario reiniciar el proceso de elección.Incluye CU-1.1 Elegir operación de altas, bajas y consultas, CU-1.2 Elegir dominio de aplicación, CU-1.1 Enlazar con ontologíaSuposiciones Se supone que la aplicación importa la librería en donde se encuentra la APIRojas, Christian 27
  • 39. Análisis y diseño act CU-1 Operar con la ontología Existent e Autenticar Enlazar con ontología (API) Razonador Nuevo Validar usuario y Elegir tipo de usuario passw ord nuev o No Ontología consistent e Cancelar peticiones Si Elegir dominio de aplicacion Autenticacion correcta Si Elegir operación a ontología Informar Ex cepción Accesar a clases Extensibilidad y Deducción Enlazar con ontología (API) Razonador Cancelar peticiones y Rollback a ej ecuciones truncas No Si Informar Ex cepción Operar en Ontología Ontología consistent e Figura 3.4 Diagrama de actividad del caso de uso CU-1 Operar con la ontologíaA continuación se muestran las tablas de descripción de los casos de uso paracada caso de uso dependiente de Operar con la ontología, así como sucorrespondiente diagrama de actividad. Tabla 3.2 Descripción del caso de uso Elegir operación de altas, bajas y consultas ID: CU-1.1 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.5.Nombre del Elegir operación de altas, bajas y consultascaso de usoActores Elegir asunto de conexión.Descripción Permitirá al usuario elegir cuál será el motivo de acceso a la ontología para que el sistema utilice la interfaz adecuada para dicha acción.Rojas, Christian 28
  • 40. Análisis y diseñoPrecondiciones 1. El usuario deberá haber pasado el proceso de autenticación correctamente. 2. Deberá haberse seleccionado ya la ontología a utilizar ya sea nueva o existente.Poscondiciones 1. El usuario accederá a la interfaz pre programada para la operación con las clases.Escenario de 1. El usuario se autentica correctamente.éxito 1 2. El usuario elige la operación a realizar. 3. La ontología es creada, modificada o eliminada correctamente. 4. La ontología es guardada.Escenario de 1. El usuario ingresa al sistema para realizar un agregado, modificaciónfracaso 1 o borrado de su ontología. 2. La ontología es inconsistente por cuestiones ajenas a la aplicación y es detectada por el razonador. 3. Actuación del manejador de la excepción generada.IncluyeSuposiciones Se supone que la aplicación importa la librería en donde se encuentra la APIRojas, Christian 29
  • 41. Análisis y diseño act CU-1.1 Eleccion operacion con ontología Seleccionar operacion a ontología Enlazar con ontología (API) Raz onador Ontología consistent e No Informar Ex cepción Si Operación Leer y nav egar en la ontología Modficar Mostrar interfaz apropiada Eliminar Eliminar obj etos Adaptar extensibilidad y deducción Eliminar indiv iduals Enlazar con ontología (API) Raz onador Si Ontología consistent e No Operar en ontología Informar ex cepción Manej ar excepción Figura 3.5 Diagrama de actividad del caso de uso Elegir operación de altas, bajas y consultasRojas, Christian 30
  • 42. Análisis y diseño Tabla 3.3 Descripción del caso de uso Elegir dominio de aplicación ID: CU-1.2 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.6Nombre del Elegir dominio de aplicacióncaso de usoActores Elegir modo de capturaDescripción Permitirá al usuario elegir cuál será la inclinación del proceso de captura, para que el sistema haga distinguir visualmente cuales son los campos recomendados y los optativos para el usuario de este dominio.Precondiciones 1. El usuario deberá haber pasado el proceso de autenticación correctamente. 2. Deberá haberse seleccionado la opción de una ontología nueva.Poscondiciones 1. Las clases disponibles para la captura estarán distribuidas de acuerdo al dominio de la aplicación elegido.Escenario de 1. El usuario se autentica correctamente.éxito 1 2. El usuario elige crear una ontología, y elige el dominio de la aplicación. 3. El usuario captura los datos en una o varias corridas de la aplicación.Escenario de 1. El usuario se autentica correctamente.fracaso 1 2. El usuario elige crear una ontología, y elige el dominio de la aplicación. 3. Debido a un error en la captura, la ontología se vuelve inconsistente y es notada por el razonador. 4. Se lanza una excepciónIncluyeSuposiciones Se supone que la aplicación importa la librería en donde se encuentra la APIRojas, Christian 31
  • 43. Análisis y diseño act CU-1.2 Eleccion dominio de aplicación Adaptar extensibilidad y deducción Ordenar los campos de captura de acuerdo a el dominio seleccionado Preguntar nuev o dominio Si Mostrar interfaz apropiada Cambiar el dominio No Figura 3.6 Diagrama de actividad del caso de uso Elegir dominio de aplicación Tabla 3.4 Descripción del caso de uso Enlazar con la ontología ID: CU-1.3 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.7.Nombre del Enlazar con la ontologíacaso de usoActores API de conexión, OntologíaDescripción Realizara las validaciones y requerimientos necesarios para enlazar la interfaz con la ontologíaPrecondiciones 1. El usuario deberá haber pasado el proceso de autenticación correctamente. 2. Deberá haberse seleccionado ya la ontología a utilizar ya sea nueva o existente. 3. Deberá haber confirmado los cambios realizados a la ontologíaPoscondiciones 1. Se realizaran los cambios programados a la ontologíaEscenario de 1. El usuario ingresa o modifica datos en la interfazéxito 1 2. Los datos son guardados en la ontologíaEscenario de 1. El usuario ingresa o modifica datos en la interfazRojas, Christian 32
  • 44. Análisis y diseñofracaso 1 2. Existe un error provocando una inconsistencia en la ontología que es detectada por el razonador. 3. Se lanza una excepción.Escenario de 1. El usuario ingresa o modifica datos en la interfazfracaso 2 2. La ontología es modificada simultáneamente causando una inconsistencia en los datos que es detectada por el razonador. 3. Se lanza una excepción.IncluyeSuposiciones Se supone que la aplicación importa la librería en donde se encuentra la APIRojas, Christian 33
  • 45. Análisis y diseño act CU-1.3 Enlazar con la ontología Generar axiomas Generar reglas Establecer obj etos Desecha elementos inserv ibles Enlazar con ontología (API) Razonador No Ontología consistent e Informar ex cepción Si Generar indiv iduals Figura 3.7 Diagrama de actividad del caso de uso Enlazar con la ontologíaEn la figura 3.8 se muestra el diagrama de caso de uso Estructuración ontológica.Este caso de uso está contemplado en el paquete mx.edu.cenidet.userontology.axiomsInference.Rojas, Christian 34
  • 46. Análisis y diseño uc CU-2 Estructuracion ontológica Generar indiv iduals Ontologí a Figura 3.8 Diagrama de casos de uso de Estructuración ontológica Tabla 3.5 Descripción del caso de uso Estructuración ontológica ID: CU-2 El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.9.Nombre del Estructuración ontológicacaso de usoActores OntologíaDescripción Permite estructurar la ontología de tal modo que se estandaricen sus identificadores conceptuales y pueda ser reutilizada de un modo más sencillo y elocuente. Véase 3.1.2Precondiciones 1. La ontología debe de ser consistente (confirmada por el razonador)Poscondiciones 1. Si la estructura no existe este será creada sin importar el nivel de granularidad. 2. Se obtendrá una ontología estructurada con relaciones.Escenario de 1. El usuario ingresa o modifica datos en la interfazéxito 1 2. Se generan las individualizaciones para cada clase utilizada. 3. Se generan las relaciones entre estas individualizaciones. 4. Se genera un individual en la clase principal para elevar el nivel de abstracción 5. Se aplican las relaciones como atributos de la clase principal.Escenario de 4. El usuario ingresa o modifica datos en la interfazfracaso 1 5. Existe un error provocando una inconsistencia en la ontología que es detectada por el razonador. 6. Se lanza una excepción.Escenario de 4. El usuario ingresa o modifica datos en la interfazfracaso 2 5. La ontología es modificada simultáneamente causando una inconsistencia en los datos que es detectada por el razonador. 6. Se lanza una excepción.IncluyeSuposiciones Se supone que la aplicación importa la librería en donde se encuentra la APIRojas, Christian 35
  • 47. Análisis y diseño act CU-2 Estructuración ontológica Generar los atributos para Generar las las clases utilizadas indiv idualizacionesde las clases utilizadas Asignar v alores a los atributos de las clases utilizadas Asignar los atributos a las indiv idualizaciones creadas Generar la Generar los atributos indiv idualizacion de la obj eto / relacion para la clase principal clase principal Asignar las indiv idualizaciones de las clases utilizadas a los atributos obj eto Enlazar con ontología (API) Raz onador Si Informar ex cepción Ontología consistent e Guardar ontología Figura 3.9 Diagrama de actividad del caso de uso Estructuración ontológicaRojas, Christian 36
  • 48. Análisis y diseño3.1.2 Estructura de URI´s (Uniform Resource Indicator).El método para identificar, atributos y propiedades en las ontologías es medianteidentificadores conceptuales, denominados URI´s, los cuales están formadas en laprimera parte por un identificador de la ontología, seguido por un símbolo “#” y porúltimo el identificador del elemento en la ontología [Protege09].Por ejemplo, el atributo “nombre”, que tiene como dominio a la clase “Personales”correspondiente a la ontología con la URI“http://www.cenidet.edu.mx/user_ontology.owl”, se identificara unívocamente de lasiguiente manera: http://www.cenidet.edu.mx/user_ontology.owl#nombreTal y como se muestra en la figura 3.10: Figura 3.10 Identificador del atributo “nombre” de la ontología en protégéSin embargo, cada elemento en la ontología es identificado siguiendo el mismopatrón y debido a que la aplicación a la que apunta este proyecto deberá generarautomáticamente los datos en la ontología, se deducen las siguientes dificultades: Los nombres son unívocos, por tanto deberá haber reglas de nomenclatura para almacenar y recuperar datos de la ontología. No se pueden identificar mediante la URI de un elemento, la naturaleza de éste, es decir, la URI señalada como (http://www.cenidet.edu.mx/user_ontology.owl#nombre) podría referirse a un atributo, un objeto, una individualización, una clase, etc.Referente a las dificultades anteriormente mencionadas, se diseñó un métodopara poder generar un árbol de abstracción, en el cual la referencia a un elementotiene coherencia y propiedad con respecto al que está contiguo (ancestro o hijoen el árbol), con la finalidad de poder estandarizar estos identificadoresconceptuales, y recuperarlos en cualquier momento. Dicho método se detalla acontinuación:Rojas, Christian 37
  • 49. Análisis y diseño3.1.2.1 Árbol de abstracción de nombresAlgunas de las restricciones para los identificadores aplicables a los elementos deuna ontología se enlistan a continuación en las siguientes reglas generales: No es posible usar caracteres especiales. Los nombres deben ser únicos (distinción entre mayúsculas y minúsculas). Los identificadores de las clases comenzaran siempre con una letra mayúscula. Los identificadores de las propiedades „datatype‟ y „object‟ serán con minúsculas, y si está conformada por más de una palabra, entonces estarán separadas por un símbolo “_”. Los identificadores de propiedades “object” terminaran con un carácter en mayúscula, p.ej. “O”.Como se aprecia en las primeras dos reglas generales, debido a la flexibilidadpara nombrar un elemento, es muy sencillo entrar en ambigüedades denomenclatura, tal vez influenciadas por el contexto, el horario, costumbres oincluso el humor del diseñador, lo que da razón a las últimas 3 reglas anteriores.Cabe mencionar que el dominio de este método son las individualizaciones de laontología, ya que las reglas para nomenclatura de los elementos de la mismaestán aplicadas por el entorno de diseño utilizado y explicadas en las primeras dosreglas de la lista anterior.A continuación se enlistan las reglas específicas: Para diferenciar a identificadores de clases y de atributos, se omitirá la opción de poner símbolos “_” en el caso de identificadores con más de una palabra para las clases, (por ejemplo, si una clase es llamada Ayuda Técnica, en lugar de nombrarse como „Ayuda_tecnica‟, se dispondrá como „AyudaTecnica‟, con la inicial de cada palabra en mayúscula) Sera determinada una clase principal que será aquella por la cual haya más relaciones con respecto a las demás clases. A la cual se nombrará con un término determinado por el diseñador (primera letra en mayúscula) que servirá como identificador univoco respecto a otras individualizaciones de la misma ontología, y que formará el primer nivel jerárquico en el árbol de abstracción generado. Cada nomenclatura definida por las reglas anteriores (excepto la que refiere al primer nivel jerárquico del árbol de abstracción a generar), deberá ir antecedida por el identificador inmediato superior completo, sin espacios y siguiendo las reglas para la nomenclatura de clases (primera letra de cada palabra en mayúscula).Rojas, Christian 38
  • 50. Análisis y diseñoA continuación se muestra un ejemplo de cómo se ha empleado este método parala nomenclatura estandarizada de las individualizaciones:Tomando en cuenta las clases que se muestran en la figura 3.11, se han aplicadolas reglas generales para identificarlas unívocamente, tal como se muestra en lafigura 3.12 Persona Enfermedades Personales No Transmisibles Nombre Transmisibles SIDA Tuberculosis Cáncer Figura 3.11 Árbol de elementos de la ontología Persona Enfermedades Personales Transmisibles NoTransmisibles nombre sida tuberculosis cancer Figura 3.12 Árbol de elementos de la ontologíaComo se puede apreciar en la figura 3.12, las nomenclaturas de las clases y susatributos, son similares (en la medida de lo posible) con respecto a su nombrecontextual (de acuerdo a la lógica) de la figura 3.11 y siguiendo las reglas básicasde nomenclatura de clases explicada anteriormente, recordando también que cadaidentificador irá precedido de la URI que identifica la ontología y del símbolo “#”,como fue explicado al inicio de este subtema.Cabe mencionar que las individualizaciones se realizan solamente sobre clases, yno sobre atributos y/o propiedades, por tanto la figura 3.13 muestra las clases alas cuales se les puede realizar individualizaciones y por tanto se les referirá unidentificador contextual ya operado por las reglas anteriores.Rojas, Christian 39
  • 51. Análisis y diseño Figura 3.13 Resultado del método para nombrar individualizacionesEn la figura 3.13 se muestra el resultado del método explicado en esta sección. Enel resultado se aprecia que cualquier elemento tiene referencia en sunomenclatura al elemento contiguo.3.1.3 Manejo de tiposUna de las limitantes hacia las cuales se vio influenciado este proyecto, fue a laoperación de los atributos de la ontología, respetando los tipos de datos comunes(float, int, bool, string, etc), ya que durante el proceso de poblado de la ontologíamediante la API (OWLAPI), no fue posible especificar el tipo de dato del atributo aoperar, ya que internamente, todos estos, se manejan como datos de tipo cadenade caracteres (esto último con la finalidad de operar mediante un nivel deabstracción superior), la conversión para obtener los tipos necesarios se realizamediante el uso de constantes predefinidas que representan a los tipos de datoscitados.Dichas constantes no son más que URI´s estandarizadas y aprobadas por OWL[Protege09], las cuales realizan un mapeo funcional con respecto a el tipo de datocitado, especificándole al entorno de diseño de ontologías (protégé) que interpreteel dato conforme al tipo asociado, utilizando para ello un esquema utilizado por elestándar XML para el manejo de tipos de dato (XSD) [W3C, 2009]. El proceso semuestra en la figura 3.14Aunque ya existe solución a esta problemática, del proceso requiere que seprocese dato por dato, por este motivo se ha estructurado un método para poderrealizar esta operación de manera parametrizada, respetando las siguientesreglas: Debe haberse especificado la URI (Identificador contextual) de la individualización a operar, dispuesta en algún sector de la memoria principal. Debe haberse especificado también la conexión con la ontología, así como la definición del razonador y su validación de consistencia.Rojas, Christian 40
  • 52. Análisis y diseño Los atributos a operar deberán ser „datatype‟. [Protege09] Los atributos serán guardados en la ontología con la siguiente estructura: Tripleta(Nombre, Valor, Tipo) En donde: Nombre Corresponde al nombre del atributo a guardar Valor Refiere a el valor que contendrá el atributo a guardar en la ontología. Respetando siempre que el tipo de datos a guardar sea de tipo cadena yque además pueda ser forzado al tipo destino. Tipo Identifica el tipo destino del atributo en cuestión. El cual debe coincidir con el tipo de dato especificado en la ontología Los atributos leídos se interpretan siempre como tipo string y el cambio de tipo se realiza mediante programación convencional. XSDVocabulary.STRING.getURI() Figura 3.14 Esquema de manejo de los tipos de datosComo se puede apreciar en la figura 3.14, los datos en la interfaz, que sondistinguidos por sus nombres y valores (elementos restantes en las tripletas), sonsimilares en los tipos de datos en el entorno de diseño (protégé), y para realizaresta conversión en el tipo se utilizan los componentes intermedios explicadospreviamente, mediante un mapeo de uno a uno.Rojas, Christian 41
  • 53. Análisis y diseño3.1.4 Análisis de la interfazPara la implementación de la interfaz se definieron los siguientes requerimientos: Adaptación dinámica de clases. Deberá ser adaptativa al usuario, es decir, deberá cuestionar al usuario sólo los datos que le interesan y/o los que sean pertinentes de acuerdo a deducciones o a los mismos datos que el usuario haya ingresado, utilizando para ello los elementos específicos en la ontología, denominados extensiones, los cuales se explican en detalle en Extensiones. En otras palabras, ser eficiente en ¿Qué preguntar? Deducción de atributos pertinentes. Debe adaptar los atributos a considerar para perfilar a un usuario, de acuerdo a los datos que haya o esté ingresando de manera dinámica, ocultando aquellos que no sean pertinentes de acuerdo a la naturaleza del usuario, procurando mostrar la menor cantidad de campos a rellenar en cada pantalla. Deducción de solicitud de datos. La interfaz debe de organizar la solicitud de datos de acuerdo al dominio de la aplicación, la cual debe de ser elegida en algún momento del proceso de operación con la ontología usada o creada. Esta operación dividirá los datos a capturar en dos grupos: “recomendados” y “optativos”, distinguiéndolos visualmente.Para cubrir los requerimientos anteriores, se implementó una interfaz en unlenguaje de programación Open Source2.La aplicación, tendrá como objetivo primordial: Poblar la ontología adaptando sus elementos y requerimientos dinámicamente de acuerdo a la información almacenada tanto previamente, como al momento por parte del usuario, para evitar la intrusión, procurando “asegurar que el usuario rellene por lo menos los datos indispensables”.De acuerdo a un consenso se determinaron los siguientes dominios de aplicación,tratando de abarcar los grupos de datos más relevantes y con mayor diferenciacontextual entre ellas.2. Open source (Código abierto)Obtenido de: http://es.wikipedia.org/wiki/Código_abierto; Ultima consulta: Julio 2009Término con el que se conoce al software distribuido y desarrollado libremente.Rojas, Christian 42
  • 54. Análisis y diseño3.1.4.1 Dominio Básico.Este dominio se encuentra implícito (no es manejable de manera selectiva visual),ya que comprenderá todos aquellos atributos considerados pertinentes paracualquier usuario y de conocimiento elemental (calificados visualmente comoRecomendados), como lo son los datos personales, datos relacionados a suorigen y dirección, y ciertas preguntas que permitirán o no, acceder a ciertoscampos si es que el usuario desea algún perfil en especifico orientado a ciertodominio.La interfaz contempla un área recomendada y un área optativa, para los atributosde cada clase e incluso entre las mismas clases, las cuales como su nombre loindica, son obligatorias u opcionales de capturar, categorizándolas de acuerdo a eldominio de la aplicación elegido y a las dependencias con otras capturasposteriores, es decir, el área obligatoria contendrá aquellos datos que no tengandependencia de el valor almacenado en otros atributos de otras clases y aquellosatributos que sean parámetros (el acceso a otras capturas depende de este valor),tomando en cuenta siempre la relevancia de este dato y procurando en todomomento la requisición mínima necesaria de datos hacia el usuario.En esta interfaz se plantea el uso de dominios de la aplicación que identifican queconjuntos de datos de la ontología son pertinentes y necesarios para esa área.El conjunto de todas las áreas concederán la completitud de la ontología, el cualsería el escenario del peor caso para cuestiones de tiempo y dedicación por partedel usuario.Se han contemplado los siguientes dominios:3.1.4.2 Dominio Médico Este dominio fue concertado para poder contemplar atributos del usuariotales como enfermedades, minusvalías, discapacidades y ayuda técnica quepudiese utilizar el usuario, tales como: muletas, silla de ruedas, bastón, etc. Lascuales se consideran elementos importantes a considerar de un usuario siempre ycuando el interés esté orientado a un dominio medico.3.1.4.3 Dominio Familiar Este dominio ha sido acordado para aquellos usuarios cuya principalactividad sea discordante con el ámbito organizacional y educativo, en el cual, sedistinguen atributos como lo son las preferencias del usuario y los gustos referidosa programación televisiva, actividades recreativas y demás.Rojas, Christian 43
  • 55. Análisis y diseño3.1.4.4 Dominio Profesional Se contempló este dominio para poder categorizar usuarios que seandependientes de una empresa u organización y cuyos datos relacionados sean deinterés especifico, como lo son el nombre del puesto, el proyecto en el que seencuentre trabajando y en el que estuvo trabajando previamente, el número deempleados que tiene a su cargo, etc.3.1.4.5 Dominio Educativo Este dominio fue concertado para atribuir elementos específicos de estaárea como lo son datos acerca de la matriculación del usuario en la institución enla que estudia, el horario y demás.3.2 DISEÑOEl proyecto consta de los siguientes elementos: Una ontología que puede ser poblada y reutilizada. Un área operativa que tiene como finalidad poblar y recuperar la ontología. Una interfaz para el manejo del prototipo de manera transparente.Los paquetes que componen los elementos para el área operativa y la interfaz sonlos siguientes: mx.edu.cenidet.userontology.front para el manejo de la interfaz gráfica. mx.edu.cenidet.userontology.axiomsInference para las operaciones con la ontología.El nombre de los paquetes se asignó siguiendo las recomendaciones descritas enel artículo Estructura de paquetes [ITA09]Todas las clases obtienen datos de la clase DATA que se encuentra en elpaquete, la cual contiene elementos de configuración para el proyecto, como loson rutas físicas para los elementos que se necesitan, variables globales decontrol de extensibilidad, etc.En la figura 3.15 se muestra el diagrama de paquetes del proyecto. Figura 3.15 Diagrama de clases del proyectoRojas, Christian 44
  • 56. Análisis y diseñoEn la figura 3.16 se muestra el diagrama de clases del paquetemx.edu.cenidet.userontology.axiomsInference class mx.edu.cenidet.userontology.axiomsInference LoadAyudaTecnicaData Stor e - persona: person = new person() + InsertIndividualObjects(String, String, HashMap, HashMap<String, List>) : void + InsertIndividualProperties(String, String, HashMap, HashMap<String, List>) : void + LoadAyudaTecnicaData(AyudaTecnica) + ontocomm() : String LoadEstudioData LoadPersonalesData - persona: person = new person() LoadMiembrosData - persona: person = new person() + LoadEstudioData(Est udio) - persona: person = new person() + LoadPersonalesDat a(Personales, Seguridad) + LoadMiembrosData(Miembros) Tupla ~ type: URI ~ value: String LoadDireccionData #tupla ~ Tupla(URI, String) - persona: person = new person() -persona -persona -persona -persona + LoadDireccionData(Direccion) LoadEnfermedadesData -persona person - persona: person = new person() # attributes: HashMap <String,Tupla> = new HashMap<Str... -persona # clase: String + LoadEnfermedadesData(Enfermedades) RelationAll -persona # ind: String - persona: person = new person() # relations: HashMap<String, List> = new HashMap<Str... -persona # tupla: Tupla LoadPublicacionesData + RelationAll(Personales) - persona: person = new person() -persona # AtribIn(URI, String, String) : void + person() + LoadPublicacionesData(Publicaciones) -persona -persona -persona LoadOrigenData LoadTrabaj oData ChargePersonalesData - persona: person = new person() LoadNiv elComputoData - persona: person = new person() ~ dato: OWLConst ant - persona: person = new person() ~ factory: OWLDataFactory + LoadOrigenData(Origen) + LoadTrabajoData(Trabajo) ~ ind: OWLIndividual + LoadNivelComputoData(Personales) ~ propiedad: OWLDataPropert y ~ reasoner: Reasoner ChargeOrigenData LoadProyectoData - AtribOut(String) : String ~ dato: OWLConst ant ChargeDireccionData + ChargePersonalesDat a(Personales, Seguridad) ~ factory: OWLDataFactory - persona: person = new person() + getUser(String) : void ~ dato: OWLConst ant ~ ind: OWLIndividual ~ factory: OWLDataFactory ~ propiedad: OWLDataPropert y + LoadProyectoData(Proyect o) ~ ind: OWLIndividual ~ reasoner: Reasoner ~ propiedad: OWLDataPropert y ~ reasoner: Reasoner - AtribOut(String) : String ChargeEstudioData DATA + ChargeOrigenData(Origen) - AtribOut(String) : String ~ dato: OWLConst ant + ChargeDireccionData(Direccion) + ayudatec: boolean ~ factory: OWLDataFactory + enfermedades: boolean ~ ind: OWLIndividual + estudia: boolean ~ propiedad: OWLDataPropert y ChargeContactoData + estudiante: boolean ~ reasoner: Reasoner ChargeNiv elComputoData + geek: boolean ~ dato: OWLConst ant + GMT: String ~ factory: OWLDataFactory - AtribOut(String) : String ~ dato: OWLConst ant + GMTdefault: String ~ ind: OWLIndividual + ChargeEstudioData(Est udio) ~ factory: OWLDataFactory + GMTDISPLAY: String ~ propiedad: OWLDataPropert y ~ ind: OWLIndividual + GMTID: String ~ reasoner: Reasoner ~ propiedad: OWLDataPropert y ChargeProyectoData + Height: int ~ reasoner: Reasoner + InternalAreaHeight: int - AtribOut(String) : String ~ dato: OWLConst ant + InternalAreaWidth: int + ChargeContactoData(Contact o) - AtribOut(String) : String ~ factory: OWLDataFactory + miembro: boolean + ChargeNivelComputoData(Personales) ~ ind: OWLIndividual + MODIFY: boolean + getUser(String) : void ~ propiedad: OWLDataPropert y + NivelComputo: String = "" ChargeMiembrosData ~ reasoner: Reasoner ~ OntologyPath: String = "srcontolog... ~ dato: OWLConst ant + pass: String - AtribOut(String) : String + proyectos: boolean ~ factory: OWLDataFactory ChargeAyudaTecnicaData + ChargeProyectoData(Proyect o) + publica: boolean ~ ind: OWLIndividual ~ dato: OWLConst ant + session: String ~ propiedad: OWLDataPropert y ~ reasoner: Reasoner ~ factory: OWLDataFactory + trabaja: boolean ~ ind: OWLIndividual + trabajador: boolean ChargePublicacionesData - AtribOut(String) : String ~ propiedad: OWLDataPropert y ~ uri: String = "http://www.cen... + ChargeMiembrosData(Miembros) ~ reasoner: Reasoner ~ dato: OWLConst ant + Width: int ~ factory: OWLDataFactory + Zonetime: boolean = true - AtribOut(String) : String ~ ind: OWLIndividual + ZonetimeSession: boolean = true ChargeTrabaj oData + ChargeAyudaTecnicaData(AyudaTecnica) ~ propiedad: OWLDataPropert y ~ reasoner: Reasoner ~ dato: OWLConst ant Logi n ~ factory: OWLDataFactory - AtribOut(String) : String ~ ind: OWLIndividual Remov e + ChargePublicacionesData(Publicaciones) ~ authentication: Authentication = new Authentication() ~ propiedad: OWLDataPropert y ~ reasoner: Reasoner + deleteIndividual() : void + exist_the_login(String) : boolean + list_usersLogin() : List - AtribOut(String) : String + Login(Authentication) + ChargeTrabajoData(Trabajo) + login_password(String, String) : boolean Figura 3.16 Diagrama de clases del paquete mx.edu.cenidet.userontology.axiomsinferenceLa descripción de cada clase que compone el paquete se detalla en el Anexo 1.Rojas, Christian 45
  • 57. Análisis y diseñoEn la figura 3.17 se muestra el diagrama de clases del paquetemx.edu.cenidet.userontology.Front class mx.edu.cenidet.userontology.Front JInternalFrame JInternalFrame JInternalFrame EstiloV ida Apariencia AyudaTecnica JInternalFrame - CheckMuchoHogareno: JCheckBox = null ChooseDomai n - jContentPane: JPanel = null + CheckAndadera: JCheckBox = null - CheckMuchoSociable: JCheckBox = null - LabelAtletico: JLabel = null + CheckBast on: JCheckBox = null - ButtonHogar: JButton = null - CheckNadaHogareno: JCheckBox = null - LabelDelgado: JLabel = null + CheckMuletas: JCheckBox = null - ButtonHospital: JButton = null - CheckNadaSociable: JCheckBox = null - LabelEstetica: JLabel = null + CheckOtros: JCheckBox = null - ButtonOrganizacion: JButton = null - CheckPocoHogareno: JCheckBox = null - LabelMucho: JLabel = null + CheckSilla: JCheckBox = null - ButtonRegresar: JButton = null - CheckPocoSociable: JCheckBox = null - LabelMuyDelgado: JLabel = null - jContentPane: JPanel = null - ButtonSalir: JButton = null - CheckRegularHogareno: JCheckBox = null - LabelObeso: JLabel = null - LabelAndadera: JLabel = null - ButtonUniversidad: JButton = null - CheckRegularSociable: JCheckBox = null - LabelPoco: JLabel = null - LabelBaston: JLabel = null - interfaz: Interfaz - jContentPane: JPanel = null - LabelRegular: JLabel = null - LabelEspecifique: JLabel = null - jContentPane: JPanel = null - LabelHogareno: JLabel = null - LabelRegularVestuario: JLabel = null - LabelMuletas: JLabel = null - LabelHogar: JLabel = null - LabelMucho: JLabel = null - LabelVestuario: JLabel = null - LabelOtro: JLabel = null - LabelHospital: JLabel = null - LabelMuchoRelaciones: JLabel = null - RadioAtletico: JRadioButton = null - Labelseleccioneayuda: JLabel = null - LabelOrganizacion: JLabel = null - LabelNadaHogareno: JLabel = null - RadioDelgado: JRadioButton = null - LabelSillaruedas JLabel = null : - LabelSelecccioneDominio: JLabel = null - LabelNadaRelaciones: JLabel = null - RadioMucho: JRadioButton = null + TextOtros: JTextField = null - LabelUniversidad: JLabel = null - LabelPoco: JLabel = null - RadioMuyDelgado: JRadioButton = null - LabelPocoRelaciones: JLabel = null - RadioObeso: JRadioButton = null + AyudaTecnica() + ChooseDomain() - LabelRegular: JLabel = null - RadioPoco: JRadioButton = null - getJContentPane() : JPanel + ChooseDomain(String, Interfaz) - LabelRegularRelaciones: JLabel = null - RadioRegular: JRadioButton = null - initialize() : void - getJContentPane() : JPanel - LabelRelaciones: JLabel = null - RadioRegularVestuario: JRadioButton = null - initialize() : void «property get» + EstiloVida() + Apariencia() - getCheckAndadera() : JCheckBox «property get» - getCheckBast on() : JCheckBox - getButtonHogar() : JButt on +estilovida - getJContentPane() : JPanel - getJContentPane() : JPanel - initialize() : void - getCheckMuletas() : JCheckBox - getButtonHospital() : JButton - initialize() : void «property get» - getCheckOtros() : JCheckBox - getButtonOrganizacion() : JButton «property get» - getCheckSilla() : JCheckBox - getButtonRegresar() : JButt on - getCheckMuchoHogareno() : JCheckBox - getRadioAtletico() : JRadioButton - getTextOtros() : JTextField - getButtonSalir() : JButton - getCheckMuchoSociable() : JCheckBox - getRadioDelgado() : JRadioButton - getButtonUniversidad() : JButton - getCheckNadaHogareno() : JCheckBox - getRadioMucho() : JRadioButton +ayudatecnica - getCheckNadaSociable() : JCheckBox JFrame - getRadioMuyDelgado() : JRadioButton - getCheckPocoHogareno() : JCheckBox - getRadioObeso() : JRadioButton Interfa z JInternalFrame - getCheckPocoSociable() : JCheckBox - getRadioPoco() : JRadioButton +aparienciaapariencia: Apariencia = new Apariencia() Enfermedade s - getCheckRegularHogareno() : JCheckBox + - getRadioRegular() : JRadioButton - getCheckRegularSociable() : JCheckBox + ayudatecnica: AyudaTecnica = new AyudaTecnica() - getRadioRegularVestuario() : JRadioButton + CheckCancer: JCheckBox = null + contacto: Contacto = new Contacto() + CheckCardiopatia: JCheckBox = null + direccion: Direccion = new Direccion() + CheckCerebo: JCheckBox = null + door: Clases = new Clases("DA T... + CheckDiabetes: JCheckBox = null JInternalFrame + enfermedad: Enfermedades = new Enfermedades() -interfaz + CheckHipertension: JCheckBox = null Clase s + estilovida: EstiloVida = new EstiloVida() + CheckIntestinales: JCheckBox = null JInternalFrame + estudio: Estudio = new Estudio(this) - ButtonApariencia: JButton = null + CheckNeumonia: JCheckBox = null Direccion + geeko: GEEK = new GEEK() - ButtonAyudaTecnica: JButton = null + checkSIDA: JCheckBox = null + intereses: Int ereses = new Int ereses() - ButtonContacto: JButton = null + CheckTuberculosis: JCheckBox = null + ButtonCambiarZoneTime: JButton = null - jContentPane: JPanel = null - ButtonDireccion: JButton = null + ComboPerinatales: JComboBox = null + ComboRegion: JComboBox = null + miembros Miembros = new Miembros() : - ButtonEnfermedades: JButton = null - jContentPane: JPanel = null - jContentPane: JPanel = null + origen: Origen = new Origen() - ButtonEstiloVida: JButton = null - LabelCancer: JLabel = null - LabelColonia: JLabel = null - PanelAreaTrabajo: JDesktopPane = null - ButtonEstudio: JButton = null - LabelCardiopatia: JLabel = null - LabelCP: JLabel = null + personales: Personales = new Personales(this) - ButtonGEEK: JButton = null - LabelCerebro: JLabel = null - LabelDireccion: JLabel = null + proyecto: Proyecto = new Proyecto() - Buttonintereses: JButton = null - LabelDiabetes: JLabel = null - LabelDireccion1: JLabel = null + publicaciones: Publicaciones = new Publicaciones() - ButtonMiembros: JButton = null - LabelEnferemedadesPerinatales: JLabel = null - LabelDistritoLocal: JLabel = null ~ saver: Saver = new Saver(this) - ButtonOrigen: JButton = null - LabelEnfermedadesContagiosas: JLabel = null - LabelExt: JLabel = null + seguridad: Seguridad = new Seguridad() - ButtonProyecto: JButton = null - LabelEnfermedadesNoContagiosas: JLabel = null - LabelInt: JLabel = null - serialVersionUID: long = 1L {readOnly} - ButtonPublicaciones: JButton = null - LabelHipertension: JLabel = null - LabelMunicipioDir: JLabel = null + trabajo: Trabajo = new Trabajo(this) - ButtonSeguridad: JButton = null - LabelInfeccionesIntestinales: JLabel = null - LabelNum: JLabel = null - ButtonTrabajo: JButton = null - LabelNeumonia: JLabel = null - LabelPiso: JLabel = null - getJContentPane() : JPanel - ButttonPersonales: JButton = null +enfermedad - LabelOtraContagiosa: JLabel = null - LabelPuerta: JLabel = null + initialize() : void - interfaz: Interfaz - LabelOtraNoContagiosa: JLabel = null - LabelRegion: JLabel = null + Interfaz() - PanelOrganizacion: JPanel = null -interfaz - LabelSeleccione: JLabel = null + LabelRegionG: JLabel = null + LoadInternalFrames() : void - pos: int - LabelSIDA: JLabel = null - PanelDireccion: JPanel = null + main(String[]) : void +door - posOp: int - LabelTuberculosis: JLabel = null - PanelDireccionOptativo: JPanel = null + rebootClases() : v oid - ProgressDH: JProgressBar = null +direccion - PanelEnfermedades: JPanel = null + TextColonia: JTextField = null # RebootInternalFrame() : void + TextOtraContagiosa: JTextField = null + TextCP: JTextField = null - SetInvisibleElementsContacto() : void + Clases() + TextOtraNoContagiosa: JTextField = null + TextDireccion: JTextField = null + showApariencia() : void + Clases(String, Interfaz ) + TextDistritoLocal: JTextField = null + showAuthentication() : void - initialize() : void + Enfermedades() + TextExt: JTextField = null + showAyudaTecnica() : void - getCheckSIDA() : JCheckBox «property get» + TextInt: JTextField = null + ShowChooseDomain() : void - getJContentPane() : JPanel - getButtonApariencia() : JButton + TextMunicipioDir: JTextField = null + showClases() : v oid - initialize() : void - getButtonAyudaTecnica() : JButton + TextPiso: JTextField = null + showContacto() : void + TextPuerta: JTextField = null «property get» - getButtonContacto() : JButt on + showDireccion() : void - getCheckCancer() : JCheckBox - getButtonDireccion() : JButton + showEnfermedades() : void - getCheckCardiopatia() : JCheckBox - getButtonEnfermedades() : JButt on + Direccion() + showEstiloVida() : void - getCheckCerebo() : JCheckBox - getButtonEstiloVida() : JButton - getJContentPane() : JPanel + showEstudio() : void - getCheckDiabetes() : JCheckBox - getButtonEstudio() : JButt on - initialize() : void + showGEEK() : void -interfaz - getCheckHipert ension() : JCheckBox - getButtonGEEK() : JButt on «property get» + showIntereses() : v oid - getCheckInt estinales() : JCheckBox - getButtonintereses() : JButt on - getButtonCambiarZoneTime() : JButton + showMiembros() : void - getCheckNeumonia() : JCheckBox - getButtonMiembros() : JButton - getComboRegion() : JComboBox + showOrigen() : void - getCheckTuberculosis() : JCheckBox - getButtonOrigen() : JButton - getPanelDireccion() : JPanel + showPersonales() : v oid - getComboPerinatales() : JComboBox - getButtonProyecto() : JButt on - getPanelDireccionOptativo() : JPanel + showProyecto() : void - getPanelEnfermedades() : JPanel - getButtonPublicaciones() : JButton - getTextColonia() : JTextField + showPublicaciones() : void - getTextOtraContagiosa() : JTextField - getButtonSeguridad() : JButton - getTextCP() : JTextField + showSaver() : void - getTextOtraNoContagiosa() : JTextField - getButtonTrabajo() : JButton - getTextDireccion() : JTextField + showSeguridad() : void - getButttonPersonales() : JButt on - getTextDistritoLocal() : JTextField + showTaskChoice() : void - getPanelOrganizacion() : JPanel - getTextExt() : JTextField + showTrabajo() : void JDialog - getProgressDH() : JProgressBar - getTextInt() : JTextField «property get» - getTextMunicipioDir() : JTextField - getPanelAreaTrabajo() : JDesktopPane Authentication +publicaciones - getTextPiso() : JTextField - ButtonAceptar: JButton = null JInternalFrame - getTextPuerta() : JTextField +geeko - ButtonAceptarNew: JButton = null Publicacione s -direccion JInternalFrame - ButtonCancel: JButton = null - ButtonCancelNew: JButton = null - jContentPane: JPanel = null JDialog GEE K - ButtonNuevo: JButton = null - LabelPublicaciones: JLabel = null ZoneTime - jContentPane: JPanel = null - interfaz: Interfaz + TextPublicaciones: JTextField = null - LabelOtroGEEK: JLabel = null - jContentPane: JPanel = null - ButtonCambia: JButton = null - LabelConfirme: JLabel = null - getJContentPane() : JPanel - LableCodigoGEEK: JLabel = null - ButtonDejar: JButton = null - LabelPassword: JLabel = null - initialize() : void - TextGEEK: JTextField = null - direccion: Direccion - LabelUser: JLabel = null + Publicaciones() - TextGEEKOtro: JTextField = null - jContentPane: JPanel = null - TextPassword: JPasswordField = null «property get» - LabelZoneTime1: JLabel = null - TextPasswordNew: JPasswordField = null + GEEK() - getTextPublicaciones() : JTextField - LabelZoneTime2: JLabel = null - TextUser: JTextField = null - getJContentPane() : JPanel - LabelZoneTime3: JLabel = null - initialize() : void - RadioDespues: JRadioButton = null + Authentication() - RadioNunca: JRadioButton = null «property get» + Authentication(String, Interfaz) - getTextGEEK() : JTextField - getJContentPane() : JPanel - getJContentPane() : JPanel - getTextGEEKOtro() : JTextField - initialize() : void - initialize() : void «property get» + ZoneTime() - getButtonAceptar() : JButt on + ZoneTime(Direccion) - getButtonAceptarNew() : JButt on «property get» - getButtonCancel() : JButton - getButtonCambia() : JButton - getButtonCancelNew() : JButton - getButtonDejar() : JButton - getButtonNuevo() : JButt on - getRadioDespues() : JRadioButt on - getTextPassword() : JPasswordField - getRadioNunca() : JRadioButton - getTextPasswordNew() : JPasswordField - getTextUser() : JTextFieldRojas, Christian 46
  • 58. Análisis y diseño class mx.edu.cenidet.userontology.Front JInternalF rame JInternalF rame JInternalF rame JInternalF rame Personale s Interese s Proyecto Sav er - jContentPane: JPanel = null + BoxMiembro: JCheckBox = null - CheckPunk: JCheckBox = null - ButtonCancel: JButton = null + CheckEnfermedad: JCheckBox = null - jContentPane: JPanel = null - jPanel1: JPanel = null - ButtonExit: JButton = null + CheckMinusvalia: JCheckBox = null - LabelCyberPunk: JLabel = null - LabelPoyecto: JLabel = null - ButtonSave: JButton = null - LabelProyectoActual: JLabel = null + ComboComputo: JComboBox = null - LabelEconomia: JLabel = null - interfaz: Interfaz - LabelProyetoAnteriorl: JLabel = null + ComboDedicacion: JComboBox = null - LabelFrecuenteEconomia: JLabel = null - jContentPane: JPanel = null + ComboSexo: JComboBox = null - LabelFrecuentePolitica: JLabel = null + T extProyectoActual: JTextField = null - ProgressSave: JProgressBar = null - interfaz: Interfaz - LabelFrecuenteSociales: JLabel = null + T extProyectoAnterior: JT extField = null - jContentPane: JPanel = null - LabelMuyEconomia: JLabel = null - getJContentPane() : JPanel - getJContentPane() : JPanel - LabelAgenteLegal: JLabel = null - LabelMuyPGP: JLabel = null - initialize() : void - LabelApellido: JLabel = null - LabelMuyPolitica: JLabel = null - getJPanel1() : JPanel + Saver() - LabelDD: JLabel = null - LabelMuySociales JLabel = null : - initialize() : void + Saver(Interfaz ) + Proyecto() - LabelDedicacion: JLabel = null - LabelNingunEconomia: JLabel = null - LabelEdoCivil: JLabel = null «property get» - LabelNingunPGP: JLabel = null «property get» - LabelEnfermedad: JLabel = null ~sav er - getButtonCancel() : JButton - LabelNingunPolitica: JLabel = null - getT extProyectoActual() : JT extField - LabelFechanac: JLabel = null - getButtonExit() : JButton - LabelNingunSociales: JLabel = null - getT extProyectoAnterior() : JT extField - LabelFijo: JLabel = null - getButtonSave() : JButt on - LabelPolitica: JLabel = null +proyecto - LabelLevel: JLabel = null - getProgressSave() : JProgressBar - LabelRegularPGP: JLabel = null - LabelMiembro: JLabel = null - LabelSinEconomia: JLabel = null JF rame - LabelMinusvalia: JLabel = null - LabelSinPolitica: JLabel = null Interfa z - LabelMinusvalidos JLabel = null : - LabelSinSociales JLabel = null : JInternalF rame - LabelMM: JLabel = null - LabelSociales: JLabel = null + apariencia: Apariencia = new Apariencia() Task Choice - LabelMovil: JLabel = null - LabePGP: JLabel = null + ayudatecnica: AyudaT ecnica = new AyudaT ecnica() - LabelNick: JLabel = null - RadioFrecuenteEconomia: JRadioButton = null + contacto: Contacto = new Contacto() - ButtonBack: JButton = null - Labelnick1: JLabel = null - RadioFrecuentePolitica: JRadioButton = null + direccion: Direccion = new Direccion() - ButtonDrop: JButton = null - LabelNivelComputo: JLabel = null - RadioFrecuenteSociales: JRadioButton = null + door: Clases = new Clases("DA T ... - ButtonModify: JButton = null - LabelNombre: JLabel = null - RadioMuyEconomia: JRadioButton = null + enfermedad: Enfermedades = new Enfermedades() - caja: JT extArea = new JT extArea() - LabelNombrePref: JLabel = null - RadioMuyPGP: JRadioButton = null + estilovida: EstiloVida = new EstiloVida() - interfaz: Interfaz - LabelPersonal: JLabel = null - RadioMuyPolitica: JRadioButton = null + estudio: Estudio = new Estudio(this) - jContentPane: JPanel = null - LabelSexo: JLabel = null - RadioMuySociales: JRadioButton = null + geeko: GEEK = new GEEK() - Label: JLabel = null - LabelSlash: JLabel = null - RadioNingunEconomia: JRadioButton = null + intereses: Int ereses = new Int ereses() - LabelSlash1: JLabel = null - RadioNingunPGP: JRadioButton = null - jContentPane: JPanel = null - getJContentPane() : JPanel - LabelT elefono: JLabel = null - RadioNingunPolitica: JRadioButton = null + miembros Miembros = new Miembros() : - initialize() : void - LabelTitulo: JLabel = null - RadioNingunSociales: JRadioButton = null + origen: Origen = new Origen() + T askChoice() - LabelYYYY: JLabel = null - RadioRegularPGP: JRadioButton = null - PanelAreaT rabajo: JDesktopPane = null + T askChoice(Interfaz ) +interfaz PanelEnfermedades: JPanel = null - - RadioSinEconomia: JRadioButton = null +intereses + personales: Personales = new Personales(this) «property get» - PanelNivelComputo: JPanel = null - RadioSinPolitica: JRadioButton = null + proyecto: Proyecto = new Proyecto() - getButtonBack() : JButt on - PanelPersonales: JPanel = null - RadioSinSociales: JRadioButton = null + publicaciones: Publicaciones = new Publicaciones() - getButtonDrop() : JButt on - PanelPersonalesOptativo: JPanel = null ~ saver: Saver = new Saver(this) + PasswordNuev oDos: JPasswordField = null - getButtonModify() : JButton - getJContentPane() : JPanel + seguridad: Seguridad = new Seguridad() + T extAgenteLegal: JT extField = null - initialize() : void - serialVersionUID: long = 1L {readOnly} +personales + T extApellido: JT extField = null -interfaz + Intereses() + trabajo: T rabajo = new T rabajo(this) -interfaz JInternalF rame + T extDia: JT extField = null «property get» + T extEdoCivil: JT extField = null Miembros - getChec kPunk() : JCheckBox - getJContentPane() : JPanel + T extFijo: JT extField = null - getRadioFrecuenteEconomia() : JRadioButton + initialize() : void - jContentPane: JPanel = null + T extMM: JT extField = null - getRadioFrecuentePolitica() : JRadioButton + Interfaz() + T extMovil: JT extField = null - Label1: JLabel = null - getRadioFrecuenteSociales() : JRadioButton + LoadInternalFrames() : void - Label2: JLabel = null + T extNickUser: JT extField = null - getRadioMuyEconomia() : JRadioButton + main(String[]) : void - Label3: JLabel = null + T extNombre: JT extField = null - getRadioMuyPGP() : JRadioButton + rebootClases() : v oid - LabelNombreClub: JLabel = null + T extNombrePref: JT extField = null - getRadioMuyPolitica() : JRadioButton # RebootInternalFrame() : void + T extTitulo: JT extField = null - LabelnombresMiembros: JLabel = null +miembros - getRadioMuySociales() : JRadioButton - SetInvisibleElementsContacto() : void + T extMiembro1: JT extField = null + T extYYYY: JT extField = null - getRadioNingunEconomia() : JRadioButton + showApariencia() : void + T extMiembro2: JT extField = null - getRadioNingunPGP() : JRadioButton + showAuthentication() : void + T extMiembro3: JT extField = null - getJContentPane() : JPanel - getRadioNingunPolitica() : JRadioButton + showAyudaT ecnica() : void + T extNombreClub: JT extField = null - initialize() : void - getRadioNingunSociales() : JRadioButton + ShowChooseDomain() : void + Personales() - getRadioRegularPGP() : JRadioButton + showClases() : v oid + Personales(Interfaz ) - getJContentPane() : JPanel - getRadioSinEconomia() : JRadioButton + showContacto() : void - initialize() : void «property get» + Miembros() - getRadioSinPolitica() : JRadioButton + showDireccion() : void - getBoxMiembro() : JCheckBox - getRadioSinSociales() : JRadioButton + showEnfermedades() : void «property get» + showEstiloVida() : void - getCheckEnfermedad() : JCheckBox - getCheckMinusvalia() : JCheckBox - getT extMiembro1() : JT extField + showEstudio() : void -interfaz - getT extMiembro2() : JT extField - getComboComputo() : JComboBox JInternalF rame + showGEEK() : void - getT extMiembro3() : JT extField - getComboDedicacion() : JComboBox + showIntereses() : v oid - getT extNombreClub() : JTextField Contacto - getComboSexo() : JComboBox + showMiembros() : void - getPanelEnfermedades() : JPanel - jContentPane: JPanel = null + showOrigen() : void - getPanelNivelComputo() : JPanel + LabelChat: JLabel = null + showPersonales() : v oid JInternalF rame +contacto - getPanelPersonales() : JPanel + LabelEmail: JLabel = null + showProyecto() : void - getPanelPersonalesOptativo() : JPanel Segurida d + LabelHomePage: JLabel = null + showPublicaciones() : void - getT extAgenteLegal() : JT extField + LabelICQ: JLabel = null + showSaver() : void +seguridad - jContentPane: JPanel = null - getT extApellido() : JT extField + LabelJabber: JLabel = null + showSeguridad() : void - LabelOldPass: JLabel = null + showT askChoice() : void - getT extDia() : JTextField + LabelMensajeriaInstantanea: JLabel = null - LabelPasswordDos: JLabel = null - getT extEdoCivil() : JT extField + LabelMSN: JLabel = null + showT rabajo() : void - LabelPasswordUno: JLabel = null - getT extFijo() : JT extField + LabelOpenID: JLabel = null «property get» - PanelSeguridad: JPanel = null - getT extMM() : JT extField + LabelWebLog: JLabel = null - getPanelAreaT rabajo() : JDesktopPane + PasswordNuev oDos: JPasswordField = null - getT extMovil() : JT extField + LabelYahoo: JLabel = null - PasswordNuevoUno: JPasswordField = null -interfaz - getT extNickUser() : JT extField - loc: int + PasswordViejo: JPasswordField = null - getT extNombre() : JT extField - loclabels: int +trabajo + T extpass: JT extField = null - getT extNombrePref() : JT extField + PanelContacto: JPanel = null - getT extT itulo() : JT extField + T extChat: JT extField = null JInternalF rame - getJContentPane() : JPanel - getT extYYYY() : JT extField + T extEmail: JT extField = null Trabaj o +origen - initialize() : void + T extICQ: JT extField = null + Seguridad() + ComboHorario: JComboBox = null JInternalF rame + T extJabber: JTextField = null «property get» + T extMensajeriaInstantanea: JT extField = null + ComboT ipoContratacion: JComboBox = null Orige n - getPanelSeguridad() : JPanel + T extMSN: JT extField = null + ComboTipoT rabajo: JComboBox = null - ButtonNivelComputo: JButton = null - getPasswordNuevoDos() : JPasswordField + T extOpenID: JTextField = null - interfaz: Interfaz - jContentPane: JPanel = null - getPasswordNuevoUno() : JPasswordField + T extPaginaPersonal: JTextField = null - jContentPane: JPanel = null - LabelCiudad: JLabel = null - getPasswordViejo() : JPasswordField + T extWebLog: JT extField = null - LabelDependientes: JLabel = null - LabelDistrito: JLabel = null - getT extpass() : JT extField + T extYahoo: JT extField = null - LabelHorario: JLabel = null - LabelNombreEmpresa: JLabel = null - LabelGobierno: JLabel = null - LabelPersonasUnidad: JLabel = null - LabelLocalidad: JLabel = null + Contacto() +estudio - LabelMoneda: JLabel = null JInternalF rame - getJContentPane() : JPanel - LabelPuesto: JLabel = null - LabelTipo: JLabel = null - LabelMunicipio: JLabel = null Estudi o - initialize() : void - LabelT ipoContratacion: JLabel = null - LabelOrigen: JLabel = null «property get» - LabelPais: JLabel = null + ComboNivelEducativo: JComboBox = null - PanelT rabajo: JPanel = null - getPanelContacto() : JPanel - Origen: JPanel = null - interfaz: Interfaz - PanelT rabajoOptativo: JPanel = null - getT extChat() : JT extField - PanelOrigenOptativo: JPanel = null - jContentPane: JPanel = null + T extDependientes: JT extField = null - getT extEmail() : JT extField + T extCiudad: JT extField = null - LabelInstitucion: JLabel = null + T extNombreEmpresa: JTextField = null - getT extICQ() : JT extField + T extDistrito: JT extField = null - LabelMatricula: JLabel = null + T extPersonasUnidad: JT extField = null - getT extJabber() : JT extField + T extGobierno: JT extField = null - LabelNivelEducativo: JLabel = null + T extPuesto: JT extField = null - getT extMensajeriaInstantanea() : JT extField + T extLocalidad: JT extField = null - LabelSupervisor: JLabel = null - getT extMSN() : JTextField + T extMoneda: JT extField = null - PanelEstudio: JPanel = null - getJContentPane() : JPanel - getT extOpenID() : JT extField + T extMunicipio: JT extField = null - PanelEstudiosOptativo: JPanel = null - initialize() : void - getT extPaginaPersonal() : JT extField + T extPais JT extField = null : + T extInstitucion: JT extField = null + T rabajo() - getT extWebLog() : JT extField + T extMatricula: JT extField = null + T rabajo(Interfaz) - getT extYahoo() : JT extField - getJContentPane() : JPanel + T extSupervisor: JT extField = null «property get» - initialize() : void - getComboHorario() : JComboBox + Origen() + Estudio() - getComboT ipoContratacion() : JComboBox + Estudio(Interfaz ) - getComboT ipoT rabajo() : JComboBox «property get» - getJContentPane() : JPanel - getPanelT rabajo() : JPanel - getOrigen() : JPanel - initialize() : void - getPanelT rabajoOptativo() : JPanel - getPanelOrigenOptativo() : JPanel - getT extCiudad() : JT extField «property get» - getT extDependientes() : JT extField - getT extDistrito() : JT extField - getComboNivelEducativo() : JComboBox - getT extNombreEmpresa() : JT extField - getT extGobierno() : JT extField - getPanelEstudio() : JPanel - getT extPersonasUnidad() : JT extField - getT extLocalidad() : JTextField - getPanelEstudiosOptativo() : JPanel - getT extPuesto() : JT extField - getT extMoneda() : JT extField - getT extInstitucion() : JT extField - getT extMunicipio() : JT extField - getT extMatricula() : JT extField - getT extPais() : JT extField - getT extSupervis or() : JT extField Figura 3.17 Diagrama De Clases De El Paquete mx.edu.cenidet.userontology.FrontRojas, Christian 47
  • 59. Análisis y diseñoLa descripción de cada clase que compone el paquete se detalla en el Anexo 2.3.2.1 Actividades del proyectoEn esta sección se muestran las principales tareas que se realizan en esteproyecto, con sus detalles y respectivos diagramas de secuencias para explicarlas actividades desarrolladas.El proceso lo inicia la aplicación Interfaz desde la cual se invocan los métodos delas demás clases, la cual instancia a una clase llamada DATA que contiene loselementos genéricos y de configuración de la aplicación que permitirán realizaroperaciones con la ontología.Para poder realizar cualquiera de las operaciones hacia o desde la ontología, esnecesaria una conexión con la ontología. El proceso de conexión detallado semuestra en el diagrama de secuencias de la figura 3.18.3.2.1.1 Conexión con ontologíaPara la conexión con la ontología, son necesarios los siguientes elementos: API de conexión (OWLAPI). Este elemento permitirá mediante sus métodos y clases, el enlace con la ontología y la inserción, modificación o eliminación de individualizaciones, propiedades, axiomas y demás. “Manager” y “Factory” son dependientes de “OWLAPI” y son descritas a continuación: o Manager. Se encargara de manejar la ontología a partir de su ubicación física como una entidad lógica y así operar localmente en ella. [Sforge09] o Factory. Es una clase que implementa métodos para estandarizar los identificadores conceptuales para los elementos de la ontología, como lo son las individualizaciones, las propiedades, las relaciones y demás. [Sforge09] Razonador (PELLET). Permitirá verificar la integridad y consistencia de la ontología de acuerdo a sus elementos guardados. Asegurando la coherencia de los tipos de datos guardados con los permitidos o especificados.Para el proceso de conexión con la ontología, primero se instancia la clase Store,mediante el método ontocomm(), la cual solicita la dirección física de la ontología,que deberá encontrarse almacenada en la clase DATA, obteniéndose así unadirección absoluta que permitirá que la API maneje los identificadoresconceptuales para los elementos de la ontología.Rojas, Christian 48
  • 60. Análisis y diseñoPosteriormente, se iniciarán los servicios referidos anteriormente, los cuales son“Manager”, “Factory” y el “Razonador”, y se devolverán por parte de la API deconexión “OWLAPI”, los identificadores de estos servicios. Figura 3.18 Diagrama de secuencias para la Conexión con la ontologíaCabe mencionar que esta conexión no requiere un cierre al terminar de utilizarla,por este motivo será necesaria una conexión por cada acceso a los datos de laontología.A continuación se describen los métodos involucrados en el ingreso al sistema porparte del usuario en sus opciones de usuario nuevo o existente.3.2.1.2 Usuario nuevoMediante una instanciación de la clase Authentication por medio del métodoShowAuthentication(), se solicita al usuario un nombre de usuario y unacontraseña (la cual debe ser requerida dos veces para verificar congruencia enesta), y verificará la disponibilidad de el nombre de usuario elegido mediante lainvocación del método exist_the_login() de la clase Login, el cual le envía comoparámetro el nombre de usuario elegido y recuperara de la invocación dichavalidación.Una vez realizado esto, y siendo satisfactoria la validación de un nuevo usuario, semostrará en pantalla la interfaz para la elección del dominio de la aplicación haciala cual se inclinará la información mostrada. El diagrama de secuencia para esteproceso se muestra en la figura 3.19Rojas, Christian 49
  • 61. Análisis y diseño Figura 3.19 Diagrama de secuencias para ingresar al sistema como usuario nuevoUna vez mostrada la pantalla para la elección del dominio de la aplicación setermina el proceso de autenticación para un usuario nuevo y continúa el procesode elección del dominio de la aplicación. (Véase Elección del dominio deaplicación)3.2.1.3 Usuario existenteEn esta actividad, se realiza una instanciación de la clase interfaz para mostrar enpantalla el panel base sobre el cual se invocarán los métodos a utilizar en eltranscurso de la aplicación.Se instancia entonces la clase Authentication mediante el métodoshowAuthentication(),el cual, solicitará al usuario un nombre de usuario y unacontraseña, la cual deberá existir registrada en la ontología, para ello hace uso deun método dentro de la clase Login, invocándolo mediante login_password,enviando como parámetros el nombre de usuario y la contraseña proporcionada,la cual invocará a sí misma, los métodos: exist_the_login() que recibirá comoparámetro el nombre de usuario en cuestión y list_usersLogin() la cual seencargará de verificar esta existencia.Rojas, Christian 50
  • 62. Análisis y diseñoUna vez realizado esto, y siendo satisfactoria la validación del usuario registrado,se mostrará en pantalla la interfaz para la elección de la operación a realizar con laontología relacionada a el usuario dispuesto. El diagrama de secuencia para esteproceso se muestra en la figura 3.20 Figura 3.20 Diagrama de secuencias para ingresar al sistema como usuario existenteUna vez terminado el proceso de autenticación para un usuario registrado, semuestra un mensaje de éxito, y continúa el proceso de elección de la operación arealizar en la ontología. (Véase 3.2.1.8)Para poder realizar las operaciones de guardado de datos en la ontología, esnecesario explicar primero el procedimiento para procesar el volcado de estosdatos en la ontología, es decir, haciendo uso de la API (OWLAPI), del razonador yde las clases pertinentes.3.2.1.4 Guardado en ontologíaEste proceso es efectuado después de que el usuario realiza algún cambio en susdatos y desea verlos reflejados en la ontología o cuando el usuario guarda porprimera vez sus datos.Rojas, Christian 51
  • 63. Análisis y diseñoSe comienza con la instanciación de la clase Remove, mediante la llamadadeleteIndividual() (véase 3.2.1.6), la cual se encargará de eliminar todas lasindividualizaciones operadas por la interfaz, utilizando para ello la conexión con laontología (véase 3.2.1.1), una vez devuelto el mensaje de éxito de la remoción deindividualizaciones pertinentes, se procede al volcado de los datos desde laspantallas de interfaz respectivas hacia las clases en la ontología cuyo procesoinvolucra la obtención de los datos desde las casillas de la interfaz y la ubicaciónde estos en los campos respectivos en la ontología.A continuación se procede a relacionar las individualizaciones, mediante la claseRelationAll, la cual verificará si se encuentran datos cuyo valor sea necesario,dentro de la clase DATA, y posteriormente se crearán las relaciones a lasindividualizaciones de manera iterativa una a una.Posteriormente agrupará todas las relaciones y las empaquetará para enviarlascomo parámetros (clase a operar, identificador conceptual actual, conjunto deatributos a insertar y conjunto de relaciones a insertar) en el métodoInsertIndividualObjects que invocará la clase STORE, la cual entablará unaconexión con la ontología (véase 3.2.1.1). Para finalmente retornar un mensaje deéxito.EL diagrama de secuencias que describe este proceso se muestra en la figura3.21Rojas, Christian 52
  • 64. Análisis y diseño Figura 3.21 Diagrama de secuencias del proceso Guardar ontologíaA continuación se describirá el proceso de modificación de la ontología, el cuallleva implícito el proceso de lectura de la misma y del vaciado de estos datos enlas casillas y elementos respectivos de la interfaz apropiada.3.2.1.5 Modificar en ontologíaEste método se encarga de obtener los datos de la ontología y asignarlos a loselementos respectivos en la interfaz.Primero se realiza una invocación de la lectura de ontología, la cual se encarga deleer los datos respectivos de la ontología uno a uno, para posteriormente asignaresos datos a las clases de la interfaz adecuada.Una vez terminado este proceso se muestra en pantalla dichas clases de lainterfaz con los datos recuperados de la ontología.Este proceso se encuentra detallado en el diagrama de secuencias de la figura3.22Rojas, Christian 53
  • 65. Análisis y diseño Figura 3.22 Diagrama de secuencias del proceso Modificación de ontología3.2.1.6 Eliminado de ontologíaEn esta actividad de la aplicación se eliminarán las individualizaciones pertinentes(utilizadas) por la misma aplicación, dejando intactas cualquier otra relación,individualización o atributo encontrado en la ontología extras.EL proceso inicia instanciando la clase Remove mediante el métododeleteIndividual(), el cual realizará iterativamente una conexión con la ontología(véase 3.2.1.1) y una eliminación de la individualización respectiva a la iteración.Por último se obtendrá como resultado un mensaje de éxito de la eliminación delos elementos en la ontología.EL proceso detallado se muestra en el diagrama de secuencias en la figura 3.23 Figura 3.23 Diagrama de secuencias del proceso Eliminación de la ontologíaRojas, Christian 54
  • 66. Análisis y diseño3.2.1.7 Elección de dominioEsta actividad de la aplicación funciona como un menú para poder acceder acualquiera de los dominios dispuestos, los cuales se encargarán de inclinar lacaptura de los datos del usuario dentro de la interfaz, disponiendo estos en doscategorías, “Recomendados” y “Opcionales”. Véase Tabla 1.33.2.1.8 Elección de operación en ontologíaEste proceso se muestra en pantalla como un menú, después de haberseautenticado el usuario dependiendo de si es un usuario nuevo o existente en losregistros de la ontología, y permitirá acceder a las clases correspondientes pararealizar la operación pertinente, como lo son: modificar, eliminar o agregar datos.Rojas, Christian 55
  • 67. Análisis y diseñoRojas, Christian 56
  • 68. 4. CAPÍTULO IV. DESARROLLO DE LA SOLUCIÓNEn este capítulo se presenta un análisis de la metodología a seguir para laconstrucción de la ontología, así como una aproximación de la misma. Se muestratambién en detalle la formalización de las características propuestas para laontología.
  • 69. Desarrollo de la soluciónA continuación, se describe el procedimiento para la obtención de la ontología,involucrando elementos y restricciones además de la metodología para laobtención de la interfaz gráfica, que servirá para la población, explotación y uso derestricciones propuestas. 4.1 RECOPILACIÓN, DISCRIMINACIÓN E INTEGRACIÓN DE DATOSPara el desarrollo de esta primera fase del proyecto fue necesario analizar lasposibles categorizaciones de un usuario, tanto en el tema de mercadotecnia, comootras áreas de estudio incluyendo algunas ontologías disponibles yafundamentadas para un propósito similar.Las ontologías relacionadas que se analizaron fueron: Aktors, FOAF y SOUPAentre otras, las cuales se muestran a detalle en el estado del arte. De entre todasestas se extrajeron los atributos que se muestran en la tabla 7 Tabla 4.1. Recopilación de atributos pertinentes para perfilar a un usuario. Clase Atributos datatype Atributos object Apariencia Forma Vestuario Ayuda Técnica Tipo ayuda Contacto E_mail Weblog Icq Id_chat Jabber Mensajeria msn openid perfiles yahoo Dirección calle código postal municipio numero numero int piso puerta región geo Enfermedades Transmisibles tipos transmisibles No transmisibles tipos no transmisibles Estilo de vida Hogareño? Relaciones? Estudio institución Matricula Nivel educativo Supervisor GEEK Código geekRojas, Christian 58
  • 70. Desarrollo de la solución Otros geek Intereses Cyberpunk Economía Pgp(pretty good privacy) Política Temas sociales Miembro Nombre club Miembros Nivel Cómputo Conocimiento computo Origen Ciudad Distrito local Gobierno Localidad Moneda Municipio País Persona TODAS las clases Personales Agente legal Apellido Dedicación Edo civil Fecha_nac Tel fijo Tel móvil Nick Nombre Nombre pref. Password Sexo Teléfono Titulo Preferencias Hobbies Tipo_comida Dominio aplic. Zona horaria Lugares_favoritos_viaje Otra_dedicacion Habilidades Vehiculos_motorizados Peliculas_al_mes Genero_peliculas Reality_shows Programas_noticias Horario_dormir Mascotas Periodico Proyecto Anterior Actual Publicaciones Link publicaciones Trabajo Dependientes Horario Nombre empresa Personal depto. Puesto Tipo Tipo contrataciónRojas, Christian 59
  • 71. Desarrollo de la soluciónEn la tabla 4.1 se muestra una cantidad considerable de atributos para podercategorizar a un usuario, tomando en cuenta datos de interés específico como esel conocimiento de cómputo, enfermedades contagiosas, el uso de aparatostécnicos necesarios por alguna minusvalía, etc.La ontología comprende el conjunto de todas las clases mostradas en la Tabla4.1, tal como se muestra en la figura 4.1. Figura 4.1. Estructura ontológicaPara poder disponer los datos en algún lenguaje procesable y además tener lasventajas de la reutilización y compartición se diseño una ontología, utilizando laherramienta “protégé” [Protege09].Esta herramienta permite además de poner los datos bajo clases y atributos,estipular las relaciones y reglas, aunque cabe mencionar que las restricciones dellenado con base en el valor de otros atributos se realizaron en la fase de diseño,lo cual se explicará a detalle más adelante.Cabe mencionar que también se analizaron los diferentes enfoques paracategorizar a las minusvalías, discapacidades, etc., y todas aquellas problemáticashumanas que afecten al rendimiento diario de una persona, además de lasenfermedades que esta posea sin la intención de ser tan explícitos en esteaspecto, simplemente de disponer de aquellas que son más comunes y queafecten en alguna medida la alimentación y o relación social entre otros factoresinmersos. [Isssste02]Para el caso de las enfermedades, se llego a la conclusión de disponer de unpequeño catalogo de enfermedades crónico-degenerativas más comunes y asícontemplarlas dentro de la ontología en forma de caja de verificación o con unsimple valor booleano.Rojas, Christian 60
  • 72. Desarrollo de la soluciónLas categorías encontradas y propuestas en la ontología, se muestran en la figura4.2. Figura 4.2. Enfermedades crónico-degenerativas en MéxicoPara cuestiones de organización se distribuyeron estas últimas en las clases“Enfermedades contagiosas” y “Enfermedades no contagiosas”, refiriéndose aenfermedades infecto contagiosas o no, e incluyendo en el primer clúster elSIDA/VIH.Después de analizar los diferentes enfoques (Véase capítulo II) para categorizar aun usuario, siendo algunas de ellas basadas en lenguaje procesable (OWL/RDF),y otras simplemente dispuestas en clúster disjuntos, se llego a la conclusión deque el mejor método para poder categorizar a un usuario es uniendo variastécnicas, y representarlas como se define a continuación. 4.2 ESTRUCTURA DE LA ONTOLOGÍAEn primera instancia, la estructura de la información será alimentada de un modoexplicito y se formará de un tipo “Nuclear + extensiones”, es decir, existirá unnúcleo (conjunto de clases con sus respectivos atributos), que será legible y podrápoblarse por cualquier usuario, ya que contendrá todos aquellos datos que son deinterés general y/o de uso común.A partir de los datos que contenga este núcleo, será posible acceder a otrasclases y/o atributos que estarán fuera del mismo, denominadas “Extensiones”, detal suerte que estas últimas contengan información referente a datos de interésRojas, Christian 61
  • 73. Desarrollo de la soluciónespecífico, y que sean cuestionables y/o accesibles a un usuario siempre ycuando cumpla una condición especificada en los datos “nucleares”.La ontología contemplará entonces el núcleo más todas las extensiones, aunquecabe mencionar que es improbable que un usuario cumpla o tenga en su perfil,acceso a todas las extensiones, incluyendo el núcleo, por la gran cantidad deinformación manejada.A continuación se definen los siguientes conceptos, generados a partir de lametodología de solución manejada. 4.2.1 NúcleoRefiere al conjunto de clases con sus respectivos atributos que son disjuntos entresí pero que en unión se contextualizan como todos aquellos datos de uso comúny/o información en general.El núcleo puede ser usado para perfilar a cualquier usuario real, sin notar detallesy características de uso específico.El núcleo será tomado como una ontología por sí misma, y será gestionadamediante un lenguaje procesable (OWL/RDF), la cual será instanciable por mediode alguna interfaz gráfica diseñada por algún lenguaje de programación (OpenSource), para las pruebas pertinentes. 4.2.2 ExtensibilidadEste proyecto propone tres tipos de extensibilidad: 1) Extensibilidad satelital queconsiste en una clase que es completamente disjunta al núcleo, por lo que no sesolapan ni comparten ningún elemento y que será añadida al núcleo de acuerdo aalguna(s) condición(es); 2) La Extensibilidad parcial, la cual consiste en una claseque es incompletamente integrante al núcleo y que lo extenderá a partir de algúnparámetro y la 3) Extensibilidad nuclear, que refiere a un conjunto de parámetrosintegrantes del núcleo que serán habilitados o agregados mientras que otros sondeshabilitados de acuerdo a cierta(s) condición(es).Este enfoque fue diseñado para evitar la intrusión excesiva a los datos del usuariopreguntando todas las posibles clases a capturar, los cuales incluso en muchoscasos pudiesen ser impertinentes y/o no aplicables.El resultado esperado es que estos datos serán accesibles para su capturaexplicita a aquellos usuarios que en realidad puedan perfilarse mejor con lautilización de estos.Rojas, Christian 62
  • 74. Desarrollo de la soluciónPara lograr este resultado se han aplicado una serie de parámetros dispuestoscomo atributos de alguna clase integrante del núcleo, los cuales tendrán undominio explicito en las extensiones (para todos los tipos), y cuyo valor restringirá(en tiempo de ejecución), a la accesibilidad en las mismas.A nivel de ontología, estos atributos serán propiedades “datatype”, que serán detipo bool, o string y cuyo valor permitirá o no, el acceso a las extensiones.Las relaciones entre la superclase “Persona” la cual contendrá a todas las clasesque conforman el núcleo, y las clases que formaran a las extensiones seránpropiedades de tipo “object”, con dominio en la superclase “Persona” y rango en laextensión relacionada.Cabe mencionar que existirá una propiedad objeto para cada extensión, y aunqueexista el caso de una sub-extensión, se asignará una propiedad objeto por cadahijo de la extensión, pero para efectos didácticos la extensión padre y las hijasserán referidas como una misma entidad en este documento.Además se especificarán en la ontología las restricciones mediante otraspropiedades de tipo objeto, que permitirán enlazar las clases extendidas con elnúcleo, únicamente a través de las clases que contengan el parámetro deextensión apropiado, lo cual se explicará a detalle más adelante.Los tipos de extensibilidad propuestos se explicarán a detalle a continuación: 4.2.2.1 Extensibilidad satelitalRefiere a un tipo de extensibilidad para el núcleo de la ontología, en el cual, unaclase disjunta3 al mismo, diseñada en un lenguaje procesable (OWL/RDF),contiene ciertos atributos de carácter específico y que en un contexto simple noson siempre necesarios. Estos serán accesibles para su población, mediante alguna interfaz gráficadiseñada en algún lenguaje de programación de código abierto, siempre y cuandolos parámetros relacionados cumplan con cierto valor.Estos parámetros comprometerán el acceso a las extensiones, y una vez que estasea realizada, la relación entre el núcleo y la extensión será de tipo débil, es decir,que la existencia de la extensión dependerá completamente del valor delparámetro dado.3. Conjunto DisjuntoObtenido de: http://es.wikipedia.org/wiki/Conjuntos_disjuntos Ultima consulta: Julio 2009Se dice que dos conjuntos son disjuntos si no tienen elementos en comúnRojas, Christian 63
  • 75. Desarrollo de la solución 4.2.2.1.1 EjemploPara poder mostrar de un modo más claro este tipo de extensión se desarrolló uncaso de estudio sencillo.Como se puede apreciar en la Tabla 4.1, una de las clases que conforman elnúcleo, es la de minusvalía, la cual está estructurada como se muestra en la figura4.3. Clase Minusvalía Minusvalías Atributos Física Psíquica Sensorial Asociada Ignorado Periodo Figura 4.3. Estructura de la clase “Minusvalía”.Esta clase tiene permite especificar si el usuario tiene alguna minusvalía y de serasí, especificar a qué tipo pertenece [Issste02], y en el caso de que el usuario nolo sepa o no esté de acuerdo con esta clasificación, éste podrá especificar el tiposegún su criterio, y permite un dato temporal en el caso de que su minusvalía hayasido ocasionada por algún incidente que temporalmente ocasione este hecho.Nótese en la figura 4.1 que existe también una clase llamada “Ayuda_tecnica”.Esta clase está fuera del núcleo, es decir, es una extensión. Y tiene una estructurasimilar a la mostrada en la figura 4.4. Clase Ayuda_tecnic a Atributos Tipo_ayuda_ tecnica Valores atributos Muletas Silla de Bastón Andadera Otro ruedas Figura 4.4. Estructura de la clase “Ayuda_tecnica”El objetivo de esta clase es especificar si a partir de una minusvalía del usuario,éste necesita de ayuda técnica como lo son las muletas, silla de ruedas, etc., ypermite especificar el nombre de alguna que no esté en esta lista de ayuda técnicacomún.Cabe hacer notar que esta clase no formar parte del núcleo, es decir, no es algocuestionable a cualquier usuario a menos de que posea alguna minusvalía.Rojas, Christian 64
  • 76. Desarrollo de la soluciónPor tanto existe el problema de hacer valida la clase de “Ayuda_tecnica” siempre ycuando la necesite y para resolver esta problemática se hará uso de unaextensibilidad de tipo satelital, de la siguiente manera.Se toma como atributo a la clase “Minusvalía”, de modo que si uno de suselementos tiene un valor valido, es decir, que el usuario haya especificado el teneralgún tipo de minusvalía mediante los valores booleanos o enteros de los atributosde la misma entonces y solo entonces podrá acceder al contenido de la clase“Ayuda_tecnica”.Aunque la restricción al acceso a la clase Ayuda_tecnica se realiza bajoprogramación, en la ontología, esta clase tomará forma por medio de la utilizaciónde un atributo “objeto” el cual enlaza a la clase “Ayuda_tecnica” al núcleo, a travésde la clase “minusvalía”, por medio de su definición con dominio en la clase“Minusvalía” y rango en la clase “Ayuda técnica.” Creando así un esquema derelación débil como se muestra en la figura 4.5. Figura 4.5. Esquema de “Extensibilidad satelital”Como se puede apreciar en la figura 4.5, se da una relación débil entre la claseminusvalía y la clase ayuda técnica, de modo que la clase ayuda técnica existesiempre y cuando la clase minusvalía lo haga. 4.2.2.1.2 Formalización de extensibilidad satelital A continuación se muestra la formalización para este tipo de extensión con lafinalidad de eliminar ambigüedades en la misma.SeaA = Núcleo de la ontologíaB = Clases fuera del núcleo de la ontología.C = Conjunto de valores validos para un parámetroRojas, Christian 65
  • 77. Desarrollo de la soluciónD = Conjunto de parámetrosx = Atributo de alguna clase que está disponible para capturar por el usuario. A B C DTomando en cuenta que C A y que D A.Se definen ahora los casos con extensión y sin ésta:Sin extensión{x:x A x B}Extendido{x:x A x B}Por tanto las condiciones para la extensión son entonces: x !C |C A C D C C y Tiene rango en B  x|x A x BDe otro modo con cualquier otra condición: x | x A x B 4.2.2.2 Extensibilidad parcialEs otro tipo de extensibilidad propuesta en este proyecto en la que una clase esincompletamente integrante del núcleo, y la totalidad de esta será accesibleúnicamente si algún parámetro del núcleo (o de alguna clase que integre alnúcleo) que tenga dominio en la clase a extender, tenga también un valordeterminado.Los elementos denominados “Parámetros” que permitirán acceder a algunasclases encontradas en alguna extensión o a partes de clases que no pertenezcanal núcleo, se identifican en la ontología como parámetros de clases de tipoRojas, Christian 66
  • 78. Desarrollo de la soluciónbooleano y que permiten el acceso dependiendo de si su valor es válido, o,parámetros de clases de tipo cadena con ciertos valores predeterminados.Para tipo de extensión, los valores predeterminados definirán el nivel de acceso enproporción a una clase de tipo “extensión”, esto es, que no sólo existirán dos tiposde cobertura (núcleo + extensión VS núcleo sin extensión) sino que pueden existirn niveles de cobertura (núcleo + (n elementos de la extensión)). Tal como semuestra en la figura 4.6. N + (E) N + (E-1L) Siendo: N Núcleo N + (E-2L) E Extensión L Nivel N Figura 4.6. Esquema de extensibilidad parcialComo se puede apreciar en la figura 4.6, el núcleo sigue siendo integro, pero lacobertura hacia la extensión varía según un índice denominado nivel, el cualintegra ciertos parámetros al núcleo en cada uno de ellos. La cantidad de nivelesse proporciona por las mismas reglas dispuestas a nivel de programación.Cabe mencionar que el acceso a estos niveles será definido a partir de los valoresque tengan los parámetros asignados, de modo que un mismo parámetro tendrádiferentes opciones a los valores asignados por defecto y la elección de uno deellos definirá que nivel de acceso a la extensión es válido y pertinente para elusuario en cuestión. 4.2.2.2.1 EjemploSe mostrará ahora un caso de estudio para poder visualizar de un modo más claroesta extensibilidad.Como se puede apreciar en la Tabla 4.1, existe una clase denominada “Contacto”que tiene una estructura como la mostrada en la figura 4.7.Rojas, Christian 67
  • 79. Desarrollo de la solución Figura 4.7. Estructura de la clase “Contacto”La clase anterior tiene como objetivo el establecer todos los datos disponibles decontacto para cualquier usuario, adaptándose a su nivel de conocimiento decómputo, para evitar la intrusión excesiva.Cabe hacer notar que esta clase no es nuclear, es decir, es disjunta a las clasesque conforman el núcleo, y tiene la característica de que sus atributos seránaccesibles de distinto modo entre ellos, como se explica a continuación.Al igual que la extensión anterior, este tipo de restricción dependerá de unparámetro encontrado en otra clase, en este caso la clase “Nivel_computo” la cualtiene una estructura como se muestra en la figura 4.8. Clase Nivel_computo Atributos Conocimiento_computo Nulo Bajo/Medio Medio/Alto Experto Figura 4.8. Estructura de la clase “Nivel_computo”Esta clase tiene un conjunto de valores disponibles para el usuario al igual queotras clases y atributos que se forman como “Parámetros”. La diferencia ocurrepor el hecho de que los valores de estos atributos asignaran ciertos sectores de laclase a extender, (cubrirán cierta parte de esta).Como se muestra en la Tabla 4.7 el problema radica en que los atributos de laclase contacto son accedidos siempre y cuando se cumplan uno de los valores dela clase Nivel_computo a la vez.Esta relación se muestra más clara en la figura 4.9.Rojas, Christian 68
  • 80. Desarrollo de la solución Figura 4.9. Relación y cobertura entre las clases “Nivel_computo” y “Contacto”Como se puede apreciar en la figura 4.9, dependiendo del nivel de cómputo seaccederán o no a ciertos niveles de la extensión, permitiendo lógicamente elllenado de los datos que dependan del conocimiento de cómputo inferior. Es decir,el usuario con un nivel “Medio/Alto” podrá capturar los datos asignados a estenivel más los datos de los niveles “Bajo/Medio” y “Nulo”.Cabe hacer mención que el valor del nivel de cómputo nulo es indistinto ya que decualquier manera está incluido en el núcleo de la ontología, y se sobreentenderáque el usuario tiene al menos un nivel de cómputo nulo, aunque está definido paramantener el contexto opcional. 4.2.2.2.2 Formalización de extensibilidad parcialA continuación se muestra la formalización para este tipo de extensión con el finde eliminar ambigüedades en la misma.SeaA = Núcleo de la ontología.B = Clases parcialmente fuera del núcleo de la ontología.C = Conjunto de valores validos para un parámetro.D = Conjunto de parámetros.E = Cobertura de la extensión.x = Atributo de alguna clase que está disponible para capturar por el usuario.E = Cobertura de la extensiónRojas, Christian 69
  • 81. Desarrollo de la solución B A E A B E C DTomando en cuenta que C A y que D A y ASe definen ahora los casos con extensión y sin ésta:Sin extensión{x | x A x (A B E)} para E=(A B); BExtendido{ x | x A x (B E) x (A B E)} para E ; BPor tanto las condiciones para la extensión son entonces: x !C |C A C D C C y Tiene rango en B  x|x A x (B E) x (A B E);para C con rango en E ; y (A B) EDe otro modo con cualquier otra condición:{ x | x A x (A B E)} para E=(A B); B 4.2.2.3 Extensibilidad nuclearEs el último tipo de extensibilidad propuesta en este proyecto, en la que existenciertos atributos en el núcleo que son pertinentes hacia un usuario mientras queotros no.Al igual que las extensiones anteriores existen ciertas clases con sus respectivosatributos que son pertinentes a cierto usuario mientras que otros no lo son y laelección y/o acceso a cada uno de ellos será definido a través de un parámetroencontrado en el núcleo.La diferencia radica entonces en que estas dos clases (o atributos de una mismaclase), son nucleares en su totalidad, es decir, son subconjuntos del núcleo, perotienen la propiedad de ser conjuntamente exclusivos, es decir, de entre dos gruposde atributos que son nucleares unos serán habilitados mientras los otros semantendrán deshabilitados a partir del valor de cierto parámetro.Rojas, Christian 70
  • 82. Desarrollo de la soluciónEsta funcionalidad es parte de extensibilidad por el hecho de que, no solamenteexiste el caso de que sean dos grupos similares (en número y tipo), sino que laelección de uno de ellos pudiese involucrar la agregación de “n” parámetros a esesubconjunto. 4.2.2.3.1 EjemploSe mostrará a continuación un caso de estudio para esclarecer este tipo deextensibilidad.Como se aprecia en la Tabla 4.1, existe una clase llamada “Personales”, la cual esuna de las clases principales de la ontología e integrante del núcleo, y presenta lasiguiente estructura. Personales Clase First_name Middle_name Last_name Nombre … Atributos Figura 4.10. Estructura de la clase “Personales”La estructura original contiene más atributos, aunque para efectos didácticos sólose mostraron los relevantes para el ejemplo de este tipo de extensibilidad.La finalidad de esta clase es muy clara, y trata de definir las cualidades y atributosde un usuario cualquiera contemplando sus datos personales básicos,contemplando su nacionalidad.Al igual que los otros tipos de extensibilidad, esta será accesible a través de unparámetro encontrado en el atributo de otra clase; en este caso será la clase“Origen”, la cual tiene una estructura como se muestra en la figura 4.11. Clase Origen Atributos Ciudad Distrito_local_origen Gobierno Localidad Moneda Municipio_origen Pais Figura 4.11. Estructura de la clase “Origen”Rojas, Christian 71
  • 83. Desarrollo de la soluciónLa finalidad de esta clase es definir la ubicación geográfica de origen de lapersona, incluyendo datos específicos como tipo de moneda y gobierno, y porconsiguiente a partir de su origen (País) se definirá como se le referenciara alnombre de esa persona. Tal como se muestra en la figura 4.12. Figura 4.12. Esquema de extensibilidad nuclearA partir de la figura anterior se puede hace notar que el atributo país encontradoen la clase origen condicionara cual de los dos grupos de atributos serán puestosa disponibilidad del usuario.Es importante notar que los dos grupos son disjuntos exclusivos (uno u otro perono ambos) y además son asimétricos, es decir, aunque los datos en los dosgrupos refieren al mismo contexto, no tienen la misma cantidad de atributos, portanto además de la elección existe una pequeña agregación a partir de unacondición.Este tipo de extensibilidad es útil para aquellos casos en que el uso de algunasvariables involucren la cancelación de otras, como por ejemplo (Casado/Soltero),(Hombre/Mujer), etc., ya que estas elecciones desencadenarían o limitarían ciertascuestiones como “embarazo” la cual es oportuno siempre y cuando el valor degénero sea femenino. 4.2.2.3.2 Formalización de extensibilidad nuclear.Para evitar ambigüedades a continuación se realizó una formalización paracondicionar este tipo de extensibilidad.SeaA = Núcleo de la ontología.B = Conjunto de atributos condicionadosC = Conjunto de atributos condicionadosD = Conjunto de valores validos para un parámetro.E = Conjunto de parámetros pertinentes.x = Atributo de alguna clase que está disponible para capturar por el usuario.Rojas, Christian 72
  • 84. Desarrollo de la solución A D C B ETomando en cuenta que B C; D A; E A y A ;Por tanto las condiciones para la extensión B son entonces: x !D |D A D D D E Tiene rango en B  x|x C (x A x B)Por tanto las condiciones para la extensión C son entonces: x !D |D A D D D E Tiene rango en C  x|x B (x A x C)Para los dos casos: {x D} y {x E}En general el uso de los parámetros puede ser interpretado para distintosdominios, asegurando una adaptación y/o aproximación de la ontología y de susatributos al uso y contexto deseado.Rojas, Christian 73
  • 85. Desarrollo de la soluciónRojas, Christian 74
  • 86. 5. CAPÍTULO V. IMPLEMENTACIÓNEn este capítulo se presenta la forma en que será operada la aplicación, así comosegmentos de código y descripciones a nivel operativo que precisaran losprocedimientos manejados.
  • 87. ImplementaciónEn este capítulo se muestran segmentos de código que explican el uso de laaplicación, los códigos completos se encuentran en el Anexo B.Para el desarrollo de la aplicación se utilizó el entorno de programación ECLIPSE, yVisual Editor como gestor grafico.La conexión con la ontología se realizó mediante la API “OWLAPI”, y PROTÉGÉ comoentorno de diseño de la ontología.A continuación se muestran algunos segmentos de código correspondientes a lasdiferentes actividades que representan la aplicación, las cuales se enlistan acontinuación: 1. Conexión con ontología 2. Usuario nuevo 3. Usuario existente 4. Volcado de ontología 5. Guardado de ontología 6. Lectura de ontología 7. Modificar en ontología 8. Eliminar ontología 9. Elección de dominio de aplicación 10. Elección de operación en ontología5.1 CONEXIÓN CON ONTOLOGÍAComo se mencionó en el capitulo anterior, esta actividad en la aplicación, tienecomo finalidad la de realizar la conexión pertinente entre la interfaz y la ontologíamanejada por protégé, mediante la API de conexión (OWLAPI). Cabe mencionarque esta actividad es frecuentemente invocada debido a que la conexiónontológica es no persistente.La principal clase involucrada en esta actividad es STORE, la cual, entre otros,contiene el método ontocomm(), el cual realiza la conexión con la ontología,direccionada mediante una ruta física y un identificador conceptual que la precisa.Este método devuelve la dirección absoluta de la ontología para poder utilizar elmétodo factory encontrado en la API de conexión y realizar las operacionespertinentes a la ontología de acuerdo a la actividad elegida.Rojas, Christian 76
  • 88. Implementación Figura 5.1. Conexión con ontología Como se puede apreciar en la figura 5.1, en la línea 3, se hace referencia a unelemento encontrado en otra clase “DATA”, la cual contiene además, ciertos datosque permitirán definir el comportamiento dinámico de la aplicación, así como datosde configuración generales.5.2 USUARIO NUEVO Y USUARIO EXISTENTEEsta actividad implica la utilización de la conexión a la ontología como es obvio, yademás otros métodos de autenticación encontrados casi en su totalidad en laclase LOGIN, ya que la interfaz gráfica que se encuentra en la claseAuthentication, que representa esta actividad, no maneja el área operativa y portanto, se excluye de este apartado.Dentro de la clase Login existen 3 métodos que son fundamentales para laautenticación de un usuario nuevo y uno existente como se muestra acontinuación: Figura 5.2. Autenticación de usuario.1Rojas, Christian 77
  • 89. ImplementaciónComo se puede apreciar en la figura 5.2, este método se encarga de verificar laexistencia de un login y u password en cierta clase en una ontología, y porconsiguiente la correspondencia de estos.Este método devuelve como resultado un valor booleano que será verdadero siexiste dicha correspondencia entre el usuario y el password, y negativo de noserla.Para la primera tarea de este método (verificar la existencia del login) es necesariohacer uso de otros métodos como se muestra a continuación. Figura 5.3. Autenticación de usuario.2Como se puede apreciar en el segmento de código de la figura 5.3, este métodose encarga de obtener una lista de los nombres de usuario registrados en laontología (mediante el método de la figura 5.2), para posteriormente hacer unbarrido uno a uno y compararlo con el heredado de el método mostrado en lafigura 5.4.Rojas, Christian 78
  • 90. Implementación Figura 5.4. Autenticación de usuario.3El segmento de código mostrado en la figura 5.4, Se obtiene una lista de todos losnombres de usuario registrados en la ontología, posteriormente los devuelve en unarreglo de tipo List.Para el caso de un usuario existente será necesario el proceso completo, y paraun usuario nuevo, debido a que solo es necesario verificar la existencia del login,entonces solamente se realizarán los últimos dos métodos, recibiendo comoparámetro el mismo nombre de usuario y devolviendo un valor booleano referenteal resultado del análisis.5.3 VOLCADO DE ONTOLOGÍAEsta actividad dentro del proyecto se enfoca a leer los datos desde las interfaces ygrabarlos en la ontología, de acuerdo a la correspondencia lógica entre ellos.Esta actividad es muy utilizada durante el proceso de guardado de la ontología yde sus elementos, ya que es operada para cada interfaz y cada clase, con susrespectivas diferencias referentes a los elementos visuales que conformen lasclases.Por este motivo y para simplificar la redacción del documento, se explicará una delas clases involucradas solamente, ejemplificando con esta, todas las demás.Rojas, Christian 79
  • 91. Implementación Figura 5.5. Volcado de datos a la ontologíaEL código mostrado en la figura 5.5, corresponde a la clase LoadOrigenData, lacual tiene como objetivo específico el de volcar los datos contenidos en elformulario interfaz Origen y grabarlos en la clase Origen en la ontología.Como se puede apreciar en las líneas (9-15), es necesario el uso del esquemaXSD para poder alinear los tipos de datos entre JAVA -> Protégé, utilizando la APIde conexión, así como el nombre del elemento a guardar y su valor (formando latripleta de datos), véase 3.1.35.4 GUARDADO DE ONTOLOGÍAEsta actividad dentro del proyecto realiza el proceso de guardado en la ontologíarespetando el siguiente algoritmo: Eliminar ontología (solo los datos alterados) Volcado de ontología Generación de las relaciones entre los elementos creados.Debido a que la primera instrucción corresponde a una actividad individual delproyecto, y la última refiere a una actividad ya explicada, nos enfocaremos a lasegunda instrucción, la cual se encarga de guardar un elemento en cada atributode tipo object dentro de la clase principal, con la finalidad de crear un árbol deabstracción, véase 3.1.2Rojas, Christian 80
  • 92. Implementación Figura 5.6. Relación de elementos en la ontologíaComo se aprecia en la figura 5.6, se identifica la clase principal, la cual contienelos atributos de tipo object hacia los cuales se realizará el guardado de losidentificadores de los elementos creados.Como se aprecia en las líneas (10,13,16,20,24,27), se especifican los elementoscreados por el proceso de guardado de datos en la ontología.Entre la línea 24 y 25, se omitieron (reducción de espacio) los elementos queaunque también fueron creados por el proceso de guardado, presentan el mismocomportamiento que los mostrados.En la línea 29 se aprecia la llamada al método InsertIndividualObjects que seencarga del grabado de datos en la ontología siguiendo la forma de tripletadescrita anteriormente.Rojas, Christian 81
  • 93. Implementación5.5 LECTURA Y MODIFICACIÓN DE ONTOLOGÍAEsta actividad en el proyecto es la encargada de realizar el proceso contrario alvolcado de datos a la ontología, ya que realiza una lectura de los datos desde laontología y los dispone en las interfaces correspondientes de acuerdo a unaplantilla de escritura. Figura 5.7. Lectura de datos desde la ontologíaEn la figura 5.7 se muestra el proceso de lectura de datos desde la ontología parala clase Origen, en la cual se muestran en las líneas (20-26), los procesos paraasignación de valores.5.6 ELIMINAR ONTOLOGÍATal y como su nombre lo indica, esta actividad se encarga de eliminar lasindividualizaciones prudentes en la ontología. La decisión sobre dejar o eliminaruna individualización se realiza con base en banderas actividades ante unamodificación previa en dicha clase.Rojas, Christian 82
  • 94. Implementación Figura 5.8. Eliminación de datos en la ontologíaRojas, Christian 83
  • 95. ImplementaciónRojas, Christian 84
  • 96. 6. CAPÍTULO VI. PRUEBASEn este capítulo se presenta el plan de pruebas correspondiente a los casos deuso analizados en el capítulo de Análisis y diseño.
  • 97. Pruebas 6.1 INTRODUCCIÓNDescripción del identificador:US: UserO: OntologyG: GeneratorEste documento define el plan de pruebas basado en el estándar IEEE 829 parapruebas de software, que permitirá verificar la funcionalidad de la USOG que esuna herramienta para la generación de ontologías de usuario basadas encontexto.La aplicación consta de dos módulos principales: 1. Interfaz: Se encarga de mostrar en pantalla todos los elementos para poder poblar la ontología de una manera ordenada y coherente tomando en cuenta deducciones de los datos almacenados. 2. Operación con ontología: Tiene como objetivo realizar las operaciones con la ontologíaLa hipótesis nula a probar es la siguiente:Las ontologías de usuario actuales no perfilan a un usuario de manera apropiada ycompleta, basándose en un dominio de la aplicación:La hipótesis alterna es:Las ontologías de usuario actuales no perfilan a un usuario de manera apropiada ycompleta, basándose en un dominio de la aplicación:A continuación se presentan los siguientes puntos además de la introducción: Descripción del plan Casos de Prueba Procedimientos de Pruebas. Resultado de Pruebas 6.2 DESCRIPCIÓN DEL PLAN 6.2.1 Características a ser probadasEl presente plan de pruebas contiene la descripción de los casos de pruebadefinidos con el fin de validar y verificar que la aplicación cumple con los requisitosde herramienta para la generación de perfiles de usuario basadas en su contextoRojas, Christian 86
  • 98. Pruebas 6.2.2 Características excluidas de las pruebasNo se dará prioridad al diseño de interfaz de las aplicaciones que se utilicen paraprobar la API.No se dará prioridad al idioma de los usuarios, tomando como idioma principal elespañol latinoamericano. 6.2.3 EnfoqueDebido a que las mediciones son principalmente de funcionalidad, la aplicación seprobará con casos que la utilicen. Las cuales serán poblados de ontologías deusuario utilizando divergencia natural de los mismos.Ya que la aplicación toma en cuenta factores como la extensibilidad de suselementos, estos se probaran con cuestiones como ¿Lo que se pregunta espertinente? ¿Es suficiente lo que se pregunta? 6.2.4 Criterio pasa/ no pasa de casos de prueba.En la descripción de los casos de prueba, se detallarán los resultados esperadospara cada uno de los casos. Se considerará que una prueba ha pasado con éxitocuando los resultados esperados coincidan con los descritos en el caso de prueba.En caso de no coincidencia, se analizarán las causas y se harán lasmodificaciones necesarias hasta que se cumplan con los resultados esperados. 6.2.5 Criterios de suspensión y requerimientos de reanudación.En ningún caso se suspenderán definitivamente las pruebas. Cada vez que sepresente que el caso no pasa una prueba, inmediatamente se procederá a evaluary corregir el error, permaneciendo en la prueba de este caso hasta que ya no sepresenten dificultades con él. 6.2.6 Tareas de pruebas.Las tareas a desarrollar para preparar y aplicar las pruebas se muestran en laTabla 6.1. Tabla 6.1 Tareas a desarrollar a las pruebas Tarea Tarea Precedente Habilidades especiales Responsabilidad de1. Preparación del plan Terminación del Conocimiento del leguaje Autor de tesisde pruebas. análisis y diseño de la OWL, ontologías de aplicación. usuario y del IEEE Std. 8292. Preparación del Tarea 1 Conocimiento sobre la Autor de tesisdiseño de pruebas. estructura de la aplicación, sus clases y métodos y del IEEE Std. 8293. Preparación de los Tarea 2 Conocimiento de las Autor de tesiscasos de prueba. aplicaciones de ontologías de usuario.4. Aplicación de pruebas. Tarea 3 Conocimiento del entorno y Autor de tesisRojas, Christian 87
  • 99. Pruebas preparación del sistema desarrollado para su ejecución.5. Resolver los Tarea 4 Conocimiento del lenguaje Autor de tesisincidentes de pruebas. de programación J2EE6. Evaluación de Tarea 4 Conocimiento de las Autor de tesisresultados. Tarea 5 preguntas de investigación, la hipótesis de prueba, y los objetivos de esta tesis. 6.2.7 Liberación de pruebas.La entrada especificada y la salida esperada en cada caso de prueba, seránsuficientes para la comprobación del objetivo alcanzado y por lo tanto para laaceptación de las pruebas. 6.2.8 Requisitos ambientales.Las características y propiedades físicas y lógicas requeridas para el ambiente depruebas, son las siguientes:Equipo PC de Escritorio Procesador Intel P4 o superior. 512M de memoria RAM o superior. 30Mb libres en Disco duro. Windows XP/VISTA/SEVENHerramientas Java (J2EE). Eclipse, como entorno de programación. Visual Editor, como entorno de desarrollo grafico. Protégé, como gestor ontológico OWLAPI, para conexión con ontología PELLET, como razonador ontológico 6.2.9 Responsabilidades.Toda la responsabilidad de las pruebas recae en la autora de la tesis. 6.2.10 Riesgos y contingencias.Falta de tiempo: El tiempo es un factor importante que genera incertidumbre a lahora de aplicar las pruebas, por lo que se tomarán como mínimo 6 casos deprueba, si el tiempo lo permite se extenderán las pruebas a otros casos.Todas las fallas que se pudieran presentar en el transcurso del desarrollo de laspruebas deberán ir resolviéndose de manera iterativa por el responsable de estatesis, hasta que la falla no produzca otras más.Rojas, Christian 88
  • 100. Pruebas 6.3 CASOS DE PRUEBAS. 6.3.1 Características a probarLa siguiente lista define las características a ser probadas: Guardado de datos a la ontología: Se verificará que las clases para el guardado de datos en la ontología funciones de manera adecuada. Lectura de datos desde la ontología: Se verificará que las clases relacionadas con la lectura de datos desde la ontología funcionen adecuadamente. Eliminado de datos de la ontología: Se verificará que las clases relacionadas con este proceso funcionen adecuadamente. Elección del dominio de aplicación: Se verificara que las clases relacionadas con el proceso de elección del dominio hacia la cual se inclinará la captura en la aplicación funcionen de manera adecuada. Enlazar con ontología: Se verificara que las clases relacionadas con el proceso de enlace con la ontología funcione6.3.2 Grupos de pruebasEn este apartado se mostraran y nombraran a las pruebas a realizar, tomando encuenta la funcionalidad de la aplicación. 6.3.2.1 Operación con la ontologíaUSOG-101 Pruebas de operación con la ontologíaUSOG-101-001 Lectura de la ontologíaUSOG-101-002 Escritura en ontologíaUSOG-101-003 Eliminado de la ontología 6.3.2.2 Estructuración ontológicaUSOG-201 Prueba de estructuración ontológicaUSOG-201-001 Estructuración de individualizaciones 6.3.2.3 Enlace con ontologíaUSOG-301 Prueba de enlace con la ontologíaUSOG-301-001 Conexión con ontología 6.3.2.4 Elección de dominio de la aplicaciónUSOG-401 Prueba de elección del dominio de la aplicaciónUSOG-401-001 Elección del dominio de la aplicación 6.3.3 Procedimiento de PruebasEste capítulo contiene la descripción de los procedimientos de pruebascorrespondientes a los distintos casos de prueba que conforman el presente plande pruebas. Los distintos casos de pruebas se encuentran organizados en gruposde pruebas cuyo objetivo es validar y verificar una determinada funcionalidad deRojas, Christian 89
  • 101. Pruebaslas rutinas de transformación. Cada uno de los casos de pruebas está dirigido a lavalidación y verificación de una funcionalidad muy concreta.Para cada uno de los grupos de pruebas se describe el propósito del grupo depruebas, el entorno de prueba necesario, los distintos conjuntos de pruebas que loconforman.Para cada uno de los casos de prueba se describe el propósito del caso, elentorno necesario para la ejecución del caso, el procedimiento de la prueba y losresultados esperados. 6.4 USOG-101 PRUEBAS DE OPERACIÓN CON LA ONTOLOGÍA 6.4.1 PropósitoVerificar que las clases relacionadas con la operación para/con la ontologíafuncionen correctamente. 6.4.2 Entorno de prueba.Para la ejecución de los casos de prueba contenidos en este grupo se utilizaránlos elementos de la aplicación. Véase 3.28 6.4.3 USOG-101-001 Lectura de la ontología 6.4.3.1 PropósitoRecuperar datos desde la ontología y ubicarlos en memoria principal 6.4.3.2 Entorno de prueba.La prueba se realizara con una ontología ya creada y consistente. Validada por elrazonador, y operada por una acción detonadora. 6.4.3.3 Proceso 1. Actuar el proceso mediante una invocación o un detonador 2. Ver la consistencia de los datos con respecto a los almacenados en la ontología. 3. Verificar la consistencia de la ontología al finalizar el proceso 6.4.3.4 Resultado esperado.Consistencia, completitud e integridad en los datos obtenidos.Rojas, Christian 90
  • 102. Pruebas 6.4.4 USOG-101-002 Escritura en ontología 6.4.4.1 PropósitoRecuperar datos de memoria principal y ubicarlos adecuadamente en la ontología 6.4.4.2 Entorno de prueba.La prueba se realizara con una ontología ya creada y consistente. Validada por elrazonador, y operada por una acción detonadora. 6.4.4.3 Proceso 7. Actuar el proceso mediante una invocación o un detonador 8. Ver la consistencia de los datos en la ontología con respecto a los almacenados en la interfaz (memoria principal). 9. Verificar la consistencia de la ontología al finalizar el proceso 6.4.4.4 Resultado esperado.Consistencia, completitud e integridad en los datos escritos.6.4.5 USOG-101-003 Eliminado de la ontología 6.4.5.1 PropósitoEliminación de datos involucrados con la aplicación, como lo son:individualizaciones, atributos y demás. 6.4.5.2 Entorno de prueba.La prueba se realizara con una ontología ya creada y consistente. Validada por elrazonador, y operada por una acción detonadora, con datos ya ingresadospreviamente. 6.4.5.3 Proceso 1. Actuar el proceso mediante una invocación o un detonador 2. Verificar que la ontología aun existente no contiene ya, los datos operados por la aplicación. 3. Verificar la consistencia de la ontología al finalizar el proceso 6.4.5.4 Resultado esperado.Consistencia, completitud e integridad en los datos exentos de la eliminaciónprogramada.6.4.6 USOG-201 Pruebas de estructuración ontológica 6.4.6.1 PropósitoVerificar que la generación automática de identificadores conceptuales estéfuncionando correctamente.Rojas, Christian 91
  • 103. Pruebas 6.4.6.2 Entorno de prueba.Para la ejecución de los casos de prueba contenidos en este grupo se utilizaránlos elementos de la aplicación. Véase Análisis de la interfaz, así como un árbol deabstracción de nombres. 3.1.26.4.7 USOG-201-001 Estructuración de individualizaciones 6.4.7.1 PropósitoGeneración de un árbol de abstracción de nombres (transparente), para lamanipulación de identificadores conceptuales destinados a individualizacionesgeneradas por la aplicación. 6.4.7.2 Entorno de prueba.La prueba se realizara con una ontología ya creada y consistente. Comparando laestructura ontológica con un árbol de abstracción de nombres diseñado para laprueba. 6.4.7.3 Proceso 1. Operar la ontología mediante un guardado de datos completo (todas las clases capturadas). 2. Comparación de la estructura ontológica con el árbol de abstracción de nombres diseñado para la prueba. 3. Verificar la consistencia de la ontología al finalizar el proceso 6.4.7.4 Resultado esperado.Similitud de identificadores conceptuales entre el árbol de abstracción de nombresy la estructura ontológica generada automáticamente.6.4.8 USOG-301 Prueba de enlace con ontología 6.4.8.1 PropósitoVerificar que la conexión con la ontología sea exitosa y los posibles manejos deexcepciones causados por inconsistencia sean adecuados. 6.4.8.2 Entorno de prueba.Para la ejecución de los casos de prueba contenidos en este grupo se utilizaránlos elementos de la aplicación. Tomando en cuenta que los más importantes paraeste punto son las herramientas requeridas. Véase 6.2.8Rojas, Christian 92
  • 104. Pruebas6.4.9 USOG-301-001 Conexión con ontología 6.4.9.1 PropósitoConexión con la ontología de un modo transparente para el usuario. 6.4.9.2 Entorno de prueba.La prueba se realizara con una ontología ya creada y consistente. Operada poruna acción detonadora, con datos a procesar, mediante el uso de los métodoscontenidos en la API de conexión (OWLAPI), y su respectivo verificador deconsistencias (razonador, PELLET). 6.4.9.3 Proceso 1. Actuar el proceso mediante una invocación o un detonador 2. Revisar los servicios que se solicitan al realizar la conexión, como lo son factory, manager y razonador 3. Verificar que cualquier inconsistencia que aparezca, tenga su respectivo manejo 4. Verificar la consistencia de la ontología al finalizar el proceso 6.4.9.4 Resultado esperado.Consistencia, completitud e integridad en los datos exentos de la eliminaciónprogramada.6.4.10 USOG-401 Prueba de elección del dominio de la aplicación 6.4.10.1 PropósitoRevisar que la inclinación de la captura de los datos en la aplicación tengancoherencia con respecto al dominio elegido en el momento de la selección. 6.4.10.2 Entorno de prueba.Para la ejecución de los casos de prueba contenidos en este grupo se utilizaránlos elementos de la aplicación. Véase Análisis de la aplicación, así como undominio de aplicación seleccionado previa o actualmente.6.4.11 USOG-401-001 Elección del dominio de la aplicación 6.4.11.1 PropósitoDiscriminación de los datos no apropiados de acuerdo al dominio de aplicaciónelegido, así como separación dinámica de los elementos de captura de acuerdo auna lógica de datos recomendados y optativos. 6.4.11.2 Entorno de prueba.La prueba se realizara con una ontología ya creada y consistente. Validada por elrazonador, y operada por una acción detonadora, con datos ya ingresadospreviamente o una ontología nueva con un usuario de reciente ingreso al sistema,Rojas, Christian 93
  • 105. Pruebasel cual ha solicitado la inclinación de la captura de su ontología de acuerdo a undominio de aplicación especifico. 6.4.11.3 Proceso 1. Un dominio de aplicación elegido. 2. Verificar que los datos de captura hayan sido modificados posterior a la elección. 3. Verificar la inserción de los datos de acuerdo a nuevas reglas definidas por cambios realizados en el proceso de captura. 4. Verificación de la consistencia de la ontología en caso de que los datos hayan sido guardados. 6.4.11.4 Resultado esperado.Modificación dinámica de los elementos de captura así como consistencia,completitud e integridad en los datos guardados en la ontología de ser el caso.A continuación se muestran las pruebas realizadas sobre el plan de pruebasdescrito previamente y referentes a las pruebas funcionales, para después mostraren detalle las pruebas operativas.6.5 PRUEBASLas partes a probar fueron aquellas que conforman la aplicación: 1. Interfaz: Se encarga de mostrar en pantalla todos los elementos para poder poblar la ontología de una manera ordenada y coherente tomando en cuenta deducciones de los datos almacenados. 2. Operación con ontología: Tiene como objetivo realizar las operaciones con la ontologíaLas pruebas se basaron en la utilización de la interfaz grafica, ya que al estardividida la parte operativa de la parte grafica, al funcionar las funciones graficas sesobre entiende que funcionará la parte operativa de haberse invocado en susmétodos de manera individual.A continuación se mostrará el desarrollo de las pruebas basadas en el plan depruebas descrito anteriormente.Las pruebas que se muestran a continuación corresponden a la operación con laontología, es decir, que los elementos en la interfaz llamaran a estos métodospara poder funcionar.Rojas, Christian 94
  • 106. Pruebas6.4.1 Pruebas Funcionales Tabla 6.2. Caso de prueba: Lectura de la ontologíaCaso de pruebaUSOG-101-001 Lectura de la ontologíaDescripción: Recuperar datos desde la ontología y ubicarlos en memoria principal. Laprueba se realizó tomando en cuenta la autenticación de un usuario existente, la cualnecesita llamar los datos del usuario y su contraseña para poder entrar al sistema.Resultado:La figura 6.1 muestra los datos de la ontología en el entorno de diseño ontológico,apreciándose en ésta, que el usuario debe ser XtianReds y la contraseña 0, para poderacceder a los datos del perfil. Figura 6.1. Datos de la ontología en protégéAl insertar datos incorrectos en el proceso de autenticación, se muestra un mensaje deerror, tal como se muestra en la figura 6.2. Figura 6.2. Autenticación invalidaPosteriormente al ingresar los datos validos se puede observar en la figura 6.3, el accesoa la elección de la operación en la ontología. Figura 6.3. Autenticación válida y elección de operación con ontologíaObservaciones:La autenticación de usuario es válida también para usuarios nuevos, tomando en cuentaque la interacciona de lectura con la ontología es durante la búsqueda de existenciaprevia del login elegido.Rojas, Christian 95
  • 107. Pruebas Tabla 6.3 Caso de prueba: Escritura en ontologíaCaso de pruebaUSOG-101-002 Escritura en ontologíaDescripción: Recuperar datos de memoria principal y ubicarlos adecuadamente en laontología. La prueba se realizó mediante la modificación de algún dato en la interfaz y larevisión de la integridad de éste con respecto al encontrado en la ontología.Resultado:Como se puede apreciar en la figura 6.4, la ontología en protégé contiene solamente a unindividual. Figura 6.4. Datos de la ontología en protégéPosteriormente se procede a crear un nuevo usuario “nueva ontología”, ingresando a laopción usuario nuevo para poder elegir el dominio de aplicación hacia el cual se inclinarála captura. Véase figura 6.5 Figura 6.5. Creación de nuevo usuario y elección del dominio de aplicaciónUna vez elegido el dominio de la aplicación, se capturan los datos requeridos por lainterfaz y se guardan con el respectivo botón asignado. Véase figura 6.6Rojas, Christian 96
  • 108. Pruebas Figura 6.6. Introducción de datos en el perfilA continuación se verifican la integridad de os datos de la ontología con respecto a losingresados en la interfaz, asegurando que el proceso de guardado de datos en laontología funciona de manera adecuada. Véase figura 6.7 Figura 6.7. Datos en la ontología después de la operaciónRojas, Christian 97
  • 109. PruebasObservaciones:Este procedimiento involucra varias acciones como lo son la conexión con la ontología, elproceso de volcado de datos, eliminación de datos de la ontología, los cuales seránexplicados independientemente en los demás casos de prueba. Tabla 6.4 Caso de prueba: Eliminado de la ontologíaCaso de pruebaUSOG-101-003 Eliminado de la ontologíaDescripción: Eliminación de datos involucrados con la aplicación, como lo son:individualizaciones, atributos y demás. La prueba se realizó eliminando un elemento alazar en un perfil ya guardado anteriormente y verificando su correspondencia en laontología antes y después de la acción.Resultado:En primer lugar se procede a revisar los datos de la ontología en protégé, paraseleccionar un elemento a eliminarse en la interfaz. Figura 6.8. Contenido de la instancia de la clase miembro en la ontologíaAhora, se realiza una autenticación en la interfaz (del usuario al cual se realizara laeliminación parcial o total), eligiendo la opción de Eliminar datos, lo cual nos mostrara unaventana tal como se muestra en la figura 6.9, en la cual se seleccionará únicamente laopción miembros y aceptando la eliminación de la clase.Rojas, Christian 98
  • 110. Pruebas Figura 6.9. Eliminación de un individuals en la ontologíaUna vez eliminados los datos se procede a revisar esta eliminación manualmente en laontología mediante protégé. Figura 6.10. Resultado en la ontología después de la operaciónComo se puede apreciar en la figura 6.10, no existe ya, el individual correspondiente a laclase Miembros.Observaciones:La interfaz está capacitada para ofrecer al usuario una eliminación parcial o total de laontología, permitiendo la elección de estos elementos.Rojas, Christian 99
  • 111. Pruebas Tabla 6.5 Caso De Prueba: Estructuración De IndividualizacionesCaso de pruebaUSOG-201-001 Estructuración de individualizacionesDescripción: Verificar que la generación automática de identificadores conceptuales estéfuncionando correctamente. La prueba se realiza guardando datos en una ontologíanueva, y verificando la correspondencia entre la creación automática de la jerarquía de losnombres de individuals con respecto a una creada manualmente.Resultado:Se procede a crear una nueva ontología a partir de un usuario nuevo, capturando susdatos respectivos y guardándolos, tal como se muestra en la figura 6.11 Figura 6.11. Guardado de datos ontológicos.Debido a que los datos guardados corresponden a las clases: apariencia, estilo de vida,origen, estudio, personales, contacto, preferencias, dirección, intereses, enfermedades ymiembros y tomando en cuenta que la aplicación solamente crea los individuals a lasclases afectadas, se procede a crear el árbol de abstracción de nombres de estos datos(Véase 3.1.2), tal como se muestra en la figura 6.12. Julian Julian Julian Julian Julian Julian JulianPr Julian JulianI JulianEnferme Julian Julian Aparie EstiloV Estudi Person Contac eferenci Direcci nteres Miemb Origen as dades ncia ida o ales to on es ro JulianN JulianTr oTrans ansmisi misibles bles Figura 6.12. Árbol de abstracción de nombres de la ontología creada.Rojas, Christian 100
  • 112. Pruebas Figura 6.13. Estructuración ontológica de la ontología en protégéComo se puede apreciar en la figura 6.13, la correspondencia con el árbol de abstracciónde nombres es directa, por tanto satisfactoria para esta prueba.Observaciones:La generación de los elementos en la ontología es directamente proporcional a la cantidadde elementos operados en la interfaz, es decir, solo los elementos operados sonmanipulados. Tabla 6.6 Caso De Prueba: Estructuración De IndividualizacionesCaso de pruebaUSOG-301-001 Conexión con ontologíaDescripción: Conexión con la ontología de un modo transparente para el usuario. Laprueba se realiza cambiando la contraseña de la cuenta mediante la interfaz en elapartado seguridad y verificando dicho cambio con respecto al contenido de la ontología.Resultado:En primera instancia se verifica el valor de la contraseña actual para ingresar al sistema,tal como se muestra en la figura 6.14. Figura 6.14. Contenido de password en la clase personales de la ontologíaRojas, Christian 101
  • 113. PruebasPosteriormente se ingresa a la ontología con esta contraseña y se cambia en el apartadoSeguridad (Respetando el procedimiento seguro para dicho cambio), y se guardan losdatos, tal como se muestra en las figuras 6.15 y 6.16. Figura 6.15. Autenticación en la ontología existente Figura 6.16. Cambio de contraseña en la ontologíaUna vez realizado el cambio de contraseña se procede a verificar la consistencia de estosdatos en la ontología por medio de protégé, tal como se muestra en la figura 6.17.Rojas, Christian 102
  • 114. Pruebas Figura 6.17. Valores ontológicos posteriores a la operación.Como se puede apreciar en la figura 6.17, los valores cambiaron después de la operacióncon la interfaz, deduciendo una óptima conexión con la ontología.Observaciones:Se eligió el procedimiento de cambio de contraseña para comprobar la conexión con laontología, sin embargo, la mayoría de las actividades realizadas necesitan esta conexión. Tabla 6.7 Caso De Prueba: Estructuración De IndividualizacionesCaso de pruebaUSOG-401-001 Elección del dominio de aplicaciónDescripción: Revisar que la inclinación de la captura de los datos en la aplicación tengancoherencia con respecto al dominio elegido en el momento de la selección. La prueba serealiza tomando en cuenta la variación de los elementos requeridos, así como sudistinción entre datos recomendados y optativos, con respecto a la misma ontología conotro dominio de aplicación.Resultado:Para la prueba primero se autentica un usuario existente y se muestra su conjunto dedatos con respecto al domino de aplicación actual (en este caso Hospital), tal como semuestra en la figura 6.18.Rojas, Christian 103
  • 115. Pruebas Figura 6.18. Autenticación y visualización de clases organizadas según el dominio de aplicación HospitalPosteriormente se ingresa nuevamente a la ontología del mismo usuario y se elige laopción Cambiar Dominio, mostrándose en pantalla un mensaje con el dominio actual paraeste usuario. Véase figura 6.19. Figura 6.19. Dominio de aplicación antes de la operaciónSe muestra ahora una pantalla de elección del dominio de aplicación nuevo. Cabemencionar que los datos guardados previamente no se pierden, solamente cambian deorganización recomendada/optativa en ciertos elementos.Una vez elegido el nuevo dominio de aplicación se muestra un mensaje de informe acercade este cambio, como se muestra en la figura 6.20Rojas, Christian 104
  • 116. Pruebas Figura 6.20. Dominio de aplicación después de la operaciónPara poder verificar dicho cambio, se procede a mostrar la nueva disposición de los datosreferente al nuevo domino de aplicación, tal como se muestra en la figura 6.21. Figura 6.21. visualización de clases organizadas según el dominio de aplicación UniversidadObservaciones:El nuevo dominio de aplicación estará disponible a partir del momento del cambio sinnecesidad de reiniciar la autenticación y será recordado por el sistema cada vez que sereingrese.Rojas, Christian 105
  • 117. Pruebas6.4.2 Pruebas operativasA continuación se muestran las pruebas que enfatizan la operación de laaplicación al ingresar perfiles de usuario, y se sobreentiende que las pruebasfuncionales son apropiadas y aprobatorias.Para estas pruebas fue necesaria la participación de la comunidad (familiares yamigos), para poder poblar la ontología con perfiles reales y así disponer de unconjunto de datos para poder realizar las operaciones pertinentes.Estas pruebas fueron realizadas bajo las siguientes condiciones: La captura de los datos por los participantes fue personal, permitiendo la libre participación de los mismos, y la captura de los datos que consideraban apropiados y de pronta captura. La aplicación genera un árbol de abstracción de nombres basado en los identificadores conceptuales de las clases instanciadas por cada usuario, tomando en cuenta las reglas para su nomenclatura (véase 3.1.2). Éste árbol se aprecia gráficamente utilizando un entorno de diseño ontológico (protégé). Manualmente, siguiendo las mismas reglas para la nomenclatura de clases, se procede a realizar un árbol de abstracción de nombres de acuerdo al identificador de sesión capturado por los mismos usuarios. Se comparan los arboles de abstracción (el generado manualmente VS el generado automáticamente por la aplicación), para verificar consistencia. Este procedimiento es repetido para verificar todas las posibles combinaciones de clases, utilizando para ello el apoyo del usuario final. Por último, se muestra una tabla comparativa de las clases capturadas por el usuario, así como el dominio de aplicación elegido.Caso de pruebaEstructuración de individualizaciones 1Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos (Véase3.1.2), tal como se muestra en el siguiente árbol generado manualmente.Rojas, Christian 106
  • 118. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 2Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 107
  • 119. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 3Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 108
  • 120. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 4Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmente .Rojas, Christian 109
  • 121. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 5Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmente .Rojas, Christian 110
  • 122. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 6Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 111
  • 123. Pruebas Como se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 7Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 112
  • 124. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 8Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 113
  • 125. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 9Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmente.Rojas, Christian 114
  • 126. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 10Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 115
  • 127. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 11Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 116
  • 128. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 12Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 117
  • 129. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 13Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos, tal como semuestra en el siguiente árbol generado manualmenteRojas, Christian 118
  • 130. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 14Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 119
  • 131. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 15Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 120
  • 132. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 16Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 121
  • 133. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 17Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 122
  • 134. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 18Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 123
  • 135. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 19Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 124
  • 136. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 20Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 125
  • 137. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 21Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 126
  • 138. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 22Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 127
  • 139. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 23Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 128
  • 140. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 24Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 129
  • 141. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 25Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 130
  • 142. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 26Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 131
  • 143. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 27Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 132
  • 144. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 28Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 133
  • 145. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 29Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 134
  • 146. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.Caso de pruebaEstructuración de individualizaciones 30Resultado:Tomando en cuenta que la aplicación solamente crea los individuals a las clasesafectadas, se procede a crear el árbol de abstracción de nombres de estos datos, talcomo se muestra en el siguiente árbol generado manualmenteRojas, Christian 135
  • 147. PruebasComo se aprecia en el árbol generado automáticamente mostrado en la figura anterior, lacorrespondencia con el árbol generado manualmente es directa, por tanto satisfactoriapara ésta prueba.6.5 OBSERVACIONES GENERALESPara todos los casos mostrados en las pruebas anteriores, la generación de loselementos en la ontología es directamente proporcional a la cantidad deelementos operados en la interfaz, es decir, solo los elementos operados sonmanipulados.Rojas, Christian 136
  • 148. PruebasA continuación se muestran algunos datos estadísticos que permitirán definir losresultados en cuanto al mundo real.En la gráfica 1 se muestra la correspondencia de clases inferidas por los usuarioscapturados, deduciéndose con esta, cuales son las clases más accesadas por losusuarios. Cabe mencionar que la población total de prueba fueron 30 elementos. Clases Apariencia Trabajo Ayuda Tecnica Publicaciones 28 Contacto 17 12 Proyecto 30 Dirección 15 5 30 2 Preferencias Enfermedades 2 7 1 3 Personales 30 9 Estilo de vida 11 Origen 30 Estudio Nivel computo 30 GEEK Miembro Intereses Grafico 1 Clases accedidas por el grupo de pruebaEn la gráfica 2 se muestran algunos elementos considerados de interés parapoder consumir el proyecto y además para darnos una idea de la importancia de lainformación capturada para realizar inferenciasRojas, Christian 137
  • 149. Pruebas Grafico 2 Estadística de salidaRojas, Christian 138
  • 150. CAPÍTULO VII. CONCLUSIONESEn este capítulo se muestran las conclusiones aportaciones, trabajos futuros,publicaciones que se obtuvieron con el presente trabajo de tesis
  • 151. Conclusiones7.1 CONCLUSIONESUna de las pautas principales para la formación de la ontología es la estructuramisma, ya que define la complejidad de la captura y la recuperación de los datosalmacenados.Los principales conocimientos obtenidos a partir del logro de este proyecto fueron:el concepto de OWL, tomando en cuenta su lenguaje, estructura, comportamientoy limitantes; así como el manejo de la API de interacción “OWL API”.La interacción con la ontología tuvo una limitante muy pronunciada, basada en elmanejo de los tipos de datos internos, ya que la API de interacción solo maneja eltipo de datos de cadena de caracteres, aunque para solucionar los demás tipos,basa su implementación en una tripleta (nombre, valor y tipo), causando que laprogramación se adapte a esta característica, usando para ello un esquema dedefinición de tipos XSD.La mayoría de las características que componen a la ontología resultante fueronconsensuales por un grupo de personas de diversa índole, así como de diversasnaciones, ya que algunas de las aportaciones ocurridas en la tesis aquí mostradafueron iniciativa del personal de la Universidad Politécnica de Valencia, España,durante una estancia ocurrida en el desarrollo del mismo.Algunos de los resultados obtenidos en esta tesis, fueron una ontología con grancapacidad de explotación por parte de servicios o sitios con Web semántica quepermitan la explotación de contenido a partir de una ontología. El proceso decaptura o población de ésta, está definido mediante una interfaz centralizada yutilizando un entorno gráfico, sin embargo, debido a que el proyecto está divididoen su área operativa y el entorno gráfico de captura, este último puede serreemplazado por alguna aplicación Web, móvil o algún método emergente.Otra de las resultantes de esta tesis fue un conjunto de datos estadísticos quepermitirán tomas conclusiones y consideraciones para el posible emparejamientocon alguna otra ontología o servicio que requiera de datos de este tipo, como lopueden ser los Servicios Basados en Localización (LBS).Un perfil de usuario en lenguaje procesable, estructurado bajo el estándar XML(etiquetado), y que puede ser operable por cualquier gestor ontológico como porejemplo protégé.Este proyecto puede ser adaptable en su contenido, ya que pueden aplicarsetécnicas para poder realizar retroalimentación por parte del usuario y asíenriquecer el contenido de la misma.Rojas, Christian 140
  • 152. ConclusionesTambién es posible modificar los dominios de aplicación predefinidos, y enfocar elproceso de captura a un área específica con la finalidad de reducir aún más loselementos recomendados de captura hacia el usuario.Es importante tomar en cuenta la experiencia obtenida en el guardado,recuperación y borrado de elementos ontológicos, ya que el tema ontologías sevislumbra como uno de los más importantes para la Web 3.0.7.2 APORTACIONESUna ontología que se caracteriza por: Modelar perfiles de usuarios estructurados en un lenguaje procesable (OWL). Generar un árbol de abstracción de nombres para cada perfil generado (Véase 3.1.2), que permitirá mapear la estructura de cada ontología generada para poder explotarla posteriormente de manera más eficiente y lógica. Tener una correspondencia directa (en tamaño y número) con los elementos operados (pertinentes) para cada perfil de usuario generado. Corresponder directamente en las clases y datos contenidos de acuerdo a un cierto dominio de aplicación. (Véase 3.1.2.3.1)Una interfaz gráfica que se caracteriza por: Contener módulos dinámicos que responderán de acuerdo al contexto de los datos capturados al momento de la operación de dichos módulos. Permitiendo personalizar dinámicamente la captura de los elementos, mostrando y requiriendo solo los pertinentes para cada usuario en cuestión. Manejar de manera transparente todas las interacciones con la ontología, así como operaciones inmersas y estructuración de árboles de abstracción de nombres para cada perfil generado.Una de las principales aportaciones a este proyecto es la facilidad de serexplotada por otros servicios, para poder dar cabida a una personalización decontenidos basada en las preferencias del usuario, así como su comportamiento einclinaciones de decisión.Los sistemas de recomendación basados en contexto son también un punto haciael cual esta tesis ofrece una aportación ya que el conjunto de datos resultantes delos perfiles de usuario obtenidos, contienen información relevante para losServicios Basados en Localización (LBS).Este proyecto aporta en gran medida entonces una funcionalidad puntual a la Web3.0 que aunque emergente, también es inminente.Rojas, Christian 141
  • 153. Conclusiones7.3 TRABAJOS FUTUROSLos elementos de un perfil de usuario basado en ontologías que comprende elpresente trabajo son: la propuesta de un conjunto de datos divididos en seccionesque se justifican como todos los datos disponibles para capturar para cualquierusuario, una estructura ontológica basada en un núcleo más extensiones lascuales serán accesibles en la medida que sean pertinentes para el usuario encuestión, la generación automática de un árbol de abstracción de nombres quepermite mapear los elementos generados por la aplicación para cada perfil deusuario generado, una interfaz gráfica centralizada que permite realizar todas lasoperaciones tanto ontológicas como inmersas de sus funciones, en este ordensurgen posibles trabajos futuros. El conjunto de datos propuestos del proyecto puede crecer en la medida que se considere necesario, además de que podrán incluirse clases faltantes para algún propósito especifico. Debido a que la ontología está estructurada de acuerdo a un núcleo más extensiones, el número de extensiones podrá crecer, generando más extensiones para casos de uso específicos de algún servicio o aplicación, además, también es posible aumentar la cantidad de atributos para cada extensión establecida. En cuanto al árbol de abstracción de nombres refiere, es posible implementar un crecimiento o disminución de las reglas establecidas para su generación, con la finalidad de afinar los resultantes de estas. Este proyecto involucra una interfaz gráfica centralizada, sin embargo, debido a que la distribución de las clases programadas han sido en un lenguaje de programación de código abierto y además divididas según la lógica de Struts (código por un lado y operación grafica por otro), es posible sustituir la interfaz gráfica por alguna aplicación web, móvil o en alguna tecnología emergente.En cuanto a trabajos futuros propuestos, se proponen los siguientes: Integración de datos de Webs sociales actuales en la ontología, por medio de RIA (Aplicaciones de internet enriquecidas), con la finalidad de facilitar más aún, el proceso de captura de datos por parte del usuario; formando así un integrador de perfiles de usuario. Publicación del árbol de abstracción de nombres. Esta opción puede ser de gran ayuda ya que ayudara a los servicios consumidores a poder utilizar solo los datos que le sean pertinentes y además de explotar correctamente los dominios de aplicación, ya que al publicar el mapa de los nombres, es posible saber el contenido de la ontología sin la necesidad de adentrarse en la misma. Generación de un middleware para el emparejamiento con algún servicio consumidor. Este software intermedio podría permitir la adaptación de la ontología hacia el sitio Web semántico, con la finalidad de discriminar oRojas, Christian 142
  • 154. Conclusiones perfeccionar el contenido del mismo a partir de los datos definidos en las preferencias del usuario.7.4 PUBLICACIONES En el transcurso de los estudios de maestría fue lograda la publicación de un artículo que lleva por nombre: “Perfiles de usuario basados en contexto, utilizando ontologías”, en el congreso de ciindet, Junio 2009. Se obtuvo el 2° lugar en el XXIV Concurso nacional de creatividad 2009 en su fase local.Rojas, Christian 143
  • 155. BIBLIOGRAFÍA[Plans03] Plans, J.I.; Trenzano, F.; Robinat, J.; (2003), “Principios de marketing “En El consumidor y el comprador, Universidad de Barcelona Virtual [en línea], disponible en: Bivitec: Mercadotecnia, recuperado: 09 de septiembre de 2008.[Trajkova04] Joana Trajkova, Susan Gauch, (2004), “Improving Ontology-Based User Profiles”, Electrical Engineering and Computer Science, University of Kansas [en línea], disponible en: “citeseer.uark.edu/publications/RIAO2004.pdf”, presentada en RIAO, Vaucluse, Francia (Abril, 2004), recuperado: 23 de septiembre de 2008.[Chan07] Hyoung-Rae Kim, Philip K. Chan (2007).” Learning implicit user interest hierarchy for context in personalization”, Springer Science+Business Media, LLC, Estados Unidos, publicada en línea: Junio 2007.[Gauch04] Devanand Ravindran, Susan Gauch (2004).” Exploiting Hierarchical Relationships in Conceptual Search”, presentada en CIKM (Conference on Information and Knowledge Management), Washington D.C., Estados Unidos de América (Noviembre, 2004)[Sarjakoski03] Annu-Maaria Nivala, L.Tiina Sarjakoski (2003), “Need for Context-Aware Topographic Maps in Mobile Devices”, Department of Geoinformatics and Cartography, Finnish Geodetic Institute, presentada en ScanGIS, ISBN: 951-22- 6565-6, Masala, Finlandia (Mayo, 2003)[Yu05] Shijun Yu, Lina Al-Jadir, Stefano Spaccapietra (2005), “Matching Users Semantics with Data Semantics in Location-Based Services”, presentada en MCMP (First International Workshop on Managing Context Information in Mobile and Pervasive Environments), Vol-165, ISSN 1613-0073, Ayia Napa, Cyprus (Mayo, 2005)[ODP08] Netscape, “DMOZ (Open Directory Project)”, Directorio [en línea], disponible en: http://www.dmoz.org/, recuperado: 23 de septiembre de 2008.[Yho08] Yahoo, Yahoo! Directory, Directorio [en línea], disponible en: http://dir.yahoo.com/, recuperado: 23 de septiembre de 2008.[Chen05] Harry Chen, Tim Finin, y Anupam Joshi (2005), “The SOUPA Ontology for Pervasive Computing”, Ed. Birkhäuser Basel Dept. of CSEE, University of Maryland, Springer, ISBN: 978-3-7643-7237-8 (Print) 978-3-7643-7361-0 (Online), DOI: 0.1007/3-7643-7361-X_10, Baltimore County, USA(Marzo, 2006)[Chen04] Harry Chen, Filip Perich, Timothy W. Finin, Anupam Joshi (2004), “SOUPA: Standard Ontology for Ubiquitous and Pervasive Applications”, presentada en MobiQuitous (1st Annual International Conference on Mobile and Ubiquitous Systems, Networking and Services), ISB N0-7695-2208-4, Cambridge, MA, USA. IEEE Computer Society (2004)[Serral07] Estefanía Serral (2007), “A MDD strategy for developing context-aware pervasive systems”, Tesis de máster en Ingeniería del Software, Métodos Formales y Sistemas de Información, Universidad Politécnica de Valencia, Valencia, España. Rojas, Christian 144
  • 156. [GEEK, 2008] GEEK(1996), “The Code of the Geeks v3.12”, disponible en http://www.geekcode.com/geek.html, recuperado: 10 de Noviembre de 2008.[Aktors08] AKT / CROSI, “Advanced Kwnoledge Technologies”, disponible en http://www.aktors.org/akt, recuperado: 10 de Noviembre de 2008.[Miller00] Miller, Libby; D., Brickley. (2000). FOAF PROJECT. (Foaf (friend of a friend)) Disponible en: www.foaf-project.org/you/index.html Última consulta: 30 de Noviembre de 2008[Muñoz08] Javier Muñoz Ferrara, Vicente Pelechano Ferragud (2008), “Model Driven Development of Pervasive Systems. Building a Software Factory”, Tésis doctoral en sistemas de información y computación, Universidad Politécnica de Valencia, Valencia, España.[Gomez07] Alberto Gómez. OWL, “Descripción de la ontología”, Universidad Rey Juan Carlos (2007). Disponible en: http://axel.deri.ie/~axepol/teaching/ri2007/alberto.pdf. Recuperado el 07 de diciembre de 2008.[W3C04] Deborah L. McGuinness, Frank van Harmelen; “OWL Web Ontology Language Overview”, W3C Recommendation (Feb. 2004). Disponible en: http://www.w3.org/TR/owl-features/. Recuperado el 08 de diciembre de 2008[Escarza07] Sebastian Escarza, Silvia Castro, Sergio Martig; “Ontologías de visualización”, Universidad Nacional del Sur, Buenos Aires, Argentina (2007). Disponible en: http://www.ing.unp.edu.ar/wicc2007/trabajos/CGIV/057.pdf. Recuperado el 08 de diciembre de 2008.[Issste02] Instituto de Seguridad y Servicios Sociales a los Trabajadores del Estado. Sector Salud. Departamento Sanitario de Gobierno Mexicano. Disponible en: http://www.issste.gob.mx/aconseja. Recuperado el 06 de diciembre de 2008.[Disweb00] Clasificación Internacional del Funcionamiento, de la Discapacidad y de la Salud, CIF. Disponible en: http://usuarios.discapnet.es/disweb2000/cif/. Recuperado el 06 de diciembre de 2008.[Who08] World Healt Organization. “International Classification of Functioning, Disability and Health” (ICF). Disponible en: http://www.who.int/classifications/icf/en/. Recuperado el 06 de diciembre de 2008.[Disc08] Tipos de discapacidades. “Clasificación en línea”. Disponible en: http://es.geocities.com/mr_herraiz82/discapacidades.htm. Recuperado el 06 de diciembre de 2008.[Croja08] Tipos y grados de discapacidad. Cruz Roja. Disponible en: http://www.cruzroja.es/portal/page?_pageid=418,12398047&_dad=portal30&_sche ma=PORTAL30. Recuperado el 06 de diciembre de 2008.[Gzlez08] Gema González. “Las diferentes minusvalías y sus características”. Disponible en: http://www.efdeportes.com/efd104/minusvalias.htm. Recuperado el 06 de diciembre de 2008.[Disca08] Servicios Sociales. “Guía de recursos sobre discapacidad”. Disponible en: http://ayuntamiento.cieza.net/serviciosmunicipales/serviciossociales/discapacidad/ tiposminusvalias.html. Recuperado el 06 de diciembre de 2008. Rojas, Christian 145
  • 157. [Protege09] Gestor ontológico. Stanford Center for Biomedical Informatics Research, disponible en: http://protege.stanford.edu/, recuperado: 17 de abril de 2009.[W3C09] Desarrollo de tecnologías de interoperación. World Wide Web Consortium, disponible en: http://www.w3.org/, recuperado: 17 de abril de 2009[ITA09] I.T. de Apizaco. Nomenclatura de paquetes, disponible en: http://www.itapizaco.edu.mx/paginas/JavaTut/froufe/parte5/cap5-14.html, recuperado: 17 de abril de 2009[Sforge09] API Ontológica, SourceForge.net, disponible en: http://owlapi.sourceforge.net, recuperado: 17 de abril de 2009[Wiki09] Wikipedia. La enciclopedia Libre Disponible en: www.wikipedia.org. Última consulta: Julio 2009.[OWL09] Lenguaje de descripción de la Web. W3C. Disponible en : http://www.idg.es/pcworld/La-W3C-presenta-el-lenguaje-de-descripcion-de-la- W/art152601.htm. Última consulta: Julio 2009[RDF09] RDF, Especificacion del módelo y sintaxis, recomendación de W3C. Disponible en: http://www.sidar.org/recur/desdi/traduc/es/rdf/rdfesp.htm. Última consulta: Julio 2009[XSD09] XML Schema, recomendación de W3C. Disponible en: http://es.wikipedia.org/wiki/XML_Schema. Última consulta: Julio 2009[API09] Definición API. Disponible en: http://es.wikipedia.org/wiki/API Última consulta: Septiembre 2007.[Gruber95] GRUBER, T. R. "Toward Principles for the Design of Ontologies Used for Knowledge Sharing" en International Journal of Human and Computer Studies, 43 (5-6), 1995, p.907-928 GRUBER, T. R. "What is an Ontology?" http://www-ksl.stanford.edu/kst/what-is- an-ontology.html. Última consulta: Julio 2009[Guarino96] GUARINO, N. "Formal Ontology, Conceptual Analysis and Kwoledge Representation" en International Journal of Human and Computer Studies, 43(5- 6), 1995, p. 625-640 Rojas, Christian 146
  • 158. ANEXO 1Descripción de las clases del paquete mx.edu.cenidet.userontology.axiomsinference Clases tipo Charge Se encargan de obtener los atributos pertenecientes a la clase instanciada y correspondientes en la ontología, modificar el tipo de dato (siempre string) hacia el tipo de dato pertinente en la interfaz de la clase respectiva operada en la aplicación y rellenar las casillas gráficas en la interfaz con estos datos. Las clases que se contemplan en este grupo son: ChargePersonalesData, ChargeAyudaTecnicaData, ChargeContactoData, ChargeDireccionData, ChargeEstudioData, ChargeMiembrosData, ChargeNivelComputoData, ChargeOrigenData, ChargeProyectoData, ChargePublicacionesData, ChargeTrabajoData. Clases tipo Load Este conjunto de clases tienen como función la de extraer los datos pertenecientesa la interfaz respectiva de la clase que se está operando con los datos que elusuario introdujo o fueron deducidos por algún medio, y guardarlos en la ontología,mediante el uso de la API (OWLAPI). Las clases involucradas en este grupo son:LoadPersonalesData, LoadAyudaTecnicaData, LoadContactoData,LoadDireccionData, LoadEstudioData, LoadMiembrosData,LoadNivelComputoData, LoadOrigenData, LoadProyectoData,LoadPublicacionesData, LoadTrabajoData. Store Esta clase contiene métodos para crear individualizaciones en la ontología yatributos de tipo objeto para relacionarlos. Person Contiene la estructura genérica para que un elemento pueda ser guardado en laontología, ya sea individualización o atributo de tipo objeto. Además contiene unmétodo para parametrizar el guardado de un valor en un atributo en la ontología. Tupla Define el valor y el tipo de los atributos a operar en la ontología. Remove Se encarga de eliminar los individuals involucrados en la ontología. Dejando a unlado aquellos que se encuentren en la ontología pero que no hayan sido operadospor el proyecto. DATA Contiene los datos genéricos para el manejo de la aplicación, así como banderaspara poder aplicar o no extensibilidades en las clases mostradas gráficamente. Login Contiene métodos para poder autenticar a un usuario y marcar una bandera encaso de validarlo. RelationAll Los métodos que contiene permiten establecer las relaciones conceptuales entrelas individualizaciones operadas por la aplicación.Rojas, Christian 147
  • 159. ANEXO 2Descripción de las clases del paquete mx.edu.cenidet.userontology.Front Clases de grupos de datos Se encargan de mostrar en pantalla los elementos que intervienen en cada grupode datos respectivamente, conservando una coherencia y relación con aquellosatributos del entorno de desarrollo de la ontología (protégé), y los métodos internosse encargan de cambiar dinámicamente el contenido de dichas interfaces. Lasclases involucradas son: Origen, Personales, Dirección, Proyecto, Contacto,Estudio, Trabajo, Enfermedades, AyudaTecnica, Miembros, Publicaciones,Apariencia, EstilodeVida, GEEK, Intereses. Seguridad Esta clase contiene métodos para cambiar de contraseña de usuario,asociándose internamente con la clase Personales, y métodos de validación de estecambio. Authentication Esta clase posee métodos para comprobar o no la autenticación de un usuariopara acceder al sistema, además de modificar su comportamiento para un usuarionuevo o un usuario existente, asegura la validación del password para un usuarionuevo y un nombre de usuario univoco. ChooseDomain Esta clase contiene una interfaz que permite definir el dominio de la aplicaciónhacia la cual se inclinaran los campos solicitados al usuario en cuestión. Clases Esta clase se encarga de mostrar gráficamente las clases disponibles para elusuario en cuestión a partir de las deducciones dinámicas que se concluyan, asícomo de organizarlas de acuerdo al dominio de aplicación elegido. Interfaz Es la clase principal de este paquete, y además la clase que tiene una funciónprincipal. Tiene como finalidad el mostrar en pantalla el área de trabajo y organizartodos los paneles superiores que se vayan utilizando. Saver Esta clase se encarga de almacenar en la ontología los datos que se encuentrendispuestos en la interfaz respectiva. TaskChoice Contiene métodos para dar una elección al usuario sobre su operación en laontología, como modificar, guardar o agregar datos en la ontología. ZoneTime Esta clase funciona para dar opciones al usuario de modificar su zona horaria“GMT”, y/o el manejo de la aparición de alertas en pantalla.Rojas, Christian 148