Centro Nacional de Investigación y Desarrollo Tecnológico
Departamento de Ciencias Computacionales
TESIS DE MAESTRÍA EN CIENCIAS
Sistema de Recomendación Contextual Basado en Ontologías para Ambientes Organizacionales y de Usuario en Entornos de Cómputo Móvil
presentada por
Nimrod González Franco Ing. en Sistemas Computacionales por el I. T. de Zacatepec
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
Co-Director de tesis:
Dra. Azucena Montes Rendón
Jurado:
Dra. Alicia Martínez Rebollar – Presidente M.C. Rocío Vargas Arroyo – Secretario
Dr. Juan Gabriel González Serna – Vocal
Cuernavaca, Morelos, México. 28 de febrero de 2012
DEDICATORIAS
A mis padres, por todo lo que han hecho por mí.
A mi hermana y hermano.
A aquellos que habrán de formar parte de mi vida
Al lector, como agradecimiento por tomarse el tiempo de leer estas palabras.
AGRADECIMIENTOS
A MPC, por las bendiciones que no puedo medir y por los dones que no puedo
evaluar. Por a aquellos que me rodean y que tanto aportan a mi vida.
A mis padres, Martha y Porfirio. Por ser padres un ejemplo de vida, por su
cuidado, su sacrificio y el esforzarse cada día. Por haber dado tanto de sí mismos,
para que pudiese disfrutar de tantas cosas. Un agradecimiento eterno por su
amor, sus enseñanzas y el apoyo que desde siempre me brindaron, que se que
siempre tendré y que es para mí la herencia más valiosa que pidiera recibir.
A mis hermanos, Maho y Aby, por el cariño y apoyo que siempre he recibido de
ustedes, esperando que comprendan que si he de tener algún logro, es también
suyo e inspirado en ustedes.
A mi director de tesis, Dr. Juan Gabriel González Serna, por brindarme su apoyo,
por su confianza, por ser un amigo y por ser una gran influencia profesional.
A los miembros del grupo de investigación CARS, por fomentar el intercambio de
ideas debido al trabajo en equipo, por ay darme a adquirir nuevos conocimientos y
profundizar en lo aprendido anteriormente, por considerar a cada integrante del
grupo como una parte importante que debe ser valorada y por mantener un
ambiente de alegría aún en los momentos de pánico.
A los profesores que conocí como alumno de CENIDET, por sus enseñanzas y
sobre todo, por su consideración de la ética en la investigación y de la
responsabilidad social. Por los días en los que no pude evitar pensar "hoy he
aprendido algo".
Al Centro Nacional de Investigación y Desarrollo Tecnológico, que me permitió
vivir apreciadas y tensas experiencias, ser parte de la institución y crecer en tantos
aspectos.
Al Dr. Oscar Corcho, por su guía, comprensión y apoyo durante la estancia de
investigación.
A los miembros del Ontology Engineering Group (OEG), por su ayuda durante una
experiencia muy intensa, en la que aprendí mucho de la convivencia, aunque
breve, con los miembros del grupo. Realmente, tener la posibilidad de
experimentar diferentes maneras de pensar y de vivir la profesión de investigador
es algo que hoy en día recuerdo con alegría, de tal forma que para mí, el
levantarme cada día por la mañana y tener un ambiente de trabajo tan
multicultural y ameno, ya era una experiencia positiva.
Al personal de la Universidad Politécnica de Madrid (UPM), por ser un apoyo muy
importante durante toda la duración de la estancia.
A Roció, Rafa, la Dra. Blanca y Hugo, por rescatarme en los momentos de
desesperación semánticos y otros momentos de pánico, por su sencillez y su
capacidad para transmitir conocimiento.
A Paty, Jaime, Everardo, Eliel, Sabo, Emma, Kaliz y resto de kushules, por todos
los momentos divertidos que pasamos juntos y el apoyo en los no tan divertidos.
A los residentes y veraniegos: Gio, Paco, Oscar, Chucho y Sadher, por sus
esfuerzos y contribuciones, sin las cuales este trabajo de tesis no estaría
terminado.
A mis revisores, por su atención, aportaciones y amistad.
A todos aquellos que me brindaron su amistad en este tiempo.
A todos ustedes, mil gracias.
RESUMEN
Dentro del dominio de los Sistemas de Recomendación Semánticos Conscientes
del Contexto (SRSCC) diseñados para organizaciones, existen trabajos que
ofrecen a los usuarios recomendaciones sobre distintos tipos de elementos
relacionados a la organización, manejando procesos de inferencia sobre
ontologías que modelan el contexto y las características de los usuarios, sin
embargo, la mayoría de estos sistemas tienen un dominio de recomendación
centrado en solo una parte de la organización, como la recomendación de
personas, la recomendación de documentos, la recomendación de eventos y la
recomendación de servicios, por ejemplo.
Esta tesis presenta un conjunto de conceptos, técnicas y metodologías aplicables
al desarrollo de SRSCC organizacionales, por lo que, con la finalidad de demostrar
la validez de esos elementos, se utilizaron en el desarrollo de un SRSCC llamado
T-Guía, el cual tiene el objetivo de ofrecer a los visitantes recomendaciones sobre
personas, objetos de conocimiento, lugares, actividades, eventos, recursos
tecnológicos y servicios -basados en competencias organizacionales- que resulten
interesantes para ellos.
Además, centrándose en el proceso de recomendación, se aplicó un conjunto de
pruebas sobre el motor de inferencia del SRSCC T-Guía, con el propósito de
verificar la forma en que los conjuntos de recomendaciones inferidos son
afectados por cambios en los factores contextuales y en las características de los
usuarios.
Finalmente, en calidad de trabajos futuros, se proponen actividades para
complementar y mejorar algunos de los conceptos propuestos en esta tesis.
ABSTRACT
In the semantic context-aware recommender systems domain there are works that
offer to the user recommendations about different types of elements related to an
organizational environment. These approaches use inference processes on
ontologies that model context and user characteristics. However, most of the
systems are centered on a single aspect of the organization such as expert people,
documents, events and services.
This thesis presents a set of concepts, techniques and methodologies applicable to
the development of Ontology Based Context-aware Recommender Systems
(OBCaRS).In order to demonstrate their validity, they are used in the development
of an OBCaRS. The specific developed OBCaRS is called T-Guía, which focuses
on offering recommendations to visitors about people, knowledge objects, places,
activities, events, technological resources and services based on organizational
competences relevant for the user.
Also, focusing on the recommendation process, a set of tests were applied to the
inference engine of the OBCaRS T-Guía, to verify how the set of recommendations
obtained is affected by changes in contextual factors and in the characteristics of
users.
Finally, as future works, some activities to complement and improve some of the
presented concepts are mentioned.
i
TABLA DE CONTENIDO
Tabla de Contenido...................................................................................................i
Lista de Figuras........................................................................................................v
Lista de Tablas........................................................................................................ix
Lista de Gráficas.......................................................................................................x
Capítulo 1 Introducción
1.1 Introducción ..................................................................................................... 2
1.2 Antecedentes ................................................................................................... 3
1.2.1 T-Guide [Arjona, 2009] .............................................................................. 3
1.2.2 Generador semiautomático de perfiles de usuario mediante OWL [Rojas,
2009] .................................................................................................................. 4
1.2.3 Modelo colaborativo para la integración de sistemas [Vargas, 2011] ......... 5
1.3 Descripción del problema ................................................................................. 5
1.4 Objetivo ............................................................................................................ 7
1.5 Justificación y beneficios .................................................................................. 8
1.6 Organización del documento ............................................................................ 9
Capítulo 2 Marco Teórico
2.1 Sistema de recomendación semántico adaptable al contexto ........................ 11
2.2 Ontología de contexto multidimensional ......................................................... 11
2.3 Clasificaciones de sistemas de recomendación ............................................. 12
2.4 Algoritmos de recomendación contextual ....................................................... 12
ii
2.4.1 Técnicas de filtrado basado en contenidos .............................................. 12
2.4.2 Técnicas de filtrado colaborativo.............................................................. 13
2.4.3 Técnicas de filtrado híbrido ...................................................................... 14
2.5 SWRL ............................................................................................................ 15
Capítulo 3 Estado del Arte
3.1 Categorización de trabajos ............................................................................. 18
3.2 Propuesta de Bouzeghoub ............................................................................. 18
3.3 Proyecto mIO! ................................................................................................ 20
3.4 Proyecto ICAS ............................................................................................... 21
3.5 Proyecto SeMoDesk ...................................................................................... 24
3.6 Propuesta de Rasanen .................................................................................. 25
3.7 SMARTMUSEUM ........................................................................................... 26
3.8 El proyecto MyMose. ...................................................................................... 29
3.9 Proyecto SEEMP ........................................................................................... 32
3.10 Estudio comparativo ..................................................................................... 35
Capítulo 4 Definición de una arquitectura genérica para un SRSCC
organizacional
4.1 Introducción ................................................................................................... 38
4.2 Descripción de la arquitectura generica para un SRSCC organizacional ....... 38
4.3 Descripción de los módulos principales de la arquitectura ............................. 43
4.3.1 Repositorio de recursos ontológicos y la Ontología de Memoria
Organizacional 1.0 ............................................................................................ 43
iii
4.3.2 Módulo Motor de Inferencia y reglas de inferencia ................................... 49
4.3.3 Definición de una GUI adaptable con mecanismos de monitoreo ............ 51
4.3.4 Módulo de identificación de comportamiento de usuarios y análisis del
funcionamiento de un SRSCC .......................................................................... 54
4.4 Utilización de la arquitectura propuesta para un SRSCC organizacional ........ 56
Capítulo 5 Desarrollo del SRSCC organizacional T-Guía
5.1 Introducción y características de implementación .......................................... 59
5.2 Reutilización de la Ontologia de Memoria Organizacional 1.0 ........................ 63
5.2.1 Poblado de la Organizational Memory Ontology implementada y la
aplicación web Semantic T-Guide .................................................................... 67
5.2.1.1 Instanciación de los catálogos seleccionados: uso de la librería NOR2O .....................67
5.2.1.2 Instanciación de elementos organizacionales: Sistema de Administración de
Información Académica SAIA y método para la transformación de sitios de IES a la web 3.0 .69
5.2.1.3 Registro de los usuarios del T-Guía: Semantic T-Guide ...............................................73
5.3 Implementación del Motor de Inferencia ......................................................... 75
5.3.1 Módulo de pre-filtrado de ítems ............................................................... 79
5.3.2 Módulo de extracción de instancias asociadas a una organización ......... 81
5.3.3 Módulo generador de recomendaciones .................................................. 82
5.3.4 Módulo para la actualización de conjuntos de ítems pre-filtrados ............ 85
5.4 Análisis y diseño de la interfaz adaptable para el cliente del SRSCC
organizacional T-Guía: Mobile T-Guide ................................................................ 86
5.5 Implementación una aplicación para el análisis del funcionamiento del T-Guía y
del comportamiento de sus usuarios: T-Guide Admin .......................................... 97
iv
Capítulo 6 Pruebas y caso de estudio
6.1 Introducción ................................................................................................. 102
6.1.1 Características a ser probadas .............................................................. 103
6.1.2 Características excluidas de las pruebas ............................................... 103
6.1.3 Enfoque ................................................................................................. 103
6.1.4 Requisitos ambientales .......................................................................... 104
6.1.5 Instancias de los conjuntos U e I usadas durante la ejecución de la fase de
pruebas .......................................................................................................... 105
6.2 Caso de estudio ........................................................................................... 107
6.3 Pruebas ....................................................................................................... 118
6.3.1 Evaluación experimental ........................................................................ 118
6.3.1.1 Caso de prueba 1. Análisis de la recomendación de ítems considerando variaciones
temporales en el proceso de inferencia .................................................................................. 118
6.3.1.2 Caso de prueba 2. Análisis de la recomendación de ítems de acuerdo al tipo de
usuario del Usuario Activo....................................................................................................... 125
6.4 Comportamiento del SRSCC organizacional T-Guía observado durante la fase
de pruebas ......................................................................................................... 138
Capítulo 7 Conclusiones
7.1 Conclusiones ............................................................................................... 141
7.2 Aportaciones ................................................................................................ 143
7.3 Trabajos futuros ........................................................................................... 144
Anexo A: Reglas de inferencia ........................................................................... 146
A.I Conjunto de reglas de inferencia ReglasIES ............................................. 146
v
A.II Conjunto de reglas de inferencia ReglasGobierno ................................... 150
A.III Conjunto de reglas de inferencia ReglasEmpresa ................................... 155
A.III Conjunto de reglas de inferencia ReglasEvento ...................................... 160
Referencias……………………………………………………………………………..164
vi
LISTA DE FIGURAS
Figura 1.1: Clases de la ontología de usuarios del Generador semiautomático de perfiles de
usuario mediante OWL………………………………………………………………………………………………………4
Figura 3.1: Red de ontologías mIO! …………………………………………………………………………………21
Figura 3.2: Modelo SeCoM………………………………………………………….…………………………………..22
Figura 3.3: Niveles del modelo contextual……………………………………………………………………….30
Figura 3.4: Arquitectura de MyMose……………………………………………………………………………….32
Figura 3.5: Relaciones principales de la SEEMP Reference Ontology………………….……………34
Figura 4.1: Caso de uso del comportamiento de un SRSCC organizacional típico…………….39
Figura 4.2: Caso de uso de la generación de recomendaciones en un SRSCC organizacional
típico……………………………………………………………………………………………………………………………….39
Figura 4.3: Arquitectura genérica de un SRSCC organizacional………………….…………………….40
Figura 4.4: Ontología de Memoria Organizacional versión 1.0………………….…………………….44
Figura 4.5: Caso de uso del comportamiento del Motor de Inferencia de un SRSCC
organizacional implementado para diversos tipos de organizaciones………………….………….50
Figura 4.6: Etapas del proceso de inferencia planteado para el Motor de Inferencia del
SRSCC organizacional T-Guía………………….…………………………….…………………………….……………51
Figura 5.1: Vista estática de los módulos del SRSCC organizacional T-Guía………………….…..59
Figura 5.2: Vista funcional de los elementos del SRSCC organizacional T-Guía…………………62
Figura 5.3: Contenido del modelo ontológico reducido………………….………………………………..63
Figura 5.4:Implementación de la Organizational Memory Ontology usando el editor
Protégé 3.4………………….…………………………….…………………………….……………………………………..64
Figura 5.5: Ventana principal de la página de documentación de la Organizational Memory
Ontology………………….…………………………….………………………………………………………………….…...65
Figura 5.6: Proceso para la instanciación de catálogos ……………………………………………..…….69
Figura 5.7: Proceso para la instanciación de elementos organizacionales………………………..72
Figura 5.8: Proceso para la instanciación de usuarios del T-Guía…………………………………….73
Figura 5.9: Formulario para la creación de una cuenta del T-Guía…………………………………..74
Figura 5.10: Formularios para la captura de los datos de contacto de un usuario de la
organización a la que pertenece………………….…………………………….……………………………………74
Figura 5.11: Módulos del Motor de Inferencia del sistema T-Guía…………………………………..77
Figura 5.12: Entradas y salida de la clase SWRL4U.java……………………………………………………78
Figura 5.13: Entradas y salida de la clase SPARQL4U.java………………….…………………………….78
Figura 5.14: Submódulo de pre-filtrado de ítems…………….…………………………….………………..81
Figura 5.15: Submódulo de extracción de instancias asociadas a una organización…………82
vii
Figura 5.16: Submódulo generador de recomendaciones………………….…………………………….84
Figura 5.17: Contenido del archivo de ejemplo nimrod.xml generado con el Módulo
generador de recomendaciones………………….…………………………….…………………………….………84
Figura 5.18: Submódulo para la actualización de conjuntos de ítems pre-filtrados…………86
Figura 5.19: Diagrama de casos de uso para la GUI adaptable del cliente del SRSCC
organizacional T-Guía………………….…………………………….…………………………….………………………87
Figura 5.20: Diagrama de casos de uso para organizar las recomendaciones en el cliente
móvil del SRSCC organizacional T-Guía………………….…………………………….…………………………..87
Figura 5.21: Diagrama de casos de uso para la interacción de los usuarios con las
recomendaciones mediante el cliente móvil del SRSCC organizacional T-Guía………………..88
Figura 5.22: Diagrama de casos de uso para registrar la interacción de los usuarios con las
recomendaciones mediante el cliente móvil del SRSCC organizacional T-Guía………………..88
Figura 5.23: Pantalla de bienvenida del Mobile T-Guide………………………………………………….89
Figura 5.24: GUI estándar del cliente del SRSCC organizacional T-Guía……………………………90
Figura 5.25: Adaptación de la GUI del cliente del SRSCC organizacional T-Guía……………..91
Figura 5.26: Estrategia de calificación manual implementada en el SRSCC organizacional T-
Guía………………….…………………………….…………………………….………………………………………………..93
Figura 5.27: Diseño de la base de datos para el cliente móvil del SRSCC organizacional T-
Guía………………….…………………………….…………………………….………………………………………………..94
Figura 5.28: Visualización de recomendaciones de personas para un usuario del tipo
Estudiante………………….…………………………….…………………………….……………………………………….94
Figura 5.29: Visualización de la información detallada de una recomendación………………..95
Figura 5.30: Visualización de recomendaciones de lugares para un usuario del tipo
Profesor Investigador………………….…………………………….…………………………….………………………95
Figura 5.31: Visualización de recomendaciones de proyectos para un usuario del tipo
Empresario………………….…………………………….…………………………….……………………………………96
Figura 5.32: Ejemplo del archivo tguia_valoradas.xml………………….…………………………….….96
Figura 5.33: Caso de uso de una aplicación para la implementación del Módulo de
identificación de comportamiento de usuarios……………………………………………………………..97
Figura 5.34: Diseño de la base de datos implementada para el SRSCC T-Guía……………...98
Figura 5.35: Caso de uso para el almacenamiento de información sobre el funcionamiento
del sistema en una aplicación para la implementación del Módulo de identificación de
comportamiento de usuarios………………….…………………………….…………………………….………..98
Figura 5.36: Pantalla de bienvenida del T-Guide Admin…………………………………………………99
Figura 5.37: Capturas de los reportes generados con el T-Guide Admin………………………..100
Figura 6.1: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario
UsuarioProfesor2 según las variaciones temporales en el Escenario 1 ............................. 112
viii
Figura 6.2: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario
UsuarioProfesor2 según las variaciones temporales en el Escenario 2 ............................. 113
Figura 6.3: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario
UsuarioProfesor2 según las variaciones temporales en el Escenario 3 ............................. 114
Figura 6.4: Diferencia en las recomendaciones de tipo Persona ....................................... 115
Figura 6.5: Despliegue de datos asociados al ítem ............................................................ 116
Figura 6.6: Visualización de las recomendaciones de tipo Lugar, Recurso y Competencia
ofrecidas al usuario UsuarioProfesor2 ............................................................................... 116
Figura 6.7: Visualización de las recomendaciones de tipo Objeto de Conocimiento y
Actividades para el usuario UsiarioProfesor2 .................................................................... 117
Figura 6.8: Cierre de la sesión del usuario UsuarioProfesor2 en la GUI adaptable ........... 117
Figura 6.9: Diferencias entre los ítems de tipo Competencias recomendados al usuario
UsuarioMuestra1 ................................................................................................................ 126
Figura 6.10: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de
Profesor para el atributo userType ..................................................................................... 127
Figura 6.11: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de
Estudiante para el atributo userType ................................................................................. 128
Figura 6.12: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de
Empresario para el atributo userType ................................................................................ 129
Figura 6.13: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de
Profesor para el atributo userType .................................................................................... 132
Figura 6.14: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de
Estudiante para el atributo userType ................................................................................. 133
Figura 6.15: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de
Empresario para el atributo userType ................................................................................ 134
Figura 6.16: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de
Profesor para el atributo userType .................................................................................... 135
Figura 6.17: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de
Estudiante para el atributo userType ................................................................................. 136
Figura 6.18: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de
Empresario para el atributo userType ................................................................................ 137
Figura 6.1: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario
UsuarioProfesor2 según las variaciones temporales en el Escenario 1 ............................. 112
Figura 6.2: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario
UsuarioProfesor2 según las variaciones temporales en el Escenario 2 ............................. 113
Figura 6.3: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario
UsuarioProfesor2 según las variaciones temporales en el Escenario 3 ............................. 114
ix
Figura 6.4: Diferencia en las recomendaciones de tipo Persona ....................................... 115
Figura 6.5: Despliegue de datos asociados al ítem ............................................................ 116
Figura 6.6: Visualización de las recomendaciones de tipo Lugar, Recurso y Competencia
ofrecidas al usuario UsuarioProfesor2 ............................................................................... 116
Figura 6.7: Visualización de las recomendaciones de tipo Objeto de Conocimiento y
Actividades para el usuario UsiarioProfesor2 .................................................................... 117
Figura 6.8: Cierre de la sesión del usuario UsuarioProfesor2 en la GUI adaptable ........... 117
Figura 6.9: Diferencias entre los ítems de tipo Competencias recomendados al usuario
UsuarioMuestra1 ................................................................................................................ 126
Figura 6.10: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de
Profesor para el atributo userType ..................................................................................... 127
Figura 6.11: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de
Estudiante para el atributo userType ................................................................................. 128
Figura 6.12: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de
Empresario para el atributo userType ................................................................................ 129
Figura 6.13: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de
Profesor para el atributo userType .................................................................................... 132
Figura 6.14: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de
Estudiante para el atributo userType ................................................................................. 133
Figura 6.15: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de
Empresario para el atributo userType ................................................................................ 134
Figura 6.16: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de
Profesor para el atributo userType .................................................................................... 135
Figura 6.17: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de
Estudiante para el atributo userType ................................................................................. 136
Figura 6.18: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de
Empresario para el atributo userType ................................................................................ 137
x
LISTA DE TABLAS
Tabla 3.1: Comparativa de los trabajos relacionados con el proyecto de tesis ............ ¡Error!
Marcador no definido.
Tabla 5.1: Ontologías importadas en implementación de la Organizational Memory
Ontology .................................................................................. ¡Error! Marcador no definido.
Tabla 6.1: Resumen de los elementos del conjunto I usado en la fase de pruebas .......... 105
Tabla 6.2: Instanciación del conjunto I usado en la fase de pruebas ...... ¡Error! Marcador no
definido.
Tabla 6.3: Instanciación de los datos del usuario UsuarioProfesor2 ....... ¡Error! Marcador no
definido.
Tabla 6.4: Elementos del subconjunto 𝑰𝒖𝒂 para el usuario UsuarioProfesor2 ........... ¡Error!
Marcador no definido.
Tabla 6.5: Elementos del subconjunto 𝑰´𝒖𝒂 para el usuario UsuarioProfesor2 ........... ¡Error!
Marcador no definido.
Tabla 6.6: Variaciones contextuales en el caso de uso del usuario UsuarioProfesor2 . ¡Error!
Marcador no definido.
Tabla 6.7: Elementos del conjunto 𝑹𝒖𝒂 para el usuario UsuarioProfesor2 ¡Error! Marcador
no definido.
Tabla 6.8: Casos de prueba ...................................................... ¡Error! Marcador no definido.
Tabla 6.9: Escenarios para la Prueba 1 .................................... ¡Error! Marcador no definido.
Tabla 6.10: Promedios de los tiempos de ejecución y las recomendaciones inferidas ¡Error!
Marcador no definido.
Tabla 6.11: Cantidad de ítems recomendados por categoría, por tipo de usuario y por
escenario.................................................................................. ¡Error! Marcador no definido.
Tabla 6.12: Recomendaciones para el UsuarioMuestra1 de acuerdo al atributo userType
................................................................................................. ¡Error! Marcador no definido.
Tabla 6.13: Hipótesis probadas en cada caso. ......................... ¡Error! Marcador no definido.
Tabla 6.14: Recomendaciones para el UsuarioMuestra2 de acuerdo al atributo userType
................................................................................................. ¡Error! Marcador no definido.
Tabla 6.15: Recomendaciones para el UsuarioMuestra3 de acuerdo al atributo userType
................................................................................................. ¡Error! Marcador no definido.
xi
LISTA DE GRÁFICAS
Gráfica 6.1: Variaciones en el tiempo total de ejecución medido en milisegundos bajo tres
combinaciones diferentes de variables temporales. ......................................................... 121
Gráfica 6.2: Variaciones en la cantidad de recomendaciones inferidas bajo tres
combinaciones diferentes de variables temporales .......................................................... 121
Gráfica 6.3: Variaciones en el tiempo total de ejecución del Módulo generador de
recomendaciones medido en milisegundos bajo tres combinaciones diferentes de
variables temporales. ......................................................................................................... 122
Gráfica 6.4: Frecuencia de repetición de los ítems de acuerdo a los tres escenarios
definidos ............................................................................................................................. 123
Gráfica 6.5: Frecuencia de repetición porcentual de un ítem de acuerdo a los tipos de
usuario ................................................................................................................................ 124
1
CAPÍTULO 1 INTRODUCCIÓN
En este capítulo se explica el contexto del trabajo de tesis desarrollado, el
problema a abordar, el objetivo y los alcances del mismo, además de la
organización en general del documento.
2
1.1 Introducción
En años recientes, ha crecido la tendencia hacia el desarrollo de aplicaciones que
buscan ofrecer a los usuarios altos niveles de comodidad, de tal forma que en la
actualidad se pone gran interés en capturar la información del entorno en el que el
usuario se desenvuelve [Sadeh, 2006]. Es por esto que los Sistemas de
Recomendación Conscientes del Contexto (SRCC) han adquirido una enorme
importancia en las áreas de investigación y desarrollo vigentes hoy en día.
Los SRCC filtran información para presentar al usuario aquella que resulte de su
interés, utilizando para ello el perfil del usuario y su contexto. Cuando la
información sobre la que opera el SRCC está descrita en ontologías se le llama
Sistema de Recomendación Semántico Consciente del Contexto (en adelante,
SRSCC). En un SRSCC pueden usarse reglas de inferencia para realizar el
proceso de filtrado.
De acuerdo a los enfoques actuales, el contexto es cualquier información que
pueda ser usada para caracterizar la situación de una entidad, donde una entidad
puede ser una persona, lugar u objeto físico o computacional, por lo que puede
verse como un espacio multidimensional donde cada dimensión es representada
por una ontología especifica [Bouzeghoub, 2009].
Bajo esta idea, los datos del contexto pueden incluir diversos aspectos, tales
como: dispositivo de usuario, red de acceso, ubicación espacial, ubicación
temporal, situación del usuario, patrones de comportamiento, consideraciones
sociales, entre otros. En cuanto al perfil del usuario se incluyen características que
describen aspectos económicos, de ocupación, sus preferencias, gustos y otros
grupos de datos que sean necesarios para el correcto funcionamiento del sistema.
Para modelar el contexto como un espacio multidimensional puede implementarse
una red de ontologías, en la que se utilizan ontologías específicas relacionadas
entre sí de acuerdo a las dimensiones requeridas, formando un conjunto que
adquiere el nombre de ontología de contexto multidimensional. Mientras más
dimensiones se consideran, el SRSCC tiene una mayor variedad de información a
considerar en su proceso de inferencia, pudiendo generar recomendaciones cada
vez más adecuadas.
Un SRSCC implementado en una organización pode recomendarle a un usuario,
por ejemplo, personas, instalaciones, libros, servicios, trámites y cualquier
información que sea afín a sus intereses.
3
En este trabajo de tesis se presenta un SRSCC que utiliza diversas ontologías
desarrolladas a partir de estándares internacionales, las cuales se interconectan
para modelar un gran número de dimensiones contextuales relacionadas con
ambientes organizacionales. Dichas dimensiones consideran múltiples dominios
de conocimiento, como la contabilidad y las ciencias de la computación, el
modelado de comercio electrónico, el manejo de recursos humanos y la
administración empresarial.
El conjunto final de ontologías que permite modelar información de Instituciones
de Educación Superior (IES), empresas y dependencias de gobierno, además,
mediante el uso de reglas de inferencia, es posible identificar varios atributos de
estas organizaciones, como son servicios, objetos de conocimiento, personas y
productos que pueden ser de interés para un usuario.
1.2 Antecedentes
La Web Semántica y los servicios de recomendación contextual semánticos son
dos de los temas que más atención han recibido en los últimos años en el
CENIDET, resaltando la relevancia que han adquirido específicamente en la línea
de investigación de Sistemas Distribuidos, dentro de la cual se han realizado
diversos trabajos relacionados con la creación y uso de ontologías, además del
desarrollo de servicios de recomendación para ambientes organizacionales.
Debido a esto, varios trabajos, incluidos algunos que aún se encuentran en
desarrollo al momento de redactar este documento de tesis, impactan de manera
importante en la investigación realizada, por lo que se describen en las secciones
siguientes.
1.2.1 T-Guide [Arjona, 2009]
Este trabajo desarrolla servicios conscientes del contexto para la localización de
personas mediante tecnologías de posicionamiento heterogéneas. Estos servicios
permiten a un usuario realizar las actividades que tiene programadas en su
agenda personal, las cuales están relacionadas con una ubicación específica, es
decir, se define una relación espacio-tiempo.
4
En este proyecto se utilizan tecnologías de auto-identificación, como RFID y
QRCode, además de teléfonos celulares para la localización de usuarios, los
cuales se pueden encontrar dentro de edificios multinivel y en áreas tipo campus,
es decir con varios edificios.
El sistema desarrollado en este trabajo de investigación consta de 3 aplicaciones:
el cliente montado en el dispositivo celular, el servidor que atiende las peticiones
del cliente y la aplicación Web que gestiona la información de tareas, ubicaciones,
usuarios y recursos.
1.2.2 Generador semiautomático de perfiles de usuario mediante
OWL [Rojas, 2009]
Este trabajo de investigación define una ontología que permite modelar a un
usuario, así como sus costumbres, roles cotidianos y características. Esta
ontología es poblada mediante una interfaz gráfica de un ambiente de desarrollo
para poder instanciarla y explotarla. La ontología comprende el conjunto de todas
las clases mostradas en la Figura 1.1.
Figura 1.1: Clases de la ontología de usuarios del Generador semiautomático de perfiles de usuario mediante OWL
5
1.2.3 Modelo colaborativo para la integración de sistemas
[Vargas, 2011]
Dentro de este trabajo de investigación, aun en desarrollo, se realiza el modelado
organizacional semántico para caracterizar competencias organizacionales,
competencias individuales, objetos de conocimiento, infraestructura y servicios. El
modelo contempla la definición de un perfil organizacional formado por los
atributos generales, los atributos financieros y las competencias de una
organización, la descripción de su capital intelectual a partir del capital humano, el
capital estructural y el capital relacional, y la definición de un perfil individual
dependiente del dominio de conocimiento para caracterizar competencias
individuales de los miembros de la organización.
De manera adicional, se busca el desarrollo de servicios de recomendación para
la conformación de grupos de trabajo sinérgicos basado en modelos semánticos
de competencias, tanto organizacionales como individuales.
1.3 Descripción del problema
En la actualidad, es habitual el desarrollo de sistemas de información que buscan
proporcionar al usuario altos niveles de comodidad y facilidad de uso,
proporcionando toda la información necesaria justo en el momento para apoyar el
proceso de toma de decisión, estos sistemas requieren información de la
ubicación del usuario [Sadeh, 2006]; esto se logra mediante servicios de
información contextuales que explotan el perfil del usuario y los datos de su
ubicación actual. Algunas de estas aplicaciones son los sistemas de
recomendación sensibles al contexto y existen algunos de ellos que poseen
características semánticas, a los que se les denomina Sistema de Recomendación
Semántico Consciente del Contexto (SRSCC).
Los SRSCC consideran el contexto de un usuario analizando diferentes factores,
y en base a ello, adaptan las recomendaciones de modo que satisfagan los
intereses del usuario. Adicionalmente, algunos SRSCC recurren al uso de las
ontologías para generar ―descripciones semánticas de servicios, lo cual facilita a
los agentes software su descubrimiento‖ [Peis, 2008].
6
Hoy en día los SRSCC consideran como información de contexto diversos
aspectos, tales como las características del dispositivo móvil de un usuario, los
servicios de conexión disponibles en el lugar que permitan acceder a una red de
área local, la ubicación espacial de personas y objetos, además de la ubicación
temporal, situación del usuario, patrones de comportamiento y consideraciones
sociales.
Esto implica que los SRSCC deben ser capaces de ubicar a un usuario e
identificar sus requerimientos o necesidades no explicitas, con la intención de
ofrecerle al usuario recomendaciones eficientes en la satisfacción de sus
necesidades.
Para que los SRSCC que se implementan actualmente en organizaciones infieran
las necesidades de un usuario, los edificios deben contar con mecanismos que
permitan monitorear su entorno, identificando personas, objetos y lugares
(instalaciones) propias de la organización o evento.
Sin embargo, en el diseño de SRSCC para organizaciones, normalmente no se
consideran aspectos relacionados con los servicios proporcionados al usuario y
los objetos de conocimiento asociados a las personas que pertenecen a una
organización.
Al no considerar estos elementos, se descuidan aspectos importantes relativos a
la naturaleza de la organización, haciendo que las recomendaciones no sean tan
precisas como deberían serlo.
Para desarrollar un SRSCC que considere los servicios ofrecidos por una
organización y los objetos de conocimiento asociados a ésta, se requiere de una
máquina de inferencia que opere con un conjunto de reglas definidas para
dominios específicos, es decir, reglas agrupadas según el tipo de organización en
la que se implemente el sistema.
En este trabajo de investigación se pretende desarrollar un mecanismo que
permita procesar reglas de inferencia para, asociar personas, actividades,
capacidades, objetos de conocimiento, instalaciones, localización geoespacial y
ubicación temporal, de manera que se infieran recomendaciones para un usuario,
extrayendo sus atributos de una ontología de perfiles, para asociarlos a los
conceptos de una ontología de dominio, de tal manera que sea posible identificar
los servicios que sean de su interés.
Utilizando este tipo de asociación en un SRSCC para una IES, se podrá, por
ejemplo, recomendar objetos de conocimiento a los usuarios que ingresen, tales
como: tesis, artículos técnicos, libros, prototipos de software, también se pueden
7
recomendar equipo de laboratorio especializado y personas; todas estas
recomendaciones dependen de las áreas de interés que define el usuario en su
perfil y que mediante modelos semánticos se pueden inferir.
De manera similar, si un usuario ingresa a un edificio de gobierno, el SRSCC
debe recomendar, por ejemplo: lugar para realizar ciertos trámites, pago de
servicios, las personas responsables de estos servicios o formatos requeridos
para realizar trámites. Otro escenario puede presentarse en un congreso, en
donde se identifica de manera automática al usuario y se le hacen
recomendaciones de conferencias relacionadas con su área de interés para
planificar el horario de las mismas, en este mismo escenario se puede conformar
también redes académicas identificando a conferencistas o asistentes al congreso
con quienes comparte área de conocimiento o líneas de investigación comunes.
1.4 Objetivo
Esta tesis es realizada con el objetivo de desarrollar servicios de recomendación
contextuales para usuarios móviles de un SRSCC organizacional, mediante la
explotación de ontologías organizacionales y ontologías de perfil de usuario, para
inferir recomendaciones de servicios, personas, lugares y objetos asociados a una
organización.
Las recomendaciones ofrecidas son visualizadas mediante el dispositivo móvil de
un usuario, aplicando técnicas avanzadas de interacción basadas en texto y
utilizando el potencial de los dispositivos móviles de última generación.
Para el cumplimiento del objetivo general, se manejan los objetivos específicos
que se describen a continuación:
Crear un conjunto de reglas de inferencia basadas en el perfil del usuario y
el contexto de organizaciones.
Diseñar e implementar en un dispositivo móvil un módulo para explotar las
recomendaciones de la máquina de inferencia.
Diseñar e implementar una interfaz de usuario en el dispositivo móvil para
mostrar las recomendaciones además de las técnicas para poder
interactuar con éstas.
Diseñar e implementar una red de ontologías multidimensional que
represente dimensiones de un ambiente organizacional.
8
1.5 Justificación y beneficios
Refiriéndose a ambientes organizacionales, a pesar del coste que representa
reestructurar la información existente para adaptarla a un modelo semántico, el
uso de un SRSCC en una organización en vez de uno tradicional permite
incorporar relaciones y contenido semántico a dicha información, lo cual se refleja
en la aplicación de procesos de inferencia en base a su significado. Para ello, se
necesita un conjunto de reglas de inferencia adecuadas para dicha organización,
además de un conjunto de ontologías apropiado para describir sus servicios
ofrecidos, las preferencias de sus usuarios y su contexto.
Actualmente, para realizar el proceso de inferencia, la mayoría de SRSCC para
organizaciones no considera objetos de conocimiento, ni las capacidades
tecnológicas y científicas de las personas que laboran en ella, específicamente en
las IES. Al considerar objetos de conocimiento y capacidades en un SRSCC, es
posible incrementar la eficiencia de las recomendaciones que se infieren en un
ambiente organizacional.
Este trabajo de tesis desarrolla un conjunto de reglas que operan sobre el perfil
de los usuarios y el contexto de diferentes tipos de instituciones, con el fin de
incrementar los alcances de los SRSCC para ambientes organizacionales.
Con el desarrollo de este tipo de SRSCC se obtienen los siguientes beneficios:
Se tiene un conjunto de reglas de inferencia que consideran la información
que describe a una organización y las preferencias de un usuario, que se
pueden reutilizar en trabajos futuros.
Se identificaron subconjuntos de reglas específicos para cada tipo de
organización, por lo cual es posible implementar sólo aquellos subconjuntos
que sean apropiados al tipo de institución para el que se desarrolle un
SRSCC.
La información contenida en las ontologías organizacionales considera
objetos de conocimiento y competencias individuales.
Se tiene un servicio de recomendación adaptable a diversos tipos de
organizaciones, el cual es capaz de ofrecer distintos resultados
considerando el entorno en el que se desenvuelve un usuario.
Las funciones del cliente del sistema de recomendación se pueden colocar
en diversos dispositivos móviles.
El trabajo realizado permite que otros desarrolladores hagan uso de una o
más funciones que requieran en futuras investigaciones.
9
1.6 Organización del documento
Este documento de tesis se encuentra organizado en siete capítulos, los cuales
describen el trabajo de investigación en sus diversas etapas como se indica a
continuación:
Capítulo 2 Marco Teórico. En este capítulo se describe la etapa relacionada con
la Investigación de conceptos claves de los SRSCCs, por lo que se presenta un
marco teórico al respecto, donde se incluyen conceptos y principios técnicos sobre
los sistemas de recomendación contextuales semánticos, redes de ontologías y
métodos de inferencia semánticos.
Capítulo 3 Estado del Arte. En este capítulo se presenta información obtenida de
la actividad de Investigación de los enfoques actuales en el desarrollo de
SRSCCs, describiendo brevemente sistemas de recomendación contextuales
semánticos y las ontologías usadas en ellos para la representación del contexto.
Capítulo 4 Definición de una arquitectura genérica para un SRSCC
organizacional. Como su nombre lo indica, en este capítulo se describe una
arquitectura capaz de permitirle a un SRSCC realizar las tareas involucradas con
su funcionamiento, las cuales se han asociado a módulos específicos que
consideran los enfoques analizados en el estado del arte.
Capítulo 5 Desarrollo del SRSCC organizacional T-Guía. En este capítulo se
describen la forma en que la arquitectura propuesta fue usada en el desarrollo de
un SRSCC organizacional, llamado T-Guía, el cual está diseñado para funcionar
de forma proactiva con clientes móviles en entornos de tipo campus.
Capítulo 6 Pruebas y caso de estudio. En este capítulo se detalla la etapa de
Pruebas al SRSCC organizacional T-Guía, especificando los resultados
observados y las hipótesis que se buscaron comprobar. Además, se describe un
escenario de uso del T-Guía en el que se analiza el comportamiento del sistema
bajo distintas variaciones contextuales.
Capítulo 7 Conclusiones. En este capítulo se plantean las conclusiones
obtenidas con la realización de este trabajo, además de sugerir áreas de
oportunidad y posibles trabajos futuros que pueden ampliar esta investigación.
Por último, se incluye una sección de anexos que aportan información de soporte
a la investigación realizada, la cual no se incorpora en el contenido principal del
documento debido a su extensión o por ser material redactado explícitamente
como complemento a aspectos claves del trabajo de tesis.
10
CAPÍTULO 2 MARCO TEÓRICO
Los contenidos de este capítulo explican conceptos necesarios para la realización
del trabajo de tesis, abarcando temas relacionados a sistemas de recomendación
contextuales semánticos, redes de ontologías y métodos de inferencia semánticos.
11
2.1 Sistema de recomendación semántico adaptable al contexto
Los sistemas de recomendación semánticos basan su proceso de recomendación
sobre una base de conocimiento, normalmente definida a través de un esquema
de conceptos (como una taxonomía o un tesauro) o una ontología, y además, para
ser considerados como adaptables al contexto, estos tipos de sistemas deben
tomar en consideración diferentes factores (temporales, de lugar, nivel de
experiencia del usuario, dispositivo que se está utilizando en el momento de recibir
la recomendación, entre otros.) para inferir el contexto en que se encuentra el
usuario y adaptar las recomendación a esas circunstancias, facilitando el acceso
de los usuarios a la información que necesitan [Peis, 2008].
Para realizar este proceso de inferencia, las técnicas utilizadas por los sistemas de
recomendación adaptables al contexto usan lo que se considera como
conocimiento funcional, es decir, se tiene conocimiento acerca de cómo un
elemento en particular responde a una necesidad particular del usuario, y por lo
tanto se puede razonar sobre la relación entre una necesidad y una posible
recomendación [Burke, 2002].
2.2 Ontología de contexto multidimensional
El contexto es cualquier información que puede ser usada para caracterizar la
situación de una entidad, donde una entidad puede ser una persona, lugar u
objeto físico o computacional, por lo que puede verse como un espacio
multidimensional donde cada dimensión es representada por una ontología
especifica [Bouzeghoub, 2009]. Para ello, se maneja una red de ontologías,
relacionadas entre sí, las cuales en conjunto contienen la información que
describe el contexto y adquieren el nombre de ontología de contexto
multidimensional.
12
2.3 Clasificaciones de sistemas de recomendación
Existen dos clasificaciones de sistemas de recomendación manejadas en la
literatura, la primera de ellas define las siguientes categorías [Balabanovi, 1997]:
Basados en contenido: al usuario se le recomiendan ítems basados en lo
que le ha gustado previamente.
Colaborativos: al usuario se le recomiendan ítems que han sido del agrado
de usuarios con preferencias similares.
Híbridos: estos sistemas combinan el enfoque basado en contenidos con el
enfoque colaborativo.
La segunda clasificación agrupa a los sistemas de recomendación en basados en
reglas, de filtrado colaborativo y de personalización basada en contenidos
[Shipman, 1995], [Chen, 1998].
2.4 Algoritmos de recomendación contextual
En los enfoques analizados para el desarrollo de sistemas de recomendación, se
encontró que existen diferencias significativas entre las técnicas de filtrado basado
en contenidos, entre las técnicas de filtrado colaborativo y entre las técnicas de
filtrado híbrido, pues cada una de éstas tiene características bien definidas que se
describen en los apartados siguientes:
2.4.1 Técnicas de filtrado basado en contenidos
Los sistemas de recomendación basados en contenidos utilizan algoritmos que
analizan la descripción de los ítems, con el objetivo de identificar aquellos que
resulten de interés para el usuario [Balabanović, 1997]. En este tipo de algoritmos
se tiene un perfil de usuario que describe sus preferencias en base a las
características de los objetos que ha calificado, lo que en la literatura se conoce
como ―correlación ítem-a-ítem‖ [Burke, 2002].
13
Existen diferentes formas de representar los ítems; una técnica para crear
estructuras que representen el contenido de los ítems es el stemming, cuya meta
es determinar un término que refleje el significado común existente entre
diferentes palabras [Balabanović, 1997]. El valor de una palabra (variable)
asociada a un término es un número real que representa su relevancia.
Dentro de los algoritmos de recomendación sobre contenidos se distinguen los
siguientes enfoques:
Árboles de decisión y reglas de inducción.
Redes neuronales.
Vecino más cercano.
Algoritmo de Rocchio.
Clasificadores lineales.
Métodos probabilísticos y Naïve Bayes.
2.4.2 Técnicas de filtrado colaborativo
Los algoritmos de filtrado colaborativo proporcionan recomendaciones o
predicciones de ítems basándose en la opinión de usuarios con características
similares, siendo que esta opinión puede ser obtenida de manera explícita o
implícita.
En otras palabras, la meta de los algoritmos de filtrado colaborativo es sugerir
nuevos ítems o predecir la utilidad de cierto ítem para un usuario particular,
basándose en los gustos y opiniones definidos previamente por usuarios similares
[Sarwar, 2001].
Para un escenario típico de filtrado colaborativo se tiene una lista de m usuarios
U = {𝑢1; 𝑢2; … ; 𝑢𝑚 } y una lista de n ítems I= {𝑖1; 𝑖2; … ; 𝑖𝑛 }. Cada usuario 𝑢𝑖 tiene
una lista de ítems 𝐼𝑢 𝑖 para los cuales expresa opiniones que pueden ser explicitas
al asignarles una puntuación (normalmente dentro de una escala establecida), o
implícita obtenida a partir de los registros.
El usuario específico para el cual se desarrolla el proceso de filtrado se le llama
usuario activo, y se distingue como 𝑢𝑎 , y se han establecido dos formas de definir
si un ítem es aceptable para un usuario, una de ellas es la predicción y la segunda
es la recomendación:
14
Predicción: es un valor numérico 𝑃𝑎 ,𝑗 que expresa el grado de
satisfacción calculado para un ítem 𝐼𝑗 ∈ 𝐼𝑢𝑎con respecto a un usuario
activo 𝑢𝑎 .
Recomendación: es una lista de N ítems 𝐼𝑟 ⊂ 𝐼, que podrían ser del
agrado de un usuario activo.
Los algoritmos de filtrado colaborativo manejan una matriz de valoraciones A de
m×n para representar la puntuación aginada por un usuario para un ítem.
2.4.3 Técnicas de filtrado híbrido
Los sistemas de recomendación híbridos combinan dos o más técnicas de
recomendación para tener un mejor desempeño. A continuación se describen
algunas de las combinaciones más comunes [Burke, 2002].
Ponderación o Weighted: en este enfoque se calcula un puntaje
para un ítem a partir de todas las técnicas de recomendación
disponibles en el sistema.
Conmutación o Switching: en este enfoque el sistema utiliza algún
criterio para cambiar entre distintas técnicas de recomendación
dependiendo de la situación presente al momento de efectuar la
recomendación.
Mixta: en este enfoque se utilizan más de una técnica de
recomendación que pueden ser ejecutadas simultáneamente, lo cual
es útil cuando se necesita generar múltiples recomendaciones al
mismo tiempo.
Función de combinación: en este enfoque se realiza una mezcla
entre algoritmos colaborativos y basados en contenido al tratar la
información colaborativa simplemente como datos adicionales, y
usar técnicas basadas en contenidos sobre el conjunto de datos
extendido. De este modo, se pueden considerar datos colaborativos
sin tener que depender exclusivamente de ellos, lo que reduce la
sensibilidad del sistema a la cantidad de usuarios que han calificado
un ítem. Otra particularidad es que permite tener una apreciación de
la similitud entre los ítems que no sería visible usando únicamente
técnicas colaborativas.
15
Cascada: la hibridación cascada implica un proceso por etapas,
primeramente se emplea una técnica para producir un conjunto de
ítems candidatos, a partir de éste se aplica una segunda técnica que
refina la recomendación de ítems. Su eficiencia radica en que la
segunda técnica se aplica sólo a los elementos que requieren un
segundo filtrado, mientras que en otros enfoques cada técnica se
aplica a todos los elementos.
Función de incremento: en este enfoque, se emplea una técnica
para producir la clasificación de un ítem incorporando esta
información denle el proceso de la siguiente técnica de
recomendación.
Meta-nivel: en este enfoque se usa el modelo generado por una
técnica como entrada de otra. El meta-nivel hibrido se enfoca
exclusivamente en la recomendación conocida como "colaboración
vía contenido" y tiene la ventaja de que el modelo es una versión
comprimida de los intereses del usuario y un mecanismo colaborativo
que puede operar fácilmente sobre su representación de densidad de
información.
2.5 Lenguaje de Reglas de la Web Semántica (SWRL)
El Lenguaje de Reglas de la Web Semántica (SWRL, o Semantic Web Rule
Language e inglés), se basa en una combinación de los sub-lenguajes OWL DL,
OWL Lite y RuleML y usa una notación similar a la EBNF [Horrocks, 2004]. SWRL
extiende el conjunto de axiomas de OWL para incluir clausulas de Horn1. Esto
hace posible combinar clausulas de Horn con una base de conocimientos en
OWL. Además, posee una sintaxis abstracta de alto nivel, con la que se puede
describir una ontología de OWL como una secuencia de axiomas y hechos.
Las reglas definidas con SWRL se definen como cláusulas de Horn, estableciendo
una relación entre un antecedente y un consecuente, es decir, cuando se cumplen
las condiciones definidas en el antecedente, las condiciones establecidas en el
1 Clausula de Horn: De acuerdo a [Nielson, 2002], una cláusula de Horn es un conjunto finito de
implicaciones. Cada implicación r es de la forma h ⇐ α donde h y α son la cabeza (antecedente) y la condición previa de r, respectivamente. En otras palabras, en una clausula se puede expresar
una disyunción de literales con al menos una literal positiva, por ejemplo: p q t
u
16
consecuente deberán cumplirse también. Estas reglas se definen de la forma
Antecedente (body) -> Consecuente (head).
Cada consecuente puede estar formado por un conjunto de átomos (incluso el
conjunto vacío) y se pueden utilizar referencias URI, que sirven para identificar
una regla y las variables son marcadas con un signo ‗?‘ como prefijo. Un ejemplo
de regla en SWRL es: la afirmación de que las propiedades hasParent y
hasBrother implican hasUncle.
hasParent(?x1,?x2) ^ hasBrother(?x2,?x3) => hasUncle(?x1,?x3)
17
CAPÍTULO 3 ESTADO DEL ARTE
Este capítulo presenta tópicos relacionados con las tendencias y enfoques
actuales en los sistemas de recomendación contextuales semánticos, los cuales
impactaron en el desarrollo de éste trabajo de tesis.
18
3.1 Categorización de trabajos
Los trabajos relacionados que se describen a continuación corresponden a
proyectos de investigación recientes (2008-2010), relacionadas con el tema de
tesis. En estos trabajos se presentan Sistemas de Recomendación Semánticos
Conscientes del Contexto (SRSCCs) que usan bases de conocimientos de dos
tipos, las que utilizan redes de ontologías y las que se basan en ontologías
tradicionales y recursos no ontológicos. En el primer tipo de base de
conocimientos se busca modelar toda la información que engloba a un SRSCC,
mientras que en el segundo caso, la mayoría de los enfoques se centran en
modelar las preferencias e intereses de los usuarios en una ontología y los
aspectos relacionados con la información contextual son obtenidos de otras
fuentes. Posteriormente se analizan tres trabajos que abordan el uso de redes
ontológicas y seis trabajos en los que se explotan ontologías tradicionales.
Finalmente, se incluye la descripción de una red de ontologías para el modelado
semántico de recursos humanos, cuyos módulos ontológicos se encuentran
estrechamente relacionados con las dimensiones contextuales manejadas en este
trabajo de tesis.
3.2 Propuesta de Bouzeghoub [Bouzeghoub, 2009]
El trabajo desarrollado por Bouzeghoub se enfoca a SRSCC que realizan
recomendaciones sobre personas, edificios, eventos y recursos disponibles
[Bouzeghoub, 2009]. Además, considera usuarios con dispositivos móviles en un
entorno de tipo campus, a los que de forma proactiva y según la situación del
usuario, se les muestra información sobre los edificios e individuos más
relevantes que se encuentran cerca de él.
Dentro de este enfoque, se sugiere que ―el contexto es un espacio
multidimensional donde cada dimensión es representada por una ontología
especifica‖, además, el concepto de situación es manejado bajo la siguiente
definición: ―una situación describe la información contextual durante un instante de
tiempo‖ [Bouzeghoub, 2009]. Esto corresponde a un conjunto de relaciones
semánticas, las cuales son validas en un instante dado o que son estables en un
intervalo de tiempo. Una situación combina todas o algunas dimensiones
19
(contextuales) al mismo tiempo‖. Además, se define un evento como ―un cambio
de situación‖.
La red de ontologías manejada está formada por cinco ontologías, las cuales se
describen a continuación:
1. Domain ontology: está ontología permite crear instancias de competencias
y recursos, (equipos y documentos), que se manejan en el sistema.
2. User ontology: incluye una lista de las competencias del usuario (conceptos
que trabaja u ofrece, así como un nivel de conocimiento, ponderado de
menos a más, que está asociado a cada concepto), una lista de sus
intereses, y una lista de recursos que ha aprendido, visto o recomendado.
3. Activity ontology: diseñada para modelar las actividades que realizan los
usuarios.
4. Location ontology: se basa en las ontologías de [Chen, 2003]. Maneja
conceptos relacionados a la localización geográfica (ejemplo, ‗inDoor‘, ‗out-
Door‘, ‗room‘, ‗school‘, ‗class‘, ‗street‘, ‗office‘, ‗train‘...), entidades
geopolíticas (‗Country‘, ‗Home‘, ‗City‘, ‗Company‘, ‗University‘, ‗State‘,
‗Department‘…) y sus relaciones.
5. Time information ontology: usan la ontología OWL-Time2 [W3C, 2006] como
modelo de tiempo, la cual es extendida para los fines del proyecto e
implementada en F-Logic. Los conceptos básicos de esta ontología son:
‗instant‘, ‗interval‘, ‗instant event‘, y ‗interval event‘ y las relaciones básicas
son ‗before‘, ‗after‘, ‗inside‘.
Además del contexto y perfil de usuario, en el proceso de inferencia se
considera el historial de recomendaciones, el cual almacena las recomendaciones
aceptadas previamente por los usuarios, para determinar cuáles son las
recomendaciones más novedosas.
2 http://www.w3.org/TR/owl-time
20
3.3 Proyecto mIO! [Cadenas, 2009]
El proyecto mIO! está orientado al sector turismo, considerando usuarios finales
con dispositivos móviles en un ambiente urbano, para quienes se ofrecen
recomendaciones sobre puntos de interés, servicios y ofertas comerciales,
permitiendo también mantener una interfaz adaptable a los clientes.
La base de conocimientos usada consiste en una red de ontologías para la
descripción del contexto, llamada mIO!, la cual fue creada usando la metodología
para la creación de redes de ontologías NeOn [Cadenas, 2009]. Esta red de
ontologías, mostrada en la Figura 3.1: Red de ontologías mIO! está formada por
las ontologías siguientes:
1. User ontology: esta ontología es usada para modelar información sobre
personas, grupos y organizaciones. Es definida reutilizando las ontologías
CoDAMoS3 y FOAF4.
2. Role ontology: esta ontología es usada para modelar roles, perfiles y
preferencias.
3. Environment ontology: esta ontología modela la información relacionada
con el ambiente, como humedad, luminosidad, ruido, etc. Esta ontología
reutiliza la ontología CoDAMoS.
4. Location ontology: esta ontología es usada para modelar información
relacionada a la localización, como lo son edificios, entidades espaciales,
coordenadas, distancia, etc. En su diseño se reutilizó la ontología SOUPA5.
5. Time ontology: en esta ontología se modela información sobre el tiempo, tal
como unidades temporales, entidades temporales, instantes, intervalos, etc.
Esta ontología es obtenida por la reutilización de la ontología OWL-Time.
6. Service ontology: esta ontología modela el conocimiento sobre los servicios.
7. Provider ontology: esta ontología modela la información sobre el proveedor
de servicios.
8. Device ontology: esta ontología reutiliza la ontología CoDAMoS , y modela
información sobre el hardware, el software y la plataforma de los
dispositivos.
9. Interface ontology: esta ontología modela información sobre las diferentes
interfaces de usuario que un dispositivo puede proporcionar.
10. Network ontology: esta ontología modela el conocimiento sobre las redes
de comunicación.
3 http://www2.cs.kuleuven.be/~distrinet/projects/CoDAMoS/ontology/context.owl
4 http://xmlns.com/foaf/spec/
5 http://cobra.umbc.edu/ont/soupa-ont.tar.gz
21
Figura 3.1: Red de ontologías mIO!
De manera adicional, en este proyecto se propone el uso de un historial del
contexto, el cual deberá ser considerado en el proceso de inferencia para deducir
mejores recomendaciones.
3.4 Proyecto ICAS [Sousa, 2009]
El proyecto ICAS presenta una arquitectura que permite la creación de servicios
sensibles al contexto y describe un modelo semántico para representar el contexto
llamado SeCoM [Sousa, 2009].
El modelo SeCoM se compone de seis ontologías principales y seis ontologías de
soporte, describiéndose las primeras de la siguiente forma:
1. Actor ontology: en esta ontología se modela la información correspondiente al perfil de entidades como personas, grupos y organizaciones.
2. Time ontology: en esta ontología se modela información temporal en términos de instantes de tiempo e intervalos de tiempo, las relaciones entre ellos e información sobre calendarios y horarios.
3. Temporal Event ontology: en esta ontología se modelan los eventos con extensiones de la Time ontology, de modo que se tienen instantes o intervalos de los eventos, además de información relacionado con su frecuencia y duración.
22
4. Space ontology: en esta ontología se modela información relacionada con la ubicación de los actores. Para ello, se consideran lugares virtuales y reales, tanto en interiores como exteriores, y relaciones entre lugares y partes de ellos, y conceptos referentes a la orientación, entre otros.
5. Spatial Event ontology: en esta ontología se modelan los eventos con extensiones de la Space ontology; se pueden representar eventos físicos (que ocurren en una localización física) y eventos virtuales (que ocurren en una localización virtual).
6. Device ontology: esta ontología describe los dispositivos en términos de hardware y software, relaciones entre sus componentes y aspectos del cómputo móvil.
7. Activity ontology: en esta ontología se describen las actividades como un conjunto de eventos espaciotemporales, incluyendo a los actores y dispositivos involucrados en ellos. Se manejan dos tipos de actividades, las planeadas y las improvisadas.
Las ontologías secundarias son: Contact ontology, Relationship ontology, Role ontology, Project ontology, Document ontology y Knowledge ontology. La Figura 3.2: Modelo SeCoM corresponde al modelo presentado en esta propuesta:
Figura 3.2: Modelo SeCoM
23
El proceso de inferencia en ICAS se basa en la consideración de las preferencias,
el contexto, los parámetros y los intereses de los usuarios para identificar los
servicios que les sean relevantes. En este enfoque, los servicios se clasifican en
categorías, y se marcan precondiciones y poscondiciones para cada uno de ellos,
de tal forma que en el proceso de filtrado de información, se realiza una búsqueda
por tipos de servicios, y después, se hace un enlace de los servicios compatibles,
en base a sus entradas y salidas. Por último se realiza una puntuación de las
combinaciones, utilizando las ponderaciones de los parámetros de evaluación
definidos por los autores y evaluando las políticas particulares de cada usuario, el
resultado se entrega al cliente en forma de lista.
De acuerdo al enfoque seguido en el proyecto, también se mantiene un historial de
las acciones de los usuarios en una base de datos. Estas acciones intervienen en
la recomendación de servicios determinando frecuencias de uso. Estas acciones
se almacenan en el formato: Action + target Triplet (e.g. update: Bob isMemberOf
the Sciences Students Group).
24
3.5 Proyecto SeMoDesk [Woerndl, 2009]
Este proyecto desarrolla un sistema de recomendación semántico que sigue un
enfoque para el manejo de información personal usando dispositivos PDA´s, el
cual realiza recomendaciones de artículos basándose en el contexto y la ontología
personal de un usuario. Para ello, se maneja un algoritmo que utiliza una función
de evaluación para recorrer el grafo de los recursos y ranquear sus nodos
[Woerndl, 2009]. Los recursos y otros elementos relevantes, tales como puntos de
interés, se señalan en un mapa desplegado en el dispositivo móvil.
La idea básica del algoritmo de recomendación es encontrar recursos relevantes y
recomendarlos junto con ítems adicionales. Las recomendaciones se obtienen a
partir de la selección de un tema o documento que es del interés del usuario, y el
sistema le muestra, en forma de lista, recursos relacionados con su selección,
para lo cual considera la agenda y localización de dicho usuario. Cuando el
usuario selecciona un elemento de la lista se le recomiendan recursos adicionales.
En este proceso el algoritmo sólo evalúa las entidades que el usuario ha definido
en el SeMoDesk.
Para identificar los ítems relevantes para el usuario, se recorre el grafo de la
ontología, usando una función de evaluación para determinar si un nodo es
recomendable; los vecinos de un nodo no recomendable son ignorados en el
recorrido. La función de evaluación considera la distancia entre el nodo
recomendable al nodo raíz, su peso dependiendo del tipo de concepto o recurso al
que corresponde, y el peso de sus relaciones con otros conceptos, considerando
que se pueden asignar distintos pesos de importancia a distintos tipos de
relaciones. La recomendación de ítems adicionales es posible por la extensión de
la ontología PIMO [Sauermann, 2007], realizada con la adición de puntos de
interés (POIs), los cuales se relacionan a los conceptos y recursos. Los objetos de
tipo POI pueden referirse, por ejemplo, a restaurantes, cines o tiendas, entre otros.
25
3.6 Propuesta de Rasanen [Rasanen , 2009]
Rasanen busca representar información referente al ambiente en que se
encuentra el usuario de un SRSCC, como condiciones de luminosidad, humedad,
temperatura y condiciones climáticas, además de esto, se consideran elementos
que describen los dispositivos que usa y la manera en que se desplaza un
usuario, como su medio de transporte y la velocidad con que se mueve [Rasanen ,
2009].
Dentro del proceso de inferencia, se propone considerar el contexto, políticas de
privacidad y preferencias de los usuarios, y también se maneja una clasificación
de actividades a las que corresponden un conjunto específico de preferencias,
teniendo, por ejemplo, que para las actividades de tipo ―viajes‖ en el proceso de
inferencia se consideran únicamente el conjunto de preferencias formadas por el
pronóstico del tiempo, las aerolíneas, los hoteles y servicios de renta de autos.
De manera adicional, el proceso de inferencia considera un historial de los lugares
que visita un usuario como factor para determinar las recomendaciones. Este
historial almacena datos referentes a la actividad y el contexto en que se realizó,
las recomendaciones que se le hicieron y los servicios que utilizó.
Para los datos de actividad y contexto se almacena el rango de tiempo en que se
realizó dicha actividad, la ubicación, el nivel de luminosidad (definidos en día,
tarde, noche, entre otros), la temperatura ambiental y la velocidad y aceleración
con que se desplazaba el usuario.
Además, para los datos de recomendaciones realizadas, se almacena la lista de
recomendaciones efectuadas con el peso de cada una de ellas, y para los datos
de los servicios usados se almacena el nombre de la recomendación y la
valoración otorgada por el usuario.
26
3.7 SMARTMUSEUM [Liiv, 2009]
La plataforma SMARTMUSEUM es utilizada para realizar recomendaciones para
el dominio del patrimonio cultural en un museo, por medio de un sistema que
combina los enfoques basado en reglas, colaborativo y personalización basada en
contenidos, siendo que estos contenidos están descritos semánticamente en una
ontología [Liiv, 2009].
La propuesta considera dos escenarios para el uso de un SRSCC, uno para
interiores y otro para exteriores, el primero de ellos está orientado a usuarios que
visitan las instalaciones del museo, mientras que el segundo se centra en usuarios
que pasean por la ciudad buscando lugares interesantes para visitar. Para la
localización, en exteriores se maneja GPS y en interiores tags RFID.
En ambos escenarios el funcionamiento es el siguiente:
1. Localizar al usuario.
2. Enviar el perfil del usuario del PDA al servidor de recomendaciones y
calcular los intereses del usuario.
3. Presentar los lugares sugeridos para visitar.
4. Presentar información detallada de los lugares que el usuario
seleccione.
5. Almacenar los intereses y comentarios del usuario en su perfil. La
información que se almacena es un indicador si al usuario le gusta o
no el ítem y un comentario sobre él.
6. Permitir al usuario modificar su perfil manualmente.
7. Ofrecer a los administradores herramientas para administrar los
museos y lugares de interés de la ciudad.
Específicamente, el SMARTMUSEUM recomienda objetos que se encuentran en
el museo, considerados como los ítems registrados en el sistema, pero además se
tiene un segundo tipo de recomendación, en el que se recomienda contenido
relacionado a un objeto en particular que el usuario visita dentro del museo.
Uno de los mecanismos para determinar la popularidad de los ítems entre los
usuarios es medir el tiempo que permanecen en las páginas web de los puntos de
interés (incluidas como ligas dentro de la información detallada de los lugares que
se recomiendan a los usuarios), y usarlo para tener un ranqueo de ellos.
27
El perfil de usuario que se maneja en SMARTMUSEUM incluye información de las
habilidades e intereses del usuario, además de un historial de los lugares que
visita. Para los dos primeros grupos de información se utilizan las ontologías
GUMO[Heckmann,2005] y Getty6, mientras que el historial se maneja como una
lista de registros que contienen el identificador del objeto, el contexto de la visita,
la URL correspondiente y la valoración asignada por el usuario para el objeto y el
contenido.
La calificación que se almacena para cada ítem es calculada por una combinación
de la entrada manual con un monitoreo implícito, en el cual se registran las
acciones que el usuario realiza para identificar si un ítem recomendado es de su
agrado, asignándose valores de la siguiente forma:
1: si el usuario indica manualmente que un ítem le gusta.
0.7: el usuario consulta información detallada sobre el ítem.
0.3: el usuario consulta sólo la información básica del ítem.
-0.01: el usuario visita el lugar donde se encuentra el objeto pero no se
muestra interesado.
-1: el usuario indica manualmente que el ítem no le agrada.
El sistema de reglas planteado para el componente de recomendación del
SMARTMUSEUM se basa en dos consideraciones:
Las capacidades y preferencias del usuario, identificadas a partir de
su perfil.
La información contextual del entorno del usuario, especificada al
comenzar el recorrido por un museo.
La primera consideración es la base del proceso de recomendación, mientras que
la información contextual es usada para optimizar las recomendaciones.
Para proporcionar recomendaciones basadas en los intereses de los usuarios y el
contexto se utiliza un componente basado en ontologías. Estos intereses son
determinados basándose en metadatos que describen los ítems que el usuario ha
etiquetado en diferentes contextos, para lo cual se utilizan anotaciones, definidas
en RDF, que describen los objetos en términos de ontologías y esquemas de
metadatos. Estas anotaciones están estructuradas utilizando una extensión del
esquema de metadatos Dublin Core7, el cual, contiene descriptores para
representar diferentes aspectos de los objetos, tales como: el tipo de objeto, su
lugar de fabricación, su creador y el material del cual está hecho, entre otros.
6 http://www.getty.edu/research/conducting_research/vocabularies/
7 http://dublincore.org/documents/1998/09/dces/
28
El perfil de usuario es obtenido mediante una aplicación web en la que se ofrece a
los usuarios una lista de palabras para definir sus intereses, la cual es obtenida a
partir del vocabulario Getty6, y después, el perfil del usuario es actualizado
continuamente mediante las anotaciones que va realizando a través de la interfaz
del PDA, en la cual indica si un ítem le agrada o no. Cada tripleta del perfil de
usuario es ligada al contexto en el que el usuario efectuó la anotación.
Además, el perfil de usuario es definido por los autores como un conjunto de ítems
de perfil, que representan tripletas individuales de la forma pi =< t, ct, w >, donde t
es una tripleta, ct el contexto de la tripleta y w es el peso de la tripleta t en ct. El
peso del ítem de perfil puede ser determinado a partir de una probabilidad
máxima, que es el número de veces que una tripleta ha sido etiquetada entre el
número total de tripletas que existen. Para evitar tener una probabilidad igual a
cero cuando no se tienen anotaciones para un objeto en cierto contexto se utiliza
el suavizado de Laplace [Field, 1988].
El perfil de contexto representa el contexto de un usuario al momento de efectuar
una recomendación, manejando información de su localización que define
restricciones espaciales para la recomendación de ítems, las cuales pueden ser
una tripleta indicando que un usuario está dentro de cierto museo, o bien, pueden
ser coordenadas del World Geodetic System 84 (WGS84)8, indicando que el
usuario se encuentra en el exterior. En un tercer escenario, se utiliza la lectura de
etiquetas RFID colocadas en objetos cercanos al usuario y cuyos identificadores
se almacenan en el perfil de usuario, lo que es útil para realizar recomendaciones
referentes a ese ítem. Para el proceso de recomendación se calcula el cociente de
similitud entre el perfil de usuario y las tripletas que describen a los objetos.
8 El World Geodetic System 84 (que significa Sistema Geodésico Mundial 1984), es un sistema de
referencia terrestre único para referenciar las posiciones y vectores. Se estableció este sistema utilizando observaciones Doppler al sistema de satélites de navegación NNSS o Transit, de tal forma que se adaptara lo mejor posible a toda la Tierra. Se define como un sistema cartesiano geocéntrico del siguiente modo:
- Origen, centro de masas de la Tierra, incluyendo océanos y atmósfera. - Eje Z paralelo a la dirección del polo CIO o polo medio definido por el BIH, época 1984.0
con una precisión de 0,005". - El eje X la intersección del meridiano origen, Greenwich, y el plano que pasa por el origen
y es perpendicular al eje Z, el meridiano de referencia coincide con el meridiano cero del BIH en la época 1984.0 con una precisión de 0,005". Realmente el meridiano origen se define como el IERS Reference Meridian (IRM).
- El eje Y ortogonal a los anteriores, pasando por el origen. - Terna rectangular dextrosum.
Fuente: Department of defense world geodetic system 1984—its definition and relationships with local geodetic systems. Technical Report TR8350.2, National Imagery and Mapping Agency, Bethesda, USA
29
Finalmente, la retroalimentación del recomendador se basa en el perfil de usuario
y el perfil de contexto, teniéndose un conjunto de tripletas para definirlos, cada una
con un peso calculado para determinar su probabilidad de ocurrencia en un
contexto dado, además, pueden usarse consultas para expandir cada tripleta,
identificando relaciones de inclusión entre ellas.
3.8 El proyecto MyMose [Zubizarreta, 2009], [Zubizarreta, 2008],
[Arias, 2008] y [Zubizarreta, 2005]
El consorcio MORFEO9 a impulsado un proyecto de investigación sobre búsqueda
contextual aplicado al entorno de Web Móvil denominado MyMose, el cual incluye
un sistema de recomendación consciente del contexto que realiza sugerencias a
los usuarios sobre servicios que pudiesen interesarle en base a sus solicitudes, y
cuya base de conocimientos está basada en ontologías y tesauros. MyMose busca
recabar los datos y preferencias de un usuario para definir su perfil y en base a
ello realizar las recomendaciones [Zubizarreta, 2009], [Zubizarreta, 2008], [Arias,
2008] y [Zubizarreta, 2005].
Dentro de este proyecto, se maneja un modelo para la obtención del contexto
usando ontologías, en el cual se incluyen todas las propiedades del ambiente del
usuario y de sus intereses, para lo cual se utiliza una taxonomía de clases y
propiedades, que se ligan a conceptos similares y si se llegasen a necesitar
nuevos conceptos estos pueden ser creados por un especialista. Una vez que las
propiedades han sido identificadas y definidas, no pueden ser removidas del
modelo, ya que esto podría producir rupturas en las dependencias entre
propiedades.
En este proyecto se propone un modelo contextual extensible dividido en tres
niveles, que corresponde a la Figura 3.3: Niveles del modelo contextual y cuya
descripción se presenta a continuación:
Propiedades recuperadas directamente: Estas son propiedades que
pueden ser reunidas automáticamente de las fuentes de información
contextual.
Propiedades derivadas: Son propiedades implícitas que pueden ser
inferidas a partir de las propiedades recuperadas directamente
9 http://uwa.morfeo-proyect.org
30
Propiedades de aplicación específica: Son propiedades adicionales
definidas o redefinidas para una aplicación específica.
Figura 3.3: Niveles del modelo contextual
De manera adicional, se propone la creación automática de propiedades a partir
de la aplicación de reglas a propiedades ya existentes, y se enfatiza el hecho de
que es posible redefinir cualquier propiedad en el modelo, igualmente que las
reglas pueden ser modificadas del registro, las cuales han sido definidas con
SWRL.
Las ontologías definidas para el modelo contextual propuesto, consideran las
siguientes dimensiones:
Perfil de usuario: Contiene propiedades explicitas e implícitas relacionadas
al usuario y sus circunstancias, así como sus preferencias. Esta ontología
es definida usando una extensión de FOAF.
Dispositivo y navegador: Este conjunto de propiedades describen las
características del dispositivo y del navegador usados por un usuario, con el
objeto de proporcionar una fuente de información que permita la
personalización de interfaces de usuario de funciones de autocompletado y
características de búsqueda entre otras.
Contexto geoespacial: La información sobre la localización de un usuario
incluye coordenadas geográficas, tipos de lugares, entidades políticas y
adicionalmente, se ha incluido en el modelo el concepto de alcance
espacia. La localización puede ser obtenida a través de GPS o
triangulación GPRS, de acuerdo a las características tecnológicas
dispositivos de usuario.
Condiciones ambientales: estas propiedades buscan modelar el ambiente
alrededor del usuario.
31
Fecha y hora: como parte de una dimensión temporal, se manejan los
elementos fecha y hora para modelar momentos asociados a los usuarios y
a los servicios recomendados por MyMose, como el instante en que se
efectúa la recomendación u horarios de atención, por ejemplo.
Otras: esta dimensión del modelo permite la inclusión de cualquier
elemento interesante que no haya sido considerado en la ontología, que
pueden ser culturales, sobre redes, contexto social, intensiones del usuario,
contexto de las actividades, entre otras.
Otro aspecto interesante en este proyecto es la definición de una clasificación de
dispositivos, además de la clasificación de contenidos Web, propone un método
para desarrollar estas clasificaciones.
La arquitectura manejada en MyMose se compone de seis módulos, los cuales
corresponden a la Figura 3.4: Arquitectura de MyMose y se explican a
continuación:
Modelo del Contexto provee una representación del usuario el ambiente y
el mecanismo de acceso, permitiendo la personalización y la conciencia del
contexto.
Tesauros: modela semánticamente entre conceptos específicos
manejados por el sistema de búsqueda.
Ontología: Describe propiedades adicionales que cada concepto del
tesauro puede tener.
Asistente para la construcción de consultas semánticas: Busca
recomendar opciones más adecuadas dentro de un contexto para evitar
escritura del usuario y personalizar el proceso de búsqueda.
Motor de búsqueda personalizada: Utiliza toda la información disponible
para encontrar resultados relevantes.
Interface usuario: En [Arias 2008] Se presenta un prototipo adaptable a los
dispositivos móviles, el cual utiliza los módulos previos para interactuar con
el usuario.
32
Figura 3.4: Arquitectura de MyMose
El sistema de recomendación semántico consciente del contexto manejado en
este proyecto para la construcción de consultas, opera sobre un tesauro definido a
partir del vocabulario SKOS10 e implementado en RDF, en el que para cada
concepto se incluyen sinónimos que reflejan la misma idea y se permite el uso de
palabras en diferentes idiomas.
Otro punto a resaltar es la definición de las propiedades isSuitableInContext e
isNotSuitableInContext, que permiten identificar si un concepto es adecuado o no
para un contexto específico y de esta forma aumentar la eficiencia del filtrado de
información. Una de las reglas aplicables al tesauro para identificar el valor de
estas propiedades se define de la forma:
concept(?c) ^context(?t)^{conditions(?t)} isSuitableInContext(?c,?t)
Usando esta regla y un conjunto de condiciones especificadas por un experto, el
Motor de Inferencia es el encargado de identificar bajo qué condiciones un
concepto es deseable.
3.9 Proyecto SEEMP [Gómez-Pérez, 2010]
El proyecto SEEMP tiene el objetivo de facilitar la administración de empleos en
Europa, y con ese objetivo, se ha desarrollado una red de ontologías capaz de
describir las características de empleos y empleados en términos de recursos
humanos [Gómez-Pérez, 2010].
10
http://www.w3.org/TR/2008/WD-skos-primer-20080221/
33
Esta red de ontologías, llamada SEEMP Reference Ontology 11, contiene varias de
las dimensiones contextuales consideradas en esta tesis, además de otras que se
pueden incluir para extender el modelo manejado, las cuales se describen a
continuación:
1. Job Seeker Ontology. Esta ontología modela información sobre los
buscadores de empleo y sus CV usada en el proyecto SEEMP.
2. Job Offer Ontology. Esta ontología modela conocimiento sobre vacantes,
empleadores y ofertas de trabajo.
3. Compensation Ontology. Esta ontología modela información sobre sueldos
y salarios, y está basada en el estándar ISO 421712, el cual es una lista de
254 nombres y códigos de monedas nacionales expresado en HTML.
4. Driving License Ontology. Esta ontología modela conocimiento relacionado
al dominio de las licencias de manejo, y está basada en las normativas de
la legislación europea13 contemplando 12 tipos de licencias de manejo.
5. Economic Activity Ontology. Esta ontología maneja conocimiento de las
actividades y sectores económicos, usando como base el estándar NACE
Rev. 1.114
6. Occupation Ontology. Esta ontología se basa en los estándares ISCO-88
(COM)15, ONET16 y European Dynamics para modelar conocimiento sobre
ocupaciones y tipos de trabajos.
7. Education Ontology. Esta ontología modela conocimiento sobre campos y
niveles de educación tomando los estándares FOET17 e ISCED9718
8. Geography Ontology. Esta ontología se basa en el estándar ISO 316619 y la
European Dynamics classifications: Continent and Region para representar
conocimiento sobre 244 países y 367 regiones del mundo.
9. Labour Regulatory Ontology. Esta ontología está basada en la clasificación
LE FOREM20 para expresar conocimiento sobre reglamentos y contratos de
trabajo.
10. Language Ontology. Esta ontología se basa en los estándares ISO 639221 y
Common European Framework of Reference (CEF)22
para modelar
conocimiento sobre idiomas.
11
http://droz.dia.fi.upm.es/seemp/ 12
http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html 13
http://ec.europa.eu/transport/home/drivinglicence/ 14
http://ec.europa.eu/comm/eurostat/ramon/ 15
http://online.onetcenter.org/ 16
http://online.onetcenter.org/ 17
http://ec.europa.eu/comm/eurostat/ramon/ 18
http://www.iso.org/iso/en/prods-services/iso3166ma/index.html 19
http://www.iso.org/iso/en/prods-services/iso3166ma/index.html 20
http://www.leforem.be/ 21
http://www.iso.org/iso/en/prods-services/popstds/languagecodes.html
34
11. Skill Ontology. Esta ontología modela conocimiento sobre habilidades basándose en la clasificación European Dynamics Skill.
12. Competence Ontology. Esta ontología modela conocimiento sobre competencias manejando el concepto Competence como una súper clase de los conceptos importados Skill, Language Proficiency y Driving License.
13. Time Ontology. Esta ontología se basa en la DAML ontology23 para
expresar conocimiento relacionado a entidades temporales. En resumen, la llamada SEEMP Reference Ontology está formada por trece módulos ontológicos como se representa en la Figura 3.5: Relaciones principales de la SEEMP Reference Ontology, con un total de 1609 clases, 6727 atributos y 94 relaciones.
Figura 3.5: Relaciones principales de la SEEMP Reference Ontology
22
http://www.cambridgeesol.org/exams/cef.htm 23
http://cs.yale.edu/homes/dvm/daml/time-page.html
35
3.10 Estudio comparativo
Para realizar una comparación entre los trabajos presentados y éste trabajo de
tesis, mostrada en la Tabla 3.1, se evaluaron las siguientes características:
Entorno: en esta columna se indica si el SRSCC está orientado a entornos
urbanos o de tipo campus.
Funcionamiento: esta columna sirve para especificar la forma en que un
SRSCC inicia su funcionamiento, es decir, si trabaja de forma proactiva o
reactiva.
Consideración de historiales: esta columna se refiere al uso de algún tipo
de historial durante el proceso de inferencia.
Condiciones contextuales complejas: de acuerdo a la definición de
Rasanen [Rasanen, 2009], esta columna indica si se consideran
dimensiones contextuales adicionales a las tradicionales, como
luminosidad, humedad y temperatura, por ejemplo.
Recursos ontológicos: esta columna sirve para expresar la forma en que
un SRSCC realiza el modelado semántico de la información que filtra.
Recomendación de Personas: esta columna indica si se consideran ítems
del tipo Persona dentro del dominio de recomendación del SRSCC.
Recomendación de Objetos de Conocimiento: esta columna indica si se
consideran ítems del tipo Persona dentro del dominio de recomendación del
SRSCC.
Recomendación de Lugares: esta columna indica si se consideran ítems
del tipo Lugar dentro del dominio de recomendación del SRSCC.
Recomendación de Servicios: esta columna indica si se consideran ítems
del tipo Servicio dentro del dominio de recomendación del SRSCC.
Recomendación de Recursos: esta columna indica si se consideran ítems
del tipo Recurso Tecnológico dentro del dominio de recomendación del
SRSCC.
Recomendación de Actividades y/o Eventos: esta columna indica si se
consideran ítems del tipo Actividad o Evento dentro del dominio de
recomendación del SRSCC.
36
Tabla 3.1: Comparativa de los trabajos relacionados con el proyecto de tesis
En
torn
o
Fu
ncio
nam
ien
to
Co
nsid
era
ció
n d
e
his
tori
ale
s
Co
nd
icio
nes
co
nte
xtu
ale
s c
om
ple
jas
Recu
rso
s o
nto
lóg
ico
s
Reco
men
dació
n d
e
Pers
on
as
Reco
men
dació
n d
e
Ob
jeto
s d
e
Co
no
cim
ien
to
Reco
men
dació
n d
e
Lu
gare
s
Reco
men
dació
n d
e
Serv
icio
s
Reco
men
dació
n d
e
Recu
rso
s
Reco
men
dació
n d
e
Acti
vid
ad
es y
/o E
ven
tos
Propuesta de
Bouzeghoub Campus Proactivo SI
NO SI SI NO SI NO SI SI
mIO! Urbano Reactivo SI NO SI NO NO SI SI NO NO
ICAS Campus Proactivo SI NO SI SI SI NO SI NO NO
Propuesta de
Rasanen Urbano
NO
ESPECIFICA
NO SI NO SI NO SI SI NO NO
SeMoDesk Urbano Reactivo NO NO SI NO NO SI SI NO NO
SMARTMUSEUM Campus/Urbano Proactivo NO SI SI NO NO SI SI SI NO
El proyecto
MyMose Urbano Reactivo NO
SI SI NO NO NO SI NO NO
Trabajo de tesis Campus Proactivo NO NO SI SI SI SI SI SI SI
37
CAPÍTULO 4: DEFINICIÓN DE UNA ARQUITECTURA GENERICA PARA
UN SRSCC ORGANIZACIONAL
Los contenidos de este capítulo describen una arquitectura genérica para SRSCC
definida a partir de los enfoques analizados en el Estado del Arte.
38
4.1 Introducción
Las tendencias en el desarrollo de SRSCCs mantienen una evolución constante,
la cual está motivada en gran medida por la búsqueda de una mayor eficiencia en
las recomendaciones que se le ofrecen al usuario. Estas tendencias, apreciadas
en los distintos SRSCCs presentados en el capítulo 3, se combinan en este
trabajo de tesis para definir una arquitectura base para la creación de SRSCCs
orientados a ambientes organizacionales, la cual fue usada con fines de
demostración en el desarrollo del SRSCC organizacional T-Guía, como se
describe en el capítulo 5.
Adicionalmente, se presentan conceptos relacionados con el análisis, diseño e
implementación de los módulos de un SRSCC organizacional, los cuales han sido
identificados a partir del análisis de los distintos SRSCCs descrito en el capítulo
anterior. Estos módulos se orientan, por una parte, a la generación de
recomendaciones y el entorno de operación de un SRSCC organizacional, y por
otro lado, a la interacción de los usuarios con el sistema de recomendación.
4.2 Descripción de la arquitectura genérica para un SRSCC
organizacional
Esta sección contiene la descripción de una arquitectura genérica para SRSCCs
organizacionales, cuyos módulos permitan realizar al menos las siguientes tareas
como parte su funcionamiento:
Permitir la administración de la información relacionada a los ítems
recomendables.
Permitir la administración de la información relacionada a los usuarios.
Detectar las condiciones contextuales que rodean a los usuarios.
Inferir y ofrecer conjuntos de ítems recomendables a los usuarios que
pueden estar clasificados y/u ordenados de acuerdo a criterios específicos.
Registrar el impacto que tienen las recomendaciones ofrecidas sobre los
usuarios.
39
En base a estas tareas y como parte del análisis realizado, se presenta el
diagrama de casos de uso mostrado en la Figura 4.1, el cual es usado para
capturar el comportamiento buscado en un SRSCC organizacional.
Figura 4.1: Caso de uso del comportamiento de un SRSCC organizacional típico
Una especificación de las sub-tareas necesarias para que un usuario pueda
consultar las recomendaciones inferidas se muestra mediante el caso de uso
presentado en la Figura 4.2, en el que se detalla el proceso de inferencia de una
forma que sea comprensible por desarrolladores, usuarios finales y expertos.
Figura 4.2: Caso de uso de la generación de recomendaciones en un SRSCC organizacional típico
40
A fin de desarrollar un SRSCC organizacional capaz de realizar todas las tareas y
sub-tareas descritas previamente, se propone una arquitectura genérica adaptable
a las necesidades de otros desarrollos, la cual se muestra en la Figura 4.3 y está
conformada por seis módulos y dos elementos de almacenamiento de acuerdo al
funcionamiento esperado para un SRSCC.
Figura 4.3: Arquitectura genérica de un SRSCC organizacional
Los componentes de la arquitectura propuesta se describen a continuación:
Módulo de poblado de ontologías: este módulo se encarga de poblar una
ontología o red de ontologías, contenida(s) en el Repositorio de recursos
ontológicos, a partir de una o más fuentes de datos, que pueden consistir
en bases de datos, archivos .xml, hojas de cálculo o documentos de texto.
Módulo de localización: este módulo identifica cuando un usuario llega a
las instalaciones de una organización y además, puede realizar el
monitoreo constante de la posición de los usuarios y de los ítems
recomendables, lo cual es almacenado en el Repositorio de recursos no
ontológicos para ser usada por el Módulo de identificación de
comportamiento de usuarios.
Módulo recolector de contexto: este módulo se encarga de identificar los
valores de las dimensiones contextuales que se consideran en el proceso
de inferencia. De manera adicional, puede implementarse de tal forma que
detecte cambios drásticos en una o más dimensiones contextuales,
motivando la generación de nuevas recomendaciones, modificando el peso
de las recomendaciones que ya han sido inferidas o la actualización del
41
estatus de disponibilidad de un ítem; el valor de las variables contextuales
puede obtenerse mediante el uso de sensores específicos para cada
dimensión contextual, pudiéndose considerar condiciones de luminosidad,
humedad, temperatura o condiciones climáticas [Rasanen , 2009], de
acuerdo a los requerimientos del SRSCC organizacional.
Módulo Motor de Inferencia: este módulo es el componente del SRSCC
que se encarga de identificar los ítems que se recomiendan a un usuario.
Adicionalmente, puede encargase de clasificar y/u ordenar las
recomendaciones, agrupándolas por tipo o identificando el peso de cada
recomendación para organizarlas jerárquicamente, por ejemplo. Para el
proceso de inferencia que permite filtrar la información, el Módulo Motor de
Inferencia recibe la salida del Módulo recolector de contexto y extrae del
Repositorio de recursos ontológicos el perfil de un usuario y las
características de los ítems recomendables, además, puede considerar el
historial de recomendaciones ofrecidas previamente al usuario, las cuales
se almacenan en el Repositorio de recursos no ontológicos.
Módulo GUI adaptable al usuario: este módulo permite modificar la forma
en que las recomendaciones inferidas por el Módulo Motor de Inferencia
serán mostradas a un usuario, con el objetivo de facilitar la interacción con
ellas. De acuerdo a las características de un usuario específico, podrán
hacerse adaptaciones en los elementos gráficos o en el contenido de la
información, por ejemplo. El proceso de adaptación es posible si se definen
diferentes conjuntos de características para el cliente del SRSCC y se
relacionan a tipos preestablecidos de usuarios, o definiendo opciones de
personalización que permitan al usuario configurar el cliente en base a sus
necesidades y preferencias.
De manera adicional, es posible implementar un mecanismo para identificar
el grado de satisfacción de un usuario con respecto a una recomendación,
lo cual se logra a través de una combinación de enfoques implícitos y
explícitos en el monitoreo; adicionalmente, las recomendaciones pueden
ser evaluadas manualmente por un usuario o se pueden analizar las
acciones que el usuario efectúa sobre cada recomendación recibida. La
salida de este módulo es una lista de recomendaciones con las acciones
que el usuario realizó sobre éstas.
Módulo de identificación de comportamiento de usuarios: este módulo
se encarga de organizar y almacenar el comportamiento de los usuarios y
del propio SRSCC, con el objetivo de contar con una fuente de información
correspondiente a las recomendaciones efectuadas por el SRSCC y
registrar la percepción de las mismas por parte de los usuario, además de
almacenar detalles referentes al el contexto en que fueron inferidas. Esta
42
información se debe almacenar en una estructura que permita considerarla
en el proceso de filtrado, a fin de generar recomendaciones más eficientes
y usarla en la identificación de patrones de comportamiento.
Para ello, el módulo recibe información del dispositivo del usuario desde la
GUI adaptable al usuario la cual es procesada junto con información
correspondiente al desplazamiento del usuario, la cual es almacenada en
tablas de posición de usuario localizadas en el Repositorio de recursos
no ontológicos.
Repositorio de recursos ontológicos: esta arquitectura plantea que las
instancias del modelo semántico usado por un SRSCC organizacional estén
contenidas en un Repositorio de recursos ontológicos. Este modelo
tiene la función de describir semánticamente las características que dan
identidad a una organización, buscando proporcionar conocimiento
consensual que sea explotable por aplicaciones semánticas desarrolladas
para ambientes organizacionales, por lo tanto, el Repositorio de recursos
ontológicos contiene instancias asociadas a distintos grupos de
información, ya sea acerca de la organización o sobre las dimensiones
contextuales consideradas por el SRSCC.
Repositorio de recursos no ontológicos: la arquitectura propuesta
contempla una base de datos en la que se almacenan los recursos no
ontológicos usados por el SRSCC, específicamente un grupo de
información espacial relacionada con el comportamiento de un usuario, la
cual es generada en forma combinada por el Módulo de localización y el
Módulo de identificación de comportamiento de usuarios.
43
4.3 Descripción de los módulos principales de la arquitectura
Esta sección describe el análisis desarrollado para la definición de los elementos
principales de la arquitectura propuesta, especificando los módulos cuyo
desarrollo se contempla dentro de los alcances de este trabajo de tesis. Dichos
módulos están relacionados con el modelado semántico de la información de la
organización, el proceso de inferencia, la interacción con las recomendaciones por
parte de un usuario y el análisis sobre la forma en que estas influyen en su
comportamiento. Los apartados siguientes detallan las características generales
de cada módulo y en el capítulo 5 se explica la forma en que han sido
implementados en un SRSCC.
4.3.1 Repositorio de recursos ontológicos y la Ontología de
Memoria Organizacional 1.0
Dado que la arquitectura considera un proceso de inferencia a partir de las
instancias de una ontología o red de ontologías, se define un elemento para
almacenarlas, denominado Repositorio de recursos ontológicos, el cual puede
ser implementando reutilizando recursos ontológicos existentes. Como parte del
trabajo realizado, se ha definido un modelo semántico propio que se presenta en
esta sección, el cual es una red de ontologías llamada Ontología de Memoria
Organizacional versión 1.0.
Esta red de ontologías tiene el objetivo de describir semánticamente dimensiones
contextuales a considerar durante el proceso de inferencia de las
recomendaciones, además de las características que dan identidad a una
organización, usando un nivel de granularidad adecuado para permitir el modelado
de distintos tipos de organizaciones como empresas, IES, instituciones de
gobierno o incluso eventos académicos (congresos, simposios, etc.).
Es importante señalar que la Ontología de Memoria Organizacional versión 1.0
puede ser extendida, modularizada y/o personalizada mediante técnicas de
reutilización de recursos ontológicos. Esta red de ontologías contiene diversos
grupos de información modelados en 19 ontologías interconectadas, las cuales
han sido desarrolladas a partir de recursos ontológicos y no ontológicos
estandarizados o comúnmente aceptados, los cuales están asociados a diferentes
dominios de conocimiento y se integran de acuerdo a su importancia,
disponibilidad y potencial de explotación.
44
Un esquema conceptual de esta red de ontologías se muestra en la Figura 4.4, en
el cual se resaltan aquellas ontologías desarrolladas total o parcialmente como
parte de otros trabajos de tesis.
Figura 4.4: Ontología de Memoria Organizacional versión 1.0
Las ontologías que conforman la red se explican a continuación:
Activity ontology: esta ontología está diseñada para modelar las
actividades que se realizan en una organización, para lo cual, se reutilizan
elementos de las ontologías SWEET Human Activities24 y ConOnto
Activity25, además de conceptos extraídos del proyecto TOVE26 , con los
cuales, se describen las actividades que desempeñan las personas
pertenecientes a una organización, considerando el tipo de actividad, su
asociación a un área de conocimiento, condiciones para su realización,
estados previos y posteriores a la realización de una actividad, el propósito
24
http://gcmd.nasa.gov/records/SWEET-Ontology.html 25
http://www.site.uottawa.ca/~mkhedr/contexto.html 26
http://www.eil.utoronto.ca/enterprise-modelling/tove/
45
de su ejecución, su relación con otras actividades y el tipo de personas que
la ejecutan. Otro punto resaltable es que al relacionarla con el resto del
modelo semántico, es posible describir los recursos organizacionales
usados para el desarrollo de una actividad, las habilidades de las personas
que las realizan e información espacio-temporal sobre las condiciones en
que es ejecutada.
Advertising ontology: esta ontología modela conocimiento relacionado a
la forma en que una organización difunde sus ideas, productos y servicios.
Para su desarrollo, se toman definiciones de la EASA27 (European
Advertising Standards Alliance) y de la ASA28 (Advertising Standars
Authority), según las cuales, se maneja una clasificación de mercados y
medios de comunicación, además de una clasificación de tipos de
publicidad y promociones comerciales.
Al integrar esta ontología al modelo semántico, es posible describir
estrategias de publicidad definidas para los productos y servicios ofrecidos
por una organización, las entidades relacionadas con el proceso publicitario
y la manera en que una organización invierte en publicidad, entre otras
cosas.
Commerce ontology: esta ontología modela conocimiento relacionado a la
compraventa de productos y servicios, lo cual es descrito bajo un enfoque
orientado a entidades organizacionales, para ello se reutiliza la ontología
Goodrelations29, que está diseñada para e-comercio y describe los
elementos necesarios para la comercialización de productos y servicios.
Al integrar esta ontología al modelo semántico, se puede usar para describir
el proceso de comercialización seguido por una organización y relacionarlo
a estrategias de publicidad.
Competence ontology: esta ontología se basa en el proyecto SEEMP para
manejar el conocimiento relacionado a las competencias de una
organización [Gómez-Pérez, 2007]. Usando esta ontología en el modelo
semántico propuesto, es posible identificar competencias organizacionales
y describir la asociación entre competencias y habilidades o competencias y
ocupaciones. La ontología reutiliza el catálogo de competencias O*Net.
Device ontology: esta ontología, tomada del proyecto MiO!, reutiliza la
ontología CoDAMoS y modela información sobre el hardware, el software y
la plataforma de los dispositivos [Cadenas, 2009]. Empleando esta
27
http://www.easa-alliance.org/Issues/page.aspx/72 28
http://www.asa.org.uk/Regulation-Explained/What-we-cover.aspx 29 http://purl.org/goodrelations/
46
ontología en el modelo semántico, es posible describir los dispositivos
usados por los usuarios de un SRSCC.
Economic Activities ontology: esta ontología toma como referencia el
proyecto SEEMP, y se basa en la Nomenclatura de Actividades
Económicas de la Comunidad Europea elaborada en el 2007, comúnmente
conocida como NACE Rev. 2, el cual es un estándar que clasifica a las
actividades económicas de acuerdo a 996 elementos organizados en 21
grupos principales. La integración de esta ontología al modelo semántico
permite asociar organizaciones, personas y ocupaciones a un tipo
especifico de actividad económica [Gómez-Pérez, 2007].
Education ontology: esta ontología es planteada a partir de la propuesta
desarrollada en el proyecto SEEMP, según la cual, se modela conocimiento
sobre niveles y campos de educación. La definición de los campos de
educación está basada en la clasificación europea de campos de educación
y entrenamiento FOET, la cual define 127 campos de educación, y además,
los niveles de educación son concebidos a partir del estándar internacional
de clasificaciones de la educación ISCED97 establecido por la UNESCO y
que define 7 niveles de educación [Gómez-Pérez, 2007]. La ontología es
usada dentro del modelo semántico para describir la educación que ha
cursado una persona.
Indoor Location ontology: esta ontología modela conocimiento
relacionado a la forma en que una entidad física puede ser localizada
dentro de las instalaciones de una organización, para ello se considera el
uso de tecnologías RFID, 802.11, 802.15 y QR-Code. La ontología es
usada dentro del modelo semántico para describir los mecanismos de
localización implementados en las instalaciones de una organización.
Infrastructure ontology: esta ontología describe el conocimiento
relacionado con las instalaciones de una organización, considerando
espacios interiores y exteriores al reutilizar elementos de las ontologías
LAIR [G Look, 2005], OntoNav30, ONALIN [M. Dudas, 2009] y COBRA-ON
[Chen,2004]. Dentro del modelo semántico, esta ontología es explotada
para definir un espacio donde se realiza una actividad, la asignación de
personas a un área de trabajo, la asociación de recursos tecnológicos y
objetos de conocimiento a un espacio determinado, la pertenencia de un
edificio a una organización y la localización geográfica de un espacio
específico de la organización.
Interface ontology: esta ontología, tomada del proyecto MiO!, modela
información sobre las diferentes interfaces de usuario que un dispositivo
puede proporcionar [Cadenas, 2009]. En el modelo semántico, esta
30
http://p-comp.di.uoa.gr/projects/ontonav/index.html
47
ontología se usa para saber las interfaces asociadas al dispositivo de un
usuario.
Knowledge Objects ontology: esta ontología modela información sobre
representaciones físicas o electrónicas de conocimiento, considerando que
dicho conocimiento puede estar plasmado en forma de texto, audio, video
o imagen. Para el desarrollo de esta ontología, se reutilizan elementos de la
ontología DBLP31, la cual defines las clases y atributos de diferentes tipos
de publicaciones. La ontología es usada dentro del modelo semántico para
describir los objetos de conocimiento que pertenecen a una organización,
su uso en el desarrollo de una actividad, su distribución en las instalaciones
y su asociación con los miembros de la organización.
Language ontology: esta ontología sigue la propuesta desarrollada en el
proyecto SEEMP, según la cual, se emplea el estándar ISO 6392, que
define la nomenclatura de los lenguajes y el marco común europeo de
referencia para las lenguas CEF32 para modelar el conocimiento
relacionado a los lenguajes. Esta ontología se integra al modelo semántico
para especificar información multilingüe relacionada a una organización,
como los idiomas que habla una persona o en los que se encuentra escrito
un objeto de conocimiento, entre otros usos. [Gómez-Pérez, 2007].
Location ontology: esta ontología, extraída del proyecto MiO!, es usada
para modelar información relacionada a la localización, como entidades
geopolíticas, entidades espaciales, coordenadas, distancia entre
posiciones, entre otros elementos. En su diseño se reutilizó la ontología
SOUPA33 [Cadenas, 2009] y es integrada al modelo semántico para
describir la localización espacial de personas, organizaciones y de los
edificios de la organización.
Occupation ontology: en esta ontología se considera el trabajo ontológico
desarrollado en el proyecto SEEMP, según el cual se plantea un modelo de
conocimiento sobre ocupaciones y empleos, tomando como base el ISCO-
2008 (COM), el catálogo de ocupaciones O*Net y la clasificación europea
de ocupaciones Eures [Gómez-Pérez, 2007]. La ontología es usada en el
modelo semántico para describir las ocupaciones que se desempeñan en
una organización y las ocupaciones que una persona puede desempeñar.
Organization ontology: esta ontología es la parte central del modelo
semántico, y describe información sobre una organización, empleando la
ontología FOAF34 para manejar los datos generales y de contacto de una
organización, además, se utilizan definiciones del estándar contable
31
http://swat.cse.lehigh.edu/projects/index.html#dldb 32
http://www.coe.int/t/dg4/linguistic/cadre_en.asp 33
http://cobra.umbc.edu/ont/soupa-ont.tar.gz 34
http://xmlns.com/foaf/spec/
48
internacional IAS35 y de las Normas Internacionales de Contabilidad 2008
NIC´s36 para modelar aspectos financieros de la organización. De manera
adicional, se utilizan definiciones ontológicas presentadas en el proyecto
para el modelado de empresas públicas y comerciales TOVE, del cual se
extraen elementos para el modelado de metas, roles, políticas y estructuras
organizacionales, además de las líneas de comunicación a través de las
cuales interactúan los miembros de una organización.
Skill ontology: esta ontología permite modelar el conocimiento relacionado
a las habilidades asociadas a una competencia organizacional, retomando
el trabajo ontológico desarrollado en el proyecto SEEMP, el cual se basa en
la clasificación europea de habilidades Eures [Gómez-Pérez, 2007].
Time ontology: en esta ontología, extraída del proyecto MiO!, se modela
información temporal, tal como: unidades temporales, entidades
temporales, instantes, intervalos, etc. Esta ontología es obtenida por la
reutilización de la ontología OWL-Time [Cadenas, 2009]. En el modelo
semántico propuesto, esta ontología permite asociar elementos temporales
a las actividades y eventos desarrollados en una organización.
Technology Resources ontology: esta ontología modela información
sobre recursos especializados que una organización posee, incluyendo
herramientas, equipos, instrumentos, materiales, máquinas y dispositivos.
Para desarrollarla, se tomaron en consideración definiciones de las NIC´s
referentes a los activos fijos de una organización, además de conceptos
extraídos del proyecto TOVE37, con lo cual, al integrar la ontología al
modelo, es posible describir el uso de los recursos tecnológicos de una
organización en la ejecución de actividades, su asignación a instalaciones
específicas, las personas responsables de ellos y los objetos de
conocimiento que describen su funcionamiento, por ejemplo.
Person ontology: esta ontología es usada para modelar información sobre
personas, incluyendo descripciones sobre sus intereses y preferencias,
además de información general y de contacto. Está diseñada reutilizando la
ontología FOAF38 y es usada para describir tanto a los miembros de una
organización, como a los usuarios de un SRSCC.
35
www.iasplus.com/standard/standard.htm 36
http://www.normasinternacionalesdecontabilidad.es 37
http://www.eil.utoronto.ca/enterprise-modelling/tove/ 38
http://xmlns.com/foaf/spec/
49
4.3.2 Módulo Motor de Inferencia y reglas de inferencia
Explotando el modelo semántico descrito en la sección anterior, es posible
procesar las instancias almacenadas en el Repositorio de recursos
ontológicos, con el objetivo de identificar ítems que le resulten interesantes a los
usuarios. Este filtrado puede ser ejecutado mediante la aplicación de reglas de
inferencia por parte del Módulo Motor de Inferencia definido en la arquitectura
propuesta.
Dadas las dimensiones modeladas y enfocándose al ambiente organizacional, se
tienen los elementos necesarios para definir reglas de inferencia de acuerdo a las
siguientes características:
Cercanía a los usuarios: el modelo permite explotar información espacial
en distintos niveles y bajo diversas apreciaciones, lo cual se logra al
considerar la localización de los elementos modelados, ya sea mediante
coordenadas geográficas usando el sistema clásico de latitud y longitud
para ambientes urbanos, o bien, identificando su posición en un punto
específico de las instalaciones de una organización, mediante un sistema
de coordenadas cartesianas para ambientes de tipo campus.
Disponibilidad de los ítems: con el modelo planteado, se pueden definir
reglas de inferencia que exploten políticas internas de una organización
para definir la accesibilidad de un ítem, ya sea en base a restricciones de
acceso para distintos tipos de usuarios, funcionamiento interno de acuerdo
a distintos momentos temporales o el estatus de los ítems dentro de un flujo
de trabajo, entre otras.
Información temporal: usando el módulo ontológico para el modelado de
entidades temporales, es posible definir reglas de inferencia que operen
sobre factores relacionados a intervalos de tiempo, épocas del año, zonas
horarias, duración de actividades, horarios y calendarios, por ejemplo.
Dispositivos de los usuarios: usando el modelo ontológico es posible
definir reglas que exploten las características de hardware y software sobre
el dispositivo de un usuario, como plataforma, conectividad, pantalla o
cámara, por ejemplo.
Aplicabilidad de los ítems: explotando el modelo ontológico, es posible
definir reglas de inferencia que identifiquen el potencial de utilidad de un
ítem en base a las actividades en que es utilizado, el conocimiento
requerido para usarlo o la manera en que son empleados dentro de la
comunicación interna de la organización.
50
Estas características son combinadas con las preferencias, intereses y habilidades
de los usuarios para obtener un conjunto de recomendaciones adecuadas para
ellos. El caso de uso mostrado en la Figura 4.5 representa el comportamiento
dentro de la arquitectura propuesta de un Motor de Inferencia de este tipo al
relacionarse con el resto de módulos.
Figura 4.5: Caso de uso del comportamiento del Motor de Inferencia de un SRSCC organizacional implementado para diversos tipos de organizaciones
Dado que el procesamiento sobre ontologías normalmente presenta un alto costo
en tiempo, se propone un tipo de proceso de inferencia dividido en sub-procesos,
lo cual tiene como objetivo reducir el tiempo que un usuario debe esperar para
consultar las recomendaciones que se le ofrecen, en especial durante su visita a la
organizacional.
La estrategia diseñada, contempla un pre-filtrado de ítems recomendables que
permite identificar aquellos que puedan resultar interesantes a un usuario, y
posteriormente, la realización de un post-filtrado de éstos en base a su
disponibilidad al momento de que dicho usuario visita una organización. Este
planteamiento es presentado gráficamente en la Figura 4.6.
51
Además, el Módulo Motor de Inferencia también puede procesar las
recomendaciones en un proceso adicional para organizarlas jerárquicamente a
partir de diversos factores como su popularidad, su disponibilidad, antigüedad u
otros.
Figura 4.6: Etapas del proceso de inferencia planteado para el Motor de Inferencia del SRSCC organizacional T-Guía
4.3.3 Definición de una GUI adaptable con mecanismos de
monitoreo
En este trabajo de tesis, se sigue la tendencia de utilizar distintas fuentes de
información para ofrecer una interfaz adaptable en los clientes de un sistema de
recomendación [Cadenas, 2009], por lo que se propone explotar el modelo
ontológico descrito en la sección 4.3.1 en la definición de las interfaces gráficas
del cliente de un SRSCC, las cuales deben ser capaces de adaptarse a las
características de los usuarios y de los dispositivos a utilizar, siguiendo un enfoque
centrado en la Interacción Humano-Máquina.
Para su desarrollo, se propone un método que toma como entrada información
referente a los requisitos del proyecto y cuya salida es un conjunto de interfaces
gráficas para el cliente del SRSCC, las cuales son asociadas a los distintos tipos
de usuarios. El método se compone de los siguientes pasos:
Paso 1. Identificación de las características de los usuarios del
sistema: Este paso consiste en identificar un conjunto de características
distintivas y significantes de los usuarios de un SRSCC, así como de los
dispositivos en los que se implementarán los clientes del sistema, en base a
los requisitos del proyecto y el uso de las ontologías Person y Device que
forman parte del modelo semántico presentado en el apartado 4.3.1.
52
Paso 2. Generación de grupos de características de usuario: Este paso
consiste en agrupar las características identificadas en el paso 1 de
acuerdo a su dominio.
Paso 3. Definición de perfiles de usuario: Este paso consiste en definir
un conjunto de perfiles de usuarios del sistema, clasificando a los usuarios
de acuerdo a los grupos de características obtenidos en el paso 2. En este
paso es posible unir diferentes grupos de características buscando lograr
una mayor precisión en la meta de proporcionar a un usuario una GUI que
le resulte agradable y útil para sus propósitos.
Paso 4. Definición de funcionalidades del sistema: Este paso consiste
en definir el conjunto de funcionalidades disponibles para cada perfil de
usuario obtenido en el paso 3.
Paso 5. Definición de contenidos: Este paso consiste en definir la
estructura de información adecuada para cada perfil de usuario obtenido en
el paso 3. Se puede considerar tanto la información que se presenta a un
usuario como la manera en que esta información se organiza.
Paso 6. Definición de una GUI estándar: Este paso consiste en diseñar
una interfaz estándar para el cliente del SRSCC.
Paso 7. Definición de la GUI adaptable: Este paso, consiste en tomar
como base la GUI estándar definida en el paso 6 y adaptarla a los usuarios,
lo cual se realiza al diseñar una interfaz para el cliente del SRSCC
específica por cada perfil de usuario obtenido en el paso 3, que implemente
las funcionalidades definidas en el paso 4 con la estructura de información
correspondiente identificada en el paso 5.
Paso 8. Modelado semántico de la GUI adaptable: Este paso consiste en
modelar cada interfaz obtenida en los pasos 6 y 7 usando la ontología
Interface del modelo semántico.
Paso 9. Asociación de usuarios a la GUI adaptable. Este paso consiste
en utilizar el Motor de Inferencia para asociar cada usuario con una
interfaz específica dentro del conjunto de interfaces obtenido en el paso 7,
lo cual se realiza en base a las características del usuario y de su
dispositivo. En caso de no contar con información suficiente, asociar un
usuario con la interfaz estándar definida en el paso 6.
Paso 10. Implementación de la GUI adaptable: Este paso consiste en
implementar en dispositivo del usuario la interfaz que le fue asociada en el
paso 7. En el caso de que el dispositivo sea utilizado por distintos usuarios
del sistema, implementar todas las interfaces de usuario que el dispositivo
soporte e instanciarlas durante el proceso de inicio de sesión conforme un
usuario vaya haciendo uso del SRSCC.
53
El modelo semántico, detallado en el apartado 4.3.1, permite identificar perfiles de
usuarios de acuerdo diversos parámetros, como intereses y preferencias, edad,
idioma, profesión, nivel educativo, género, plataforma del dispositivo u otras
características de los equipos móviles, entre otros. Estos perfiles de usuario
permitirán establecer las características de la GUI adaptable al usuario.
La adaptabilidad de la interfaz del cliente puede enfocarse al contenido de
información que se presenta a un usuario, la disponibilidad de las distintas
funciones existentes en el sistema o cuestiones de diseño, como lo son el uso de
imágenes, colores, tamaños de letra o la disposición de los elementos gráficos,
entre otros.
De manera adicional, en este trabajo de tesis se sigue el planteamiento propuesto
durante el desarrollo del proyecto SMARTMUSEUM [Liiv, 2009], para implementar
técnicas que permitan identificar el grado de satisfacción de un usuario con
respecto a una recomendación, por lo que se propone un tipo de monitoreo que
combine enfoques implícitos y explícitos, el cual está basado principalmente en la
interacción entre los usuarios y la GUI del SRSCC.
El aspecto implícito del monitoreo, propuesto para determinar la popularidad de los
ítems recomendados entre los usuarios, consiste en analizar las acciones que
cada usuario realiza, tanto usando la GUI como en el mundo real, con respecto a
cada recomendación que el SRSCC le ofrece, siendo que estas acciones pueden
ser usadas para tener un ranqueo de los ítems.
El conjunto de acciones está compuesto por las opciones que se proporcionan, a
través de la GUI, para que los usuarios administren las recomendaciones recibidas
y se complementan con el análisis del comportamiento de un usuario, que es
posible gracias a las funcionalidades del Módulo de localización y del Módulo
de identificación de comportamiento de usuarios.
Además, entre las acciones a realizar, se contempla la posibilidad de que las
recomendaciones sean evaluadas manualmente por un usuario, lo cual
correspondería a un enfoque explicito de monitoreo. La definición de valores
válidos asignables a un ítem y el conjunto de acciones reconocidas por el
monitoreo se definen por los desarrolladores de acuerdo a las necesidades de un
SRSCC.
La información generada con la implementación de estos mecanismos puede ser
procesada por el Módulo de identificación de comportamiento de usuarios y
almacenada en el Repositorio de recursos no ontológicos para posteriormente ser
explotada por el Motor de Inferencia.
54
4.3.4 Módulo de identificación de comportamiento de usuarios y
análisis del funcionamiento de un SRSCC
Para realizar un filtrado de información más eficiente, existen enfoques que
proponen que el Motor de Inferencia de un SRSCC, además de información
proveniente de recursos ontológicos, considere información extraída de recursos
no ontológicos, lo cual permite aumentar la exactitud de las recomendaciones que
se ofrecen a un usuario.
De acuerdo a la arquitectura mostrada en la sección 4.2, se propone usar el
elemento Repositorio de recursos no ontológicos para administrar fuentes de
información que no sean modeladas semánticamente, las cuales contengan datos
que permitan optimizar el proceso de inferencia o reflejen un historial del
funcionamiento del SRSCC, por ejemplo. En el caso del historial, puede ser
explotado para identificar aspectos relevantes asociados con las
recomendaciones, como la popularidad de un ítem o su nivel de novedad.
El uso de historiales dentro del proceso de recomendación es un factor común en
el estado de arte presentado, y para la arquitectura propuesta, el Módulo de
identificación de comportamiento de usuarios se encarga de identificar,
analizar y gestionar el comportamiento de los usuarios y del propio SRSCC, a fin
de tener una fuente de información correspondiente a las recomendaciones
efectuadas previamente, la percepción de las mismas por parte de los usuarios y
el contexto en que se infirieron, de tal modo que el historial propuesto para este
trabajo se estructura en los siguientes grupos de información:
Historial de recomendaciones: siguiendo la tendencia marcada en
diversos proyectos ([Bouzeghoub, 2009], [Liiv, 2009] y [Rasanen, 2009]),
en este grupo de información se almacena las recomendaciones ofrecidas
a los usuarios, a fin de determinar cuándo una recomendación resulta
novedosa para un usuario específico. Además, se almacena la valoración
otorgada por el usuario a cada ítem recomendado lo cual es útil para
calcular su popularidad. El valor que se almacena para cada
recomendación es calculado por una combinación de la entrada manual con
un monitoreo implícito de acuerdo al planteamiento presentado en el
apartado 4.3.4.
Historial del contexto: basándose en una propuesta sobre la
administración del contexto de un SRSCC [Cadenas, 2009], en este grupo
de información se almacenan las características contextuales presentes al
momento de efectuar una recomendación, como la ubicación del usuario,
información temporal o la disponibilidad de los ítems, entre otras
55
particularidades. Esta información, combinada con el historial de acciones,
puede ser útil para la identificación de patrones de comportamiento entre
los usuarios. En el caso del SRSCC organizacional T-Guía, se define un
historial de contexto centrado en información espacio-temporal asociada a
las recomendaciones como se especifica en el apartado 4.3.4, sin embargo,
los grupos de información pueden ser extendidos para satisfacer las
necesidades de un proyecto específico o inferir factores no evidentes
explotando características de los usuarios, características del hardware
utilizado, características de las interfaces implementadas en los clientes del
SRSCC o características relacionadas con el ambiente organizacional,
entre otros aspectos.
Historial de acciones: tomando como base los conceptos presentados en
la arquitectura ICAS [Sousa, 2009], en este grupo de información se
almacenan las acciones que realizan los usuarios a partir de las
recomendaciones recibidas, lo cual puede intervenir en el proceso de
recomendación determinando frecuencias de uso. Para la implementación
de este historial, las acciones y su valoración son especificadas en relación
a las necesidades del proyecto, considerando que las acciones se definen
por predicados que corresponden a tripletas en el formato
Usuario+Accion+Item, que al aplicarse a elementos específicos, pueden
leerse como María + consulta_información_de + Sitio Web, o Juan +
entra_a + Edificio Administrativo, por ejemplo. La intención de utilizar este
formato, es establecer un conjunto de información que sea fácilmente
trasladado a un modelo semántico que describa la conducta de los usuarios
de un SRSCC.
La salida del Módulo de identificación de comportamiento de usuarios es
almacenada en el componente Repositorio de recursos ontológicos, para
posteriormente ser considerada por el Módulo Motor de Inferencia en el proceso
de recomendación, además, puede ser explotada para permitirles a los
administradores de un SRSCC conocer el desempeño del mismo. Este
desempeño puede expresarse en base a consultas sobre los datos referentes a
las recomendaciones inferidas, las condiciones en que se infirieron, la interacción
de los usuarios con el sistema y el comportamiento de los usuarios con respecto a
las recomendaciones. Para la generación de esta información, se proponen dos
aspectos a considerar: por un lado los usuarios del sistema y cómo impactan las
recomendaciones que reciben en las acciones que realizan, y por otro lado,
identificar qué es lo que recomienda el SRSCC, con qué frecuencia y bajo qué
condiciones contextuales.
56
4.4 Utilización de la arquitectura propuesta para un SRSCC
organizacional
A fin de usar la arquitectura propuesta en el desarrollo de SRSCCs
organizacionales, se sugieren las siguientes actividades para reutilizar los
conceptos descritos en este capítulo:
Actividad 1: Especificación de requerimientos de un SRSCC
organizacional. Esta actividad corresponde directamente con la Ingeniería
de requisitos, refiriéndose a todas las tareas relacionadas con la
identificación de las necesidades y particularidades que el SRSCC debe
satisfacer, tomando en cuenta las características de los usuarios y de los
equipos a utilizar. Entre los aspectos a definir, se incluyen el entorno de
operación del SRSCC organizacional, su dominio de recomendación y las
características de los clientes a implementar, por ejemplo. Esto se logra con
la aplicación de las técnicas establecidas en la ingeniería de requisitos,
tomando como entrada la información relacionada al SRSCC a desarrollar y
produciendo como salida un conjunto de requisitos.
Actividad 2: Reutilización de la arquitectura del sistema. En esta
actividad, los desarrolladores toman como entrada la arquitectura
presentada en la sección 4.2 y el conjunto de requisitos producido en la
actividad 1, con el propósito de identificar los módulos que les sean de
utilidad para el SRSCC a desarrollar; posteriormente, se pueden añadir
módulos adecuados para satisfacer los requerimientos del SRSCC en caso
de ser necesario. Como salida de la actividad, se tiene una arquitectura de
sistema acorde al SRSCC a desarrollar.
Actividad 3: Especificación de Requisitos ontológicos: esta actividad
corresponde a la especificación de requisitos de una ontología definida en
la NeOn methodology [Suárez – Figueroa, 2010], y se refiere a la
identificación de los requisitos que el modelo semántico del SRSCC
organizacional a desarrollar debe cumplir. Para ello, se toma como entrada
un conjunto de necesidades ontológicas y se produce como salida un
Documento de Especificación de Requisitos de la Ontología (ORSD) de
acuerdo a la plantilla manejada en la NeOn methodology.
Actividad 4: Reutilización del modelo semántico. Esta actividad toma
como entrada el Documento de Especificación de Requisitos de la
Ontología producido en la actividad 3, el objetivo es identificar los módulos
ontológicos del modelo descrito en la sección 4.3.1 que sean de utilidad
para el SRSCC que se pretende desarrollar, por lo tanto, se tiene como
salida un nuevo modelo semántico acorde a las necesidades del proyecto
57
en desarrollo. Para la ejecución de la actividad, se sugiere usar el
escenario de reutilización de recursos ontológicos definido en la NeOn
methodology [Suárez – Figueroa, 2010].
Actividad 5: Implementación de los módulos del SRSCC. En esta
actividad, se implementan los módulos del sistema definidos en la actividad
2 con excepción del Módulo Motor de Inferencia, la Módulo GUI
adaptable al usuario y el Módulo de identificación de comportamiento
de usuarios, los cuales se implementaran en las actividades posteriores.
Actividad 6: Implementación del Módulo Motor de Inferencia. Esta
actividad consiste en definir las reglas de inferencia que el SRSCC
organizacional utilizará para producir las recomendaciones. Se toma como
entrada el conjunto de requisitos definido en la actividad 1 y el modelo
semántico producido en la actividad 4, sobre el cual aplicarán las reglas de
inferencia. Además, se toma en consideración las diferentes fuentes de
información correspondientes a recursos no-ontológicos, de acuerdo a la
implementación de los módulos del sistema efectuada en la actividad 5.
Actividad 7: Definición de una GUI adaptable al usuario. Como su
nombre lo indica, esta actividad consiste en aplicar el método descrito el
apartado 4.3.3 para producir una GUI adaptable al usuario implementada
para los clientes del SRSCC.
Actividad 8: Implementación de un módulo de identificación de
comportamiento de usuarios. Esta actividad tiene como objetivo
proporcionar a los administradores del SRSCC organizacional una forma de
interpretar el funcionamiento del sistema, lo cual se logra aplicando el
planteamiento descrito en la sección 4.3.4.
58
CAPÍTULO 5: DESARROLLO DEL SRSCC ORGANIZACIONAL T-GUÍA
Los contenidos de este capítulo hacen referencia al desarrollo de un sistema de
recomendación semántico consciente del contexto usando la arquitectura propuesta,
el cual es llamado T-Guía.
59
5.1 Introducción y características de implementación
El prototipo del SRSCC organizacional T-Guía fue desarrollado usando algunos de
los módulos de la arquitectura propuesta, con el fin de demostrar la efectividad de
los conceptos, métodos y técnicas presentados en el capítulo 4, además, el
funcionamiento del resto de los elementos fue simulado durante la fase de
pruebas. Estos módulos han sido implementados mediante el desarrollo diversas
aplicaciones que se distribuyen en dos partes principales, una del lado del servidor
y otra de lado del cliente móvil del sistema, como se muestra en la Figura 5.1.
Figura 5.1: Vista estática de los módulos del SRSCC organizacional T-Guía
Los módulos del lado servidor se desarrollaron utilizando el IDE NetBeans 6.8,
soportado sobre Microsoft Windows y se describen a continuación:
Aplicaciones Web: son un conjunto de aplicaciones que los usuarios y
administradores del SRSCC organizacional T-Guía pueden utilizar a través
de Internet mediante un navegador, formado por los proyectos SAIA y
Semantic T-Guide descritos con mayor detalle en los apartados 5.2.1.2 y
5.2.1.3, desarrollados bajo el Framework Struts 2, que se crean con el
objetivo de permitir poblar el Repositorio de recursos ontológicos para
tener un conjunto de información sobre la cual aplicar el proceso de
inferencia durante la fase de pruebas, emulando el funcionamiento del
Módulo de poblado de ontologías.
60
Por otra parte, el proyecto T-guide Admin, que utiliza los métodos de la
aplicación de escritorio 2DB T-Guide detallada posteriormente, se utiliza
para implementar el funcionamiento del Módulo de identificación de
comportamiento de usuarios. Mediante estas aplicaciones, los usuarios y
administradores del sistema pueden administrar la información tanto de los
perfiles de usuario, como de los elementos organizacionales a recomendar,
respectivamente. También se siguió el planteamiento descrito en el capítulo
anterior para implementar el uso de los historiales, estableciendo la
generación de reportes para los administradores del sistema en el T-guide
Admin.
Módulo Motor de Inferencia: los métodos de este módulo, implementados
de acuerdo a la estrategia planteada en la sección 5.3, están codificados en
un proyecto de NetBeans llamado OBCaRS T-Guide y permiten aplicar
sobre una ontología conjuntos de reglas de inferencia definidas en el
lenguaje SWRL, las cuales se almacenan en archivos de Excel en formato
97-2003.
Estas reglas son aplicadas con el método ruleEngine.infer() de la SWRL
Rule Engine API sobre la ontología multidimensional, la cual es manejada
mediante un TDB39, que es un componente de Jena40 que proporciona
almacenamiento de grandes volúmenes de datos RDF. Jena, un framework
semántico para Java, es capaz de soportar RDF, RDFS, OWL y SPARQL,
además de notaciones como RDF/XML, N3 y Ntriples [Jena]. En el mismo
proyecto se incluye también un método para simular el funcionamiento del
Módulo de localización, con el objetivo de utilizarlo durante la fase de
pruebas al sistema.
Repositorio de recursos ontológicos: este componente se refiere a la
ontología multidimensional implementada, que se describe en el punto 5.2,
la cual fue definida en el lenguaje OWL1 usando el editor de ontologías
Protégé en su versión 3.4, sin embargo, algunas de las ontologías
importadas como la ontología FOAF, se mantienen en RDF.
Repositorio de recursos ontológicos: mediante una estructura de
directorios en el servidor, los archivos que contienen las recomendaciones
generadas para cada usuario son almacenadas en el lenguaje XML
(Extensible Markub Language), y además, se almacenan los archivos que
contienen las reglas de inferencia.
GUI adaptable al usuario: se maneja un prototipo cliente móvil para el T-
Guía, el cual corre en el sistema operativo para dispositivos móviles
Android, y fue desarrollado utilizando el IDE de Eclipse, soportado sobre
39
http://openjena.org/wiki/TDB 40
http://jena.sourceforge.net/
61
Linux (Ubuntu 10.10) con el SDK de Android. El cliente, llamado Mobile T-
Guide, puede conectarse al servidor para acceder a un archivo .xml que
contiene las recomendaciones inferidas para un usuario, y las despliega en
una interfaz que adapta sus características gráficas y opciones de
navegación según el tipo de usuario para el que se muestren las
recomendaciones. La base de datos del dispositivo móvil, usada para
registrar las acciones que efectúa un usuario sobre la GUI, está
implementada utilizando el sistema de gestión de bases de datos SQLite41.
Una vista dinámica de la arquitectura, considerando las aplicaciones desarrolladas
durante la implementación del SRSCC organizacional T-Guía y cómo interactúan
entre sí, se presenta en la Figura 5.2. En dicha figura, se representa el
funcionamiento del T-Guía bajo la siguiente descripción: las aplicaciones web
SAIA y Semantic T-Guide permiten instanciar la información que será considerada
durante el proceso de inferencia. Estas instancias son almacenadas en un TDB en
el servidor, el cual es accedido por la aplicación OBCaRS T-Guide durante el
proceso de filtrado de ítems. En dicho proceso se aplican las reglas de inferencia,
organizadas en diferentes subconjuntos, que están especificadas en archivos .xls
almacenados en el servidor. Una vez que las recomendaciones han sido inferidas,
se crea con ellas un archivo xml que es accedido por la aplicación T-Guide Mobile,
la cual se encuentra en el cliente del SRSCC organizacional T-Guide, es decir, el
dispositivo móvil. El T-Guide Mobile permite al usuario interactuar con las
recomendaciones, a partir de lo cual se crea un segundo archivo xml que es
procesado por la aplicación 2DB T-Guide para registrar en una base de datos en
el servidor el comportamiento de los usuarios. La base de datos con la información
sobre el comportamiento de los usuarios es consultada por la aplicación T-Guide
Admin, la cual permite generar reportes sobre diversos aspectos del
funcionamiento del SRSCC organizacional T-Guía.
41
http://www.sqlite.org/
62
Figura 5.2: Vista funcional de los elementos del SRSCC organizacional T-Guía
Con el objetivo de generar un banco de datos sobre los cuales efectuar la fase de
pruebas al sistema, además de los elementos del T-Guía descritos previamente,
se llevo a cabo un conjunto de procesos, descritos en el apartado 5.2.1, para
poblar la Organizational Memory Ontology que es explotada por el Módulo Motor
de Inferencia. Detalles referentes a la versión del modelo semántico
implementado, su poblado y los módulos que lo explotan se presentan en las
secciones siguientes.
63
5.2 Reutilización de la Ontología de Memoria Organizacional 1.0
Para implementar el SRSCC organizacional T-Guía, se reutilizó la Ontología de
Memoria Organizacional 1.0 descrita en el capítulo 4, esto se logró al seleccionar y
adaptar los módulos ontológicos necesarios para modelar toda la información
considerada como relevante para el proceso de inferencia. Las modificaciones
hechas a los módulos seleccionados incluyó la agregación de propiedades de tipo
de dato y propiedades de objeto, la modificación del dominio o rango de
propiedades ya existentes y la creación o eliminación de clases e instancias.
Este proceso de adaptación, congruente con la Actividad 4: Reutilización del
modelo semántico de la metodología propuesta en la sección 4.3.1, permitió
definir una versión reducida de la red de ontologías original, que es el conjunto de
ontologías interconectadas entre sí llamado Organizational Memory Ontology,
cuyo contenido es resumido en la Figura 5.3:
Figura 5.3: Contenido del modelo ontológico reducido
64
El módulo ontológico correspondiente a la organización fue adaptado a una
ontología organizacional manejada en proyectos previos desarrollados en
CENIDET, con la finalidad de permitir la compatibilidad con ellos.
La codificación de la OrganizationalMemory.owl implementada en OWL 1 fue
realizada mediante el uso de Protégé 3.4, y su contenido coincide con los
elementos descritos en la ¡Error! No se encuentra el origen de la referencia..
El producto ontológico final se compone por 188 clases, 174 relaciones y 197
atributos obtenidos mediante la importación de las ontologías que se enlistan a
continuación y cuya incorporación a la ontología principal se expresa mediante la
Figura 5.4.
Figura 5.4: Implementación de la Organizational Memory Ontology usando el editor Protégé 3.4
Como parte del proceso de la documentación de la Organizational Memory
Ontology implementada, la herramienta OWLDoc [NeOn-OWLDoc] fue usada
como base para crear un conjunto de archivos .html que contienen el listado de
cada elemento de la ontología, organizados por ontologías, por clases, por
propiedades de tipo de dato, por propiedades de objeto y por instancias, los cuales
pueden ser visualizados con un navegador como se muestra en la Figura 5.5.
65
Figura 5.5: Ventana principal de la página de documentación de la Organizational Memory Ontology
Tabla 2.1: Ontologías importadas en implementación de la Organizational Memory Ontology
Prefijo Ontología Tipo de contenido
OM: http://www.CENIDET.edu.mx/OrganizationalMemory.owl
Elementos únicos de la Organizational Memory ontology
comerce: http://purl.org/goodrelations/v1 Elementos para modelar la comercialización de productos y servicios por parte de una organización
foaf: http://xmlns.com/foaf/0.1/ Elementos usados para modelar agentes organizacionales
time: http://www.w3.org/2006/time-entry
Elementos usados para el modelado de condiciones temporales
resource: http://www.CENIDET.edu.mx/TechnologyResource
Elementos que permiten el modelado de recursos tecnológicos pertenecientes a una organización
xfoaf: http://www.CENIDET.edu.mx/xfoaf.owl
Extensión a foaf manejada en proyectos desarrollados en
66
CENIDET accounting: http://www.CENIDET.edu.mx/Ac
counting Elementos usados para el modelado de aspectos contables y financieros de una organización
Advertising: http://www.CENIDET.edu.mx/Advertising
Elementos usados para modelar las estrategias publicitarias seguidas por una organización
wgs84_pos: http://www.w3.org/2003/01/geo/wgs84_pos
Elementos para el modelado de aspectos espaciales
ontoedu: http://www.owl-ontologies.com/ontoedu.owl
Elementos para el modelado de objetos de conocimiento pertenecientes a IES
KnowledgeObject: http://www.CENIDET.edu.mx/KnowledgeObject
Elementos para el modelado de objetos de conocimiento pertenecientes a diversos tipos de organizaciones.
infraestructura: http://www.CENIDET.edu.mx/IndoorLocation.owl
Elementos usados para el modelado de las instalaciones de una organización
languagecode: http://www.fao.org/aims/aos/languagecode.owl
Elementos usados para modelar idiomas
ontocompany: http://www.owl-ontologies.com/ontocompany.owl
Elementos para el modelado de objetos de conocimiento pertenecientes a empresas
Location: http://www.cenitmio.es/ontologies/Location.owl
Elementos para el modelado de una localización espacial
CompetencyCatalog: http://www.CENIDET.edu.mx/CompetencyCatalog.owl
Elementos usados para modelar las competencias que puede poseer una organización
OrganizationalActivities: http://www.CENIDET.edu.mx/OrganizationalActivities
Elementos usados para definir los distintos tipos de actividades que se pueden realizar en una organización
humanActivities: http://sweet.jpl.nasa.gov/ontology/human_activities.owl
Elementos para modelar las características de una actividad específica
dbpl: http://gate.ac.uk/gate-extras/neon/ontologies/lir/dbpl.owl
Elementos usados para el modelado de características multilingües
OccupationsOntology: http://droz.dia.fi.ump.es/ontologies/OccupationsOntologyTBox.owl
Elementos usados para modelar las ocupaciones asociadas a una organización
dblp: http://swat.cse.lehigh.edu/resources/onto/dblp.owl
Elementos usados para el modelado de publicaciones
67
Para el uso de la Organizational Memory Ontology por parte del SRSCC
organizacional T-Guía, se concentran todos los archivos que forman el proyecto
de Protégé asociado al modelo semántico implementado en una carpeta llamada
TGuideOntology. En esta carpeta se irán almacenando nuevas versiones de la
ontología conforme se ejecuten las etapas del proceso de inferencia, creando
distintos archivos .owl en los que se reflejen las recomendaciones inferidas. Estos
archivos servirán de base para la creación del TDB sobre el cual se operan los
submódulos del Motor de Inferencia de acuerdo a lo descrito en la sección 5.3.
5.2.1 Poblado de la Organizational Memory Ontology
implementada y la aplicación web Semantic T-Guide
La arquitectura para SRSCC, presentada en el capítulo anterior, contempla un
Módulo para el poblado de ontologías como medio para obtener las instancias
de los elementos organizacionales disponibles para ser recomendados, sin
embargo, dado que su implementación no se encuentra dentro de los alcances de
este trabajo, fue sustituido definiendo tres procesos diferentes de acuerdo al tipo
de instancias que se requieren para la Organizational Memory Ontology. Estos
procesos son descritos en los apartados siguientes.
5.2.1.1 Instanciación de los catálogos seleccionados: uso de la librería
NOR2O
A fin de mantener un control de la información que es proporcionada para ser
instanciada, se decidió emplear catálogos existentes sobre elementos claves del
modelo ontológico, considerando los siguientes:
Catálogo de intereses y áreas de conocimiento: este catálogo está
formado por la unión del Catálogo de áreas de conocimiento ANIEI, el
Catálogo de materias de investigación de la UNESCO y las líneas de
especialización manejadas por los miembros de CENIDET, y es usado para
reflejar tanto el interés de un usuario en algún tópico de las ciencias o
tecnología, como para manejar la asociación de objetos de conocimiento,
proyectos, actividades, eventos e instalaciones especializadas con una o
más áreas de conocimiento.
68
Catálogo de ocupaciones: este catálogo tiene como elementos la
traducción al español de las ocupaciones consideradas en la ontología
Occupation Ontology, descrita en el capítulo anterior, las cuales fueron
reducidas previamente al dominio de proyecto, considerando las ramas
correspondientes a Profesiones, Profesionales de la educación y Directivos
de empresas, añadiendo los puestos particulares manejados en CENIDET.
Este catálogo se utiliza para indicar la ocupación desempeñada por una
persona, las ocupaciones asociadas a una competencia organizacional y la
asociación de ocupaciones a una organización, además del tipo de clientes
que atiende una organización.
Catálogo de actividades económicas: este catálogo tiene como
elementos la traducción al español de las actividades económicas
consideradas en la ontología Economic Activity Ontology, descrita en el
capítulo anterior. El catálogo se utiliza para indicar el giro de una
organización, la posible explotación de un proyecto por parte de
organizaciones que realicen una determinada actividad económica o el tipo
de organizaciones que conforman el mercado sectorial que atiende una
organización.
Catálogo de zonas económicas: este catálogo tiene como elementos las
Regiones socioeconómicas consideradas por la INEGI. El catálogo es
usado para indicar la zona económica en la que se encuentra una
organización y las zonas económicas que conforman el mercado geográfico
que atiende una organización.
Catálogo de habilidades: este catálogo tiene como elementos la
traducción al español del catálogo de habilidades definido por O*Net, y es
utilizado en la especificación de las competencias individuales que posee
una persona, así como las habilidades que requieren tener las personas
asociadas a una actividad o evento de la organización, las habilidades
técnicas necesarias para usar un recurso tecnológico y las habilidades que
poseen los participantes en un evento.
Para instanciar los catálogos seleccionados en la ontología explotada por el
sistema de recomendación, primero se tomó la información que describe cada
catálogo desde distintas fuentes heterogéneas para unificarla manualmente en un
archivo de Excel en formato 97-2003, y luego, se empleó la librería NOR2O
[Villavizon, 2010] para convertirlos en instancias de dicha ontología, como se
muestra en la Figura 5.6.
69
Para utilizar la herramienta NOR2O es necesario editar tres archivos de
configuración: 1) el archivo nor.xml, que contiene la especificación del archivo
separado por comas (CSV, con extensión xls) que contiene los datos a instanciar,
2) el archivo prnor.xml que define el patrón de transformación para los datos
contenidos en el archivo CSV y 3) el archivo or.xml que permite definir la salida de
las instancias a una ontología existente o a una nueva ontología.
Figura 5.6: Proceso para la instanciación de catálogos
5.2.1.2 Instanciación de elementos organizacionales: Sistema de
Administración de Información Académica SAIA y método para la
transformación de sitios de IES a la web 3.0
Para el poblado de las instancias de los elementos organizacionales disponibles
para ser recomendados, considerando un caso de prueba sobre una institución de
educación superior, se utiliza el Sistema de Administración de Información
Académica (SAIA), el cual fue planteado para instanciar los ítems
correspondientes a la organización CENIDET.
Para el desarrollo de esta aplicación, se planteó un proceso para la transformación
de sitios de IES a la web 3.0 llamado MyEDU2SeWeb, el cual se basa en la
Metodología para Creación de Sitios Web de Maybel Gil42 y se conforma de las
siguientes fases:
42
http://www.casupo.org.ve/CV/may/alumnos.php
70
Fase I. Análisis: Esta fase se compone de 4 tareas principales:
Análisis del sitio actual: conocer y entender el funcionamiento del sitio de la
organización.
Definición de objetivos de la versión semántica del sitio: Establecer el
propósito de la implementación semántica del sitio actual.
Definición de Audiencia: definir los usuarios del sitio
Expectativas de la Organización: definir lo que la organización espera y no
espera lograr con la adaptación de su sitio web.
Fase II. Planificación: esta fase tiene como objetivo definir los aspectos claves
para la adaptación del sitio a la Web 3.0, y se compone de las siguientes tareas:
Selección del Software: Identificar herramientas y tecnologías que faciliten
la migración del un sitio Web a una versión semántica del mismo.
Selección de recursos ontológicos reutilizables: identificar ontologías o
redes de ontologías cuyos elementos coincidan con el dominio del sitio web
a transformar.
Selección del equipo de trabajo: Identificar al personal necesario para
realizar la transformación del sitio y asignarles tareas de acuerdo a sus
competencias individuales.
Benchmarking: Definir una estrategia que permita la evaluación subjetiva y
cuantitativa del proceso de transformación del sitio.
Definición de la Estructura de Navegación: definir la forma en que los
visitantes podrán saltar de una página a otra dentro del sitio Web utilizando
el sistema de hipervínculos.
Costos de Inversión: estimar los costos en recursos que conlleva la
ejecución del proyecto.
Beneficios a obtener: definir los beneficios que la organización espera
obtener con la implementación de una versión semántica del sitio.
Fase III. Contenido: esta fase busca definir la relación entre módulos ontológicos
y los contenidos que se mostraran en la versión semántica del sitio. Las tareas
que la componen son:
Definición del contenido conceptual: definir el conjunto de información que
será mostrada en la nueva versión del sitio web.
71
Asociación de módulos ontológicos a los bloques de contenido: Definir las
clases, atributos y relaciones asociados a los bloques de contenidos que se
mostraran.
Identificación de fuentes de información heterogéneas: identificar la
existencia, disponibilidad y accesibilidad actuales de la información que se
mostrará en la versión semántica del sitio web.
Priorización de bloques de contenido: definir conjuntos de información
claves para conseguir los beneficios esperados por la organización.
Poblado de los módulos ontológicos: realizar el poblado de los bloques de
contenido definidos para el sitio, poniendo especial atención en aquellos a
los que se les haya asignado mayor prioridad
Fase IV. Diseño: Esta fase tiene el objetivo de diseñar la nueva versión del sitio
Web tomando en cuenta cuestiones tales como navegabilidad, interactividad y
arquitectura de la información.
Diseño basado en usabilidad: diseñar la nueva versión del sitios Web de
forma tal que los usuarios puedan interactuar con ellos de la forma más
fácil, cómoda e intuitiva posible
Diseño basado en accesibilidad: diseñar la nueva versión del sitio
considerando que este y sus contenidos sea accedidos por todas las
personas independientemente de la discapacidad (física, intelectual o
técnica) que presenten o de las que se deriven del contexto de uso
(tecnológicas o ambientales).
Fase V. Programación: Esta fase tiene como objetivo la implementación de la
nueva versión del sitio Web. Las tareas que componen son las siguientes:
Administración de la base de conocimientos: programar todos los
elementos necesarios para la creación, modificación, eliminación y
explotación de las instancias asociadas con la nueva versión del sitio Web.
Administración de la base de datos: programar todos los elementos
necesarios para la creación, modificación, eliminación y explotación de los
elementos que no puedan ser almacenados en una ontología o red de
ontologías, como archivos descargables, imágenes, etcétera.
Programación Intermedia: programar los elementos asociados con la
administración del sitio web, como manejo de sesiones, autenticación de
usuarios, funciones permitidas a los usuarios, etcétera.
Interfaz: codificar e implementar la interfaz gráfica de usuario diseñada para
la nueva versión del sitio web.
72
Fase VI. Testeo: Esta fase tiene el objetivo de comprobar el correcto
funcionamiento de la nueva versión del sitio web.
Detección de errores (bugs): pruebas generales a toda la funcionalidad del
nuevo sitio Web.
Comprobación de comportamiento en ambientes concurrentes: verificación
de la persistencia y congruencia de las instancias asociadas con el sitio
Web.
Análisis del desempeño del sitio: pruebas para evaluar aspectos del
desempeño del sitio al operar sobre ontologías o redes de ontologías.
Identificación de áreas de oportunidad: definir posibles mejoras al sitio Web
semántico.
Fase VII. Mercadeo y Publicidad: esta fase tiene como objetivo dar a conocer la
versión semántica del sitio web de la organización, y consiste en difundirlo
mediante redes de colaboración o mediante redes sociales, por ejemplo.
El SAIA fue desarrollado siguiendo esta metodología, tomando como base el sitio
Web tradicional del CENIDET para crear una nueva versión semántica del mismo,
la cual es capaz de reflejar la estructura del modelo semántico manejado en el
capítulo 4, de tal forma que permite la creación, modificación, eliminación y
recuperación de instancias sobre la Organizational Memory Ontology por medio de
un almacén de tripletas (TDB de Jena) que es sincronizado con la ontología cada
vez que una operación se realiza. Este proceso es representado por la Figura 5.7.
Figura 5.7: Proceso para la instanciación de elementos organizacionales
73
5.2.1.3 Registro de los usuarios del T-Guía: Semantic T-Guide
Para permitir el registro de los usuarios del T-Guía, se presenta una aplicación
web llamada Semantic T-Guide, que permite a los usuarios crear o modificar una
cuenta con la que utiliza el sistema. La aplicación reutiliza un servicio web,
desarrollado previamente en CENIDET, para realizar operaciones de creación,
modificación y recuperación de instancias sobre la Organizational Memory
Ontology por medio de un almacén de tripletas (TDB) que es sincronizado con la
ontología cada vez que una operación se realiza. El proceso realizado por el
Semantic T-Guide es representado en la Figura 5.8.
Figura 5.8: Proceso para la instanciación de usuarios del T-Guía
Los bloques de información que se ingresan en el Semantic T-Guide, los cuales
definen el perfil de un usuario, están estructurados en formularios
correspondientes a los datos de una cuenta, datos del usuario y a datos de una
organización a la que pertenece, siendo estos últimos opcionales en caso de que
el usuario no se encuentre relacionado a alguna organización.
La Figura 5.9 muestra el formulario para la creación de una cuenta, en el cual se
debe indicar si corresponde a un tipo de usuario Empresario, Estudiante o
Profesor Investigador externos, que son los tipos de usuarios definidos en la etapa
de especificación de requisitos y que corresponden a valores que el atributo
userType de la clase Person puede tomar, el cual es usado por la GUI adaptable
para identificar cual estructura de información y qué características gráficas son
usadas para mostrar las recomendaciones en el cliente.
74
A partir del correo electrónico de una persona, se define también el valor del
atributo userName de la clase Person, usado para nombrar el archivo .xml en el
que se almacenan el conjunto de recomendaciones ofrecidas para ese usuario, y
que también es usado junto con la contraseña ingresada al usar la cuenta para
efectuar iniciar sesión en el cliente del sistema.
Figura 5.9: Formulario para la creación de una cuenta del T-Guía
La Figura 5.10 muestra capturas de los formularios para ingresar los datos de
contacto de un usuario y de su organización.
Figura 5.10: Formularios para la captura de los datos de contacto de un usuario de la organización a la que pertenece
75
5.3 Implementación del Motor de Inferencia
El proceso de recomendación implementado en el SRSCC organizacional T-Guía
está dividido en sub-procesos, ejecutados por diversos submódulos del Módulo
Motor de Inferencia de acuerdo a las etapas del proceso de inferencia
presentadas en la sección 5.3.
Para fines de experimentación, también se codificaron métodos que simulan el
funcionamiento del Módulo de localización, con los cuales se invoca la ejecución
del proceso de recomendación para un usuario. El proceso se dispara cuando se
detecta la llegada de un usuario a las instalaciones de la organización, para lo cual
se utilizan tecnologías de autoidentificación como RFID43 o NFC44.
Del lado del servidor, en el Repositorio de recursos ontológicos, se tiene un
repositorio de tripletas (TDB) creado a partir de la Organizational Memory
Ontology, poblada con las instancias de los elementos organizacionales y de los
usuarios del sistema, además, en el Repositorio de recursos no ontológicos, se
mantienen un archivo de reglas de inferencia generales llamado ReglasTGuia.xls
y un archivo de reglas especializadas para cada tipo de organización en el que se
implemente el sistema T-Guía, llamados ReglasGov.xls, ReglasEmpresas.xls y
ReglasIES.xls, los cuales se almacenan en una carpeta llamada TGuideRules que
es accedida por el Motor de Inferencia, mediante los métodos codificados en el
proyecto de NetBeans OBCaRS, durante su proceso de recomendación.
Dado que en los alcances planteados para el trabajo de tesis se maneja la
implementación del SRSCC organizacional T-Guía en un escenario de tipo IES, se
toma el archivo ReglasIES.xls, que contiene las reglas que se aplican al
implementar el sistema sobre una institución de educación superior.
El objetivo de este tipo de implementación es que al llevar el sistema T-Guía a
diferentes escenarios organizacionales, este pueda adaptarse fácilmente
indicando el conjunto de reglas que se debe ejecutar para cada organización.
43
La Identificación por Radio Frecuencia, RFID por sus siglas en íngles, es una tecnología
inalámbrica que utiliza ondas de radio frecuencia para transferir datos entre un lector y una etiqueta incorporada a una persona u objeto, para su identificación, categorización o seguimiento, entre otros propósitos. http://www.rfid.org/ 44
La Near Field Communication (NFC), una tecnología de comunicación inalámbrica, de corto
alcance y alta frecuencia que permite el intercambio de datos entre dispositivos a menos de 10cm. http://www.nfc-forum.org/home/
76
Cuando un usuario se registra en el SRSCC organizacional, mediante la aplicación
Semantic T-Guide, se aplica un conjunto de reglas basadas en contenidos que se
encuentran almacenadas en el archivo ReglasTGuia.xls, mostradas en el Anexo 1,
lo cual permite realizar un primer filtrado a partir del identificador de ese usuario
para obtener sólo los elementos recomendables que coincidan con sus intereses y
preferencias. Este primer sub-proceso es ejecutado por el Submódulo de pre-
filtrado de ítems.
Las coincidencias son determinadas mediante un Matching semántico
[Giunchiglia, 2003] evaluando los contenidos del perfil del usuario y los incluidos
en la descripción de los ítems, de las dimensiones contextuales y de las políticas
de la empresa. Para ello, se toma como base el conocimiento explícito definido en
la red de ontologías mediante las instancias de relaciones, clases y propiedades.
Además, durante las diferentes etapas del proceso de recomendación se usa
también la inferencia de conocimiento semántico implícito, que va generándose
durante la ejecución de cada subproceso.
Posteriormente, se ejecuta un segundo conjunto de reglas, también almacenadas
en el archivo ReglasTGuia.xls, las cuales permiten extraer aquellos elementos
recomendables asociados a una organización específica.
Esto permite que cada organización donde se implemente el T-Guía tenga un
repositorio local formado únicamente por sus instancias. Este sub-proceso
corresponde al Submódulo de extracción de instancias asociadas a una
organización.
Además, se mantiene en el servidor local de la organización un archivo con
extensión .xml por cada usuario que la visite, este archivo contienen la lista de
recomendaciones que se infirieron para dicho usuario. El contenido de estos
archivos, que se nombran usando el identificador de la instancia de dicho usuario
de la forma usuario.xml, es desplegado en el cliente móvil por el Mobile T-Guide
descrito en la sección 5.4.
Finalmente, usando los identificadores de un usuario y del campus de la
organización al que llega, así como datos temporales de fecha y hora, el
Submódulo generador de recomendaciones abre el archivo .xls que contiene
las reglas definidas para el tipo de organización visitada, las cuales consideran
aspectos contextuales de espacio, tiempo y disponibilidad, permitiendo identificar
los elementos recomendables asociados al campus visitado que están disponibles
en ese momento para ser ofrecidos al usuario. Una vez que estos elementos son
identificados, se estructuran en un archivo .xml que es leído por el cliente cuando
el usuario inicia sesión en el Mobile T-Guide.
77
De manera adicional, cuando se registran nuevos elementos organizacionales
para ser instanciados en la Organizational Memory Ontology, el Submódulo para
la actualización de conjuntos de ítems pre-filtrados implementado en el SAIA,
se encarga de comparar las características de un nuevo elemento con las
características de cada usuario registrado, de tal forma que sí estas coinciden, el
elemento es añadido al subconjunto obtenido por la ejecución del Submódulo de
pre-filtrado de ítems.
El registro de nuevos ítems puede estar a cargo de los administradores del
sistema o lo pueden realizar los miembros de la organización como parte de la
administración de su información personal, y además, la actualización del
subconjunto de ítems recomendables asociados a la organización puede
implementarse en otros desarrollos de forma automática tras cada operación
sobre la base de conocimientos, este proceso es constante de acuerdo a un
criterio propio de los administradores del sistema o manualmente a solicitud de un
administrador.
El funcionamiento detallado de los módulos, representados en la Figura 5.11, es
presentado en las secciones siguientes:
Figura 5.11: Módulos del Motor de Inferencia del sistema T-Guía
La implementación del Módulo Motor de Inferencia fue desarrollada mediante la
codificación de tres clases principales llamadas SWRL4U.java, SPARQL4U.java y
OBCaRS.java.
78
La clase SWRL4U.java, representada en la Figura 5.12, contiene métodos que
permiten aplicar un conjunto de reglas SWRL almacenadas en un archivo .xls
sobre una ontología, considerando la asignación de valores a las múltiples
variables que pudiesen estar involucradas en las reglas, para producir una nueva
versión de la ontología inicial que contenga las inferencias obtenidas.
Figura 5.12: Entradas y salida de la clase SWRL4U.java
La clase SPARQL4U.java, representada en la Figura 5.13, contiene métodos que
permiten aplicar un conjunto de consultas SPARQL almacenadas en un archivo
.xls sobre una ontología, considerando la asignación de valores a las múltiples
variables que pudiesen estar involucradas en las consultas, para producir un
archivo .xml que contenga el resultado de las consultas.
Figura 5.13: Entradas y salida de la clase SPARQL4U.java
La clase OBCaRS.java contiene métodos que corresponden a los cuatro
submódulos del Módulo Motor de Inferencia presentados en la Figura 5.11, y en
ellos, se invocan los métodos de las clases SWRL4U.java y SPARQL4U.java para
realizar las distintas etapas del proceso de inferencia. Cada una de las etapas se
describen en los apartados siguientes.
79
Además, la forma en que se han definido las clases SWRL4U.java y
SPARQL4U.java permite que éstas sean fácilmente reutilizables en otros
proyectos que requieran el uso de reglas SWRL o consultas SPARQL, pues para
ello el desarrollador únicamente deberá especificar el conjunto de reglas o
consultas que desea aplicar, junto con la lista de valores (pudiendo estar vacía)
para las variables a considerar.
5.3.1 Submódulo de pre-filtrado de ítems
La estrategia seguida para el poblado del el conjunto de ontologías Organizational
Memory Ontology, descrito en el punto 5.3, permite definir tanto un conjunto I
formado por los n ítems o elementos organizacionales instanciados en la base de
conocimientos, como un conjunto 𝑈 formado por los m usuarios registrados en el
sistema, tal que:
I= {𝑖1; 𝑖2; … ; 𝑖𝑛} (1)
𝑈 = {𝑢1; 𝑢2;… ;𝑢𝑚 } (2)
A partir de esto, cuando un usuario realiza el proceso de registro en el sistema T-
Guía, se crea una nueva instancia de éste en la Organizational Memory Ontology,
modificándose el conjunto de usuarios 𝑈 (2) de la forma:
𝑈 = 𝑈 ∪{𝑢𝑚+1} (3)
Posteriormente, se ejecuta el Módulo de pre-filtrado, el cual toma al usuario recién
registrado como el usuario activo 𝑢𝑎 y pasa la Organizational Memory Ontology
poblada a un TDB, sobre el cual se aplica un conjunto de reglas de inferencia,
almacenadas en el archivo ReglasTGuia.xls, diseñadas para identificar los
elementos de 𝐼 que coincidan con el conjunto de características del usuario activo.
Para ello, se maneja un conjunto 𝐷 (4), formado por las características que
pueden poseer los usuarios y que está definido por la unión del conjunto 𝑇, que
corresponde a las x áreas de conocimiento en las que los usuarios podrían tener
80
interés, el conjunto 𝐻 que representa las y competencias individuales
(habilidades) que pueden tener los usuarios y del conjunto 𝑂 que corresponde a
las z ocupaciones que pueden desempeñar los usuarios. Los conjuntos 𝑇, 𝐻 y 𝑂
corresponden a los catálogos manejados en el sistema SAIA, que se describen en
la sección 5.2.1.
𝐷 = 𝑇 ∪ 𝐻 ∪ 𝑂 (4)
Este módulo también se encarga de obtener un subconjunto de 𝐷 (4), el cual
corresponde a los intereses, habilidades y ocupaciones del usuario activo que es
llamado 𝐷𝑢𝑎 (5), formado por la unión de un subconjunto 𝑇𝑢𝑎
, que corresponde a
los x´ tópicos de interés del usuario 𝑢𝑎 , un subconjunto 𝐻𝑢𝑎, que representa las y´
competencias de 𝑢𝑎 y de un subconjunto 𝑂𝑢𝑎, que corresponde a las z´
ocupaciones de 𝑢𝑎 , teniendo que:
𝐷𝑢𝑎= 𝑇𝑢𝑎
∪ 𝐻𝑢𝑎∪ 𝑂𝑢𝑎
(5)
Como resultado de la aplicación de estas reglas se identifica un subconjunto de 𝐼
(1), llamado 𝐼𝑢𝑎 (6), formado por los w ítems que podrían ser del agrado del
usuario activo 𝑢𝑎 :
𝐼𝑢𝑎⊆ 𝐼 (6)
Las modificaciones hechas sobre el TDB para reflejar los elementos que
conforman el subconjunto 𝐼𝑢𝑎 (6) son manejadas en una nueva versión de la
ontología.
El proceso se repite cada vez que un usuario se registra, con lo cual se tiene la
versión original del modelo semántico implementado y una versión modificada, en
la que se van añadiendo las relaciones necesarias para indicar la posible
preferencia de cada uno de los usuarios hacia los ítems.
El objetivo del módulo, representado por la Figura 5.14, es reducir la cantidad de
ítems que se considerarán durante el proceso de inferencia que se ejecuta cuando
81
un usuario visita una organización, y de esta forma, reducir tiempos de respuesta
que podrían ser muy altos si se considerará el conjunto completo de ítems.
Figura 5.14: Submódulo de pre-filtrado de ítems
5.3.2 Submódulo de extracción de instancias asociadas a una
organización
Este módulo, que puede ser ejecutado periódicamente, permite a una
organización tener un repositorio de recursos ontológicos local, formado por las
instancias (ítems) que sean identificadas como interesantes para los usuarios.
Durante su funcionamiento, el módulo crea un TDB´ a partir de la Organizational
Memory Ontology reducida por el Submódulo de pre-filtrado de ítems, sobre el
cual, se aplica un conjunto de reglas de inferencia, almacenadas en el archivo
ReglasTGuia.xls, para obtener un subconjunto de 𝐼𝑢𝑎 (6), llamado 𝐼´𝑢𝑎
(7), que se
forma únicamente por los elementos de 𝐼𝑢𝑎 (6) asociados a la organización
visitada, tal que:
𝐼´𝑢𝑎⊆ 𝐼𝑢𝑎
(7)
82
Este proceso es realizado considerando que el subconjunto 𝐼𝑢𝑎 (6) puede contener
elementos de más de una organización que haya sido modelada en la
Organizational Memory Ontology. Las modificaciones hechas sobre el TDB´ por
este módulo son almacenadas en una versión local de la Organizational Memory
Ontology. El módulo es representado en la Figura 5.15.
Figura 5.15: Submódulo de extracción de instancias asociadas a una organización
5.3.3 Submódulo generador de recomendaciones
Este módulo toma como entrada la salida del Submódulo de extracción de
instancias asociadas a una organización, junto con el identificador del usuario,
información espacial especificada por el identificador del campus organizacional
que visita, información temporal, la disponibilidad de los ítems especificada en sus
instancias y el archivo que contiene el conjunto de reglas contextuales definidas
para el tipo de organización que visita el usuario.
Como se explicó anteriormente, se utilizaron diferentes archivos de reglas con el
objetivo de permitir la definición de conjuntos independientes para IES,
instituciones de gobierno y empresas, sin embargo, dado los alcances del trabajo
de tesis, únicamente se implementan las reglas para IES del archivo
ReglasIES.xls.
83
El propósito del módulo es definir un subconjunto de 𝐼´𝑢𝑎 (7), llamado 𝑅𝑢𝑎
(8),
formado por los ítems que podrían ser del agrado de un usuario 𝑢𝑎 y que sean
recomendables según las condiciones contextuales presentes al momento de
inferir las recomendaciones, de la forma:
𝑅𝑢𝑎⊆ 𝐼´𝑢𝑎
(8)
Para poder obtener los elementos de 𝑅𝑢𝑎 (8) se sigue el siguiente algoritmo:
Sea C el conjunto de los k factores contextuales relevantes para la
recomendación de los ítems:
C = {𝑐1; 𝑐2; … ; 𝑐𝑘} (9)
Sea V el conjunto de los i valores que puede tomar un factor contextual de
C (9):
V = {𝑣1; 𝑣2; … ; 𝑣𝑖} (10)
Sea 𝑓𝑢𝑎 una función para definir el valor (10) de cada elemento del contexto
en el momento 𝑚𝑢𝑎 en que el usuario activo 𝑢𝑎 llega a las instalaciones de
la organización:
𝑓𝑢𝑎: 𝐶,𝑚𝑢𝑎
→ 𝑉 (11)
Sea 𝑔𝑖𝑗 una función para definir el valor (10) que debe tener cada elemento
del contexto para que un ítem 𝑖𝑗 que pertenece a 𝐼 (1) sea considerado
como recomendable:
𝑔𝑖𝑗 : 𝐶, 𝑖𝑗 → 𝑉 (12)
84
Sí el valor de cada elemento del contexto definido por 𝑓𝑢𝑎 (11) es igual al
valor de cada elemento del contexto para un ítem 𝑖𝑗 definido por 𝑔𝑖𝑗 (12),
entonces el ítem 𝑖𝑗 pasa a formar parte de 𝑅𝑢𝑎 (8).
Finalmente, el Módulo generador de recomendaciones pasa la información de los
ítems contenidos en 𝑅𝑢𝑎 (8) a un archivo .xml identificado con el nombre del
usuario activo 𝑢𝑎 que se almacena en el servidor. El funcionamiento de este
módulo se representa en la Figura 5.16, la Figura 5.17 muestra un ejemplo de los
archivos .xml que se generan como salida de este módulo, correspondiente al
archivo nimrod.xml usado para los ejemplos presentados en este capítulo.
Figura 5.16: Submódulo generador de recomendaciones
Figura 5.17: Contenido del archivo de ejemplo nimrod.xml generado con el Módulo generador de recomendaciones
85
5.3.4 Módulo para la actualización de conjuntos de ítems pre-
filtrados
El poblado de los elementos organizacionales modelados en la Organizational
Memory Ontology es realizado con ayuda de la aplicación SAIA, descrita en la
sección 5.2, la cual permite añadirlos al conjunto I (1) como un nuevo ítem 𝑖𝑛+1,
modificando el conjunto original de la forma:
I= I ∪{𝑖𝑛+1} (13)
Una vez que el ítem ha sido añadido es considerado por este módulo como un
ítem activo 𝑖𝑎 , entonces se aplica un conjunto de reglas de inferencia
almacenadas en el archivo ReglasTGuia.xls, las cuales están basadas en
comparar los contenidos de los ítems (1) contra el perfil de los usuarios (2), para
determinar si el ítem 𝑖𝑎 podría resultar interesante para cada usuario registrado en
el sistema, considerando que la compartición del ítem puede estar restringida a
cierto tipo de usuarios, por lo que primeramente se obtiene un subconjunto de 𝑈
(2) llamado 𝑈´ (14), formado por todos los usuarios que pueden acceder a ese
ítem, tal que :
𝑈´ ⊆ 𝑈 (14)
Estas restricciones de acceso son definidas como parte de las políticas de la
organización y se modelan semánticamente por medio de la relación
isShareableWith, que tiene como dominio un ítem recomendable y como rango un
grupo humano, que puede referirse a nivel educativo, profesión o rango
generacional.
Posteriormente, se va tomando secuencialmente cada elemento de 𝑈´ (14) como
𝑢𝑎 para definir su subconjunto 𝐷𝑢𝑎 (5) correspondiente, el cual es usado para
identificar sí el ítem 𝑖𝑎 podría ser recomendable para ese usuario.
Finalmente, las inferencias obtenidas por este módulo son añadidas a la versión
de la ontología modificada por el proceso de pre-filtrado.
86
El funcionamiento del método se describe en la Figura 5.18.
Figura 5.18: Submódulo para la actualización de conjuntos de ítems pre-filtrados
5.4 Análisis y diseño de la interfaz adaptable para el cliente del
SRSCC organizacional T-Guía: Mobile T-Guide
Aplicando el método para la definición de una interfaz adaptable al usuario,
presentado en la sección 4.3.3, se define una GUI para el cliente del T-Guía
capaz de modificar algunas de sus características gráficas y de contenido, lo cual
es realizado de acuerdo al perfil de sus usuarios. Dado que la implementación del
Motor de Inferencia se contempló en un periodo posterior al diseño de la interfaz
del cliente y a que el modelo semántico fue desarrollado en paralelo, la
funcionalidad de los pasos 8 y 9 fue emulada manualmente. El método fue
ejecutado tomando como entrada los requisitos del proyecto y las capacidades del
equipo cliente, definiendo tres perfiles de usuarios: Estudiante, Profesor-
investigador y Empresario.
El cliente del SRSCC organizacional T-Guía, llamado Mobile T-Guide, también
permite registrar las acciones que un usuario realiza con las recomendaciones
recibidas, como se expresa en el caso de uso mostrado en la Figura 5.19.
87
Figura 5.19: Diagrama de casos de uso para la GUI adaptable del cliente del SRSCC organizacional T-Guía
El Mobile T-Guide organiza las recomendaciones que se muestran mediante la
GUI adaptable al usuario como indica el caso de uso presentado en la Figura
5.20.
Figura 5.20: Diagrama de casos de uso para organizar las recomendaciones en el cliente móvil del SRSCC organizacional T-Guía
88
Además, los usuarios interactúan con las recomendaciones recibidas de forma
variada, desde la visualizarlas hasta visitarlas, ubicarlas en un mapa, consultar
detalles sobre ellas, calificarlas o ignorarlas, como se muestra en la Figura 5.21.
Figura 5.21: Diagrama de casos de uso para la interacción de los usuarios con las recomendaciones mediante el cliente móvil del SRSCC organizacional T-Guía
Cada una de las acciones que realiza el usuario sobre las recomendaciones
recibidas, ya sea mediante la GUI adaptable al usuario del Mobile T-Guide o
identificadas de forma implícita, deben ser registradas para lograr el monitoreo del
comportamiento de los usuarios, siendo esto realizado como se describe en el
caso de uso mostrado en la Figura 5.22.
Figura 5.22: Diagrama de casos de uso para registrar la interacción de los usuarios con las recomendaciones mediante el cliente móvil del SRSCC organizacional T-Guía
89
El Mobile T-Guide permite a un usuario iniciar sesión y consultar las
recomendaciones que el SRSCC infiere para él. La Figura 5.23 muestra la pantalla
de bienvenida del Mobile T-Guide, la cual implementa el mecanismo de logueo
con el userName y el password que se definen cuando se crea una cuenta en el
Semantic T-Guide.
Figura 5.23: Pantalla de bienvenida del Mobile T-Guide
En relación a las funcionalidades y la estructura de información determinadas para
cada perfil de usuario del SRSCC organizacional T-Guía, se establece que un
usuario de tipo Estudiante tiene acceso a las funciones requeridas para gestionar
una sesión en el sistema, visualizar las recomendaciones ofrecidas por el SRSCC,
consultar información detallada sobre ellas, calificarlas y solicitar su ubicación
dentro de las instalaciones de la organización.
Además, se plantea que las recomendaciones ofrecidas por el SRSCC
organizacional T-Guía estén organizadas según el tipo de ítem recomendado,
permitiéndole a un Estudiante el acceso a los siguientes grupos de elementos:
personas, instalaciones, objetos de conocimiento, servicios basados en
competencias, recursos tecnológicos y actividades.
Los ítems recomendados son presentados en listas independientes para cada
grupo de recomendación, mostrando información mínima del ítem, la cual consiste
en su nombre y disponibilidad; un Estudiante puede consultar información
90
detallada de cada ítem enlistado, para lo cual en la GUI se despliegan datos como
el nombre, el estado, la descripción e información de contacto del ítem, además de
un rating bar para permitirle al usuario calificar el ítem y la opción solicitar su
localización, en el caso de que el ítem sea de tipo persona, se añade una opción
para solicitar una cita con la persona recomendada.
Las funciones y estructura de información son similares para usuarios de tipo
Profesor-investigador y Empresario, sin embargo, estos últimos tendrán acceso a
un grupo de elementos adicional, correspondiente a ítems recomendados que
describan proyectos realizados por la institución.
La Figura 5.24 muestra el diseño de la interfaz base del cliente móvil del SRSCC
organizacional T-Guía, la cual parte de la pantalla de inicio de sesión e incluye
pantallas para mostrar los grupos de recomendaciones y la información detallada
sobre un ítem. La manera en que esta GUI se adapta a los usuarios es
ejemplificada en la Figura 5.25.
Figura 5.24: GUI estándar del cliente del SRSCC organizacional T-Guía
91
Figura 5.25: Adaptación de la GUI del cliente del SRSCC organizacional T-Guía
Considerando las funciones disponibles para los usuarios, el catalogo de acciones
para la interacción con las recomendaciones contempla las siguientes
posibilidades:
Usuario + Visita + Ítem_ recomendado.
Usuario + Visualiza_en_mapa + Ítem_ recomendado.
Usuario + Consulta + Ítem_ recomendado.
Usuario + Ignora + Ítem_ recomendado.
Usuario + Solicita_cita_con + Ítem_ recomendado.
Usuario + Califica + Ítem_ recomendado.
Donde item_recomendado puede ser un elemento de entre el conjunto de
recomendaciones correspondientes a personas, instalaciones, objetos de
conocimiento, servicios basados en competencias, recursos tecnológicos,
actividades o proyectos.
92
La asignación de valores a un ítem se define de la siguiente forma:
Valor igual a 1: si el usuario se desplaza a la posición de un ítem recomendado.
Valor igual a 1: si el usuario solicita una cita con un ítem recomendado del tipo persona.
Valor igual a 0.7: si el usuario decide visualizar en un mapa la posición de un ítem recomendado.
Valor igual a 0.3: si el usuario consulta información detallada sobre un ítem recomendado.
Valor igual a -0.01: si el usuario ignora un ítem recomendado.
Para la evaluación manual de un ítem recomendado por parte de los usuarios, es importante analizar el proceso de toma de decisiones que conduce hacia una calificación específica, lo cual es útil para conocer el impacto que una recomendación tiene sobre un usuario.
En el caso de la GUI diseñada para el SRSCC organizacional T-Guía, al momento de desplegar la información detallada sobre un ítem, se incluye la opción de calificar dicho ítem implementando la estrategia de evaluación por estrellas, la cual es un sistema de calificación comúnmente difundido para evaluar contenidos, complementado con una barra indicadora con significado iconográfico como se aprecia en la Figura 5.26, además, se establece la calificación de los ítems recomendados con una puntuación comprendida entre cero y cinco estrellas ordenadas de izquierda a derecha. La interpretación de una calificación es definida como:
o Cero estrellas indican que un usuario consultó la información
detallada de un ítem pero no se mostró interesado en calificarlo, por
lo tanto, al ítem se asigna un valor igual a 0.
o Una estrella, considerando el significado de su posición en relación a
la barra indicadora, es interpretada como que al consultar la
información detallada de un ítem, el usuario se da cuenta de que
esa recomendación no corresponde con lo que esperaba encontrar,
por lo que indica manualmente que el ítem no le agrada, según lo
cual al ítem se asigna un valor igual a -1.
o Dos estrellas, considerando el significado de su posición en relación
a la barra indicadora, es interpretada como que al consultar la
información detallada de un ítem, el usuario se da cuenta de que
esa recomendación no le resulta de utilidad, sin embargo, no le
desagrada totalmente y por lo tanto al ítem se asigna un valor igual a
0.2.
o Tres estrellas, considerando el significado de su posición en relación
a la barra indicadora, es interpretada como que al consultar la
información detallada de un ítem, el usuario se da cuenta de que
93
esa recomendación no le resulta altamente significante, por lo que
indica manualmente que el ítem le causa un nivel medio de
satisfacción, según lo cual al ítem se asigna un valor igual a 0.5.
o Cuatro estrellas, considerando el significado de su posición en
relación a la barra indicadora, es interpretada como que al consultar
la información detallada de un ítem, el usuario se da cuenta de que
esa recomendación puede serle de utilidad, por lo que indica
manualmente que la recomendación fue recibida de manera
satisfactoria, según lo cual al ítem se asigna un valor igual a 0.8.
o Cinco estrellas, considerando el significado de su posición en
relación a la barra indicadora, es interpretada como que al consultar
la información detallada de un ítem, el usuario se da cuenta de que
esa recomendación es altamente satisfactoria de acuerdo a sus
intereses, por lo que indica manualmente que la recomendación le
agrada, según lo cual al ítem se asigna un valor igual a 1.
Figura 5.26: Estrategia de calificación manual implementada en el SRSCC organizacional T-Guía
Las acciones y su calificación correspondiente son almacenadas temporalmente
en tablas auxiliares, localizadas en una base de datos en el dispositivo móvil,
conforme son ejecutadas por el usuario. La Figura 5.27 muestra el diseño de la
base de datos para el cliente móvil del T-Guía.
94
Figura 5.27: Diseño de la base de datos para el cliente móvil del SRSCC organizacional T-Guía
Una vez que se inicia sesión, la aplicación se conecta al servidor para obtener un
archivo .xml que contiene las recomendaciones del usuario el valor del atributo
userType, el cual sirve para identificar la opciones de navegación y el fondo usado
cuando se muestren en el cliente, las cuales son organizadas según el tipo de
recomendaciones que contenga.
Las figuras siguientes muestran un ejemplo, tomando el archivo nimrod.xml
presentado en la Figura 5.18, de la forma en que las recomendaciones inferidas
son visualizadas en la aplicación Mobile T-Guide. La Figura 5.28 muestra la forma
en que las recomendaciones de ítems del tipo Persona son enlistadas para un
usuario del tipo estudiante, y la Figura 5.29 muestra el despliegue de información
detallada sobre una recomendación de tipo Persona específica cuando es
seleccionada.
Figura 5.28: Visualización de recomendaciones de personas para un usuario del tipo Estudiante
95
Figura 5.29: Visualización de la información detallada de una recomendación
Las figuras 5.30 y 5.31 muestran la forma en que se enlistan recomendaciones de
ítems del tipo Lugar para un usuario Profesor Investigador y del tipo Proyecto
para un usuario Empresario.
Figura 5.30: Visualización de recomendaciones de lugares para un usuario del tipo Profesor Investigador
96
Figura 5.31: Visualización de recomendaciones de proyectos para un usuario del tipo Empresario
El Mobile T-Guide implementa los mecanismos de monitoreo implícito que se
describen en el capítulo anterior, almacenando las acciones que el usuario realiza
sobre la aplicación; estos datos se utilizan para generar un nuevo archivo .xml,
llamado tguia_valoradas.xml, que es procesado por la aplicación T-Guide Admin
para generar reportes referentes a las recomendaciones ofrecidas por el sistema.
La imagen presentada en la Figura 5.32 muestra un ejemplo de los archivos que
genera el Mobile T-Guide.
Figura 5.32: Ejemplo del archivo tguia_valoradas.xml
97
5.5 Implementación de una aplicación para el análisis del
funcionamiento del T-Guía y del comportamiento de sus usuarios:
T-Guide Admin
La información obtenida en el cliente móvil del T-Guía puede ser explotada por el
Módulo de identificación de comportamiento de usuarios, descrito en la
sección 4.3.4, con el objetivo de que el Motor de Inferencia pueda explotarla en
futuros procesos de recomendación, además de dar a los administradores una
apreciación del funcionamiento del SRSCC como se representa en el caso de uso
mostrado en la Figura 5.33
Figura 5.33: Caso de uso de una aplicación para la implementación del Módulo de identificación de comportamiento de usuarios
Para lograr conocer el desempeño del sistema, es necesario almacenar la
información generada en la GUI adaptable al usuario, siguiendo una estructura
tal que pueda ser procesada para describir la generación de recomendaciones
bajo distintas circunstancias, para lo cual se implementó el Repositorio de
recursos no ontológicos presentado en la sección 4.2 usando el diseño de base
datos mostrado en la Figura 5.34.
98
Figura 5.34: Diseño de la base de datos implementada para el SRSCC T-Guía
Con esta estructura de información, es posible manejar conjuntos de datos en
base a las recomendaciones inferidas, el contexto en que se infirieron y la forma
en que los usuarios interactuaron con las recomendaciones recibidas, de acuerdo
a lo descrito en el caso de uso presentado en la Figura 5.35.
Figura 5.35: Caso de uso para el almacenamiento de información sobre el funcionamiento del sistema en una aplicación para la implementación del Módulo de identificación de comportamiento de usuarios
99
Para efectuar este proceso, se implementó una aplicación Web llamada T-Guide
Admin, cuya pantalla de bienvenida se presenta en la Figura 5.36. Esta aplicación
procesa el archivo tguia_valoradas.xml para almacenar su contenido en la base de
datos presentada previamente, la cual fue implementada usando el gestor de
bases de datos MySQL 5.5.12. Esta base de datos es consultada mediante una
serie de reportes según los ítems recomendados, la popularidad de los mismos o
el contexto en que se infirieron.
En trabajos futuros, la base de datos descrita en esta sección puede transformase
en una ontología que modele el comportamiento de los usuarios de un SRSCC
organizacional, lo cual puede realizarse, por ejemplo, tomando como base el R2O
& ODEMapster45, que es un marco integrado para la expresión formal, la
evaluación, verificación y explotación de correspondencias semánticas entre
ontologías y bases de datos relacionales, un lenguaje de transformación de bases
de datos relacionales en RDF.
Figura 5.36: Pantalla de bienvenida del T-Guide Admin
45
http://mayor2.dia.fi.upm.es/oeg-upm/index.php/es/downloads/9-r2o-odempaster
100
La Figura 5.37 muestra algunas capturas de dichos reportes. A través de la
interfaz gráfica, empleando las opciones de su menú, se tiene acceso a
operaciones de consultas sobre la base datos al seleccionar el tipo de reporte que
se desee generar. Las operaciones de altas y modificaciones de los registros de la
base de datos se efectúan por los métodos para interpretar el archivo .xml que
recibe la aplicación.
El propósito al desarrollar el T-Guide Admin es proporcionar una forma fácil de
comprender la manera en que el sistema de recomendación está trabajando, sin
embargo, en trabajos futuros, la información que se maneja con esta aplicación
puede ser explotada para identificar patrones de comportamiento de los usuarios,
de tal forma que ayuden a efectuar mejores recomendaciones.
Figura 5.37: Capturas de los reportes generados con el T-Guide Admin
101
CAPÍTULO 6: PRUEBAS AL SRSCC ORGANIZACIONAL
T-GUÍA Y CASO DE ESTUDIO
En este capítulo se describen las pruebas efectuadas a los módulos desarrollados
como parte del SRSCC organizacional T-Guía, sistema utilizado para comprobar
la veracidad de los conceptos y técnicas propuestos en este trabajo de tesis.
102
6.1 Introducción
Este capítulo expone las pruebas realizadas para verificar la funcionalidad del
SRSCC organizacional T-Guía, centrándose en el proceso ejecutado para generar
las recomendaciones y la forma en que estas son visualizadas por el usuario, por
lo que se identifican dos aéreas de análisis principales, los módulos del Motor de
Inferencia del lado servidor y la GUI adaptable ejecutada en el dispositivo cliente.
La funcionalidad del Módulo de localización, cuyo desarrollo no está incluido en
los alcances de esta tesis y que se encarga de disparar la ejecución del Módulo
generador de recomendaciones, fue simulada para fines de experimentación.
Las hipótesis que se persigue demostrar son las siguientes:
1. La cantidad y tipo de recomendaciones ofrecidas por el SRSCC T-Guía
varían según el tipo de usuario para el que se realice el proceso de
inferencia.
2. La cantidad y tipo de recomendaciones ofrecidas por el SRSCC T-Guía
varían según las condiciones contextuales presentes al momento de
efectuar el proceso de inferencia
3. La frecuencia con que un ítem específico es recomendado a los usuarios
varía según el tipo de usuario y las condiciones contextuales presentes al
momento de efectuar el proceso de inferencia.
La verificación estadística de las hipótesis enunciadas, las cuales se encuentran
estrechamente relacionadas al proceso de inferencia, se realiza al reunir y
comparar información generada durante la experimentación con el Motor de
Inferencia y el cliente del SRSCC T-Guide.
La realización de las pruebas implicó 121 ejecuciones del Motor de Inferencia,
tomando una población de 42 usuarios, instanciados a partir de catálogos
nacionales de investigadores, visitantes de CENIDET y usuarios creados con
propósito de experimentación, de acuerdo a las necesidades de las pruebas
descritas en las secciones siguientes.
Además, se maneja un conjunto de 153 ítems recomendables correspondientes a
elementos organizacionales de CENIDET de las 7 categorías definidas en la etapa
de análisis de requerimientos, contenidos en una versión de la ontología
multidimensional poblada con más de 2000 instancias de las diferentes clases que
la conforman, las cuales fueron obtenidas de manera manual o semi-automatizada
empleando las herramientas Protégé 3.4 y NOR2O respectivamente.
103
6.1.1 Características a ser probadas
Las pruebas realizadas fueron definidas con el fin de validar y verificar la
capacidad del Motor de Inferencia para generar distintas recomendaciones, de
acuerdo a variaciones en las condiciones contextuales y las características de los
diferentes usuarios del sistema de recomendación.
Debido a la naturaleza del conjunto de ítems recomendables instanciados, los
cuales están asociados a un único campus de una IES, las pruebas se orientaron
a experimentar con variaciones temporales y comprobar el funcionamiento bajo un
segundo escenario espacial, con un campus careciente de elementos
organizacionales, para el cual, el Módulo generador de recomendaciones no
encontró ítems recomendables asociados a dicho campus, y en consecuencia, el
conjunto de recomendaciones a ofrecer resultó ser vacio.
6.1.2 Características excluidas de las pruebas
No se da prioridad a las aplicaciones y técnicas usadas para simular el
funcionamiento de los módulos de localización de los usuarios y para el poblado
de la ontología.
No se verificará la percepción del usuario para cada recomendación que le es
ofrecida por el sistema de recomendación.
6.1.3 Enfoque
Las pruebas están diseñadas para generar un conjunto de datos que permita
analizar cuantitativamente el proceso de inferencia realizado bajo distintos
escenarios, de tal forma que sea posible identificar tendencias en la cantidad y tipo
de recomendaciones inferidas, así como en la frecuencia con que los ítems son
recomendados.
Además, se registraron los tiempos de ejecución para analizarlos en busca de una
relación entre la cantidad de recomendaciones ofrecidas por el sistema y el
tiempo que toma inferirlas para cada usuario en los diferentes escenarios
considerados.
104
6.1.4 Requisitos ambientales
Las características y propiedades físicas y lógicas presentes en el ambiente de
pruebas, son las siguientes:
Especificaciones del equipo: Notebook HP G42-164LA
Microprocesador: Procesador AMD Athlon II Dual-Core para notebooks
P320 a 2,1GHz
Caché del microprocesador: 1 MB de caché de nivel 2
Memoria: 3 GB
Sistema Operativo: Windows SEVEN
Disco duro: 320 GB (30Mb libres)
Herramientas
NetBeans 6.9, como entorno de programación desde el cual se disparará la
aplicación que simula la invocación del Motor de Inferencia por parte de
los módulos que se encuentran fuera de los alcances de esta tesis.
Eclipse simulador, como entorno de desarrollo gráfico para visualizar las
recomendaciones ofrecidas en cada ejecución.
Android 2.1-update1 - API Level 7 para el AVD usado en la etapa de
simulación.
Jess 7.1p2 descargado desde la página oficial de Jess46, como razonador
ontológico usado por los módulos del Motor de Inferencia.
46
http://www.jessrules.com
105
6.1.5 Instancias de los conjuntos U e I usadas durante la
ejecución de la fase de pruebas
Para el desarrollo de las pruebas presentadas en este capítulo, fue necesario
contar con información instanciada sobre los conjuntos 𝑈 (2) e 𝐼 (1),
correspondientes a los usuarios del sistema y los ítems recomendables que se
debían filtrar para recomendar aquellos que fuesen de interés de dichos usuarios.
Para el conjunto 𝐼 (1) se manejó una población que corresponde a los 153 ítems
asociados con la organización CENIDET, cuyo resumen se presenta en la Tabla
6.1, sin embargo, la conformación de este conjunto 𝐼 (1) implicó la instanciación de
diferentes clases, por lo que se incluye un resumen de éstas de acuerdo a lo
presentado en la Tabla 6.2.
Tabla 6.1: Resumen de los elementos del conjunto I usado en la fase de pruebas
Tipo de ítem Cantidad
Persona 62
Objeto de conocimiento 17
Proyecto de investigación y desarrollo 39
Lugar 14
Recurso 15
Evento 3
Actividad 3
Tabla 3: Instanciación del conjunto I usado en la fase de pruebas
Clase Cantidad Descripción
KnowledgeDomain 1067 Las instancias de la clase KnowledgeDomain se utilizan para modelar un área de conocimiento y fue instanciada de forma semi- automatizada con la biblioteca NOR2O, para crear un catálogo de intereses y áreas de conocimiento formado por la unión del catálogo de áreas de conocimiento ANIEI, el catálogo de materias de investigación de la UNESCO y las líneas de especialización manejadas por los miembros de CENIDET, obteniendo un total de 1067 instancias de la clase KnowledgeDomain.
HumanCategory 16 Las instancias de la clase HumanCategory, con sus subclases EducationalLevel y Profession se utilizaron para crear 16 instancias que describen los tipos de persona que pueden visitar una IES, los
106
cuales fueron extraídos de los requisitos del sistema y de las clasificaciones definidas por la SEP y DGEST para el nivel educativo de los estudiantes de educación superior y media superior en México.
Person 62 Las instancias de esta clase corresponden a los profesores de las distintas áreas de especialización del CENIDET, cuya información fue extraída de la página web de la organización.
Education 83 Las instancias de la clase Education representan el campo de educación y el nivel de educación de los profesores de las distintas áreas de especialización del CENIDET.
dblp:Publication 17 Se realizó la instanciación de objetos de conocimiento escritos por profesores de las distintas áreas de especialización del Departamento de Ciencias Computacionales de CENIDET. Las sub-clases instanciadas fueron: dblp:Article_in_Journal, dblp:Article_in_Proceedings, dblp:book y dblp:Thesis.
foaf:Project 39 Las instancias de esta clase corresponden a los proyectos de investigación desarrollados en el CENIDET. La información fue extraída del sitio web de la organización, haciendo referencia a los diferentes departamentos de investigación y desarrollo.
Occupation 165 Las instancias de esta clase, obtenidas de forma semi- automatizada con la biblioteca NOR2O tomando como base el ISCO-2008 (COM) en español, permiten representar las ocupaciones y empleos que desempeñan las personas asociadas a CENIDET.
Place 14 Las instancias de esta clase representan las instalaciones asociadas a CENIDET, esta información fue extraída del plano y registros poseídos por la organización, mediante un levantamiento físico en cada una de las áreas funcionales del edificio de ciencias computacionales.
Division 13 Las instancias de esta clase representan las distintas unidades departamentales existentes en la organización CENIDET, que corresponden a la estructura organizacional.
Service 4 Las instancias de esta clase representan servicios ofrecidos por CENIDET. La información
107
correspondiente fue extraída del sitio Web de la institución.
Resource 15 Las instancias de esta clase corresponden a recursos tecnológicos que pertenecen a la organización CENIDET.
ExperienceRequirements
44 Las instancias de esta clase y sus subclases se utilizan para representar las habilidades que puede poseer una persona, manejando como clases principales las clases BasicSkills y CrossFunctionalSkills.
Hours 3 Las instancias de esta clase representan los horarios de trabajo de CENIDET.
CalendarClockDescription
3 Las instancias de esta clase describen condiciones particulares de los horarios de trabajo de CENIDET.
Event 3 Las instancias de esta clase representan eventos en los que participa la organización CENIDET.
Activity 3 Las instancias de esta clase representan actividades organizacionales desempeñadas por personas asociadas a CENIDET.
6.2 Caso de estudio
Se define un caso de estudio mediante el cual se expone el funcionamiento de los
módulos del Motor de Inferencia y de la GUI adaptable operando sobre un
conjunto de instancias correspondientes a los elementos organizacionales de
CENIDET.
Supóngase que la Dra. Emma León Vega, Investigador Titular C Tiempo Completo
de la UNAM, visita por primera vez la organización CENIDET en su campus
Cerritus. Considerando que sus datos son almacenados en la instancia
UsuarioProfesor2 durante el registro de usuario descrito en el capítulo 5 de esta
tesis, al momento de iniciar el proceso de inferencia se define como Usuario Activo
𝑢𝑎 al usuario UsuarioProfesor2, con el valor Profesor-Investigador para el atributo
userType.
108
El conjunto de información correspondiente a este usuario se presenta en la Tabla
6.3 y la instanciación de los aspectos relevantes para el proceso de inferencia se
muestra en la Tabla 6.4.
Tabla 6.3: Datos del usuario UsuarioProfesor2
Datos generales
Nombre Emma
Apellido paterno León
Apellido materno Vega
Grado Máximo de Estudios Doctorado
Datos de contacto
e-Mail [email protected]
Web http://132.248.35.1:8080/druinv/iaca.jsp?k=0B0415041B22201D241F261B0D0124
Teléfono 7773291840
Ocupación
Nombre de la ocupación o puesto de trabajo Profesor-Investigador
Intereses
Palabras que describen los intereses de la persona. Ontologías
Competencias y Habilidades
Entender las implicaciones de la nueva información tanto para actuales y futuras de resolución de problemas y toma de decisiones Monitoreo evaluación del desempeño del mismo otros individuos u organizaciones para realizar mejoras o tomar medidas correctivas Seleccionar y utilizar los métodos de formación instrucción y procedimientos adecuados para la situación al aprender o ensenar cosas nuevas Usar la lógica y el razonamiento para identificar las fortalezas y debilidades de soluciones alternativas conclusiones o enfoques a los problemas
109
Tabla 4: Instanciación de los datos del usuario UsuarioProfesor2
Datos de identificación de la instancia
Nombre de la instancia UsuarioProfesor2
URI http://www.CENIDET.edu.mx/OrganizationalMemory.owl#UsuarioProfesor2
Clase Person
Relaciones instanciadas
Nombre de la relación Valor de dominio Valor de rango
is_interested_in UsuarioProfesor2 Ciclo_de_vida_de_una_ontologia_asi_como_a_las_metodologias_y_redes_de_ontologias
is_interested_in UsuarioProfesor2 Otras_especializaciones_en_materia_de_tecnologia_especificar_
belongsToHumanCategory UsuarioProfesor2 Doctorado belongsToHumanCategory UsuarioProfesor2 Profesor-Investigador
hasCompetency UsuarioProfesor2 Entender_las_implicaciones_de_la_nueva_informacion_tanto_para_actuales_y_futuras_de_resolucion_de_problemas_y_toma_de_decisiones
hasCompetency UsuarioProfesor2 Monitoreo_evaluacion_del_desempeno_del_mismo_otros_individuos_u_organizaciones_para_realizar_mejoras_o_tomar_medidas_correctivas
hasCompetency UsuarioProfesor2 Seleccionar_y_utilizar_los_metodos_de_formacion_instruccion_y_procedimientos_adecuados_para_la_situacion_al_aprender_o_ensenar_cosas_nuevas
hasCompetency UsuarioProfesor2 Usar_la_logica_y_el_razonamiento_para_identificar_las_fortalezas_y_debilidades_de_soluciones_alternativas_conclusiones_o_enfoques_a_los_problemas
performsOccupation UsuarioProfesor2 Colegio_universidad_y_ensenanza_superior
isCategoryOf Doctorado UsuarioProfesor2 isCategoryOf Profesor-
Investigador UsuarioProfesor2
Atributos instanciados
Nombre del atributo Valor de dominio Valor de rango
family_name UsuarioProfesor2 Leon
lastName UsuarioProfesor2 Vega firstName UsuarioProfesor2 Emma
mbox UsuarioProfesor2 [email protected]
110
De acuerdo al planteamiento descrito en el capítulo 5, el primer módulo del Motor
de Inferencia en ejecutarse el Módulo de pre-filtrado de ítems, el cual identifica
el subconjunto 𝐼𝑢𝑎(6) descrito en la sección 5.3.1, formado por los 9 ítems que
podrían ser del agrado del usuario activo UsuarioProfesor2, cuyo detalle se
muestra en la Tabla 6.5. Las inferencias realizadas por este módulo son
almacenadas en el archivo OrganizationalMemory2.owl.
Tabla 5: Elementos del subconjunto 𝑰𝒖𝒂 para el usuario UsuarioProfesor2
Tipo de ítem Cantidad
Persona 6
Objeto de conocimiento
0
Lugar 1
Recurso 1
Actividad 0
Competencia 1
Proyecto No aplica para usuarios de tipo Profesor-Investigador
Posteriormente, se ejecuta el Módulo de extracción de instancias asociadas a
una organización para la instancia de la organización CENIDET, operando sobre
el archivo OrganizationalMemory2.owl para extraer un subconjunto de 𝐼𝑢𝑎(6),
llamado 𝐼´𝑢𝑎(7), formado por los ítems candidatos a ser recomendados para ese
usuario que se encuentran asociados a CENIDET, obteniendo los elementos
descritos de forma resumida en la Tabla 6.6.
El resultado de la ejecución de este módulo es almacenado en el archivo
OrganizationalMemory3.owl. Debido a que al momento de realizar estas pruebas
únicamente se cuenta con instancias de la organización CENIDET, el subconjunto
𝐼´𝑢𝑎 (7) identificado por este módulo contiene los mismos elementos que el
conjunto 𝐼𝑢𝑎(6).
111
Tabla 6: Elementos del subconjunto 𝑰´𝒖𝒂 para el usuario UsuarioProfesor2
Tipo de ítem Cantidad
Persona 6
Objeto de conocimiento
0
Lugar 1
Recurso 1
Actividad 0
Competencia 1
Proyecto No aplica para usuarios de tipo Profesor-Investigador
Cuando el módulo de localización detecta la llegada del usuario
UsuarioProfesor2, se ejecuta el Módulo generador de recomendaciones, que
de acuerdo al planteamiento presentado en la sección 5.3.3 toma el archivo
OrganizationalMemory3.owl, que contiene las inferencias realizadas por los
módulos previos para conformar el subconjunto 𝐼´𝑢𝑎 (7), a partir del cual se ofrecen
distintos grupos de recomendaciones, siendo que cada grupo es un subconjunto
𝑅𝑢𝑎(8) diferente, inferidos de acuerdo a las circunstancias contextuales presentes
en ese momento y que están definidas por 𝑔𝑖𝑗 (12).
Para fines de experimentación, se definen cuatro escenarios distintos para la
ejecución de este módulo, definidos por cambios en las variables temporales y
espaciales consideradas en el proceso de inferencia, que se traducen en la
consideración de una asignación de valores diferente según 𝑔𝑖𝑗 (12) para cada
escenario. Estos escenarios son descritos en la Tabla 6.7.
Tabla 7: Variaciones contextuales en el caso de uso del usuario UsuarioProfesor2
Escenario 1 Escenario 2 Escenario 3 Escenario 4
Lugar Campus Cerritus
Campus Cerritus
Campus Cerritus
Campus Barrancus
Día Lunes Martes Miércoles Lunes
Hora 14:30:00 15:30:00 10:00:00 14:30:00
Para cada ejecución, el Módulo generador de recomendaciones almacena las
relaciones que infiere en el archivo OrganizationalMemory4.owl, el cual, es
consultado para crear el archivo UsuarioProfesor2.xml, que es desplegado al
usuario en cada escenario mediante la GUI adaptable.
112
El conjunto 𝑅𝑢𝑎 (8) de recomendaciones ofrecidas según las variaciones
contextuales en cada escenario se resumen en la Tabla 6.8, además, las Figuras
6.1, 6.2 y 6.3 muestran la forma en que listas de ítems desplegados en el cliente
varía de acuerdo a las condiciones temporales.
Tabla 8: Elementos del conjunto 𝑹𝒖𝒂 para el usuario UsuarioProfesor2
Tipo de ítem recomendado
Escenario 1 Escenario 2 Escenario 3 Escenario 4
Persona 6 2 6 0
Objeto de conocimiento
0 0 0 0
Lugar 1 0 0 0
Recurso 1 0 0 0
Actividad 0 0 0 0
Competencia 1 0 1 0
Proyecto No aplica para usuarios de tipo Profesor-Investigador
Figura 6.1: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario UsuarioProfesor2 según las variaciones temporales en el Escenario 1
113
Figura 6.2: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario UsuarioProfesor2 según las variaciones temporales en el Escenario 2
114
Figura 6.3: Capturas del cliente mostrando las recomendaciones ofrecidas al usuario UsuarioProfesor2 según las variaciones temporales en el Escenario 3
Cuando el usuario se loguea en la aplicación cliente, puede ver en la primer
pestaña de navegación los ítems recomendados de tipo Persona, los cuales están
relacionados a temas de interés asociados a las ontologías y que corresponden a
los propios intereses instanciados para el usuario.
En la Figura 6.4 se resalta la diferencia en las recomendaciones enlistadas de tipo
Persona por la GUI adaptable de acuerdo a cada una de las variaciones en los
atributos temporales y espaciales, según las cuales puede resultar que un ítem
específico no sea recomendado debido a que no se encuentra en el campus
visitado o que de acuerdo a la información instanciada de horarios de trabajo, la
persona no se encuentra en ese momento dentro de las instalaciones.
115
Figura 6.4: Diferencia en las recomendaciones de tipo Persona
Al consultar información detallada sobre una recomendación específica, la GUI
adaptable muestra datos asociados al valor de algunos de los atributos del ítem
instanciados en la ontología, los cuales son extraídos mediante una consulta de
SPARQL para incluirlos en el archivo.xml que lee el cliente, desplegándolos como
se muestra en la Figura 6.5.
116
Figura 6.1: Despliegue de datos asociados al ítem
De igual forma, al navegar mediante las pestañas restantes, el usuario puede
consultar distintas recomendaciones según los escenarios planteados. Las
recomendaciones de tipo Lugar, Recurso y Competencia, ofrecidas en el
escenario 1 al usuario UsuarioProfesor2, se muestran en la Figura 6.6.
Figura 6.6: Visualización de las recomendaciones de tipo Lugar, Recurso y Competencia ofrecidas al usuario UsuarioProfesor2
117
Además, en caso de que un sub-conjunto de ítems recomendados a desplegar en
una pestaña especifica este vacío, no se muestra ningún elemento en las listas,
como en el caso de las recomendaciones de tipo Objeto de Conocimiento y
Actividades para este caso de uso en el escenario 1, tal y como se muestra en la
Figura 6.7.
Figura 6.7: Visualización de las recomendaciones de tipo Objeto de Conocimiento y Actividades para el usuario UsiarioProfesor2
Una vez que el usuario UsuarioProfesor2 usa la GUI adaptable para consultar
las recomendaciones ofrecidas por el sistema de recomendación, accede a la
pestaña Salir para cerrar su sesión en el cliente mediante la pantalla presentada
en la Figura 6.8.
Figura 6.8: Cierre de la sesión del usuario UsuarioProfesor2 en la GUI adaptable
118
6.3 Pruebas
Una breve descripción de las pruebas realizadas se muestra en la Tabla 6.9; el
caso 1 corresponde al comportamiento del Motor de Inferencia de acuerdo a
cambios en las condiciones temporales al momento de su ejecución. El caso 2
busca reflejar la capacidad del Motor de Inferencia para ofrecer
recomendaciones acordes al tipo de usuario para el que se realice el proceso de
recomendación.
Tabla 9: Casos de prueba
Caso de prueba
Descripción Hipótesis a probar
1
Ejecutar el Motor de Inferencia para cada elemento del conjunto 𝑈 formado por los m usuarios registrados en el sistema bajo distintas condiciones temporales.
Hipótesis 2
Hipótesis 3
2 Ejecutar el Motor de Inferencia para un sub-conjunto de 𝑈 formado por 7 usuarios representativos realizando modificaciones en su atributo Tipo de usuario.
Hipótesis 1
6.3.1 Evaluación experimental
6.3.1.1 Caso de prueba 1. Análisis de la recomendación de ítems
considerando variaciones temporales en el proceso de inferencia
Objetivo: Comprobar las hipótesis 2 y 3 planteadas en la introducción de este
capítulo, mediante la generación y análisis de información que describa
cuantitativamente el comportamiento del Motor de Inferencia durante la definición
del conjunto 𝑅𝑢𝑎, formado por los ítems recomendados a los usuarios según las
características de un usuario activo 𝑢𝑎 y las condiciones contextuales presentes al
momento de efectuar el proceso de inferencia.
Descripción:
1. El conjunto 𝑈 definido para esta prueba está formado por 32 usuarios con
intereses relacionados a las TIC´s, instanciados en el archivo
OrganizationalMemory.owl, el cuál será tomado como entrada por el
Módulo de pre-filtrado de ítems.
119
Los elementos de 𝑈 corresponden a 15 usuarios de tipo Profesor-
Investigador tomados de un catálogo de investigadores nacionales, 10
usuarios de tipo Estudiante que corresponden a estudiantes de licenciatura
que visitaron las instalaciones de CENIDET durante el mes de Agosto del
2011 y 7 usuarios de tipo Empresario. El conjunto 𝐼 sobre el que se realiza
la prueba está definido por 153 ítems recomendables asociados a la
organización CENIDET.
2. Las variables temporales consideradas en el proceso de inferencia tomaran
su valor de acuerdo a los tres escenarios siguientes mostrados en la Tabla
6.10.
Tabla 10: Escenarios para la Prueba 1
Escenario T1 Escenario T2 Escenario T3
Campus Cerritus
Campus Cerritus
Campus Cerritus
Lunes Martes Miércoles
14:30:00 15:30:00 10:00:00
3. Se registrará la cantidad de ítems recomendados, su tipo y el tiempo de
ejecución que toma realizar el proceso de inferencia para cada uno de los
usuarios contemplados en el conjunto 𝑈 bajo cada escenario.
Entrada:
Un archivo OrganizationalMemory.owl que contiene las instancias de los conjuntos
𝑈 e 𝐼, además de 3 valores diferentes para las variables temporales consideradas
en el proceso de inferencia.
Salida:
Datos estadísticos que reflejen la cantidad y tipo de recomendaciones inferidas
para cada tipo de usuario de acuerdo a los tres escenarios temporales planteados.
Análisis de resultados:
Durante la realización de esta prueba, se realizaron 96 ejecuciones del Motor de
Inferencia, en las cuales se efectuó la recomendación de 42 de los 153 ítems que
forman el conjunto 𝐼, que representa un conjunto 𝑅 global conformado por menos
de un tercio de los elementos del conjunto 𝐼, lo cual puede entenderse debido a
120
que la mayoría de los usuarios mostraron intereses asociados a áreas de
conocimiento similares.
El tiempo tomado para llevar a cabo el proceso de recomendación y la cantidad de
ítems recomendados a cada usuario, de acuerdo a los tres escenarios planteados,
se presenta en las Gráficas 6.1 y 6.2, mostrando diferencias en el comportamiento
del Motor de Inferencia.
Adicionalmente, en la Tabla 6.11 se muestra el promedio de los tiempo de
ejecución y las recomendaciones inferidas en cada caso, sin embargo, dado que
el proceso de inferencia se ha dividido en subprocesos de acuerdo a los módulos
descritos en el capítulo anterior, el tiempo que un usuario debe esperar desde el
momento en que su presencia es detectada en las instalaciones, hasta que las
recomendaciones son inferidas para que las consulte en el cliente, se reduce a
aquel que corresponda a la ejecución del Módulo generador de
recomendaciones, cuyo comportamiento es ilustrado mediante la Gráfica 6.3.
Tabla 11: Promedios de los tiempos de ejecución y las recomendaciones inferidas
Tiempo de ejecución promedio en milisegundos
Tiempo de espera en milisegundos al llegar al campus
Cantidad promedio de recomendaciones
inferidas
Escenario T1 367977.625 203219.719 7.65625
Escenario T2 354856.156 9793.78125 7.25
Escenario T3 366437.625 5263.06250 8.75
121
Gráfica 6.1: Variaciones en el tiempo total de ejecución medido en milisegundos bajo tres combinaciones diferentes de variables temporales.
Gráfica 6.2: Variaciones en la cantidad de recomendaciones inferidas bajo tres combinaciones diferentes de variables temporales
122
Gráfica 6.3: Variaciones en el tiempo total de ejecución del Módulo generador de recomendaciones medido en milisegundos bajo tres combinaciones diferentes de variables temporales.
123
Al analizar la información generada durante la ejecución de la prueba, se observa
que la cantidad de ítems de las categorías definidas varía para cada caso
presentado, lo cual se resume en la Tabla 6.12. De manera adicional, la Gráfica
6.4 muestra porcentualmente la cantidad de ocasiones en que un ítem fue
recomendado de acuerdo a los tres escenarios definidos.
Tabla 12: Cantidad de ítems recomendados por categoría, por tipo de usuario y por escenario
ítems recomendados
Escenario 1 Escenario 2 Escenario 3
Pro
fes
or
Alu
mn
o
Em
pre
sa
rio
To
tal
Pro
fes
or
Alu
mn
o
Em
pre
sa
rio
To
tal
Pro
fes
or
Alu
mn
o
Em
pre
sa
rio
To
tal
Persona 4 2 1 7 1 5 20 26 4 5 20 29
Objeto de conocimiento
0 0 5 5 0 0 0 0 0 0 0 0
Lugar 1 2 3 6 0 0 0 0 0 0 0 0
Recurso 1 2 3 6 0 0 0 0 0 0 0 0
Actividad 0 0 1 1 0 0 1 1 0 0 1 1
Competencia 1 0 1 2 0 0 0 0 0 0 0 0
Proyecto 0 0 9 9 0 0 9 9 0 0 9 9
Ítems totales recomendados
7 6 23 36 1 5 30 36 4 5 30 39
Gráfica 6.4: Frecuencia de repetición de los ítems de acuerdo a los tres escenarios definidos
124
Mediante el análisis realizado, es posible dar como verdadera la hipótesis 2: ―La
cantidad y tipo de recomendaciones ofrecidas por el SRSCC T-Guía varían según
las condiciones contextuales presentes al momento de efectuar el proceso de
inferencia‖.
De manera adicional, en la Gráfica 6.5 se muestra la repetición porcentual de un
ítem de acuerdo a los tipos de usuario para los cuales se realizó el proceso de
inferencia, por lo que aunado a la información analizada previamente y resumida
en la Gráfica 6.4, es posible aceptar como verdadera la hipótesis 3: ―La frecuencia
con que un ítem específico es recomendado a los usuarios varía según el tipo de
usuario y las condiciones contextuales presentes al momento de efectuar el
proceso de inferencia‖.
Gráfica 6.5: Frecuencia de repetición porcentual de un ítem de acuerdo a los tipos de usuario
125
6.3.1.2 Caso de prueba 2. Análisis de la recomendación de ítems de acuerdo
al tipo de usuario del Usuario Activo.
Objetivo: Comprobar las hipótesis 1 planteada en la introducción de este capítulo,
mediante la generación y análisis de información que describa cuantitativa y
cualitativamente las diferencias en la definición del conjunto 𝑅𝑢𝑎(8) por parte del
Motor de Inferencia, asignando valores diferentes al atributo Tipo de Usuario de
un usuario activo 𝑢𝑎 al momento de efectuar el proceso de inferencia.
Descripción:
1. El conjunto 𝑈 definido para esta prueba está formado por 7 usuarios de
muestra con intereses relacionados con las líneas de investigación de
CENIDET, instanciados en el archivo OrganizationalMemory.owl, el cuál
será tomado como entrada por el Motor de Inferencia en tres ejecuciones
para cada usuario, modificando en cada una de ellas el valor del atributo
Tipo de Usuario del usuario activo 𝑢𝑎 . El conjunto 𝐼 sobre el que se realiza
la prueba está definido por 153 ítems recomendables asociados a la
organización CENIDET.
2. Los valores permitidos para el atributo Tipo de Usuario serán Profesor-
Investigador, Empresario y Estudiante.
3. Se registrará la cantidad de ítems recomendados y su tipo para cada
ejecución del proceso de inferencia.
4. Se efectuará una ejecución del Motor de Inferencia por cada combinación
Usuario-Tipo de usuario, realizando 21 ejecuciones en total.
5. Se analizarán las diferencias entre los 21 conjuntos 𝑅𝑢𝑎 agrupados por el
usuario correspondiente a cada ejecución.
Entrada:
Un archivo OrganizationalMemory.owl que contiene las instancias de los conjuntos
𝑈 (2) e 𝐼 (1).
Salida:
21 subconjuntos 𝑅𝑢𝑎 (8) distintos, uno por cada ejecución del Motor de
Inferencia, almacenados en archivos .xml , que se analizarán en busca de datos
estadísticos que reflejen la variación en la cantidad y tipo de recomendaciones
inferidas para cada usuario de acuerdo a los tres tipos de usuarios planteados.
126
Análisis de resultados:
Durante la realización de esta prueba se encontró al menos una diferencia entre
los tres conjuntos 𝑅𝑢𝑎 generados para cada usuario muestra, ya sea en la cantidad
de ítems recomendados, su tipo o en el ítem recomendado.
En el caso del usuario identificado como UsuarioMuestra1, el cual tiene interés
en las tecnologías WiFi, Bluetooth, RFID NFC QRCodes y Servicios basados en
localización -LBS-, los cuales se trabajan en la línea de investigación de Sistemas
Distribuidos, se observaron diferencias en la cantidad e ítems recomendados,
pues adicionalmente a que los ítems de tipo Proyecto se ofrecen sólo en el caso
de una inferencia para un usuario de tipo Empresario, las competencias
recomendadas también son diferentes de acuerdo el tipo de usuario, analizando
que a un Empresario se le ofrece la competencia Desarrollo de proyectos con
WiFi, mientras que a un usuario de tipo Estudiante se le ofrece la competencia
Proyectos de residencia profesional. Además, siendo usuario del tipo Profesor-
Investigador, se ofrecen las competencias Investigación colaborativa y Desarrollo
de proyectos con WiFi, disponibles para ese tipo de usuario. Las diferencias entre
los ítems de tipo Competencias recomendados se resaltan mediante la Figura 6.9,
adicionalmente, la forma en que el conjunto de ítems recomendados es
desplegado en el cliente para cada caso se muestra en las Figuras 6.10, 6.11 y
6.12, además de que se resumen en la Tabla 6.13.
Figura 6.9: Diferencias entre los ítems de tipo Competencias recomendados al usuario UsuarioMuestra1
127
Figura 6.10: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de Profesor para el atributo userType
128
Figura 6.11: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de Estudiante para el atributo userType
129
Figura 6.12: Recomendaciones enlistadas para el UsuarioMuestra1 con el valor de Empresario para el atributo userType
130
Tabla 13: Recomendaciones para el UsuarioMuestra1 de acuerdo al atributo userType
Tipo de ítem ofrecido
Recomendaciones inferidas con el valor
Profesor para el atributo userType
Recomendaciones inferidas con el valor
Estudiante para el atributo userType
Recomendaciones inferidas con el valor Empresario para el atributo userType
Persona Profesor1 Profesor1 Profesor1
Objeto de conocimiento
ISSN1390-3608 ISSN1390-3608 ISSN1390-3608
Lugar info_dcc_pb_lab_SD info_dcc_pb_lab_SD info_dcc_pb_lab_SD
Recurso info_dcc_pb_lab_SD Resource1
info_dcc_pb_lab_SD Resource1
info_dcc_pb_lab_SD Resource1
Actividad Evento1 Evento1 Evento1
Competencia Servicio7 Servicio1
Servicio8 Servicio1
Proyecto <<No aplica para el tipo de usuario>> Proyecto5 Proyecto6 Proyecto2
Para usuarios con intereses relacionados a la línea de investigación Inteligencia
Artificial e Ingeniería de Software, reconocidos como UsuarioMuestra2 y
UsuarioMuestra3 respectivamente, se observa un comportamiento similar, como
se aprecian en las Tablas 6.14 y 6.15, las cuales corresponden a las capturas del
cliente presentadas en las Figuras 6.13, 6.14, 6.15, 6.16, 6.17 y 6.18.
Tendencias similares se observaron en las ejecuciones para los otros cuatro
usuarios y las correspondientes variaciones en el atributo userType, por lo que la
hipótesis 1 es aceptada como verdadera: ―la cantidad y tipo de recomendaciones
ofrecidas por el SRSCC T-Guía varían según el tipo de usuario para el que se
realice el proceso de inferencia”.
Tabla 14: Hipótesis probadas en cada caso.
Hipótesis Caso de prueba Resultado
1 Caso de prueba 2 Aceptada
2 Caso de prueba 1 Aceptada
3 Caso de prueba 1 Aceptada
131
Tabla 15: Recomendaciones para el UsuarioMuestra2 de acuerdo al atributo userType
Tipo de ítem ofrecido
Recomendaciones inferidas con el
valor Profesor para el atributo userType
Recomendaciones inferidas con el valor
Estudiante para el atributo userType
Recomendaciones inferidas con el valor Empresario para el atributo userType
Persona Profesor14 Profesor16 Profesor58 Profesor15 Profesor32 Profesor59 Profesor12 Profesor53 Profesor56
Profesor14 Profesor16 Profesor58 Profesor15 Profesor32 Profesor59 Profesor12 Profesor53
Profesor56 >
Profesor14 Profesor16 Profesor58 Profesor15 Profesor32 Profesor59 Profesor12 Profesor53 Profesor56
Objeto de conocimiento
ISSN0302-9743 ISSN0302-9743 ISSN0302-9743
Lugar info_dcc_pb_lab_IA info_dcc_pb_lab_IA info_dcc_pb_lab_IA
Recurso info_dcc_pb_lab_IA info_dcc_pb_lab_IA info_dcc_pb_lab_IA
Actividad
Competencia Servicio7 Servicio8
Proyecto <<No aplica para el tipo de usuario>>
Tabla 16: Recomendaciones para el UsuarioMuestra3 de acuerdo al atributo userType
Tipo de ítem ofrecido
Recomendaciones inferidas con el
valor Profesor para el atributo userType
Recomendaciones inferidas con el valor
Estudiante para el atributo userType
Recomendaciones inferidas con el valor Empresario para el atributo userType
Persona Profesor7 Profesor9
Profesor7 Profesor9
Profesor7 Profesor9
Objeto de conocimiento
ISSN3-540-22060-7 ISSN3-540-22060-7 ISSN3-540-22060-7
Lugar info_dcc_pb_lab_IS info_dcc_pb_lab_IS info_dcc_pb_lab_IS
Recurso info_dcc_pb_lab_IS info_dcc_pb_lab_IS info_dcc_pb_lab_IS
Actividad
Competencia Servicio7 Servicio8
Proyecto <<No aplica para el tipo de usuario>>
132
Figura 6.13: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de Profesor para el atributo userType
133
Figura 6.14: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de Estudiante para el atributo userType
134
Figura 6.15: Recomendaciones enlistadas para el UsuarioMuestra2 con el valor de Empresario para el atributo userType
135
Figura 6.16: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de Profesor para el atributo userType
136
Figura 6.17: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de Estudiante para el atributo userType
137
Figura 6.18: Recomendaciones enlistadas para el UsuarioMuestra3 con el valor de Empresario para el atributo userType
138
6.4 Comportamiento del SRSCC organizacional T-Guía observado
durante la fase de pruebas
Como se ha explicado en la sección anterior, el T-Guía presenta variaciones en la
cantidad, frecuencia y tipo de recomendaciones ofrecidas, ya sea debido a partir
de los diversos tipos de usuario para los que se realiza el proceso de inferencia o
como consecuencia de variaciones en las condiciones contextuales.
Además, contrastando los resultados obtenidos en las pruebas contra los
resultados esperados, los cuales fueron identificados a partir del análisis del
conjunto de información usado como entrada durante el proceso de inferencia, se
considera que el desempeño del sistema es eficiente, ya que las métricas de
Precisión, Recuerdo y Medida F presentaron valores cercanos a 1, siendo
calculados con las siguientes consideraciones:
En el cálculo de las métricas se define como Relevantes a los ítems que se
esperaba que fuesen recomendados. De acuerdo a la información
instanciada, durante la fase de pruebas el T-Guía ha contado con 153 ítems
de los cuales, a partir de las características de los usuarios, se esperaba
que se recomendaran 44 ítems, por lo tanto se tiene un valor para la
variable Relevantes igual a 44.
Se define como Relevantes recuperados a los ítems Relevantes que se
recomendaron; de acuerdo a los resultados obtenidos, durante las pruebas
se recomendaron 42 ítems, los cuales pertenecían al conjunto de ítems
esperados, por lo tanto el valor de la variable Relevantes recuperados es
igual a 42.
Se define como Recuperados a los ítems recomendados. En total, durante
las diferentes ejecuciones del T-Guía se recomendaron 42 ítems de las
diferentes categorías.
La Precisión de un sistema de recomendación, calculada con la fórmula 15, indica
que tan preciso es el T-Guía expresando que proporción de los ítems
recomendados eran realmente interesantes para el usuario. Un valor de 1 para la
métrica Precisión indica que todas las recomendaciones ofrecidas pertenecían al
conjunto de los ítems que se esperaba que el T-Guía recomendara.
Precisión = 𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠
𝑅𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠 (15) Precisión =
42
42
Precisión = 1
139
La métrica Recuerdo, calculada mediante la fórmula 16, expresa la proporción de
ítems recomendados con respecto al conjunto de ítems que se esperaba que se
recomendaran. En esta métrica, el T-Guía mostró un valor igual a 0.9545, dado
que dos de los ítems esperados no se recomendaron en ninguna ejecución.
Recuerdo = 𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠 𝑟𝑒𝑐𝑢𝑝𝑒𝑟𝑎𝑑𝑜𝑠
𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑡𝑒𝑠 (16) Recuerdo =
42
44
Recuerdo = 0.9545
La métrica Medida F, calculada con la fórmula 17, expresa el desempeño de un
sistema de recomendación a partir de la Precisión y el Recuerdo. La Medida F
del T-Guía a partir de las pruebas realizadas es igual a 0.9767.
Medida F = 2 ∗ 𝑅𝑒𝑐𝑢𝑒𝑟𝑑𝑜 ∗ 𝑃𝑟𝑒𝑐𝑖𝑠𝑖 ó𝑛
𝑅𝑒𝑐𝑢𝑒𝑟𝑑𝑜 + 𝑃𝑟𝑒𝑐𝑖𝑠𝑖 ó𝑛 (17) Medida F =
2 ∗ 0.9545∗ 1
0.9545+ 1
Medida F = 0.9767
140
CAPÍTULO 7 CONCLUSIONES Y TRABAJOS FUTUROS
En este capítulo se presentan las conclusiones obtenidas a través del proceso de
investigación desarrollado para llevar a cabo este trabajo de tesis, las
aportaciones más relevantes que surgen a través de éste, y algunos posibles
trabajos futuros que se pueden realizar a partir de los conceptos y técnicas
presentados.
141
7.1 Conclusiones
En este trabajo de tesis se realizó la investigación necesaria para el desarrollo de
un SRSCC organizacional diseñado para entornos de cómputo móvil, cuyo
dominio de recomendación contempla distintos elementos organizacionales que
son ofrecidos mediante una interfaz gráfica adaptable a las características de sus
usuarios.
Los conceptos y técnicas manejados en este trabajo pueden ser retomados en
otros proyectos relacionados con ambientes organizacionales, por lo que dentro
de su descripción se incluyen aspectos relacionados a una posible implementación
en otros tipos de desarrollos. Estos conocimientos se enfocan al modelado
semántico de dimensiones contextuales, redes de ontologías, poblado de
ontologías a partir de recursos no ontológicos, filtrado de información basado en
reglas, procesos de inferencia sobre ontologías, desarrollo de interfaces gráficas a
partir de perfiles de usuarios, interacción humano-máquina en SRSCC con
clientes móviles, análisis del comportamiento de usuarios y análisis del
funcionamiento de SRSCC.
Como parte de este trabajo, se desarrolló el SRSCC organizacional T-Guía con un
escenario de implementación orientado a IES, específicamente el CENIDET, sin
embargo, también se dejan asentadas las bases para trasladar el desarrollo
realizado a otros escenarios organizacionales, como instituciones de gobierno y
empresas, con lo cual se demuestra la flexibilidad de la metodología aplicada, no
quedando limitado el uso de un SRSCC organizacional a una institución en
particular. Esto contrasta con la mayoría de SRSCC organizacionales que se
desarrollan actualmente, pues estos se conciben como aplicaciones ad-hoc
elaboradas específicamente para una organización y dominio precisos y, por tanto,
no resultan generalizables ni utilizables para otros propósitos, por lo que su
funcionalidad se limita normalmente a esa única organización.
De entre las conclusiones obtenidas, se encontró que un modelado semántico de
ambientes organizacionales que contemple múltiples dimensiones contextuales,
las cuales estén interrelacionadas mediante asociaciones entre los diversos
elementos ontológicos usados para modelarlas, puede ser explotado en el
desarrollo de SRSCC para permitir la definición de un proceso de inferencia que
considere una amplia variedad de factores contextuales.
Otro aspecto importante es que dada la experiencia adquirida durante la fase de
implementación, el manejo de reglas de inferencia mediante una estrategia de
definición y almacenamiento que permita aislarlas de la ontología sobre la que se
142
aplican, y que además resulta ajena al lenguaje y características de
programación, permite una fácil modificación del funcionamiento del Motor de
Inferencia de un SRSCC.
Adicionalmente, fue posible apreciar que el uso de sub-conjuntos independientes
de reglas de inferencia para distintos escenarios de aplicación, en los cuales se
pueden incluir reglas que consideren las políticas operacionales de una
organización específica, permite una fácil adaptación de un SRSCC organizacional
a distintas organizaciones.
Otra conclusión presentada se refiere al uso de técnicas de pre-filtrado para el
proceso de inferencia de un SRSCC, pues considerando aquellos que se diseñan
para entornos de tipo campus y enfatizando en aquellos que además operan
sobre clientes móviles, ayuda a reducir el tiempo de respuesta que un usuario
debe esperar al visitar un campus para acceder a las recomendaciones ofrecidas
por el sistema.
De manera adicional, se menciona que es posible registrar la forma en que un
usuario interactúa con las recomendaciones ofrecidas por un SRSCC que opera
sobre clientes móviles, generando información que puede ser explotada en el
proceso de inferencia y en el análisis del funcionamiento del sistema.
Finalmente y como resultado del comportamiento observado al interactuar con
otros proyectos en desarrollo durante la realización de esta tesis, se recalca el
hecho de que el uso de información estandarizada en la fase de instanciación de
los ítems recomendables por un SRSCC, e inclusive durante la instanciación de
sus usuarios, contribuye a que estas instancias sean explotables por otros
proyectos semánticos asociados al dominio de los estándares utilizados, pues se
tiene un conjunto de información que resulta congruente con terminologías y
conceptualizaciones manejadas internacionalmente.
143
7.2 Aportaciones
Como resultado de este trabajo de tesis, se obtuvo el conocimiento tanto para
modelar semánticamente ambientes organizacionales y dimensiones contextuales
asociados a ellos, como para explotar este tipo de modelado mediante el
desarrollo de un SRSCC.
El modelo semántico presentado puede servir de base a distintos proyectos
semánticos para ambientes organizacionales, ya que es capaz de modelar el
conocimiento sobre diversos aspectos organizacionales y factores contextuales
asociados a ellos, definidos sobre estándares internacionales comúnmente
aceptados de acuerdo a los diversos dominios modelados.
Como parte de los elementos desarrollados para el SRSCC organizacional T-
Guía, se definió e implementó un mecanismo que permite a los desarrolladores
una fácil aplicación de reglas de inferencia en SWRL sobre ontologías sin
necesidad de conocer características propias de su programación o
implementación, lo cual es reflejado en los métodos de la clase SWRL4U.java
descrita en el capítulo 5.
Adicionalmente, se presenta un método para el desarrollo de interfaces gráficas
adaptables a los usuarios que puede ser aplicado en el desarrollo de otros clientes
móviles.
Otra aportación es la propuesta de un método para la adaptación de sitios Web de
IES a la Web 3.0, el cual fue usado para la definición del Sistema de
Administración de Información Académica del CENIDET, y que puede ser
aplicable al desarrollo de otras aplicaciones semánticas.
144
7.3 Trabajos futuros
Como una complementación al trabajo realizado, es posible realizar diferentes
trabajos futuros, sugiriéndose los siguientes:
Implementación del monitoreo de las acciones efectuadas por los usuarios
de un SRSCC sobre una ontología de comportamiento de usuario.
Extender el dominio de las variables contextuales consideradas en las
reglas de inferencia.
Implementar historiales de recomendación en el proceso de inferencia
Definir e implementar un mecanismo para evaluar el nivel de eficiencia de
las recomendaciones inferidas con respecto a lo que el usuario desea.
Desarrollo de aplicaciones semánticas explotando el conjunto de ontologías
propuesto.
Extender el dominio de las recomendaciones inferidas a estrategias
publicitarias, alianzas organizacionales, comercialización de productos y
ofertas de empleo, entre otros.
Desarrollar clientes del SRSCC para distintos sistemas operativos móviles o
para computadoras de escritorio.
145
ANEXOS
146
Anexo A: Reglas de inferencia
A.I Conjunto de reglas de inferencia ReglasIES
.
Identificador Regla Descripción
ReglaIES01
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ is_interested_in(?persona, ?areaConocimiento) → isRecommendableFor(?persona, ?usuario)
Esta regla permite identificar personas que comparten intereses con un usuario
ReglaIES02
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ dblp:Publication(?OC) ∧ hasAssociatedKnowledgeDomain(?OC, ?areaConocimiento) → isRecommendableFor(?OC,
?usuario)
Esta regla permite identificar objetos de conocimiento asociados a los intereses de un usuario
ReglaIES03
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?lugar,
?areaConocimiento) ∧ infraestructura:Place(?lugar) → isRecommendableFor(?lugar, ?usuario)
Esta regla permite identificar instalaciones donde se realicen actividades relacionadas a los intereses de un usuario
ReglaIES04
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?recurso, ?areaConocimiento) ∧ resource:Resource(?recurso) → isRecommendableFor(?recurso, ?usuario)
Esta regla permite identificar recursos usados en el desarrollo de actividades asociadas a los intereses de un usuario
ReglaIES05
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ human_activities:hasAssociatedKnowledgeDomain(?a
ctividad, ?areaConocimiento) ∧ orgActivities:Activity(?actividad) → isRecommendableFor(?actividad, ?usuario)
Esta regla permite identificar actividades organizacionales asociadas a los intereses de un usuario
ReglaIES06
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasAssociatedKnowledgeDomain(?evento, ?areaConocimiento) ∧ Event(?evento) → isRecommendableFor(?evento, ?usuario)
Esta regla permite identificar eventos con temáticas asociadas a los intereses de un usuario
ReglaIES07
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasAssociatedKnowledgeDomain(?servicio, ?areaConocimiento) ∧ Service(?servicio) →
isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios asociados a los intereses de un usuario
ReglaIES08
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ Service(?servicio) ∧ orientedTo(?servicio, ?grupoHumano) → isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios ofrecidos por la IES a personas que coincidan con las características de un usuario
147
ReglaIES09
human_activities:belongsToHumanCategory
(?usuario, Empresario ) ∧ human_activities:KnowledgeDomain(?areaConocimiento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasProjectProfile(?proyecto, ?proyectoProfile) ∧ hasAssociatedKnowledgeDomain(?proyecto,
?areaConocimiento) → isRecommendableFor(?proyecto, ?usuario)
Esta regla permite identificar proyectos de investigación asociados a los intereses de un usuario de Empresario
ReglaIES10
isRecommendableFor(?persona, ?usuario) ∧ xfoaf:worksAt(?persona, ?organizacion) → instansOf(?persona,?organizacion)
Esta regla permite identificar la asociación de personas con la IES visitada
ReglaIES11
isRecommendableFor(?OC, ?usuario) ∧ hasKnowledgeObject(?organizacion, ?OC) → instansOf(?OC, ?organizacion)
Esta regla permite identificar la asociación de objetos de conocimiento con la IES visitada
ReglaIES12
isRecommendableFor(?recurso, ?usuario) ∧owns (?organizacion, ?recurso) → instansOf(?recurso,
?organizacion)
Esta regla permite identificar la asociación de recursos tecnológicos con la IES visitada
ReglaIES13
isRecommendableFor(?instalacion, ?usuario) ∧ owns(?organizacion, ?instalacion) → instansOf(?instalacion, ?organizacion)
Esta regla permite identificar la asociación de instalaciones tecnológicas con la IES visitada
ReglaIES14
isRecommendableFor(?servicio, ?usuario) ∧ serves(?organizacion, ?servicio) → instansOf(?servicio, ?organizacion)
Esta regla permite identificar la asociación de servicios con la IES visitada
ReglaIES15
isRecommendableFor(?evento, ?usuario) ∧ isOrganizedBy (?evento, ?organizacion) → instansOf(?evento, ?organizacion)
Esta regla permite identificar eventos asociados con la IES visitada
ReglaIES16
isRecommendableFor(?servicio, ?usuario) ∧ serves(?organizacion, ?servicio) → instansOf(?servicio, ?organizacion)
Esta regla permite identificar la asociación de servicios dirigidos al tipo de usuario para el que se desarrolla el proceso de inferencia con la IES visitada
ReglaIES17
isRecommendableFor(?proyecto, ?usuario) ∧ participatesInA(?organizacion, ?proyecto) → instansOf(?proyecto, ?organizacion)
Esta regla permite identificar la participación de la IES visitada en proyectos de investigación y desarrollo.
ReglaIES18
→ arrivedTo(?usuario, ?lugar) Esta regla permite definir la llegada de un usuario a un campus de una IES
148
ReglaIES19
arrivedTo(?usuario, ?lugar) ∧ instansOf(?instalacion,
?organizacion) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ isRecommendableFor(?instalacion,?usuario) → isNearOf(?instalacion,?usuario)
Esta regla permite identificar la presencia de instalaciones especializadas en el campus visitado por un usuario
ReglaIES20
arrivedTo(?usuario, ?lugar) ∧ instansOf(?persona, ?organizacion) ∧ isRecommendableFor(?persona,?usuario) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ infraestructura:occupiedBy(?instalacion, ?persona) → isNearOf(?persona,?usuario)
Esta regla permite identificar la asociación de lugares de trabajo de los miembros de la IES en el campus visitado por un usuario
ReglaIES21
arrivedTo(?usuario, ?lugar) ∧ instansOf(?OC, ?organizacion) ∧ dblp:Publication(?OC) ∧ instansOf(?OC, ?organizacion) ∧ isRecommendableFor(?OC,?usuario)
∧ hasKnowledgeObject(?instalacion, ?OC) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?OC,?usuario)
Esta regla permite identificar la asociación de objetos de conocimiento al campus de la IES visitado
ReglaIES22
arrivedTo(?usuario, ?lugar) ∧ instansOf(?recurso, ?organizacion) ∧ instansOf(?recurso, ?organizacion) ∧ resource:Resource(?recurso) ∧ isRecommendableFor(?recurso,?usuario) ∧ infraestructura:hasResource(?instalacion, ?recurso) ∧ resource:is_associated_to(?instalacion, ?lugar) →
isNearOf(?recurso,?usuario)
Esta regla permite identificar la asociación física de recursos tecnológicos con el campus de la IES visitado
ReglaIES23
arrivedTo(?usuario, ?lugar) ∧ Event(?evento) ∧ instansOf(?evento, ?organizacion) ∧ isRecommendableFor(?evento,?usuario) ∧ heldin(?evento, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?evento,?usuario)
Esta regla permite identificar los eventos cuya realización se asocia al campus de la IES visitado
ReglaIES24
arrivedTo(?usuario, ?lugar) ∧ instansOf(?proyecto, ?organizacion) ∧ isRecommendableFor(?proyecto,?usuario) ∧ developedAt(?proyecto, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?proyecto,?usuario)
Esta regla permite identificar los proyectos de investigación asociados al campus de la IES visitado
ReglaIES25
arrivedTo(?usuario, ?lugar) ∧ instansOf(?servicio, ?organizacion) ∧ isRecommendableFor(?servicio,?usuario) ∧ isOfferedAt(?servicio, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?servicio,?usuario)
Esta regla permite identificar los servicios ofrecidos por la IES en el campus especifico que es visitado
ReglaIES26
Hours (?horario) → arrivedAt(?usuario, ?horario) Esta regla permite establecer el momento en que un usuario visita una IES
ReglaIES27
isNearOf(?servicio,?usuario) ∧ hasHours(?servicio, ?horario) → offerTo(?servicio,?usuario)
Esta regla permite identificar la disponibilidad de los servicios ofrecidos por una IES en base a su relación con los horarios
149
de trabajo definidos por la organización
ReglaIES28
isNearOf(?OC,?usuario) ∧ canBeUsedAt(?OC, ?horario) → offerTo(?OC,?usuario)
Esta regla permite identificar la disponibilidad de los objetos de conocimiento que posee una IES en base a su compartición física durante los horarios de trabajo definidos por la organización
ReglaIES29
isNearOf(?recurso,?usuario) ∧ canBeUsedAt(?recurso, ?horario) → offerTo(?recurso,?usuario)
Esta regla permite identificar la disponibilidad de los recursos tecnológicos que posee una IES en base a su compartición física durante los horarios de trabajo definidos por la organización
ReglaIES30
isNearOf(?instalacion,?usuario) ∧ canBeUsedAt(?instalacion, ?horario) → offerTo(?instalacion,?usuario)
Esta regla permite identificar la disponibilidad de instalaciones especializadas que posee una IES en base a sus horarios de uso definidos por la organización
ReglaIES31
isNearOf(?evento,?usuario) ∧ dateEnd(?evento, ?FechaFinal) ∧ swrlb:lessThanOrEqual("?fecha", ?FechaFinal) ∧ timeEnd(?evento, ?HoraFinal) ∧ swrlb:lessThanOrEqual("?hora", ?HoraFinal) → offerTo(?evento,?usuario)
Esta regla permite identificar la disponibilidad de los eventos en los que participa una IES en base a los atributos temporales que describen su periodo de ejecución
ReglaIES32
isNearOf(?proyecto, ?usuario) ∧ projectName(?proyecto, ?nombre) → offerTo(?proyecto, ?usuario)
Esta regla permite la recomendación de proyectos de investigación cercanos al usuario
150
A.II Conjunto de reglas de inferencia ReglasGobierno
Identificador Regla Descripción
ReglaGob01
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?persona, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ is_interested_in(?persona, ?areaConocimiento) → isRecommendableFor(?persona, ?usuario)
Esta regla permite identificar personas que comparten intereses con un usuario y cuya información puede ser accedida por ese tipo de usuario
ReglaGob02
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?OC, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ dblp:Publication(?OC) ∧ hasAssociatedKnowledgeDomain(?OC, ?areaConocimiento) → isRecommendableFor(?OC,
?usuario)
Esta regla permite identificar objetos de conocimiento asociados a los intereses de un usuario disponibles para ser accedidos por el tipo de usuario para el que se realiza el proceso de inferencia
ReglaGob03
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?lugar, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?lugar,
?areaConocimiento) ∧ infraestructura:Place(?lugar) → isRecommendableFor(?lugar, ?usuario)
Esta regla permite identificar instalaciones disponibles para ser visitadas por cierto tipo de usuarios en donde se realicen actividades relacionadas sus intereses
ReglaGob04
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?recurso, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?recurso, ?areaConocimiento) ∧ resource:Resource(?recurso) → isRecommendableFor(?recurso, ?usuario)
Esta regla permite identificar recursos usados en el desarrollo de actividades asociadas a los intereses de un usuario que sean definidos como compartibles con los usuarios
ReglaGob05
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ orientedTo(?actividad, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ human_activities:hasAssociatedKnowledgeDomain(?a
ctividad, ?areaConocimiento) ∧ orgActivities:Activity(?actividad) → isRecommendableFor(?actividad, ?usuario)
Esta regla permite identificar actividades organizacionales asociadas a los intereses de un usuario y que estén orientadas al tipo de usuario
151
ReglaGob06
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ orientedTo(?actividad, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasAssociatedKnowledgeDomain(?evento, ?areaConocimiento) ∧ Event(?evento) → isRecommendableFor(?evento, ?usuario)
Esta regla permite identificar eventos con temáticas asociadas a los intereses de un usuario que estén orientadas a su tipo de usuario
ReglaGob07
human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasAssociatedKnowledgeDomain(?servicio, ?areaConocimiento) ∧ Service(?servicio) →
isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios asociados a los intereses de un usuario
ReglaGob08
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ Service(?servicio) ∧ orientedTo(?servicio, ?grupoHumano) → isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios ofrecidos por la institución de gobierno a personas que coincidan con las características de un usuario
ReglaGob09
human_activities:belongsToHumanCategory (?usuario, Empresario ) ∧ human_activities:KnowledgeDomain(?areaConocimiento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasProjectProfile(?proyecto, ?proyectoProfile) ∧ hasAssociatedKnowledgeDomain(?proyecto,
?areaConocimiento) → isRecommendableFor(?proyecto, ?usuario)
Esta regla permite identificar proyectos de investigación asociados a los intereses de un usuario de Empresario
ReglaGob10
isRecommendableFor(?persona, ?usuario) ∧ xfoaf:worksAt(?persona, ?organizacion) → instansOf(?persona,?organizacion)
Esta regla permite identificar la asociación de personas con la institución de gobierno visitada
ReglaGob11
isRecommendableFor(?OC, ?usuario) ∧ hasKnowledgeObject(?organizacion, ?OC) → instansOf(?OC, ?organizacion)
Esta regla permite identificar la asociación de objetos de conocimiento con la institución de gobierno visitada
ReglaGob12
isRecommendableFor(?recurso, ?usuario) ∧owns (?organizacion, ?recurso) → instansOf(?recurso,
?organizacion)
Esta regla permite identificar la asociación de recursos tecnológicos con la institución de gobierno visitada
ReglaGob13
isRecommendableFor(?instalacion, ?usuario) ∧ owns(?organizacion, ?instalacion) → instansOf(?instalacion, ?organizacion)
Esta regla permite identificar la asociación de instalaciones tecnológicas con la institución de gobierno visitada
ReglaGob14 isRecommendableFor(?servicio, ?usuario) ∧ serves(?organizacion, ?servicio) → instansOf(?servicio,
Esta regla permite identificar la asociación
152
?organizacion) de servicios con la institución de gobierno visitada
ReglaGob15
isRecommendableFor(?evento, ?usuario) ∧ isOrganizedBy (?evento, ?organizacion) → instansOf(?evento, ?organizacion)
Esta regla permite identificar la asociación de eventos con la institución de gobierno visitada
ReglaGob16
isRecommendableFor(?servicio, ?usuario) ∧ serves(?organizacion, ?servicio) → instansOf(?servicio, ?organizacion)
Esta regla permite identificar la asociación de servicios dirigidos al tipo de usuario para el que se desarrolla el proceso de inferencia con la institución de gobierno visitada
ReglaGob17
isRecommendableFor(?proyecto, ?usuario) ∧ participatesInA(?organizacion, ?proyecto) → instansOf(?proyecto, ?organizacion)
Esta regla permite identificar la participación de la institución de gobierno visitada en proyectos de investigación y desarrollo.
ReglaGob18
→ arrivedTo(?usuario, ?lugar) Esta regla permite definir la llegada de un usuario a las instalaciones de una institución de gobierno
ReglaGob19
arrivedTo(?usuario, ?lugar) ∧ instansOf(?instalacion,
?organizacion) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ isRecommendableFor(?instalacion,?usuario) → isNearOf(?instalacion,?usuario)
Esta regla permite identificar la presencia de instalaciones especializadas en la institución de gobierno visitada por un usuario
ReglaGob20
arrivedTo(?usuario, ?lugar) ∧ instansOf(?persona, ?organizacion) ∧ isRecommendableFor(?persona,?usuario) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ infraestructura:occupiedBy(?instalacion, ?persona) → isNearOf(?persona,?usuario)
Esta regla permite identificar personas que comparten intereses con un usuario cuyo espacio de trabajo se encuentra dentro de las instalaciones de la institución de gobierno visitada
ReglaGob21
arrivedTo(?usuario, ?lugar) ∧ instansOf(?OC, ?organizacion) ∧ dblp:Publication(?OC) ∧ instansOf(?OC, ?organizacion) ∧ isRecommendableFor(?OC,?usuario)
∧ hasKnowledgeObject(?instalacion, ?OC) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?OC,?usuario)
Esta regla permite identificar la asociación de objetos de conocimiento a la institución de gobierno visitada
ReglaGob22
arrivedTo(?usuario, ?lugar) ∧ instansOf(?recurso, ?organizacion) ∧ instansOf(?recurso, ?organizacion) ∧ resource:Resource(?recurso) ∧ isRecommendableFor(?recurso,?usuario) ∧
Esta regla permite identificar la asociación entre recursos tecnológicos y las instalaciones de la institución de gobierno
153
infraestructura:hasResource(?instalacion, ?recurso) ∧ resource:is_associated_to(?instalacion, ?lugar) →
isNearOf(?recurso,?usuario)
visitada
ReglaGob23
arrivedTo(?usuario, ?lugar) ∧ Event(?evento) ∧ instansOf(?evento, ?organizacion) ∧ isRecommendableFor(?evento,?usuario) ∧ heldin(?evento, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?evento,?usuario)
Esta regla permite identificar los eventos cuya realización se asocia a la institución de gobierno visitada
ReglaGob24
arrivedTo(?usuario, ?lugar) ∧ instansOf(?proyecto, ?organizacion) ∧ isRecommendableFor(?proyecto,?usuario) ∧ developedAt(?proyecto, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → offerTo(?proyecto, ?usuario)
Esta regla permite la recomendación de los proyectos de investigación asociados a la institución de gobierno visitada
ReglaGob25
arrivedTo(?usuario, ?lugar) ∧ instansOf(?servicio, ?organizacion) ∧ isRecommendableFor(?servicio,?usuario) ∧ isOfferedAt(?servicio, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?servicio,?usuario)
Esta regla permite identificar los servicios ofrecidos por la institución de gobierno visitada
ReglaGob26
Hours (?horario) → arrivedAt(?usuario, ?horario) Esta regla permite establecer el momento en que un usuario visita una institución de gobierno
ReglaGob27
isNearOf(?servicio,?usuario) ∧ hasHours(?servicio, ?horario) → offerTo(?servicio,?usuario)
Esta regla permite identificar la disponibilidad de los servicios ofrecidos por una institución de gobierno en base a su relación con los horarios de trabajo definidos por la organización
ReglaGob28
isNearOf(?OC,?usuario) ∧ canBeUsedAt(?OC, ?horario) → offerTo(?OC,?usuario)
Esta regla permite identificar la disponibilidad de los objetos de conocimiento que posee una institución de gobierno en base a su compartición física durante los horarios de trabajo definidos por la organización
ReglaGob29
isNearOf(?recurso,?usuario) ∧ canBeUsedAt(?recurso, ?horario) → offerTo(?recurso,?usuario)
Esta regla permite identificar la disponibilidad de los recursos tecnológicos que posee una institución de gobierno en base a su
154
compartición física durante los horarios de trabajo definidos por la organización
ReglaGob30
isNearOf(?instalacion,?usuario) ∧ canBeUsedAt(?instalacion, ?horario) → offerTo(?instalacion,?usuario)
Esta regla permite identificar la disponibilidad de instalaciones especializadas que posee una institución de gobierno en base a sus horarios de uso definidos por la organización
ReglaGob31
isNearOf(?evento,?usuario) ∧ dateEnd(?evento, ?FechaFinal) ∧ swrlb:lessThanOrEqual("?fecha", ?FechaFinal) ∧ timeEnd(?evento, ?HoraFinal) ∧ swrlb:lessThanOrEqual("?hora", ?HoraFinal) → offerTo(?evento,?usuario)
Esta regla permite identificar la disponibilidad de los eventos en los que participa una institución de gobierno en base a los atributos temporales que describen su periodo de ejecución
155
A.III Conjunto de reglas de inferencia ReglasEmpresa
Identificador Regla Descripción
ReglaEmpresa01
human_activities:HumanCategory(?grupoHumano)
∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?persona, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocim
iento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ is_interested_in(?persona, ?areaConocimiento) → isRecommendableFor(?persona, ?usuario)
Esta regla permite identificar personas que comparten intereses con un usuario y cuya información puede ser accedida por ese tipo de usuario
ReglaEmpresa02
status(?estado) ∧ isShareableWhile(?OC, ?estado) ∧ human_activities:HumanCategory(?grupoHumano)
∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?OC, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocim
iento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ dblp:Publication(?OC) ∧ hasAssociatedKnowledgeDomain(?OC, ?areaConocimiento) → isRecommendableFor(?OC,
?usuario)
Esta regla permite identificar objetos de conocimiento que una empresa define como compartibles de acuerdo a una situación específica asociados a los intereses de un usuario disponibles para ser accedidos por el tipo de usuario para el que se realiza el proceso de inferencia
ReglaEmpresa03
status(?estado) ∧ isShareableWhile(?lugar, ?estado) human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?lugar, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocim
iento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?lugar,
?areaConocimiento) ∧ infraestructura:Place(?lugar) → isRecommendableFor(?lugar, ?usuario)
Esta regla permite identificar instalaciones que una empresa define como compartibles de acuerdo a una situación específica disponibles para ser visitadas por cierto tipo de usuarios en donde se realicen actividades relacionadas sus intereses
ReglaEmpresa04
status(?estado) ∧ isShareableWhile(?recurso, ?estado) ∧ human_activities:HumanCategory(?grupoHumano)
∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?recurso, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocim
iento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?recurso, ?areaConocimiento) ∧ resource:Resource(?recurso) → isRecommendableFor(?recurso, ?usuario)
Esta regla permite identificar recursos que una empresa define como compartibles de acuerdo a una situación específica usados en el desarrollo de actividades asociadas a los intereses de un usuario que sean definidos como compartibles con los usuarios
156
ReglaEmpresa05
human_activities:HumanCategory(?grupoHumano)
∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ orientedTo(?actividad, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocim
iento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ human_activities:hasAssociatedKnowledgeDomain(
?actividad, ?areaConocimiento) ∧ orgActivities:Activity(?actividad) → isRecommendableFor(?actividad, ?usuario)
Esta regla permite identificar actividades organizacionales asociadas a los intereses de un usuario y que estén orientadas al tipo de usuario
ReglaEmpresa06
human_activities:HumanCategory(?grupoHumano)
∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ orientedTo(?actividad, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocim
iento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasAssociatedKnowledgeDomain(?evento, ?areaConocimiento) ∧ Event(?evento) → isRecommendableFor(?evento, ?usuario)
Esta regla permite identificar eventos con temáticas asociadas a los intereses de un usuario que estén orientadas a su tipo de usuario
ReglaEmpresa07
human_activities:KnowledgeDomain(?areaConocim
iento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasAssociatedKnowledgeDomain(?servicio, ?areaConocimiento) ∧ Service(?servicio) →
isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios asociados a los intereses de un usuario
ReglaEmpresa08
human_activities:HumanCategory(?grupoHumano)
∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ Service(?servicio) ∧ orientedTo(?servicio, ?grupoHumano) → isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios ofrecidos por la empresa a personas que coincidan con las características de un usuario
ReglaEmpresa09
human_activities:belongsToHumanCategory (?usuario, Empresario ) ∧ human_activities:KnowledgeDomain(?areaConocimiento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasProjectProfile(?proyecto, ?proyectoProfile) ∧ hasAssociatedKnowledgeDomain(?proyecto,
?areaConocimiento) → isRecommendableFor(?proyecto, ?usuario)
Esta regla permite identificar proyectos de investigación asociados a los intereses de un usuario de Empresario
ReglaEmpresa10
isRecommendableFor(?persona, ?usuario) ∧ xfoaf:worksAt(?persona, ?organizacion) → instansOf(?persona,?organizacion)
Esta regla permite identificar la asociación de personas con la empresa visitada
ReglaEmpresa11
isRecommendableFor(?OC, ?usuario) ∧ hasKnowledgeObject(?organizacion, ?OC) → instansOf(?OC, ?organizacion)
Esta regla permite identificar la asociación de objetos de conocimiento con la empresa visitada
ReglaEmpresa12 isRecommendableFor(?recurso, ?usuario) ∧owns (?organizacion, ?recurso) → instansOf(?recurso,
?organizacion)
Esta regla permite identificar la asociación de recursos
157
tecnológicos con la empresa visitada
ReglaEmpresa13
isRecommendableFor(?instalacion, ?usuario) ∧ owns(?organizacion, ?instalacion) → instansOf(?instalacion, ?organizacion)
Esta regla permite identificar la asociación de instalaciones tecnológicas con la institución de gobierno visitada
ReglaEmpresa14
isRecommendableFor(?servicio, ?usuario) ∧ serves(?organizacion, ?servicio) → instansOf(?servicio, ?organizacion)
Esta regla permite identificar la asociación de servicios con la empresa visitada
ReglaEmpresa15
isRecommendableFor(?evento, ?usuario) ∧ isOrganizedBy (?evento, ?organizacion) → instansOf(?evento, ?organizacion)
Esta regla permite identificar la asociación de eventos con la empresa visitada
ReglaEmpresa16
isRecommendableFor(?servicio, ?usuario) ∧ serves(?organizacion, ?servicio) → instansOf(?servicio, ?organizacion)
Esta regla permite identificar la asociación de servicios dirigidos al tipo de usuario para el que se desarrolla el proceso de inferencia con la empresa visitada
ReglaEmpresa17
isRecommendableFor(?proyecto, ?usuario) ∧ participatesInA(?organizacion, ?proyecto) → instansOf(?proyecto, ?organizacion)
Esta regla permite identificar la participación de la empresa visitada en proyectos de investigación y desarrollo.
ReglaEmpresa18
→ arrivedTo(?usuario, ?lugar) Esta regla permite definir la llegada de un usuario a las instalaciones de una empresa
ReglaEmpresa19
arrivedTo(?usuario, ?lugar) ∧ instansOf(?instalacion, ?organizacion) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ isRecommendableFor(?instalacion,?usuario) ∧ canBeUsedAt(?instalacion, ?horario) → offerTo(?instalacion,?usuario)
Esta regla permite recomendar instalaciones especializadas localizadas en la empresa visitada por un usuario y que se encuentran disponible en el momento de la visita
ReglaEmpresa20
arrivedTo(?usuario, ?lugar) ∧ instansOf(?persona, ?organizacion) ∧ isRecommendableFor(?persona,?usuario) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ infraestructura:occupiedBy(?instalacion, ?persona) → isNearOf(?persona,?usuario)
Esta regla permite identificar personas que comparten intereses con un usuario cuyo espacio de trabajo se encuentra dentro de las instalaciones de la empresa visitada
158
ReglaEmpresa21
arrivedTo(?usuario, ?lugar) ∧ instansOf(?OC, ?organizacion) ∧ dblp:Publication(?OC) ∧ instansOf(?OC, ?organizacion) ∧ isRecommendableFor(?OC,?usuario) ∧ hasKnowledgeObject(?instalacion, ?OC) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?OC,?usuario)
Esta regla permite identificar la asociación de objetos de conocimiento a la empresa visitada
ReglaEmpresa22
arrivedTo(?usuario, ?lugar) ∧ instansOf(?recurso, ?organizacion) ∧ instansOf(?recurso, ?organizacion) ∧ resource:Resource(?recurso) ∧ isRecommendableFor(?recurso,?usuario) ∧ infraestructura:hasResource(?instalacion, ?recurso) ∧ resource:is_associated_to(?instalacion, ?lugar) →
isNearOf(?recurso,?usuario)
Esta regla permite identificar la asociación entre recursos tecnológicos y las instalaciones de la empresa visitada
ReglaEmpresa23
arrivedTo(?usuario, ?lugar) ∧ Event(?evento) ∧ instansOf(?evento, ?organizacion) ∧ isRecommendableFor(?evento,?usuario) ∧ heldin(?evento, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?evento,?usuario)
Esta regla permite identificar los eventos cuya realización se asocia a la empresa visitada
ReglaEmpresa24
arrivedTo(?usuario, ?lugar) ∧ instansOf(?proyecto, ?organizacion) ∧ isRecommendableFor(?proyecto,?usuario) ∧ developedAt(?proyecto, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → offerTo(?proyecto, ?usuario)
Esta regla permite la recomendación de los proyectos de investigación asociados a la empresa visitada
ReglaEmpresa25
arrivedTo(?usuario, ?lugar) ∧ instansOf(?servicio, ?organizacion) ∧ isRecommendableFor(?servicio,?usuario) ∧ isOfferedAt(?servicio, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?servicio,?usuario)
Esta regla permite identificar los servicios ofrecidos por la empresa visitada
ReglaEmpresa26
Hours (?horario) → arrivedAt(?usuario, ?horario) Esta regla permite establecer el momento en que un usuario visita una empresa
ReglaEmpresa27
isNearOf(?servicio,?usuario) ∧ hasHours(?servicio, ?horario) → offerTo(?servicio,?usuario)
Esta regla permite identificar la disponibilidad de los servicios ofrecidos por una empresa en base a su relación con los horarios de trabajo definidos por la organización
ReglaEmpresa28
isNearOf(?OC,?usuario) ∧ canBeUsedAt(?OC, ?horario) → offerTo(?OC,?usuario)
Esta regla permite identificar la disponibilidad de los objetos de conocimiento que posee una empresa en base a su compartición física
159
durante los horarios de trabajo definidos por la organización
ReglaEmpresa29
isNearOf(?recurso,?usuario) ∧ canBeUsedAt(?recurso, ?horario) → offerTo(?recurso,?usuario)
Esta regla permite identificar la disponibilidad de los recursos tecnológicos que posee una empresa en base a su compartición física durante los horarios de trabajo definidos por la organización
ReglaEmpresa30
isNearOf(?evento,?usuario) ∧ dateEnd(?evento, ?FechaFinal) ∧ swrlb:lessThanOrEqual("?fecha", ?FechaFinal) ∧ timeEnd(?evento, ?HoraFinal) ∧ swrlb:lessThanOrEqual("?hora", ?HoraFinal) → offerTo(?evento,?usuario)
Esta regla permite identificar la disponibilidad de los eventos en los que participa una empresa en base a los atributos temporales que describen su periodo de ejecución
160
A.III Conjunto de reglas de inferencia ReglasEvento
Identificador Regla Descripción
ReglaEvento01
Event(?evento) ∧ participatesIn (?evento, ?persona) ∧ human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?persona, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ is_interested_in(?persona, ?areaConocimiento) → isRecommendableFor(?persona, ?usuario)
Esta regla permite identificar personas que participan en un evento y que comparten intereses con un usuario y cuya información puede ser accedida por ese tipo de usuario
ReglaEvento02
Event(?evento) ∧ hasAssociated(?evento, ?OC) ∧ human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?OC, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ dblp:Publication(?OC) ∧ hasAssociatedKnowledgeDomain(?OC, ?areaConocimiento) → isRecommendableFor(?OC,
?usuario)
Esta regla permite identificar objetos de conocimiento relacionados con un evento y que estén asociados a los intereses de un usuario disponibles para ser accedidos por el tipo de usuario para el que se realiza el proceso de inferencia
ReglaEvento03
Event(?evento) ∧ hasAssociated(?evento, ?lugar) ∧ human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?lugar, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?lugar,
?areaConocimiento) ∧ infraestructura:Place(?lugar) → isRecommendableFor(?lugar, ?usuario)
Esta regla permite identificar instalaciones disponibles en el lugar donde se realiza un evento para ser visitadas por cierto tipo de usuarios en donde se realicen actividades relacionadas sus intereses
ReglaEvento04
Event(?evento) ∧ hasAssociated(?evento, ? recurso) ∧ human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ isShareableWith(?recurso, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ resource:isAssociatedToKnowledgeDomain(?recurso, ?areaConocimiento) ∧ resource:Resource(?recurso) → isRecommendableFor(?recurso, ?usuario)
Esta regla permite identificar recursos usados en un evento asociados a los intereses de un usuario que sean definidos como compartibles con los usuarios
ReglaEvento05
Event(?evento) ∧ hasAssociated(?evento, ?actividad) ∧ human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ orientedTo(?actividad, ?grupoHumano) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ human_activities:hasAssociatedKnowledgeDomain(?a
ctividad, ?areaConocimiento) ∧
Esta regla permite identificar actividades realizadas en un evento que estén asociadas a los intereses de un usuario y que estén orientadas al tipo de usuario
161
orgActivities:Activity(?actividad) → isRecommendableFor(?actividad, ?usuario)
ReglaEvento06
Event(?evento) ∧ hasAssociated(?evento, ?servicio) ∧ human_activities:KnowledgeDomain(?areaConocimi
ento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasAssociatedKnowledgeDomain(?servicio, ?areaConocimiento) ∧ Service(?servicio) →
isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios asociados a los intereses de un usuario
ReglaEvento07
human_activities:HumanCategory(?grupoHumano) ∧ human_activities:belongsToHumanCategory(?usuario, ?grupoHumano) ∧ Service(?servicio) ∧ orientedTo(?servicio, ?grupoHumano) → isRecommendableFor(?servicio, ?usuario)
Esta regla permite identificar servicios ofrecidos durante u nevento a personas que coincidan con las características de un usuario
ReglaEvento08
Event(?evento) ∧ hasAssociated(?evento, ?proyecto) ∧ human_activities:belongsToHumanCategory (?usuario, Empresario ) ∧ human_activities:KnowledgeDomain(?areaConocimiento) ∧ is_interested_in(?usuario, ?areaConocimiento) ∧ hasProjectProfile(?proyecto, ?proyectoProfile) ∧ hasAssociatedKnowledgeDomain(?proyecto,
?areaConocimiento) → isRecommendableFor(?proyecto, ?usuario)
Esta regla permite identificar proyectos de investigación asociados a los intereses de un usuario de Empresario
ReglaEvento09
Event(?evento) ∧ isRecommendableFor(?OC,
?usuario) ∧ hasKnowledgeObject(?evento, ?OC) → instansOf(?OC, ?evento)
Esta regla permite identificar la asociación de objetos de conocimiento con el evento visitado
ReglaEvento10
Event(?evento) ∧ isRecommendableFor(?recurso,
?usuario) ∧owns (?evento, ?recurso) →
instansOf(?recurso, ?evento)
Esta regla permite identificar la asociación de recursos tecnológicos con el evento visitado
ReglaEvento11
Event(?evento) ∧ isRecommendableFor(?instalacion,
?usuario) ∧ owns(?evento, ?instalacion) → instansOf(?instalacion, ?evento)
Esta regla permite identificar la asociación de instalaciones tecnológicas con el evento visitado
ReglaEvento12
Event(?evento) ∧ isRecommendableFor(?servicio,
?usuario) ∧ serves(?evento, ?servicio) → instansOf(?servicio, ?evento)
Esta regla permite identificar la asociación de servicios con el evento visitado
ReglaEvento13
ReglaEvento14
Event(?evento) ∧ isRecommendableFor(?servicio,
?usuario) ∧ serves(?evento, ?servicio) → instansOf(?servicio, ?evento)
Esta regla permite identificar la asociación de servicios dirigidos al tipo de usuario para el que se desarrolla el
162
proceso de inferencia con el evento visitado
ReglaEvento15
Event(?evento) ∧ isRecommendableFor(?proyecto,
?usuario) ∧ participatesInA(?evento, ?proyecto) → instansOf(?proyecto, ?evento n)
Esta regla permite identificar la participación de la institución de gobierno visitada en proyectos de investigación y desarrollo.
ReglaEvento16
→ arrivedTo(?usuario, ?lugar) Esta regla permite definir la llegada de un usuario a las instalaciones de una institución de gobierno
ReglaEvento17
arrivedTo(?usuario, ?lugar) ∧ instansOf(?instalacion,
?evento) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ isRecommendableFor(?instalacion,?usuario) → isNearOf(?instalacion,?usuario)
Esta regla permite identificar la presencia de instalaciones especializadas en la institución de gobierno visitada por un usuario
ReglaEvento18
arrivedTo(?usuario, ?lugar) ∧ isRecommendableFor (?persona, ?usuario) ∧ isRecommendableFor(?persona,?usuario) ∧ resource:is_associated_to(?instalacion, ?lugar) ∧ infraestructura:occupiedBy(?instalacion, ?persona) → isNearOf(?persona,?usuario)
Esta regla permite identificar personas que comparten intereses con un usuario cuyo espacio de trabajo se encuentra dentro de las instalaciones de la institución de gobierno visitada
ReglaEvento19
arrivedTo(?usuario, ?lugar) ∧ instansOf(?OC, ?evento) ∧ dblp:Publication(?OC) ∧ instansOf(?OC?evento) ∧ isRecommendableFor(?OC,?usuario) ∧ hasKnowledgeObject(?instalacion, ?OC) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?OC,?usuario)
Esta regla permite identificar la asociación de objetos de conocimiento a la institución de gobierno visitada
ReglaEvento20
arrivedTo(?usuario, ?lugar) ∧ instansOf(?recurso, ?evento) ∧ instansOf(?recurso, ?evento) ∧ resource:Resource(?recurso) ∧ isRecommendableFor(?recurso,?usuario) ∧ infraestructura:hasResource(?instalacion, ?recurso) ∧ resource:is_associated_to(?instalacion, ?lugar) →
isNearOf(?recurso,?usuario)
Esta regla permite identificar la asociación entre recursos tecnológicos y las instalaciones de la institución de gobierno visitada
ReglaEvento21
arrivedTo(?usuario, ?lugar) ∧ Event(?evento) ∧ instansOf(?evento, ?evento) ∧ isRecommendableFor(?evento,?usuario) ∧ heldin(?evento, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?evento,?usuario)
Esta regla permite identificar los eventos cuya realización se asocia a la institución de gobierno visitada
ReglaEvento22
arrivedTo(?usuario, ?lugar) ∧ instansOf(?proyecto, ?evento) ∧ isRecommendableFor(?proyecto,?usuario) ∧ developedAt(?proyecto, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → offerTo(?proyecto, ?usuario)
Esta regla permite la recomendación de los proyectos de investigación asociados a la institución de gobierno visitada
163
ReglaEvento23
arrivedTo(?usuario, ?lugar) ∧ instansOf(?servicio, ?evento) ∧ isRecommendableFor(?servicio,?usuario) ∧ isOfferedAt(?servicio, ?instalacion) ∧ resource:is_associated_to(?instalacion, ?lugar) → isNearOf(?servicio,?usuario)
Esta regla permite identificar los servicios ofrecidos por la institución de gobierno visitada
ReglaEvento24
Hours (?horario) → arrivedAt(?usuario, ?horario) Esta regla permite establecer el momento en que un usuario visita una institución de gobierno
ReglaEvento25
isNearOf(?servicio,?usuario) ∧ hasHours(?servicio, ?horario) → offerTo(?servicio,?usuario)
Esta regla permite identificar la disponibilidad de los servicios ofrecidos por una institución de gobierno en base a su relación con los horarios de trabajo definidos por la organización
ReglaEvento26
isNearOf(?OC,?usuario) ∧ canBeUsedAt(?OC, ?horario) → offerTo(?OC,?usuario)
Esta regla permite identificar la disponibilidad de los objetos de conocimiento que posee una institución de gobierno en base a su compartición física durante los horarios de trabajo definidos por la organización
ReglaEvento27
isNearOf(?recurso,?usuario) ∧ canBeUsedAt(?recurso, ?horario) → offerTo(?recurso,?usuario)
Esta regla permite identificar la disponibilidad de los recursos tecnológicos que posee una institución de gobierno en base a su compartición física durante los horarios de trabajo definidos por la organización
ReglaEvento28
isNearOf(?instalacion,?usuario) ∧ canBeUsedAt(?instalacion, ?horario) → offerTo(?instalacion,?usuario)
Esta regla permite identificar la disponibilidad de instalaciones especializadas que posee una institución de gobierno en base a sus horarios de uso definidos por la organización
164
Referencias
Listado de las referencias utilizadas en este trabajo de tesis.
165
[Adomavicius, 2005] Adomavicius, G., and A. Tuzhilin. 2005. Toward the next generation of recommender systems: A survey of the state-ofthe-art and possible extensions. Ieee Transactions on Knowledge and Data Engineering 17 (6):734-749.
[Arias, 2008] Arias, M., Zubizarreta, A., de la Fuente, P., Cantera, J. M., Cabrero, J., García, G., Llamas, C., and Vegas, J. (2008) ―Context-Based Personalization for Mobile Web Search‖, in International Work in PersDB 2008 33-39.
[Balabanovi, 1997] M. Balabanovi and Y. Shoham. Fab: Content-Based, Collaborative Recommendation. Comm. ACM, vol. 40, no. 3, pp. 66-72, 1997.
[Balabanović, 1997] Marko Balabanović, Yoav Shoham ―Content-based, collaborative recommendation‖. Magazine Communications of the ACM Volume 40 Issue 3, March 1997
[Bouzeghoub, 2009] Amel Bouzeghoub, Kien Ngoc Do, Leandro Krug Wives, "Situation-Aware Adaptive Recommendation to Assist Mobile Users in a Campus Environment," aina, pp.503-509, 2009 International Conference on Advanced Information Networking and Applications, 2009. Bradford, United Kingdom. May 26-May 29. ISBN: 978-0-7695-3638-5
[Breese, 1998] Breese, J. S., Heckerman, D., & Kadie, C. (1998). Empirical analysis of predictive algorithms for collaborative filtering. In Proceedings of the Fourteenth Conference on Uncertainty in Artificial Intelligence, pp. 43–52.
[Burke, 2002] Robin BURKE, R. 2002. Hybrid recommender systems: Survey and Experiments. User Model. User-Adapt. Interact. 12, 4, 331–370.
[Cadenas, 2009] Alejandro Cadenas, Carlos Ruiz, Iker Larizgoitia, Raúl García-Castro, Carlos Lamsfus, Iñaki Vázquez, Marta González, David Martín, María Poveda. ―Context management in mobile environments: a semantic approach‖. ACM International Conference Proceeding Series , Proceedings of the 1st Workshop on Context, Information and Ontologies, Heraklion, Greece Article No.: 2. Year of Publication: 2009 ISBN:978-1-60558-528-4
[Chen, 1998] C. Chen, ―Generalised similarity analysis and pathfinder network scaling,‖ Interacting with Computers, vol. 10, pp. 107–128, Feb. 1998.
[Chen, 2003] H. Chen, T. Finin, and A. Joshi, "An Ontology for Context-Aware Pervasive Computing Environments," Special Issue on Ontologies for Distributed Systems, Knowledge Engineering Review, vol. 18, pp. 197-207, 2003.
[Estrada, 2011] Ricardo Estrada Peláez. Herramienta para la generación y explotación de mapas contextuales semánticos de organizaciones en formato SVG. Tesis de maestria en desarrollo, Depto. de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, Mor.
[Field, 1988] Field, D. A.(1988), ―Laplacian smoothing and Delaunay triangulations‖, Commuications in Applied Numerical Methods., vol. 4, pp. 709-712.
166
[Giunchiglia, 2003] Giunchiglia F. and Shavaiko P. Semantic Matching. Knowledge Engineering Review journal, 18(3):265–280, 2003.
[Goldberg, 2001] K. Y. Goldberg, T. Roeder, D. Gupta, and C. Perkins. Eigentaste: A constant time collaborative filtering algorithm. Inf. Retr., 4(2):133–151, 2001.
[Heckmann,2005] D. Heckmann, T. Schwartz, B. Brandherm, M. Schmitz and M. von Wilamowitz-Moellendorff, GUMO – the General User Model Ontology. User Modeling 2005: 10th International Conference, UM 2005. - Edinburgh : Birkhäuser, 2005.
[Herlocker,1999] Herlocker, J. L., J. A. Konstan, A. Borchers, and J. Riedl. 1999. An algorithmic framework for performing collaborative filtering. In Sigir'99: Proceedings of 22nd International Conference on Research and Development in Information Retrieval, edited by M. Hearst, F. Gey and R. Tong. New York: Assoc Computing Machinery, 230-23
[Horrocks, 2004] I. Horrocks, P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof y M. Dean, SWRL: A Semantic Web Rule Language Combining OWL and RuleML, W3C Member Submission. (2004)
[Kim, 2005] Kim, D., and B. J. Yum. 2005. Collaborative filtering based on iterative principal component analysis. Expert Systems with Applications 28 (4):823-83
[Lemire, 2005] Lemire, D., Boley, H., McGrath, S., Ball, M.: Collaborative filtering and inference rules for context-aware learning object recommendation. J. Interact. Technol. Smart Educ. 2(3), 179–188 (2005)
[Lemire, 2005b] D. Lemire and A. Maclachlan, ―Slope One Predictors for Online Rating-Based Collaborative Filtering‖, Proc. SIAM Data Mining (SDM ‘05), 200
[Liiv, 2009] Liiv, I.; Tammet, T.; Ruotsalo, T.; Kuusik, A.; ―Personalized Context-Aware Recommendations in SMARTMUSEUM: Combining Semantics with Statistics. Advances in Semantic Processing‖, 2009. SEMAPRO '09. Third International Conference on Digital Object Identifier: 10.1109/SEMAPRO.2009.25 Publication Year: 2009 , Page(s): 50 – 55
[Rasanen , 2009] US 20090228211A1 United States Patent Application Publication oo Pub. No.: US 2009/0228211 Al Rasanen et al. Pub. Date: Sep. 10,2009 LOCATION-BASED NOVELTY INDEX VALUE AND RECOMMENDATION SYSTEM AND METHOD. Inventors: Eero Rasanen , Roman Kikta, Antti Sorvari, Jukka-Pekka Salmenkaita, Yka Huhtala, Heikki Mannila, Hannu T. Toivonen, Kari Oinonen, Juhani Murto. Assignee: Nokia Corporation. (2009). USA
[Sarwar, 2001] Badrul Sarwar, George Karypis, Joseph Konstan, and John Riedl ―Item-Based Collaborative Filtering Recommendation Algorithms‖. WWW '01 Proceedings of the 10th international conference on World Wide Web table of contents. P. 285 – 295. ACM New York, NY, USA ©2001 ISBN: 1-58113-348-0 doi>10.1145/371920.372071
[Sauermann, 2007] Sauermann, L., van Elst, L., and Dengel, A., ―PIMO – a Framework for Representing Personal Information Models‖, Proc. of I-Semantics' 07, 2007.
167
[Sawar, 2001] Sarwar, B. M., Karypis, G., Konstan, J. A., and Riedl, J. 2001. Item-based collaborative filtering recommendation algorithms. In Proceedings of the 10th InternationalWorldWideWeb Conference (WWW10).
[Shipman, 1995] F. M. Shipman, C. C. Marshall, and T. P. Moran, ―Finding and using implicit structure in humanorganized spatial layouts of information,‖in Proc. Of CHI, pp. 346–353. 1995.
[Sousa, 2009] Sousa, João Paulo; Carrapatoso, Eurico; Fonseca, Benjamin; Pimentel, Maria da Graça; Neto, Renato Bulcão; ―Composition of context aware mobile services using a semantic context model‖. Editorial: IARIA. International Journal on Advances in Software. ISSN 1942-2628. 2:2-3 (2009) p. 275-287.
[Ungar, 1998] Ungar, L. H., and D. P. Foster. 1998. Clustering Methods for Collaborative Filtering. Paper read at Proceedings of the Workshop on Recommendation System
[Vargas, 2011] Vargas Arroyo, Rocío. Modelo colaborativo para la integración de sistemas, tesis de doctorado en desarrollo, Depto. de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, Mor.
[W3C, 2006] W3C, "Time ontology in OWL," draft version 2006, http://www.w3.org/TR/owl-time/.
[Wang, 2006]| J. Wang, A. P. de Vries, and M. J. T. Reinders. Unifying user-based and item-based collaborative filtering approaches by similarity fusion. In SIGIR ‘06: Proceedings of the 29th annual international ACM SIGIR conference on Research and development in information retrieval, pages 501–508, New York, NY, USA, 2006. ACM Press.
[Woerndl, 2008] Woerndl, W., and Woehrl, M., ―SeMoDesk: Towards a Mobile Semantic Desktop‖. Proc. Personal Information Management (PIM) Workshop, CHI 2008 Conference, Florence, Italy, 2008
[Woerndl, 2009] Woerndl, W.; Hristov, A.; ―Recommending Resources in Mobile Personal Information Management‖, Digital Society, 2009. ICDS '09. Third International Conference on Digital Object Identifier: 10.1109/ICDS.2009.21. Publication Year: 2009 , Page(s): 149 – 154
[Xue, 2005] G.-R. Xue, C. Lin, Q. Yang, W. Xi, H.-J. Zeng, Y. Yu, and Z. Chen. Scalable collaborative filtering using cluster-based smoothing. In Proc. of SIGIR, 2005.
[Yris,2011] Miguel A. Yris Pastor. API para Servicios de localización en interiores basado en tecnologías WiFi, Buetooth, RFID y QRCodes. Tesis de maestria en desarrollo, Depto. de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, Mor.
[Zubizarreta, 2005] Zubizarreta, A., de la Fuente, P., Cantera, J. M., Arias, M., Cabrero, J., García, G., Llamas, C., and Vegas, J. (2005) ―Context-Based Personalization for Mobile Web Search‖, in International Work in PersDB 2008 33-39.
[Zubizarreta, 2008] Zubizarreta, A., de la Fuente, P., Cantera, J. M., Arias, M., Cabrero, J., García, G., Llamas, C., and Vegas, J. (2008) ―A georeferencing method for locating geographic context in web search‖, in CIKM 2008:1485-1486.
168
[Zubizarreta, 2009] Zubizarreta, A., de la Fuente, P., Cantera, J. M., Arias, M., Cabrero, J., García, G., Llamas, C., and Vegas, J. (2009). ―Extracting geographic context from the web: Georeferencing in mymose‖. In 31st European Conference on Information Retrieval, ECIR 2009, Toulouse, France, April 6-9, 2009, Lecture Notes in Computer Science. Springer