cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales

TESIS 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 Suplente

Cuernavaca, Morelos, México.

Rojas, Christian

15 de Septiembre de 2009

i

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

AGRADECIMIENTOS A Dios. Siempre primero. A mis padres, por tanta paciencia, apoyo, y por enseñarme con amor y ejemplo que 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 el fin. Por contagiarme de su paciencia y ser mi compañera. Al Centro Nacional de Investigación y Desarrollo Tecnológico por permitirme un lugar entre sus alumnos y obtener mis estudios de maestría. Al Consejo Nacional de Ciencia y Tecnología por la beca para manutención otorgada y 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 su tesista, por todas esas horas de paciencia otorgadas, por la amabilidad y respetuosidad 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 dedicado A 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 por haber mitigado la tristeza de no pasar navidad y fin de año con la familia, cuando España fue nuestro hogar. Aunque me resulta imposible agradecer en solo este espacio a todas esas personas que hicieron posible éste logro. A todos ellos:

Rojas, Christian

iii

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

Rojas, Christian

iv

ÍNDICE Lista de figuras ................................................................................................................................. ix Lista de tablas.................................................................................................................................... x Lista de Gráficos ............................................................................................................................... x Glosario de términos y siglas ......................................................................................................... xi 1.

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 User's 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 ............................................................................................. 17

Capí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 2.2.1

Conceptos generales ........................................................................................................ 22 XSD ........................................................................................................................... 22

Rojas, Christian

v

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

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

4.

Árbol de abstracción de nombres ........................................................................................................38

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

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

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

5.

Extensibilidad satelital .........................................................................................................................63

Extensibilidad nuclear .........................................................................................................................70

4.2.2.3.1

Ejemplo .......................................................................................................... 71

4.2.2.3.2

Formalización de extensibilidad nuclear. ....................................................... 72

Capítulo V. Implementación ................................................................................................... 75 5.1

Conexión con ontología ..................................................................................................... 76

5.2

Usuario nuevo y usuario existente .................................................................................... 77

Rojas, Christian

vi

6.

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

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 6.4

Procedimiento de Pruebas ........................................................................................ 89 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 ................................................................ 91

Rojas, Christian

vii

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

Capítulo VII. Conclusiones ........................................................................................................... 139 7.1

Conclusiones ................................................................................................................... 140

7.2

Aportaciones .................................................................................................................... 141

7.3

Trabajos futuros............................................................................................................... 142

7.4

Publicaciones .................................................................................................................. 143

Bibliografía ..................................................................................................................................... 144 Anexo 1 ........................................................................................................................................... 147 Anexo 2 ........................................................................................................................................... 148 Rojas, Christian

viii

LISTA DE FIGURAS Figura 1.1 Perspectiva de SOUPA + CoBrA para modelar a un usuario. ........................................... 4 Figura 1.2 Perspectiva de GEEK para modelar a un usuario ............................................................. 5 Figura 1.3 Perspectiva de AKTORS para modelar a un usuario ........................................................ 6 Figura 1.4 Perspectiva de FOAF para modelar a un usuario ............................................................. 7 Figura 1.5 Mapa del comportamiento del comprador ......................................................................... 9 Figura 1.6 Ontologías integrantes de SOUPA .................................................................................. 13 Figura 3.1 Diagrama de bloques del proceso general del proyecto ................................................. 24 Figura 3.2 Diagrama general de casos de uso ................................................................................. 25 Figura 3.3 Diagrama de casos de uso de Operar con la ontología .................................................. 26 Figura 3.4 Diagrama de actividad del caso de uso CU-1 Operar con la ontología ........................... 28 Figura 3.5 Diagrama de actividad del caso de uso Elegir operación de altas, bajas y consultas .... 30 Figura 3.6 Diagrama de actividad del caso de uso Elegir dominio de aplicación ............................. 32 Figura 3.7 Diagrama de actividad del caso de uso Enlazar con la ontología ................................... 34 Figura 3.8 Diagrama de casos de uso de Estructuración ontológica................................................ 35 Figura 3.9 Diagrama de actividad del caso de uso Estructuración ontológica ................................. 36 Figura 3.10 Identificador del atributo “nombre” de la ontología en protégé ...................................... 37 Figura 3.11 Árbol de elementos de la ontología ............................................................................... 39 Figura 3.12 Árbol de elementos de la ontología ............................................................................... 39 Figura 3.13 Resultado del método para nombrar individualizaciones .............................................. 40 Figura 3.14 Esquema de manejo de los tipos de datos .................................................................... 41 Figura 3.15 Diagrama de clases del proyecto ................................................................................... 44 Figura 3.16 Diagrama de clases del paquete mx.edu.cenidet.userontology.axiomsinference ......... 45 Figura 3.17 Diagrama de clases del paquete mx.edu.cenidet.userontology.Front ........................... 47 Figura 3.18 Diagrama de secuencias para la Conexión con la ontología ........................................ 49 Figura 3.19 Diagrama de secuencias para ingresar al sistema como usuario nuevo ...................... 50 Figura 3.20 Diagrama de secuencias para ingresar al sistema como usuario existente.................. 51 Figura 3.21 Diagrama de secuencias del proceso Guardar ontología.............................................. 53 Figura 3.22 Diagrama de secuencias del proceso Modificación de ontología .................................. 54 Figura 3.23 Diagrama de secuencias del proceso Eliminación de la ontología ............................... 54 Figura 4.1. Estructura ontológica ...................................................................................................... 60 Figura 4.2. Enfermedades crónico-degenerativas en México ........................................................... 61 Figura 4.3. Estructura de la clase “Minusvalía”. ................................................................................ 64 Figura 4.4. Estructura de la clase “Ayuda_tecnica” .......................................................................... 64 Figura 4.5. Esquema de “Extensibilidad satelital” ............................................................................. 65 Figura 4.6. Esquema de extensibilidad parcial ................................................................................ 67 Figura 4.7. Estructura de la clase “Contacto” .................................................................................... 68 Figura 4.8. Estructura de la clase “Nivel_computo” .......................................................................... 68 Figura 4.9. Relación y cobertura entre las clases “Nivel_computo” y “Contacto” ............................. 69 Figura 4.10. Estructura de la clase “Personales” .............................................................................. 71 Figura 4.11. Estructura de la clase “Origen” ..................................................................................... 71 Figura 4.12. Esquema de extensibilidad nuclear .............................................................................. 72 Figura 5.1. Conexión con ontología .................................................................................................. 77 Figura 5.2. Autenticación de usuario.1 .............................................................................................. 77 Figura 5.3. Autenticación de usuario.2 .............................................................................................. 78 Figura 5.4. Autenticación de usuario.3 .............................................................................................. 79 Figura 5.5. Volcado de datos a la ontología ...................................................................................... 80 Figura 5.6. Relación de elementos en la ontología ........................................................................... 81 Figura 5.7. Lectura de datos desde la ontología ............................................................................... 82 Figura 5.8. Eliminación de datos en la ontología .............................................................................. 83 Figura 6.1. Datos de la ontología en protégé .................................................................................... 95 Figura 6.2. Autenticación invalida ..................................................................................................... 95 Figura 6.3. Autenticación válida y elección de operación con ontología .......................................... 95 Rojas, Christian

ix

Figura 6.4. Datos de la ontología en protégé .................................................................................... 96 Figura 6.5. Creación de nuevo usuario y elección del dominio de aplicación .................................. 96 Figura 6.6. Introducción de datos en el perfil .................................................................................... 97 Figura 6.7. Datos en la ontología después de la operación .............................................................. 97 Figura 6.8. Contenido de la instancia de la clase miembro en la ontología ..................................... 98 Figura 6.9. Eliminación de un individuals en la ontología ................................................................. 99 Figura 6.10. Resultado en la ontología después de la operación ..................................................... 99 Figura 6.11. Guardado de datos ontológicos. ................................................................................. 100 Figura 6.12. Árbol de abstracción de nombres de la ontología creada. ......................................... 100 Figura 6.13. Estructuración ontológica de la ontología en protégé................................................. 101 Figura 6.14. Contenido de password en la clase personales de la ontología ................................ 101 Figura 6.15. Autenticación en la ontología existente ...................................................................... 102 Figura 6.16. Cambio de contraseña en la ontología ....................................................................... 102 Figura 6.17. Valores ontológicos posteriores a la operación. ......................................................... 103 Figura 6.18. Autenticación y visualización de clases organizadas según el dominio de aplicación Hospital ............................................................................................................................................ 104 Figura 6.19. Dominio de aplicación antes de la operación ............................................................. 104 Figura 6.20. Dominio de aplicación después de la operación ........................................................ 105 Figura 6.21. visualización de clases organizadas según el dominio de aplicación Universidad .... 105

LISTA DE TABLAS Tabla 1.1. Análisis comparativo del estado del arte.......................................................................... 16 Tabla 3.1 Descripción del caso de uso Operar con la ontología ...................................................... 26 Tabla 3.2 Descripción del caso de uso Elegir operación de altas, bajas y consultas ....................... 28 Tabla 3.3 Descripción del caso de uso Elegir dominio de aplicación ............................................... 31 Tabla 3.4 Descripción del caso de uso Enlazar con la ontología ..................................................... 32 Tabla 3.5 Descripción del caso de uso Estructuración ontológica .................................................... 35 Tabla 4.1. Recopilación de atributos pertinentes para perfilar a un usuario. .................................... 58 Tabla 6.1 Tareas a desarrollar a las pruebas ................................................................................... 87 Tabla 6.2. Caso de prueba: Lectura de la ontología ......................................................................... 95 Tabla 6.3 Caso de prueba: Escritura en ontología............................................................................ 96 Tabla 6.4 Caso de prueba: Eliminado de la ontología ...................................................................... 98 Tabla 6.5 Caso De Prueba: Estructuración De Individualizaciones ................................................ 100 Tabla 6.6 Caso De Prueba: Estructuración De Individualizaciones ................................................ 101 Tabla 6.7 Caso De Prueba: Estructuración De Individualizaciones ................................................ 103

LISTA DE GRÁFICOS Grafico 1 Clases Accedidas Por El Grupo De Prueba .................................................................... 137 Grafico 2 Estadística de salida ........................................................................................................ 138

Rojas, Christian

x

GLOSARIO DE TÉRMINOS Y SIGLAS IEEE

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

1. CAPÍTULO I. INTRODUCCIÓN

En este capítulo se presenta la descripción del problema que dio origen al presente trabajo de tesis, su objetivo, justificación y beneficios. También los trabajos relacionados. Y por último la organización del documento.

Introducción

1.1

INTRODUCCIÓN

Debido a la inexactitud de los sistemas y estudios actuales para perfilar o modelar a un usuario real, se ha visto la necesidad de analizar las posibles categorizaciones del mismo, basadas en áreas como la mercadotecnia, psicología, y computación. Esto con la finalidad de obtener un conjunto de datos que permitan perfilar de un modo eficiente 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 lo puede 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ía que permita modelar a un usuario, así como sus costumbres, deficiencias, roles cotidianos y características, y poblarla mediante alguna interfaz gráfica de un ambiente de desarrollo para poder instanciarla y explotarla. Debido a que la información obtenida del usuario será proporcionada de manera explícita, es decir, directamente por el usuario, se investigarán e implementarán una serie de técnicas para evitar en la medida de lo posible la intrusión excesiva de sus datos, y por consiguiente obtener sólo los necesarios para un cierto dominio de aplicación, sin menoscabar la pertinencia de los mismos.

1.2

DESCRIPCIÓN DEL PROBLEMA

Los perfiles de usuarios son una importante herramienta para personalizar respuestas, entornos y evitar la intrusión excesiva de datos secundarios, así como para 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 su conjunto de datos básico (nombre, edad, sexo, etc.), también poseen datos especializados, que sólo poseerán aquellos usuarios que estén en el dominio de aplicación de esa categorización. Es entonces necesaria, una depuración de los datos de un usuario, dispuestos por Web 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

Introducció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 lo puede 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 que cumpla con las características citadas, modelando a un usuario y tomando en cuenta sus costumbres, deficiencias, roles cotidianos y características, y poblarla mediante una interfaz gráfica para poder instanciarla y explotarla. Debido a que la información para perfilar al usuario deberá ser directamente introducida por el mismo, se investigaron e implementaron una serie de técnicas para evitar, en la medida de lo posible, la intrusión excesiva de datos del usuario, y por consiguiente obtener sólo los necesarios para un cierto dominio de aplicación, sin menoscabar la pertinencia de los mismos. Una de las problemáticas inmersas en el uso de ontologías es nombrar semánticamente de forma unívoca a los elementos en la ontología, como lo son atributos, clases e individuals (instancia de una clase); los cuales son representados mediante 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 el peor de los casos esta nomenclatura arbitraria ocasionará que se tengan que implementar heurísticas más complejas para la recuperación de elementos a partir de un conjunto de identificadores conceptuales unívocos. Para resolver estos problemas, en esta tesis se propone una técnica para el tratamiento de los identificadores conceptuales mediante la generación de un árbol de abstracción de nombres a partir de un conjunto de reglas.

1.3

OBJETIVO

Obtener 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áfica para poder instanciarla y explotarla.

Rojas, Christian

3

Introducción

1.4

JUSTIFICACIÓN

Una gran cantidad de interpretaciones para categorizar a un usuario están disponibles en el mercado, sin embargo, la mayoría de estas, contemplan una estructura influenciada por el domino hacia el cual intencionalmente fueron creadas, es decir, que los datos que consideran capturar son divergentes, debido a que cada categorización especializa los datos a sus intereses. Aunque muchas de estas categorizaciones son similares en sus datos básicos (datos personales), existe la variabilidad en su formato, es decir, estos conjuntos de datos está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 un usuario. 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.

Información básica de perfil

Información de contacto

Profesional y social

• Nombre • Género • Edad • Fecha de nacimiento

• Correo • Dirección • Página personal • Número telefónico • Mensajería instantanea • Id. de chat

Perspectiva

SOUPA + CoBrA

• Amigos • Dependientes de organizacion

Figura 1.1 Perspectiva de SOUPA + CoBrA para modelar a un usuario.

Rojas, Christian

4

Introducción En la figura 1.2, se aprecia una perspectiva de GEEK [Geek09], en la que se enfatiza sobre las preferencias del usuario.

Figura 1.2 Perspectiva de GEEK para modelar a un usuario

La siguiente lista muestra los detalles de algunos elementos marcados con la letra asignada 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

Introducción

Figura 1.3 Perspectiva de AKTORS para modelar a un usuario

La siguiente lista muestra los detalles de algunos elementos marcados con la letra asignada en la figura 1.3. A. B. C. D.

Refiere a la ubicación geográfica según el uso horario (GMT) Referente al origen de la persona. (Lugar natal) Indica cómo le gusta a la persona ser llamada (parte de su nombre) 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 a un usuario tomando en cuenta que estos datos están inclinados a cuestiones de contacto debido a la naturaleza del proyecto en el que está inmerso, la cual toma como base los microformatos [Miller00].

Rojas, Christian

6

Introducción

Figura 1.4 Perspectiva de FOAF para modelar a un usuario

La siguiente lista muestra los detalles de algunos elementos marcados con la letra asignada en la figura 1.4. A. B. C. D. E. F. G.

Organización fundada por un proyecto o persona Una imagen utilizada para representar algo en específico Documento que representa un tema principal Algo que fue hecho o fabricado por esta persona Algún agente que hizo algo Liga a las publicaciones de esta persona Una muestra en imagen de algo interesante.

Como se puede apreciar en las figuras anteriores, las categorizaciones para un usuario son dedicadas a cierto dominio y en algunos casos de gran tamaño, estas se justifican así mismas en su contenido, y son muy útiles para el contexto de investigació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 que las 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

Introducción

1.5

BENEFICIOS

El principal beneficio que se obtuvo de esta tesis es una herramienta que permite modelar usuarios basándose en el contexto propio, mediante el uso de ontologías en lenguaje procesable, utilizando una interfaz gráfica. Las aplicaciones que pueden realizarse 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 RELACIONADOS

En primera instancia se describe un estudio del área mercadotécnica, en el cual se perfila a un usuario, denominado técnicamente como “comprador”. Posteriormente se muestra un conjunto de artículos asociados al tema, y por último dos tesis (doctorales y de maestría) involucradas por igual

1.6.1 Principios de marketing Este trabajo representa un estudio basado en la mercadotecnia, el cual maneja el concepto de cliente (sinónimo con usuario para fines del proyecto de tesis) Aquí se definen dos conceptos muy distintos entre sí, pero que aparentan una similitud, estos son: “Cliente” y “Consumidor”, pero contempla no sólo productos sino servicios por igual en estas definiciones. Debido a esta separación de definiciones, Rojas, Christian

8

Introducción consideran necesarias las categorizaciones de los comportamientos de estos dos actores, fijando la atención en el comprador (cliente). Véase figura 1.5.

Figura 1.5 Mapa del comportamiento del comprador

Se especifican también los roles de compra que son diferentes métricas adoptadas según la(s) rutina(s) en las que se desenvuelve el usuario, así como los tipos de comportamiento 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 subclasificaciones de datos. De modo que al no explayarse los datos internos de las categorías, solo los grupos, dejan espacio a ambigüedades. [Plans03]

1.6.2 Improving Ontology-Based User Profiles Intenta clasificar intereses del usuario, siendo su principal objetivo investigar técnicas que implican la construcción de perfiles de usuario basados en ontologías. La idea es construir perfiles sin interacción humana, esto es, de manera automática, con el simple monitoreo de los hábitos del usuario. Toma mucha importancia el definir los conceptos más importantes en la construcción o categorización de estos usuarios al igual que involucran estos conceptos o características de un modo jerárquico y cuestionan firmemente la cantidad de niveles necesarios para categorizar al usuario. Rojas, Christian

9

Introducción

Sin embargo las principales problemáticas se basan en la elección de los elementos pertinentes para la elaboración de dicho perfil y cómo proyectar estos datos en el mismo, ya que se explayan dos técnicas para obtener estos datos, las cuales son implí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 no vectorial, esto es, aplicando niveles de abstracción con cierta ponderación. [Trajkova04]

1.6.3 Learning implicit user interest hierarchy for context in personalization El contenido de este documento presenta una visión de la categorización de un usuario 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 un perfil, 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áticas muy distintas entre sí, puede darse el caso que en un nivel de abstracción no tengan relación, sin embargo, si se eleva el nivel de abstracción de esas navegaciones, se hace que pertenezcan al mismo concepto. Este artículo utiliza para la generación de un perfil de usuario una estructura jerárquica, denominada por ellos como: UIH (jerarquía de intereses del usuario por sus siglas en inglés). Se propone que la alimentación de las jerarquías y de los conceptos inmersos en ellas sean por un medio automático, esto es, dinámicamente, por medio de la navegación Web del usuario, usando la lógica de que los intereses se contemplan como pasivos cuando el nivel de abstracción es más alto y más activos cuando el nivel de abstracció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 los perfiles son constantemente actualizados por el usuario, y no es práctico el definir un perfil 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ás precisa que una realizada de un modo vectorial o lineal, sobre todo por cuestiones ontológicas. [Chan07]

Rojas, Christian

10

Introducción

1.6.4 Need for Context-Aware Topographic Maps in Mobile Devices Este trabajo se especializa en servicios que facilitan mapas cartográficos a usuarios, y uno de sus principales factores a tomar en cuenta es la capacidad que se tiene o no para darle al usuario algo en específico que cumpla con sus expectativas, todo esto con 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ón para localización de detalles vía espacial, (esto debido a que aplican ontologías para la solución de los mismos) y por lo tanto la exactitud de estos debe de ser por demás precisa, tomando en cuenta todos los detalles que conlleva. Para la eficiente provisión de los mapas solicitados se emplean las siguientes categorías de acuerdo al momento de la solicitud de los mismos: Contexto de cómputo Contexto del usuario: Refiere a habilidades físicas, habilidades perceptuales y cognitivas, y diferentes personalidades del usuario en cuestión. Contexto Físico Contexto de tiempo. Contexto de historia Sin embargo, debido a que el destino final de estos mapas son los dispositivos móviles, estos términos cambian con base en adaptabilidad. [Nivala03]

1.6.5 Matching User's Semantics with Data Semantics in Location-Based Services Relación de semántica de usuarios con semántica de datos en LBS Propone cierta flexibilidad a los servicios de información para que puedan entender correctamente lo que está siendo solicitado por el usuario, y como seleccionar la información que esa relevante para esta solicitud, tomando en cuenta la gestión, el diseño y los factores humanos. En este artículo se definen los siguientes conceptos: 1.6.5.1 Perfil de usuario Son dinámicos. Dos usuarios en las mismas condiciones, en la misma ubicación y haciendo la misma petición pueden tener resultados distintos (polimorfismo) de acuerdo a su perfil. Se definen también los perfiles de usuario de tipo estático (explicito), y de tipo dinámico (implícito), es decir, alimentados por preguntas directas acerca de sus características, hábitos o comportamiento, y alimentada por el análisis constante de su comportamiento mediante su navegación u otro método, respectivamente. Rojas, Christian

11

Introducción 1.6.5.2 Perfiles de datos Los perfiles de datos describen servicios de datos. Del mismo modo en que un esquema describe una base de datos, un perfil de datos proporciona información acerca de los datos provistos por un servicio. [Yu05]

1.6.6 Exploiting Hierarchical Relationships in Conceptual search Debido al constante crecimiento de sitios Web, la pertinencia de muchas de las respuestas arrojadas hacia un usuario que los consulta, dependen de una cierta personalización, la cual, no existe al momento, porque a pesar de que los mecanismos son más novedosos en cuestiones de navegación y búsqueda, los principios 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 la misma palabra de búsqueda, el motor de búsqueda arroja como resultado el mismo conjunto de respuestas, siendo que es muy probable que cada uno de ellos se haya referido a un contexto distinto. [Gauch04] La herramienta que ellos desarrollaron denominada KeyConcept toma en cuenta tanto estas palabras clave como los conceptos o temas relacionados de su consulta directa y automáticamente de Open Directory. [Odp08] Este artículo entonces, utiliza una estructuración de tipo jerárquica para poder realizar la alimentación de una ontología adoptando los beneficios de este tipo de estructuración en contraste con una de tipo vectorial, además de que toma en cuenta un mejoramiento iterativo, refinándose la jerarquía automáticamente.

1.6.7 SOUPA: Standard ontology for ubiquitous and pervasive applications En este artículo se explica a detalle el SOUPA, ésta ontología se modelar y soportar aplicaciones de cómputo pervasivo.

diseñó para

Esta ontología está definida en lenguaje OWL, la cual incluye un componente modular de vocabulario para representar agentes inteligentes asociados a intenciones, deseos, creencias, perfiles de usuario, información de contexto, acciones y políticas de seguridad y privacidad, y además se explica cómo puede ser extendida y usada para soportar aplicaciones de CoBrA [Chen2005] para la construcción de cuartos inteligentes (habitaciones con sensores de radio frecuencia); y MoGATU, un gestor de datos peer-to-peer para ambientes pervasivos. [Chen04] A continuación se definen los componentes de las ontologías integrantes de SOUPA:

Rojas, Christian

12

Introducción

Figura 1.6 Ontologías integrantes de SOUPA

1.6.7.1 SOUPA Core. Define el vocabulario genérico y universal para la construcción de aplicaciones de computo pervasivas. Este conjunto de ontologías consiste en vocabularios para expresar conceptos que son asociados con personas, agentes, intenciones, deseos y creencias; acciones políticas, tiempo, espacio y eventos. Véase figura 1.6 1.6.7.2 SOUPA Extensión Se extiende de SOUPA Core. Define vocabulario adicional para el soporte de tipos específicos de aplicaciones y ejemplos provenientes de la definición de nuevas extensiones de ontología. figura arriba Estas 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 systems Esta tesis propone un enfoque metodológico al desarrollo de sistemas pervasivos conscientes de los contextos basados en ontologías y normas del MDD (Model-Driven Development), 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

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 usuario Estos sistemas no solo deben capturar información del contexto, también deben entenderlo y adaptar su comportamiento acorde a éste a partir de las preferencias del usuario. En esta tesis se define una ontología de contexto y un repositorio contextual OWL como un sistema capaz de almacenar en una máquina de lenguaje procesable tanto la información contextual actual como la información contextual histórica. Este framework automáticamente actualiza el repositorio contextual OWL de acuerdo a los cambios producidos en la información contextual al tiempo de ejecución. Para poder gestionar la localización del usuario se requiere que cada uno de ellos tenga un dispositivo de localización (por ejemplo, un brazalete de identificación por radio frecuencia) para ser identificados por los propios sensores. [Serral07]

1.6.9 Categorizaciones independientes de un Usuario. 1.6.9.1 GEEK Un geek es una persona hábil para la informática, la electrónica y la tecnología, y ademá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, han desarrollado 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 y describen 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íticoeconómicos, de entretenimiento y más. Cabe mencionar que cada una de las categorías y de las opciones operadas por esta categorización tiene asignado un símbolo univoco (conjunto de caracteres carentes de sentido en un contexto habitual), y formando una concatenación de acuerdo al orden de petición, es como se forma el código geek, cuyo análisis y ejemplo cae fuera de los intereses de este documento.

1. Gadget (Gizmo) Obtenido de: http://es.wikipedia.org/wiki/Gadget ; Ultima consulta: Julio 2009 Es 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 suelen tener un diseño más ingenioso que el de la tecnología corriente.

Rojas, Christian

14

Introducción 1.6.9.2 AKTORS AKTORS es una ontología creada por AKT (Advanced Kwnoledge Technologies), el cual es fundado en EPSCR (Engineering and Physical Sciences Research Council) el cual tienen como objetivo desarrollar y extender un rango de tecnologías provenientes 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 gran medida 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, utilizando tecnologías desarrolladas dentro de la Web semántica para describir relaciones mediante 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 entre las cosas. FOAF proporciona algunos mecanismos básicos para que nos ayuden a decirle a la agentes sobre las conexiones entre las cosas que interesan a los usuarios finales. FOAF es una tecnología sencilla que facilita el compartir y utilizar la información sobre las personas y sus actividades (por ejemplo, fotos, calendarios, diarios), para transferir información entre los sitios Web, y para extender automáticamente, fusionar y re-usar en línea. [Miller00] Para representar el lenguaje FOAF se ha descrito una especificación con diccionarios de 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 elementos estudiados anteriormente, reflejando los parámetros más importantes.

Rojas, Christian

15

Introducción

[CHAN07]

Implícita

Jerárquica

[GAUCH04]

Implícita

Jerárquica

[SARJAKOSKI03]

N/E

Lineal

[YU05]

Explicita / Implícita

Ninguno

[CHEN05]

Explicita

[CHEN04]

Explicita

[SERRAL07]

Explicita

Lineal

[GEEK08]

Explicita

Lineal

[AKTORS08]

Explicita

Jerárquica

[MILLER00]

Explicita

Lineal

Nuestro Enfoque

Explicita

Núcleo + Extensión

Lenguaje procesable OWL

Jerárquica

Seguridad / Privacidad

Implícita

Retroalimentación o autoaprendizaje

[TRAJKOVA04]

Uso en ambiente domótico

Ninguna

Uso de agentes

Arquitectura

Ninguna

Uso de ponderancias

Exploración

[PLANS03]

Roles de Usuario

Nombre

Tabla 1.1. Análisis comparativo del estado del arte.

Núcleo + Extensión Núcleo + Extensión

N/E= No Especificado

Rojas, Christian

16

Introducción

1.7

ALCANCE DEL PROYECTO DE TESIS

El proyecto de tesis que se dispone en este documento, se conforma de acuerdo a 5 puntos 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 DOCUMENTO

Este documento de tesis ésta estructurado de la siguiente manera: En el capítulo 2 se presentan los conceptos sobre las tecnologías involucradas en el desarrollo de la tesis. En el capítulo 3, se muestran los casos de uso, escenarios, diagramas de actividad, clases y secuencia que representan el análisis y diseño del proyecto realizado. En el capítulo 4, se detalla el procedimiento seguido para la obtención del prototipo. En el capítulo 5, se explica el uso de la aplicación así como segmentos de código importantes. En el capítulo 6, se presentan los resultados de las pruebas. En el capítulo 7, se presentan las aportaciones de la tesis, los trabajos futuros y las publicaciones realizadas durante el desarrollo de la tesis.

Rojas, Christian

17

Introducción

Rojas, Christian

18

CAPÍTULO II. MARCO TEÓRICO En 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 el proyecto en el ámbito semántico y continúa con los conceptos generales que se utilizaran en el transcurso de este documento.

Marco teórico

2.1

CONCEPTOS SEMÁNTICOS

2.1.1 OWL El Lenguaje de Ontologías Web (OWL) está diseñado para ser usado en aplicaciones que necesitan procesar el contenido de la información en lugar de únicamente representar información para los humanos. OWL facilita un mecanismo de interoperabilidad de contenido Web más eficiente que los mecanismos admitidos por XML, RDF, y esquema RDF (RDF-S) proporcionando vocabulario adicional junto con una semántica formal. OWL tiene tres sub-lenguajes, con un nivel de expresividad creciente: OWL Lite, OWL DL, y OWL Full. La Web semántica se basará en la capacidad de XML para definir esquemas de etiquetas a medida y en la aproximación flexible de RDF para representar datos. El primer nivel requerido por encima de RDF para la Web semántica es un lenguaje de ontologías que pueda describir formalmente el significado de la terminología usada en los 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, "uno exacto"), igualdad, más tipos de propiedades, características de propiedades (por ejemplo, simetría), y clases enumeradas. [OWL09]

2.1.2 RDF El fundamento o base de RDF es un modelo para representar propiedades designadas y valores de propiedades. El modelo RDF se basa en principios perfectamente establecidos de varias comunidades de representación de datos. Las propiedades RDF pueden recordar a atributos de recursos y en este sentido corresponden con los tradicionales pares de atributo-valor. Las propiedades RDF representan también la relación entre recursos y por lo tanto, un modelo RDF puede parecer un diagrama entidad-relación. (De forma más precisa, los esquemas RDF que son 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 recursos corresponden con objetos y las propiedades corresponden con objetos específicos y variables de una categoría. El modelo de datos de RDF es una forma de sintaxis-neutral para representar expresiones RDF. La representación del modelo de datos se usa para evaluar la equivalencia en significado. Dos expresiones RDF son equivalentes si y sólo si sus representaciones del modelo de datos son las mismas. Esta definición de equivalencia permite algunas variaciones sintácticas en expresiones sin alterar el significado. El modelo de datos básico consiste en tres tipos de objetos: Rojas, Christian

20

Marco teórico

Recursos

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. Una propiedad es un aspecto específico, característica, atributo, o Propiedades 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 RDF enunciados] [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 W3C Es un consorcio que tiene como visión la de guiar la Web a su potencialidad máxima a modo de foro de información, comercio, comunicación y conocimiento colectivo, mediante tecnologías inter-operativas, especificaciones, líneas maestras, software y herramientas. [W3C04]

2.1.4 Ontología Existen varias definiciones sobre éste concepto, entre ellas se encuentran: Una ontología constituye "Una especificación formal y explicita de una conceptualizació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 del que se identifican los conceptos que son relevantes; hace referencia a la necesidad de especificar de forma consciente los distintos conceptos que conforman una ontología. [Gruber] “Una ontología es una base de datos que describe los conceptos en el mundo y algunos dominios, algunas de sus propiedades y como los conceptos se relacionan unos con otros”. [Weigand]

Rojas, Christian

21

Marco teórico Ontología describe una cierta realidad con un vocabulario específico, usando un conjunto de premisas de acuerdo con un sentido intencional de palabras del vocabulario. [Guarino]

2.2

CONCEPTOS GENERALES

2.2.1 XSD XML Schema es un lenguaje de esquema utilizado para describir la estructura y las restricciones 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 consigue así una percepción del tipo de documento con un nivel alto de abstracción. Fue desarrollado por el World Wide Web Consortium (W3C) y alcanzó el nivel de recomendación en mayo de 2001. [XSD09]

Rojas, Christian

22

3. CAPÍTULO III. ANÁLISIS Y DISEÑO

En este capítulo se presentan los diagramas de caso de uso, la definición de escenarios y los diagramas de actividad que corresponden a la fase de análisis. Así mismo se presenta los diagramas de clase y de secuencia correspondiente a la etapa del diseño.

Análisis y diseño

3.1

ANÁLISIS

La figura 3.1 muestra el proceso de trabajo del proyecto, tomando en cuenta bloques de manera abstracta.

Figura 3.1 Diagrama de bloques del proceso general del proyecto

Como se puede apreciar en la figura 3.1, el proceso de desarrollo se dividió en dos segmentos, 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”, las cuales se encuentran unidas mediante código. A continuación se presentan los diagramas de caso de uso, la definición de escenarios y los diagramas de actividad que corresponden a la fase de análisis del proyecto, respectivo a la sección de “operación con clases” de acuerdo a figura 3.1. Y posteriormente se mostraran las partes importantes de análisis de la sección de “Interfaz” de acuerdo a figura 3.1. Rojas, Christian

24

Análisis y diseño

3.1.1 Análisis de operación con clases En la figura 3.2 se muestra el diagrama general de casos de uso del proyecto y se muestran las funciones principales que ofrece.

Figura 3.2 Diagrama general de casos de uso

En la figura 3.2 el usuario accede o crea su ontología previa autenticación y realiza modificaciones en ella mediante el uso de la interfaz. Una vez que se ha autenticado y definido si se creará, modificará o eliminará su ontología, el usuario elegirá cual será el dominio de la aplicación hacia la cual se inclinaran los datos de la captura. Este caso de uso contempla el paquete: mx.edu.cenidet.userontology.axiomsInference y mx.edu.cenidet.userontology.front

Rojas, Christian

25

Análisis y diseño

Figura 3.3 Diagrama de casos de uso de Operar con la ontología

Como 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 únicamente consumida por el proyecto y como su nombre lo indica, tiene como funcionalidad la 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 la cual 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

Nombre caso de uso Actores Descripción

El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.4 del Operar con la ontología

Precondiciones Poscondiciones Escenario de éxito 1

Escenario éxito 2

de

Escenario éxito 3

de

Rojas, Christian

Usuario, API de conexión, Ontología Permite al usuario realizar operaciones sobre la ontología, como lo son agregar, modificar y eliminar tanto de manera global como detallada. Requisitos mínimos del sistema comunes para cualquier aplicación. Se obtendrá la ontología del usuario para poder ser reutilizada 1. El usuario ingresa al sistema para crear una nueva ontología 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 creada 1. El usuario ingresa al sistema para modificar su ontología 2. El proceso de autenticación es correcto 3. Se realizan las modificaciones pertinentes apropiadamente 4. La ontología es guardada 1. El usuario ingresa al sistema para borrar su ontología 2. El proceso de autenticación es correcto

26

Análisis y diseño 3. Se realiza el borrado de la ontología 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 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ía Suposiciones Se supone que la aplicación importa la librería en donde se encuentra la API

Rojas, Christian

27

Análisis y diseño act CU-1 Operar con la ontología

Existent e

Enlazar con ontología (API)

Autenticar

Razonador

Nuevo

Validar usuario y passw ord nuev o

Elegir tipo de usuario

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

Operar en Ontología

No Informar Ex cepción

Si

Ontología consistent e

Figura 3.4 Diagrama de actividad del caso de uso CU-1 Operar con la ontología

A continuación se muestran las tablas de descripción de los casos de uso para cada caso de uso dependiente de Operar con la ontología, así como su correspondiente diagrama de actividad. Tabla 3.2 Descripción del caso de uso Elegir operación de altas, bajas y consultas

ID: CU-1.1

Nombre caso de uso Actores Descripción

El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.5. del Elegir operación de altas, bajas y consultas

Rojas, Christian

Elegir asunto de conexió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.

28

Análisis y diseño Precondiciones

Poscondiciones Escenario éxito 1

de

Escenario fracaso 1

de

Incluye Suposiciones

Rojas, Christian

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. 1. El usuario accederá a la interfaz pre programada para la operación con las clases. 1. El usuario se autentica correctamente. 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. 1. El usuario ingresa al sistema para realizar un agregado, modificación 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. Se supone que la aplicación importa la librería en donde se encuentra la API

29

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

Leer y nav egar en la ontología

Operación

Modficar Mostrar interfaz apropiada

Eliminar Eliminar obj etos

Adaptar extensibilidad y deducción

Eliminar indiv iduals

Enlazar con ontología (API)

Raz onador

Si No

Ontología consistent e 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 consultas

Rojas, Christian

30

Análisis y diseño Tabla 3.3 Descripción del caso de uso Elegir dominio de aplicación

ID: CU-1.2

Nombre caso de uso Actores Descripción

El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.6 del Elegir dominio de aplicación

Elegir modo de captura 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ón Incluye Suposiciones Se supone que la aplicación importa la librería en donde se encuentra la API

Rojas, Christian

31

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

Nombre caso de uso Actores Descripción

El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.7. del Enlazar con la ontología

API de conexión, Ontología Realizara las validaciones y requerimientos necesarios para enlazar la interfaz con la ontología Precondiciones 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ía Poscondiciones 1. Se realizaran los cambios programados a la ontología Escenario de 1. El usuario ingresa o modifica datos en la interfaz éxito 1 2. Los datos son guardados en la ontología Escenario de 1. El usuario ingresa o modifica datos en la interfaz Rojas, Christian

32

Análisis y diseño fracaso 1

Escenario fracaso 2

de

Incluye Suposiciones

Rojas, Christian

2. Existe un error provocando una inconsistencia en la ontología que es detectada por el razonador. 3. Se lanza una excepción. 1. El usuario ingresa o modifica datos en la interfaz 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. Se supone que la aplicación importa la librería en donde se encuentra la API

33

Análisis y diseño act CU-1.3 Enlazar con la ontología

Generar axiomas

Generar reglas

Desecha elementos inserv ibles

Establecer obj etos

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ía

En 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

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

Nombre caso de uso Actores Descripción

El diagrama de actividades que incluye el escenario de éxito y los escenarios de fracaso se muestra en la figura 3.9. del Estructuración ontológica

Precondiciones Poscondiciones

Escenario éxito 1

de

Escenario fracaso 1

de

Escenario fracaso 2

de

Incluye Suposiciones

Rojas, Christian

Ontología 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.2 1. La ontología debe de ser consistente (confirmada por el razonador) 1. Si la estructura no existe este será creada sin importar el nivel de granularidad. 2. Se obtendrá una ontología estructurada con relaciones. 1. El usuario ingresa o modifica datos en la interfaz 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. 4. El usuario ingresa o modifica datos en la interfaz 5. Existe un error provocando una inconsistencia en la ontología que es detectada por el razonador. 6. Se lanza una excepción. 4. El usuario ingresa o modifica datos en la interfaz 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. Se supone que la aplicación importa la librería en donde se encuentra la API

35

Análisis y diseño act CU-2 Estructuración ontológica

Generar los atributos para las clases utilizadas

Generar las 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 indiv idualizacion de la clase principal

Generar los atributos obj eto / relacion para la clase principal

Asignar las indiv idualizaciones de las clases utilizadas a los atributos obj eto

Enlazar con ontología (API)

Raz onador

Informar ex cepción

Ontología consistent e

Si Guardar ontología

Figura 3.9 Diagrama de actividad del caso de uso Estructuración ontológica Rojas, Christian

36

Análisis y diseño

3.1.2 Estructura de URI´s (Uniform Resource Indicator). El método para identificar, atributos y propiedades en las ontologías es mediante identificadores conceptuales, denominados URI´s, los cuales están formadas en la primera 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 la siguiente manera: http://www.cenidet.edu.mx/user_ontology.owl#nombre Tal 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 mismo patrón y debido a que la aplicación a la que apunta este proyecto deberá generar automá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étodo para poder generar un árbol de abstracción, en el cual la referencia a un elemento tiene coherencia y propiedad con respecto al que está contiguo (ancestro o hijo en el árbol), con la finalidad de poder estandarizar estos identificadores conceptuales, y recuperarlos en cualquier momento. Dicho método se detalla a continuación:

Rojas, Christian

37

Análisis y diseño 3.1.2.1 Árbol de abstracción de nombres Algunas de las restricciones para los identificadores aplicables a los elementos de una 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 flexibilidad para nombrar un elemento, es muy sencillo entrar en ambigüedades de nomenclatura, tal vez influenciadas por el contexto, el horario, costumbres o incluso 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 la ontología, ya que las reglas para nomenclatura de los elementos de la misma están aplicadas por el entorno de diseño utilizado y explicadas en las primeras dos reglas 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

Análisis y diseño A continuación se muestra un ejemplo de cómo se ha empleado este método para la nomenclatura estandarizada de las individualizaciones: Tomando en cuenta las clases que se muestran en la figura 3.11, se han aplicado las reglas generales para identificarlas unívocamente, tal como se muestra en la figura 3.12

Persona Enfermedades

No Transmisibles

Transmisibles

SIDA

Personales

Tuberculosis

Nombre

Cáncer

Figura 3.11 Árbol de elementos de la ontología

Persona Enfermedades Transmisibles

sida

tuberculosis

Personales NoTransmisibles

nombre

cancer

Figura 3.12 Árbol de elementos de la ontología

Como se puede apreciar en la figura 3.12, las nomenclaturas de las clases y sus atributos, son similares (en la medida de lo posible) con respecto a su nombre contextual (de acuerdo a la lógica) de la figura 3.11 y siguiendo las reglas básicas de nomenclatura de clases explicada anteriormente, recordando también que cada identificador 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, y no sobre atributos y/o propiedades, por tanto la figura 3.13 muestra las clases a las cuales se les puede realizar individualizaciones y por tanto se les referirá un identificador contextual ya operado por las reglas anteriores.

Rojas, Christian

39

Análisis y diseño

Figura 3.13 Resultado del método para nombrar individualizaciones

En la figura 3.13 se muestra el resultado del método explicado en esta sección. En el resultado se aprecia que cualquier elemento tiene referencia en su nomenclatura al elemento contiguo.

3.1.3 Manejo de tipos Una de las limitantes hacia las cuales se vio influenciado este proyecto, fue a la operació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ía mediante la API (OWLAPI), no fue posible especificar el tipo de dato del atributo a operar, ya que internamente, todos estos, se manejan como datos de tipo cadena de caracteres (esto último con la finalidad de operar mediante un nivel de abstracción superior), la conversión para obtener los tipos necesarios se realiza mediante el uso de constantes predefinidas que representan a los tipos de datos citados. 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 dato citado, especificándole al entorno de diseño de ontologías (protégé) que interprete el dato conforme al tipo asociado, utilizando para ello un esquema utilizado por el estándar XML para el manejo de tipos de dato (XSD) [W3C, 2009]. El proceso se muestra en la figura 3.14 Aunque ya existe solución a esta problemática, del proceso requiere que se procese dato por dato, por este motivo se ha estructurado un método para poder realizar esta operación de manera parametrizada, respetando las siguientes reglas: 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

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 Valor

Tipo

Corresponde al nombre del atributo a guardar 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. 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 datos

Como se puede apreciar en la figura 3.14, los datos en la interfaz, que son distinguidos por sus nombres y valores (elementos restantes en las tripletas), son similares en los tipos de datos en el entorno de diseño (protégé), y para realizar esta conversión en el tipo se utilizan los componentes intermedios explicados previamente, mediante un mapeo de uno a uno. Rojas, Christian

41

Análisis y diseño

3.1.4 Análisis de la interfaz Para 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 un lenguaje 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 diferencia contextual entre ellas.

2. Open source (Código abierto) Obtenido de: http://es.wikipedia.org/wiki/Código_abierto; Ultima consulta: Julio 2009 Término con el que se conoce al software distribuido y desarrollado libremente.

Rojas, Christian

42

Análisis y diseño 3.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 para cualquier usuario y de conocimiento elemental (calificados visualmente como Recomendados), como lo son los datos personales, datos relacionados a su origen y dirección, y ciertas preguntas que permitirán o no, acceder a ciertos campos si es que el usuario desea algún perfil en especifico orientado a cierto dominio. La interfaz contempla un área recomendada y un área optativa, para los atributos de cada clase e incluso entre las mismas clases, las cuales como su nombre lo indica, son obligatorias u opcionales de capturar, categorizándolas de acuerdo a el dominio de la aplicación elegido y a las dependencias con otras capturas posteriores, es decir, el área obligatoria contendrá aquellos datos que no tengan dependencia de el valor almacenado en otros atributos de otras clases y aquellos atributos 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 todo momento 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 que conjuntos 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 cual sería el escenario del peor caso para cuestiones de tiempo y dedicación por parte del usuario. Se han contemplado los siguientes dominios: 3.1.4.2 Dominio Médico Este dominio fue concertado para poder contemplar atributos del usuario tales como enfermedades, minusvalías, discapacidades y ayuda técnica que pudiese utilizar el usuario, tales como: muletas, silla de ruedas, bastón, etc. Las cuales se consideran elementos importantes a considerar de un usuario siempre y cuando el interés esté orientado a un dominio medico. 3.1.4.3 Dominio Familiar Este dominio ha sido acordado para aquellos usuarios cuya principal actividad sea discordante con el ámbito organizacional y educativo, en el cual, se distinguen atributos como lo son las preferencias del usuario y los gustos referidos a programación televisiva, actividades recreativas y demás.

Rojas, Christian

43

Análisis y diseño 3.1.4.4 Dominio Profesional Se contempló este dominio para poder categorizar usuarios que sean dependientes de una empresa u organización y cuyos datos relacionados sean de interés especifico, como lo son el nombre del puesto, el proyecto en el que se encuentre trabajando y en el que estuvo trabajando previamente, el número de empleados 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 en la que estudia, el horario y demás.

3.2

DISEÑO

El 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 son los 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 en el artículo Estructura de paquetes [ITA09] Todas las clases obtienen datos de la clase DATA que se encuentra en el paquete, la cual contiene elementos de configuración para el proyecto, como lo son rutas físicas para los elementos que se necesitan, variables globales de control de extensibilidad, etc. En la figura 3.15 se muestra el diagrama de paquetes del proyecto.

Figura 3.15 Diagrama de clases del proyecto Rojas, Christian

44

Análisis y diseño En la figura 3.16 se muestra el diagrama de clases del paquete mx.edu.cenidet.userontology.axiomsInference class mx.edu.cenidet.userontology.axiomsInference

LoadAyudaTecnicaData

Stor e + + +

InsertIndividualObjects(String, String, HashMap, HashMap) : void InsertIndividualProperties(String, String, HashMap, HashMap) : void ontocomm() : String

-

persona: person = new person()

+

LoadAyudaTecnicaData(AyudaTecnica)

LoadEstudioData LoadPersonalesData LoadMiembrosData -

persona: person = new person()

+

LoadMiembrosData(Miembros)

-

persona: person = new person()

+

LoadPersonalesDat a(Personales, Seguridad)

-

persona: person = new person()

+

LoadEstudioData(Est udio)

Tupla

#tupla

LoadDireccionData -

~ ~

type: URI value: String

~

Tupla(URI, String)

persona: person = new person() -persona

+

-persona-persona -persona LoadEnfermedadesData

LoadDireccionData(Direccion) -persona

RelationAll -

persona: person = new person()

+

RelationAll(Personales)

person

# # -persona # # #

attributes: HashMap = new HashMap