CENTRO DE INVESTIGACION Y DE ESTUDIOS AVANZADOS DEL … · 2014-12-02 · y Marco porque desde el...

$: CENTRO DE INVESTIGACION Y DE ESTUDIOS AVANZADOS DEL … · 2014-12-02 · y Marco porque desde el inicio me \adoptaron" y nunca me dejaron sola, ni en la cuesti on acad emica ni en$
CENTRO DE INVESTIGACION Y DEESTUDIOS AVANZADOS DEL INSTITUTO

POLITECNICO NACIONAL

Unidad Zacatenco

Departamento de Computacion

Un algoritmo de coincidencia semantico para la

localizacion de recursos en entornos colaborativos

T E S I S

Que presenta

Salma Leonor Velasco Perez

Para obtener el grado de

Maestra en Ciencias

en Computacion

Directoras de la Tesis:

Dra. Sonia Guadalupe Mendoza Chapa

Dra. Elvia Kimberly Garcıa Garcıa

Mexico, D.F. Noviembre, 2014

ii

Agradecimientos

Principalmente quiero dar la gracias al CINVESTAV-IPN unidad Zacaten-co, en especial al Departamento de Computacion y al CONACyT por brindarmela oportunidad y los recursos para poder estudiar un posgrado.

Gracias doctora Sonia, por darme la oportunidad de ser su asesorada y poresa confianza que me dio. Por ser no solo un ejemplo de doctora, sino tambiende persona, por su apoyo durante todo el ano de tesis y el conocimiento que mecompartio.

Gracias doctora Kim, por siempre estar al pendiente de mı y por solucionarmis dudas constantes y fuera de horario. Gracias por no solo asesorarme, sinotambien por ser una buena persona conmigo en todo momento.

Gracias a los doctores Amilcar Meneses y Jose Guadalupe Rodrıguez,por tomarse el tiempo de leer mi tesis y ser mis sinodales, ademas de todos losconocimiento que recibı durante sus clases, tambien a los doctores Debrup Cha-kraborty, Sergio Chapa y Cesar Huitzil.

Gracias mami, Silvia, por darnos el mejor ejemplo de escalar lo mas alto quepodamos sin descuidar a nuestra familia. Gracias por siempre apoyarnos en todosnuestros suenos, nunca dejarnos solas y darnos esos animos que siempre funcionan.Muchas gracias porque siempre confiaste y cuidaste de mı incluso a traves de ladistancia. Gracias por ese corazon tan grande para cuidar de todos nosotros ydedicarnos tiempo a cada uno. Doy gracias a Dios por haberme brindado unamama tan carinosa, trabajadora, luchadora, protectora, que da todo por nosotros...Gracias por darnos esa confianza de saber que siempre podemos contar contigo entodo momento.

Gracias hermanitas, Ale y Bety, por siempre cuidar de mı como mis se-gundas mamas y ser mis amigas incondicionales, por siempre darme animos yapoyarme en todas y cada una de las metas que me propongo. Gracias por ser esashermanas que todo mundo me envidia, por todos sus cuidados y detalles, por losconsejos, los animos y los reganos.

Gracias papa, Orlando, por estar al pendiente de mı aun en la lejanıa, porseguirme apoyando para alcanzar mis metas y siempre darme animos.

Gracias a mis sobrinos, Yami y Alex, porque cada que voy a su casa se queme recibiran con los brazos abiertos y con muchas ganas de jugar, por no dejar quemi nina interna muera y por darme grandes ratos de diversion y muchos abrazosde animo.

Gracias a toda mi familia, en especial a mis cunados, Jose Luis y Mario, amis tıos Fer, Lolis y Gaby, y a mis primos Fer, Carmen, Bhisa y Richi por siempre

iii

estar al pendiente de nosotros y apoyarnos en todas esas situaciones difıciles quehemos pasado, tambien por los animos que siempre nos dan.

Gracias Sofi, a mis amigos Karla, Jorge, Petla, Imi, Memo, Voncita, Yarey Marco porque desde el inicio me “adoptaron” y nunca me dejaron sola, ni enla cuestion academica ni en la sentimental, gracias por su amistad, por confiary siempre estar al pendiente de mı. Gracias Edgar, Abi, Chava y Fermin porbrindarme su amistad, por compartir su tiempo conmigo y su apoyo constante.Gracias a todos mis companeros de generacion porque de todos tengo muy buenosrecuerdos y aprendı muchas cosas.

iv

Indice general

Lista de figuras VI

1. Introduccion 11.1. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . 11.2. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 21.4. Organizacion de la tesis . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Marco teorico 52.1. Trabajo Colaborativo Asistido por Computadora . . . . . . . . . . . 52.2. Computo Ubicuo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3. Ontologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4. Protocolos de descubrimiento . . . . . . . . . . . . . . . . . . . . . 122.5. Contexto de investigacion . . . . . . . . . . . . . . . . . . . . . . . 13

3. Estado del Arte 173.1. Trabajos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1. DAIDALOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.2. AIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.1.3. UDDI CON ALGORITMO DE COINCIDENCIA . . . . . . 223.1.4. CASSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2. Analisis comparativo . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4. Analisis y diseno del algoritmo de coincidencia semantico 314.1. Descripcion de la arquitectura RAMS . . . . . . . . . . . . . . . . . 314.2. Diseno del algoritmo de coincidencia . . . . . . . . . . . . . . . . . 344.3. Ontologıas de la arquitectura RAMS . . . . . . . . . . . . . . . . . 36

4.3.1. Ontologıa HumanResource . . . . . . . . . . . . . . . . . 364.3.2. Ontologıa PhysicalResource . . . . . . . . . . . . . . . . . 384.3.3. Ontologıa VirtualResource . . . . . . . . . . . . . . . . . 434.3.4. Ontologıa Context . . . . . . . . . . . . . . . . . . . . . . . 434.3.5. Ontologıa InstitutionInformation . . . . . . . . . . . . . 454.3.6. Ontologıa MetaOntology . . . . . . . . . . . . . . . . . . . 47

4.4. Estados de disponibilidad . . . . . . . . . . . . . . . . . . . . . . . 474.4.1. Estado Allowed . . . . . . . . . . . . . . . . . . . . . . . . . 474.4.2. Estado Free . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

v

4.4.3. Estado Satisfy Restrictions . . . . . . . . . . . . . . . . . . . 494.4.4. Estado Reachable . . . . . . . . . . . . . . . . . . . . . . . . 504.4.5. Estado Available Provider . . . . . . . . . . . . . . . . . . . . 514.4.6. Estado Satisfy Context Restrictions . . . . . . . . . . . . . . . 51

4.5. Similitud semantica entre las clases de las ontologıas . . . . . . . . . 51

5. Implementacion del algoritmo de coincidencia en RAMS 555.1. Estructura y bibliotecas del algoritmo de coincidencia . . . . . . . . 555.2. Desarrollo del algoritmo de coincidencia . . . . . . . . . . . . . . . 585.3. Modulo de multi-busqueda . . . . . . . . . . . . . . . . . . . . . . . 635.4. Modulo de suscripcion . . . . . . . . . . . . . . . . . . . . . . . . . 655.5. Interfaces graficas de usuario . . . . . . . . . . . . . . . . . . . . . . 675.6. Resultados del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . 69

5.6.1. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . 705.6.2. Indicadores de desempeno . . . . . . . . . . . . . . . . . . . 715.6.3. Pruebas del algoritmo de coincidencia semantico . . . . . . . 73

6. Conclusiones y trabajo a futuro 776.1. Recapitulacion del problema . . . . . . . . . . . . . . . . . . . . . . 776.2. Conclusiones y contribuciones . . . . . . . . . . . . . . . . . . . . . 776.3. Trabajo a futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A. Ontologıas 81

vi

Indice de figuras

1.1. Capıtulos de la tesis . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Tipos de topologıas en el area Groupware . . . . . . . . . . . . . . . 8

2.2. Ejemplo de ontologıa . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3. Union entre las areas y herramientas . . . . . . . . . . . . . . . . . 14

2.4. Algoritmo de coincidencia semantico basado en contexto colaborativo 15

3.1. Mecanismo de filtrado de DAIDALOS . . . . . . . . . . . . . . . . . 19

3.2. Arquitectura de AIDAS . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3. Arquitectura de UDDI con algoritmo de coincidencia . . . . . . . . 23

3.4. Analisis de las caracterısticas de los algoritmos de coincidencia delos trabajos relacionados . . . . . . . . . . . . . . . . . . . . . . . . 27

3.5. Analisis de atributos semejantes de los trabajos relacionados . . . . 28

4.1. Componentes de la arquitectura RAMS . . . . . . . . . . . . . . . . 33

4.2. Diseno original del algoritmo de coincidencia de RAMS . . . . . . . 35

4.3. Diseno actual del algoritmo de coincidencia . . . . . . . . . . . . . . 36

4.4. Clases principales de la ontologıa HumanResource . . . . . . . . . . 37

4.5. Subclases de la clase JobPosition . . . . . . . . . . . . . . . . . . . 37

4.6. Subclases agregadas a la clase HumanResource para el caso de uncentro de investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.7. Clases principales de la ontologıa PhysicalResource . . . . . . . . . 39

4.8. Subclases de la clase Building . . . . . . . . . . . . . . . . . . . . . 39

4.9. Subclases originales de la clase Hardware . . . . . . . . . . . . . . . 40

4.10. Subclases originales de la clase Hardware . . . . . . . . . . . . . . . 41

4.11. Subclases modificadas de la clase Hardware . . . . . . . . . . . . . . 42

4.12. Clases principales de la ontologıa VirtualResource . . . . . . . . . . 43

4.13. Subclases de la clase File . . . . . . . . . . . . . . . . . . . . . . . . 44

4.14. Subclases de la clase Tools . . . . . . . . . . . . . . . . . . . . . . . 44

4.15. Clases de la ontologıa Context . . . . . . . . . . . . . . . . . . . . . 45

4.16. Subclases de la clase OrganizationalContext . . . . . . . . . . . . . 45

4.17. Subclases de la clase PhysicalContext . . . . . . . . . . . . . . . . . 46

4.18. Clase principal de la ontologıa InstitutionInformation . . . . . . . . 46

4.19. Subclases de la clase Department . . . . . . . . . . . . . . . . . . . 47

4.20. Clases que forman MetaOntology . . . . . . . . . . . . . . . . . . . 48

4.21. Ejemplo de subsuncion . . . . . . . . . . . . . . . . . . . . . . . . . 52

vii

5.1. Paquetes del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . 565.2. Bibliotecas importadas al proyecto . . . . . . . . . . . . . . . . . . 575.3. Consulta de autenticacion del usuario . . . . . . . . . . . . . . . . . 615.4. Estructura hilos Callable . . . . . . . . . . . . . . . . . . . . . . 625.5. Interfaz inicial de la aplicacion que explota el algoritmo de coincidencia 675.6. Interfaz del menu principal de la aplicacion . . . . . . . . . . . . . . 685.7. Interfaz para la seleccion del tipo de recurso a buscar . . . . . . . . 695.8. Pantalla preguntando por las caracterısticas tecnicas . . . . . . . . 695.9. Pantalla de los estados de disponibilidad . . . . . . . . . . . . . . . 705.10. Pantalla solicitando al usuario las preferencias de contexto . . . . . 705.11. Pantalla entregando los resultados finales . . . . . . . . . . . . . . . 715.12. Resultados de la similitud semantica en recursos fısicos . . . . . . . 735.13. Resultados de la similitud semantica en recursos virtuales . . . . . . 745.14. Resultados de la similitud semantica en recursos humanos . . . . . 745.15. Resultados del algoritmo de coincidencia en recursos fısicos . . . . . 755.16. Resultados del algoritmo de coincidencia en recursos virtuales . . . 755.17. Resultados del algoritmo de coincidencia en recursos humanos . . . 755.18. Tabla de los tiempos de ejecucion de las tareas principales . . . . . 76

1. Tipos de ontologıas . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

viii

Resumen

En las grandes organizaciones, existe un problema recurrente que pocos investiga-dores han considerado referente a la localizacion y al uso compartido de recursos,una tarea muy comun que puede ser mejorada en terminos de tiempo y accesibi-lidad. En un contexto organizacional, el uso de recursos adecuados para resolverun problema contribuye a generar mejores resultados para una meta establecida.Un equipo de trabajo dentro de una organizacion debe contar con un sistema queayude a sus miembros a encontrar estos recursos de manera rapida y eficiente. Losrecursos encontrados por el sistema deben satisfacer los requerimientos tecnicos, lasrestricciones y los permisos de uso definidos para dicho grupo de trabajo, ademasde localizarse lo mas cercano posible a sus miembros. La resolucion del problemade comparticion de recursos a traves de un sistema computacional es un objetivodel Trabajo Cooperativo Asistido por Computadora. Por otro lado, el problema dela busqueda de recursos puede ser tratado como una version de la localizacion deServicios Web. Por lo tanto, en esta tesis se propone el desarrollo de un algoritmode coincidencia semantico basado en contexto colaborativo para solucionar el pro-blema de descubrimiento y uso compartido de recursos dentro de una organizacion.Debido a las similitudes que comparten ambos tipos de busqueda, podemos usaralgunas herramientas que se utilizan actualmente en el descubrimiento de serviciosWeb para la localizacion de recursos compartidos dentro de una organizacion. En-tre estas herramientas, podemos mencionar a los protocolos de descubrimiento deservicios Web, e.g., Jini, UpnP y UDDI, y a los algoritmos de coincidencia semanti-cos. Estos ultimos, ademas de generar resultados a traves de similitud sintacticade palabras claves entre los servicios solicitados y los servicios publicados, tambienusan similitud semantica para mostrar servicios que pueden ser usados de formasimilar a los solicitados originalmente. Para poder implementar similitud semanti-ca en nuestro algoritmo de coincidencia usamos ontologıas porque han probado serel modelo idoneo para representar y analizar el significado y contexto de la infor-macion (en este caso, el contexto colaborativo para la localizacion y el prestamode recursos compartidos en una organizacion), proveen un razonamiento eficientesobre dicha informacion y permiten la interoperabilidad de servicios como base deconocimiento, la cual puede ser manipulada a traves del algoritmo de coincidenciapropuesto. Estas ontologıas fueron disenadas de forma generica para ser adoptadaspor cualquier organizacion y explotar el contexto colaborativo en ellas, medianterelaciones que permiten representar la existencia de vınculos entre los colabora-dores de dicha organizacion, con el fin de mejorar la certitud de la respuesta quenuestro algoritmo proporciona.

ix

x

Abstract

In large organizations, there exists a recurrent problem that few researchers ha-ve considered concerning the discovery and sharing of resources, a very commontask that can be improved in terms of time and accessibility. In an organizationalcontext, the use of appropriate resources to solve a problem contributes to produ-ce better results for a specific goal. A teamwork in an organization should havea system to help its members to find such resources quickly and efficiently. Theresources found by the system must satisfy the technical requirements, restrictionsand use permissions for the teamwork, and these resources must be located as closeas possible to its members. The solution of the resource sharing problem througha computer system is a target of the Computer Supported Cooperative Work field.On the other hand, the resource search problem can be treated as a version of theWeb service discovery. Therefore, in this thesis, we propose the development of acollaborative context-based semantic matchmaker to solve the problem of resourcediscovery and sharing in an organization. Due to the similarities shared by bothtypes of searches, we can rely on some tools that are currently used in the discoveryof Web services to find shared resources in an organization. Among these tools, wecan mention the Web service discovery protocols, e.g., Jini, UpnP, and UDDI, andsemantic matchmakers. The latter ones are designed to generate results throughsyntactic similarity of keywords between the requested service and the publishedones and also use semantic similarity to show services that can be used similarlyto the requested ones. To implement semantic similarity in our matchmaker, weuse ontologies because they have demonstrated to be the ideal model to representand analyze the meaning and context of information (in this case, the collaborativecontext for discovering and borrowing shared resources in an organization), provi-de an efficient reasoning about such information and facilitate the interoperabilityof services as a knowledge base, which can be manipulated through the proposedmatchmaker. These ontologies were designed in a generic way to be adopted byany organization and exploit the collaborative context in them, through relations-hips that can represent the existence of ties between the employees of such anorganization, in order to improve the certainty of the response that our algorithmprovides.

xi

xii

Capıtulo

1Introduccion

1.1. Planteamiento del problema

En una organizacion existen diferentes tipos de recursos, los cuales podemos clasi-ficar en tres grupos principales: humanos, fısicos y virtuales [1]. Los recursos huma-nos se refieren a las personas que pertenecen en una organizacion, ası como a susvisitantes. Entre los recursos fısicos podemos encontrar dispositivos como camaras,teclados, monitores, pantallas, discos duros, multifuncionales, etc. Es importantemencionar que los edificios y espacios compartidos, como salas de juntas y audito-rios, tambien forman parte de esta categorıa. Finalmente, los recursos virtuales sonlos programas y/o archivos a los que un usuario puede acceder y/o utilizar; entre es-tos podemos encontrar bases de datos, controladores, archivos virtuales, antivirus,sistemas operativos, etc. Todos los recursos mencionados anteriormente pueden sercompartidos entre colegas, visitantes o un grupo especıfico de colaboradores de laorganizacion. Sin embargo, el acceso a estos recursos debe ser controlado para cadapersona, de acuerdo a sus caracterısticas especıficas (e.g., personas que pertenecena diferentes grupos de trabajo o con diferente jerarquıa y/o restricciones) ya quedichos recursos podrıan sufrir mal trato o abuso.

Es importante que en una organizacion las personas cuenten con un sistemapara compartir todos sus recursos de forma natural e intuitiva con el fin de motivara los colaboradores a incorporar el uso de dicho sistema a sus actividades diariassin problemas. Este sistema debe usar un algoritmo de coincidencia adecuado paraque el usuario pueda encontrar recursos en una organizacion de cualquier tamano.Actualmente existen trabajos que proponen este tipo de algoritmos (Suraci et al.[2], Toninelli et al. [3], Kawamura et al. [4] y Patel et al. [5]) los cuales se basan enun algoritmo semantico que utiliza el significado de cada uno de los recursos paramejorar los resultados de la busqueda realizada por un usuario. Sin embargo, estostrabajos asumen que la mayorıa de los usuarios no tiene restricciones de acceso a losrecursos, de acuerdo a sus relaciones laborales o personales, no toman en cuentala disponibilidad actual de dichos recursos y, en su mayorıa, han sido pensadospara aplicaciones que actuan como clientes, no para humanos. Debido a que lostrabajos relacionados no consideran restricciones de uso, todos los recursos sonpermitidos para todas las personas que ingresan a la organizacion. De igual forma,la localizacion de los recursos y/o usuarios no es importante para estos trabajos, locual es una desventaja significativa, ya que podrıa sugerirse a un usuario utilizarun recurso que se encuentre muy lejano a el, e incluso es posible que el recursosolicitado no este dentro de las instalaciones de la organizacion, e.g., si un usuario

1

solicita un servicio Web, que la organizacion no tiene en su poder, puede solicitarloa una organizacion asociada, sin importar la ubicacion fısica del dispositivo en elque este almacenado. Tambien es importante que el usuario deberıa ser prevenidode cualquier cambio en los recursos de la organizacion.

Los trabajos relacionados utilizan ontologıas, pero algunos no consideran lasimilitud semantica entre las clases de dicha ontologıa. Por lo tanto, los recur-sos arrojados por una busqueda podrıan no ser los ideales para el usuario. Estostrabajos relacionados, tampoco permiten la busqueda de mas de un recurso si-multaneamente, i.e., un usuario debe realizar una consulta para cada uno de losrecursos en los que esta interesado.

1.2. Hipotesis

El uso de un algoritmo de coincidencia semantico ayudarıa a mejorar la busquedade un recurso con base en el concepto que representa, no solamente en la sintaxisque lo identifica. La inclusion del contexto del usuario (e.g., su localizacion o surelacion con colaboradores) en un algoritmo semantico mejorıa la busqueda de unrecurso porque evitarıa que el usuario recorra largas distancias para obtener elrecurso que desea usar. Adicionalmente, si este algoritmo incorpora un metodopara obtener la distancia semantica entre las clases de su ontologıa, creara unajerarquizacion de resultados que el usuario podrıa usar para tomar con mayorfacilidad una decision con respecto a la consulta que realizo.

1.3. Objetivos del proyecto

El objetivo general de la presente tesis es enriquecer y validar un algoritmo decoincidencia semantico, capaz de encontrar el mejor recurso disponible para sa-tisfacer la peticion de un usuario, considerando las capacidades y el contexto delas entidades involucradas en dicha peticion, i.e., los recursos, el solicitante y elproveedor, ası como sus relaciones y dependencias con otros recursos.

Los objetivos particulares son:

1. Analizar los algoritmos de coincidencia existentes para enriquecer la propues-ta actual.

2. Mejorar y validar los grados de coincidencia especificados por el algoritmobase.

3. Realizar las modificaciones pertinentes en el algoritmo de coincidencia actualpara obtener mejores resultados.

2

4. Desarrollar una interfaz de usuario que facilite el uso del algoritmo de coin-cidencia.

1.4. Organizacion de la tesis

Esta tesis se ha desarrollado en 6 capıtulos, como se muestra en la Figura 1.1. Unavez que hemos planteado el problema de investigacion, la hipotesis y los objetivos,haremos enfasis en las diferentes areas que son de interes para desarrollar dichotrabajo. En el capıtulo 2, se describen las principales caracterısticas del TrabajoColaborativo Asistido por Computadora y del Computo Ubicuo. De igual forma,en dicho capıtulo estudiaremos las ontologıas como una herramienta para la ob-tencion de conocimiento a partir de sus relaciones y entidades, ası como de ladistancia manejada entre las clases de las mismas. Posteriormente analizamos al-gunos protocolos de descubrimiento, los cuales han servido como inspiracion paradesarrollar este trabajo. Finalmente en el contexto de investigacion, relacionamosel Trabajo Colaborativo Asistido por Computadora con la Computacion Ubicua ylas ontologıas para dar un panorama al lector del trabajo ya mencionado.

En el capıtulo 3, describimos el estado del arte actual de nuestra propuesta. Serealiza un analisis de las arquitecturas similares a nuestro trabajo, e.g., DAIDA-LOS, AIDAS, UDDI con algoritmo de coincidencia, CASSD y RAMS.

Figura 1.1: Capıtulos de la tesis

Previamente al desarrollo del algoritmo, en el capıtulo 4, analizamos la arquitec-tura RAMS, presentando una breve descripcion de la misma. Una parte importantepara el desarrollo del algoritmo de coincidencia semantico que proponemos son lasontologıas de la arquitectura RAMS, por lo tanto, se realiza un minucioso estudiode estas. Posteriormente, describimos el uso de distancia entre las clases de lasontologıas para obtener un mejor resultado en la busqueda de recursos, ası comolos grados de coincidencia y tipos de preferencias que serviran para realizar labusqueda de recursos.

3

En el capıtulo 5 describimos la implementacion del algoritmo de coincidencia,por lo tanto, presentamos la estructura y bibliotecas del programa. Posteriormente,son explicados el desarrollo de los modulos de la aplicacion del algoritmo de coin-cidencia semantico ası como las interfaces graficas de dichos modulos. Finalmente,en este capıtulo presentamos las pruebas de validacion del algoritmo final.

En el capıtulo 6, detallamos las conclusiones a las que hemos llegado y el trabajofuturo a realizar en este proyecto.

4

Capıtulo

2Marco teorico

A continuacion hacemos enfasis en las diferentes areas de interes para nuestrotrabajo. En la Seccion 2.1, describimos la importancia del area denominada Tra-bajo Colaborativo Asistido por Computadora, sus caracterısticas principales y susaplicaciones en nuestra vida cotidiana. Tambien hablamos del Computo Ubicuo ylas entidades necesarias para construir una aplicacion en esta area (Seccion 2.2).En la seccion 2.3 hacemos enfasis en las ontologıas como una herramienta parala obtencion de conocimiento a partir de sus relaciones y entidades, ası como enla distancia manejada entre las clases de una ontologıa. A traves de esta distan-cia se pueden definir grados de coincidencia a traves de un puntaje caracterıstico.Posteriormente, en la seccion 2.4 mencionaremos las caracterısticas de los proto-colos de descubrimiento de servicios, los cuales han servido como inspiracion paradesarrollar este trabajo. Finalmente la seccion 2.5 corresponde al contexto de in-vestigacion, el cual explica la relacion entre el Trabajo Colaborativo Asistido porComputadora, la Computacion Ubicua y las ontologıas, con el objetivo de proveeral lector un panorama integral de este trabajo.

2.1. Trabajo Colaborativo Asistido por Compu-

tadora

Se ha comprobado que trabajar con otras personas en la realizacion de una ta-rea (trabajo colaborativo), genera mejores resultados que cuando una sola personaquiere desarrollar la misma tarea (trabajo individual) [6]. Este comportamiento sevio reflejado a traves de las observaciones que realizaron sociologos en diferentesambitos, e.g., escuelas, dependencias gubernamentales, centros de investigacion,etc. Algunos ejemplos de tareas que han generado mejores resultados en un en-torno colaborativo son: la redaccion de documentos, la realizacion de prototipos,el desarrollo de experimentos, la toma de decisiones. Los ejemplos antes mencio-nados son una parte de las tareas cotidianas realizadas en equipo por la mayorıade nosotros. Por lo tanto, es importante desarrollar tecnicas que logren dotar a losgrupos de los elementos necesarios, para que puedan elaborar de la mejor formaposible las tareas que les sean asignadas.

El trabajo colaborativo posee una serie de caracterısticas que lo diferencian deotras modalidades de trabajo en grupo [7]:

su base recae en una fuerte relacion de interdependencia de los diferentes

5

miembros que conforman el equipo de trabajo;

delega una clara responsabilidad individual de cada miembro del grupo parael alcance de la meta final;

reconoce que la responsabilidad de cada miembro del grupo es compartida,i.e., todos los miembros tienen parte de responsabilidad para la ejecucion deacciones del grupo;

permite formar grupos heterogeneos de acuerdo a las habilidades y carac-terısticas de los miembros;

persigue el logro de objetivos a traves de la realizacion (individual y conjunta)de tareas;

exige a todos y cada uno de los participantes habilidades comunicativas,deseo de compartir la ejecucion de tareas, ası como relaciones simetricas yrecıprocas.

Un requerimiento importante del grupo es que disponga de los recursos necesa-rios para alcanzar su meta. Por esta razon es importante contar con un mecanismoque permita a los integrantes del equipo localizar de forma rapida y apropiada losrecursos que mejor les convengan.

Por otro lado, cabe recalcar que conforme va avanzando la tecnologıa, esta seva haciendo cada vez mas necesaria, principalmente el uso de computadoras. Esteinstrumento tecnologico nos permite realizar casi cualquier tarea, incluyendo lasque se mencionaron anteriormente. Por tal motivo es importante compenetrar eltrabajo colaborativo con el constante crecimiento de la tecnologıa computacionalpara poder sacar mayor provecho de ambas partes. El area que se encarga de di-cho acoplamiento se denomina Trabajo Colaborativo Asistido por Computadora oCSCW por sus siglas en ingles (Computer Supported Cooperative Work). CSCW fuedefinido por Greif [8] como: “una actividad coordinada, asistida por computadora,tal que la comunicacion y resolucion de problemas se lleva a cabo por un grupode individuos que colabora”, i.e., pretende maximizar los resultados y minimizarla perdida de tiempo e informacion en beneficio de los objetivos organizacionales.

En esta area, se han disenado diferentes tipos de arquitecturas que facilitanla comunicacion entre los miembros de un grupo, eliminan las barreras de tiempoy distancia entre los colaboradores, e incluso descubren los recursos disponiblespara dicho grupo de trabajo (c.f. Capıtulo 3). Para lograr dichos objetivos, estasarquitecturas hacen uso de areas como:

Sistemas distribuidos: puesto que el software de CSCW (denominado co-mo sistemas colaborativos) es inherentemente distribuido, una gran variedad

6

de tecnicas y mecanismos desarrollados en la comunidad de sistemas dis-tribuidos pueden ser exitosamente adoptados en CSCW. Los componentesde un sistema distribuido son usados para proveer un conjunto de serviciosbasicos, de manera que algunos sistemas colaborativos son construidos en lacima. En estos casos, el sistema colaborativo es visto por la infraestructurade un sistema distribuido como una aplicacion.

Bases de datos: algunas caracterısticas de los sistemas colaborativos hacenque las bases de datos sean un atractivo candidato para su infraestructura.Los sistemas colaborativos realizan conjuntos de transacciones a traves deun almacenamiento de datos explıcito (o espacio colaborativo).

Interfaz de usuario: los sistemas colaborativos son interactivos siempre y,por lo tanto, el diseno de la interfaz de usuario es crıtica para su aceptaciony uso.

Comunicacion: la mayorıa de los sistemas colaborativos dependen de lasinfraestructuras de comunicacion digital. Los productos mas exitosos delCSCW son aquellos que permiten a los usuarios comunicarse facilmente.

Coordinacion: ayuda a la comunicacion en el intercambio de un dato oconjunto de datos de un punto a otro. La coordinacion es una caracterısticacrıtica del Trabajo Colaborativo Asistido por Computadora, la cual se lograa traves de acciones distribuidas para lograr la organizacion de los datos.

El detonador principal para usar sistemas colaborativos en una organizacion esla distribucion que permiten las computadoras en un area geografica. Una organi-zacion generalmente tiene un edificio para oficinas centrales y mas edificios paradistribuir otras areas de trabajo; es posible que estos edificios se encuentren en unamisma area geografica o distribuidos en todo el mundo. A pesar de esta distanciafısica, el uso de sistemas colaborativos puede facilitar la interaccion entre todos lostrabajadores de dicha organizacion.

Dentro de CSCW encontramos el area conocida como Groupware, la cual segunEllis [9] se refiere: “al uso de herramientas computacionales para mejorar y facilitarel desempeno del trabajo colaborativo, potencialmente distribuido en el espacio y/oen el tiempo”. Por lo tanto, esta area se dedica al desarrollo de software y hardwarepara entornos colaborativos. Existen cuatro tipos de topologıas de Groupware (verFigura 2.1): interacciones cara a cara, interacciones sıncronas remotas, interaccio-nes asıncronas remotas e interacciones asıncronas.

7

Figura 2.1: Tipos de topologıas en el area Groupware

2.2. Computo Ubicuo

Mark Weiser [10] describio una vision de la computacion del siglo XXI, la cual dis-cutıa la ubicuidad de las computadoras personales. Segun Weiser, “las tecnologıasmas profundas son aquellas que desaparecen... se tejen a sı mismas en las telas dela vida cotidiana hasta que se vuelven indistinguibles”.

Idealmente, el Computo Ubicuo incluye la colaboracion entre dispositivos, demanera que la percepcion del entorno sea mas completa, permitiendo el voto, laponderacion, el resumen, etc., de diversas variables del entorno, tales como la luz,el sonido o la ubicacion. Esta tendencia se esta manifestando en mayor medidapor la convergencia entre la electronica avanzada (principalmente la tecnologıainalambrica) e Internet. Los elementos del Computo Ubicuo son muy delgados(casi invisibles), moviles y se pueden embeber en casi cualquier objeto imaginable,incluyendo computadoras personales, carros, herramientas, electrodomesticos, ropay varios artıculos de consumo, todos intercomunicados a traves de redes. El objetivode los investigadores del Computo Ubicuo es crear sistemas que sean Ubicuos ymimetizados en el entorno, completamente conectados, con intuicion, configurablessin esfuerzo y siempre disponibles.

Por otro lado, como mencionan Siddarth [11] y Najar [12], la habilidad delas aplicaciones (especialmente las ubicuas) en hacer uso de las condiciones delentorno del usuario (temporales, espaciales, fısicas y ambientales), ası como ladisponibilidad de los servicios en los que esta interesado el usuario son mejoradaspor el conocimiento del contexto. Chen define al contexto como un conjunto deestados y configuraciones del ambiente, que determinan el comportamiento de unaaplicacion o una situacion en la cual ocurre un evento de interes para el usuario[13]. Un paradigma de computacion donde las aplicaciones descubren y explotan

8

la informacion contextual es conocida como Computacion Basada en el Contexto oComputacion Consciente del Contexto. Es necesario resaltar que la relevancia delcontexto varıa de acuerdo al dominio sobre el cual se esta trabajando, por lo tantoes necesario formalizar dicho contexto y limitarlo al dominio sobre el que se vayautilizar. Una vez definido el dominio, los sistemas basados en contexto permitenpersonalizar automaticamente el entorno del usuario (en este caso la arquitectura)y, por lo tanto, minimizar la interaccion entre el sistema y el usuario.

Los principales retos del Computo Ubicuo son:

reconocimiento del contexto (identidad, localizacion, estado de animo, etc.);

definicion de arquitecturas de software y herramientas de desarrollo de apli-caciones;

integracion de dispositivos heterogeneos;

desarrollo de interfaces naturales;

evaluacion de ambientes ubicuos;

integracion de medios fısicos y digitales;

consideracion de aspectos sociales, e.g., privacidad, seguridad y costo.

2.3. Ontologıas

La definicion de ontologıa (vease A) mas citada es la de Gruber [14], quien diceque “es la conceptualizacion de una abstraccion, un punto de vista simplificado delmundo que deseamos representar para algun proposito. Cada base de conocimien-to, sistema basado en conocimiento, o agente de nivel de conocimiento esta basadoen alguna conceptualizacion explıcita o implıcita. Una ontologıa es una especifi-cacion explıcita de una conceptualizacion. El termino es seguido de una filosofıa,donde una ontologıa es un sistema basado en la existencia. Para los sistemas deInteligencia Artificial, lo existente es lo que debe de ser representado”.

Las ontologıas suelen ser tan grandes que los usuarios, en el mismo dominiopero con diferentes intereses, no puede identificar los conceptos relevantes a susnecesidades. De hecho, existen ontologıas que son libres de contexto con respectoa su representacion y definicion. El contexto aparece como meta-informacion envarias disciplinas para caracterizar la situacion especıfica de una entidad, paradescribir un grupo de entidades conceptuales o como un fragmento de conocimientopara manejar la informacion; el contexto tambien funge como una construccionlogica para facilitar el razonamiento de servicios.

9

Las ontologıas de dominio son desarrolladas capturando un conjunto de con-ceptos y sus vınculos de acuerdo al contexto. Un contexto puede ser visto desdediferentes perspectivas, e.g., de acuerdo al nivel de abstraccion, a la escala de granu-laridad, al interes en las comunidades del usuario y a la percepcion del desarrolladorde la ontologıa [15].

En general, una ontologıa describe formalmente un dominio de discurso. Tıpi-camente, una ontologıa consiste de una lista finita de terminos y de relaciones entreestos. Los terminos denotan conceptos importantes (clases de objetos) del dominio.Las relaciones comunmente incluyen jerarquıas de clases. Una jerarquıa identificaque una clase C es subclase de otra clase C’ si cada objeto en C es tambien incluidoen C’. Si tomamos como ejemplo una escuela, ademas de representar subclases (e.g.maestro, alumno, curso, departamento, etc.) podemos incluir informacion como:

propiedades (X ensena Y).

restricciones de valor (solo los miembros de la facultad pueden dar cursos).

declaraciones de no union (los miembros de la facultad y personas en generalno son los mismos).

especificacion de relaciones logicas entre objetos (cada departamento de-bera incluir al menos diez miembros de la facultad).

Todas las clases de una ontologıa empiezan a partir de la superclase Thing.En la Figura 2.2, encontramos un ejemplo grafico de una ontologıa, unicamentemencionando sus clases, debido a que las propiedades, restricciones y el resto de loscomponentes de la ontologıa son declarados a traves del lenguaje OWL (OntologyWeb Language [16]). OWL cuenta con RDF (Resource Description Framework [17])y RDF Schema (RDFS [18]) que permiten representar y describir los conceptos deun dominio mediante relaciones taxonomicas y jerarquicas de dichos conceptos.OWL es uno de los lenguajes con mayor capacidad expresiva para representarontologıas.

La ingenierıa del conocimiento y, en particular, el procesamiento de ontologıasson uno de los temas en los que mas se esta centrando la atencion en la informaticaactual. La razon principal es la emergencia de un nuevo conjunto de aplicacionesen las que las ontologıas juegan un papel fundamental. La mayorıa de estas aplica-ciones se encuentran en dos campos: la ultima generacion de sistemas para la Web(Web 2.0 [19], Web Semantica [20]) y la necesidad de integracion de aplicacionesempresariales cada vez mas distribuidas.

En el contexto de la Web semantica las ontologıas proveen un entendimientocompartido de un dominio, el cual es necesario para vencer las diferencias en laterminologıa. Esto se logra mediante anotaciones semanticas [21] y [22], las cualesofrecen descripciones semanticas explıcitas de los servicios Web. Estas anotaciones

10

Figura 2.2: Ejemplo de ontologıa

semanticas mejoran las busquedas Web, permitiendo el acceso a los recursos Weba traves de sus descripciones semanticas. De esta forma, las ontologıas aseguranla recuperacion de servicios Web bajo las inferencias realizadas sobre el dominiode conocimiento. Las ontologıas se encuentran declaradas bajo el formato de datosRDF a traves del lenguaje OWL, que se ha vuelto el lenguaje estandar para elintercambio de informacion en la Web.

Las ontologias nos permiten tomar en cuenta conocimiento implıcito en las ano-taciones durante el proceso de consulta. Este conocimiento se encuentra a traves deenlaces de subsuncion entre los tipos de conceptos (clases) y los tipos de relaciones:relaciones distintivas, axiomas o reglas de deduccion, etc. Por lo tanto, el conoci-miento implıcito permite inferencias que mejoran la eficiencia de los algoritmos decoincidencia.

Ademas de su uso en la Web semantica, el uso de ontologıas se extiende aotras areas por su manejo de similitud semantica, agregando un mejor resultadoque la coincidencia sintactica de palabras clave. Las ontologıas permiten el usode Grados de Coincidencia [23], para poder establecer un estandar en la similitudsemantica. Estos grados se determinan por la distancia mınima entre las clasesen el arbol taxonomico de la ontologıa. En el trabajo de Paolucci [23], se definencuatro grados de coincidencia, basados en dos entidades, el recurso solicitado y elrecurso anunciado:

Exact: en dicho caso el recurso solicitado es equivalente al recurso anunciado.

Plug-in: cuando el recurso anunciado es un conjunto que incluye al recursosolicitado.

Subsumes: contrario al caso de Plug in, el recurso solicitado incluye en su

11

definicion al recurso anunciado, i.e., el proveedor no satisface completamentela solicitud.

Fail: cuando no se encuentra ningun caso de los mencionados anteriormente.

Como menciona Fu [24], podemos afirmar que la similitud semantica se puederepresentar en terminos cuantitativos, asignando un grado de coincidencia entre lasolicitud de un servicio y un servicio ofertado.

2.4. Protocolos de descubrimiento

Los protocolos de descubrimiento son aplicaciones que permiten a los usuariosbuscar servicios o recursos. Dichos protocolos promueven el uso de servicios Webdentro de una organizacion. Como los servicios son de naturaleza dinamica, losprotocolos deben adaptarse en tiempo de ejecucion.

De acuerdo a Zhu [25] los aspectos de diseno de los protocolos de descubrimientoson:

Identificacion del servicio y de los atributos: es la forma en que el clienteespecifica el servicio que quiere usar.

Metodo de comunicacion inicial: son los patrones de comunicacion utiliza-dos entre clientes y servicios en el registro y descubrimiento, e.g., unicast,multicast o broadcast.

Metodo de registro y descubrimiento: se basan en registro o interrogacion.

Infraestructura del servicio de descubrimiento: si no existe una infraestruc-tura especıfica, los clientes y los servicios se comunican directamente duranteel descubrimiento (adecuado para entornos restringidos). El sistema puedeincluir un servicio de directorio donde los servicios se registran y sobre el queclientes ejecutan el proceso de descubrimiento.

Validez de la informacion sobre el servicio: es la forma en que se corrobora lainformacion sobre el estado del servicio. Puede dejarse a iniciativa del cliente(hard state) o proporcionar mecanismos de validacion (soft state).

Ambito del descubrimiento: la mayorıa de los protocolos restringen el ambitoa parametros muy ligados a la red subyacente.

Seleccion del servicio: el descubrimiento puede dar lugar a una lista de servi-cios que cumplen la especificacion de los atributos de busqueda. Se requiereseleccionar uno de los servicios de la lista. Normalmente, la seleccion se dejaen manos del cliente, aunque el servicio de descubrimiento podrıa hacer unaseleccion automatica.

12

Metodo de invocacion del servicio, el cual consta de tres posibles niveles:

• Ubicacion del servicio (URL, direccion IP...).

• Mecanismo de comunicacion.

• Operaciones de la aplicacion.

En caso de que el usuario no especifique los niveles anteriores, la aplicaciones responsable de definirlos.

Control del uso del servicio: se proporciona un mecanismo de leasing (detenerla tarea que se encuentra actualmente en ejecucion) o bien el cliente puedeliberar explıcitamente el servicio.

Comunicacion del estado del servicio: en caso de que el protocolo proporcioneeste mecanismo, el cliente puede conocer los cambios en el estado del serviciopor encuesta o bien por notificacion del servidor mediante eventos.

Mecanismos de seguridad: que pueden estar integrados al protocolo o imple-mentados mediante extensiones, i.e., necesitan de otra aplicacion para agregarseguridad.

2.5. Contexto de investigacion

Debido a la inmensa cantidad de servicios en la red y su similitud, los usuariosde servicios Web se vieron en la necesidad de crear un metodo para minimizarel tiempo de busqueda y mejorar los resultados obtenidos. Este metodo fue lla-mado algoritmo de coincidencia. Existen tres tipos de algoritmos de coincidencia:sintacticos, semanticos e hıbridos [26]. Los algoritmos de coincidencia sintacticosunicamente encontraban los servicios Web a traves de palabras clave iguales alas que el usuario buscaba; en este tipo de algoritmo se clasifican los principalesprotocolos de descubrimiento (e.g., SLP y UDDI). Los algoritmos de coinciden-cia semanticos basan su busqueda en la similitud del concepto de dos serviciosWeb (e.g., UDDI con algoritmo de coincidencia). Finalmente, los algoritmos decoincidencia hıbridos unen la busqueda sintactica con la busqueda semantica paraencontrar los mejores resultados de servicios Web para el usuario. Cabe resaltar quelos protocolos de descbrimiento, o al menos los primeros fueron creados unicamentepara su interaccion con otra aplicacion, por lo tanto no permitıan la interaccioncon personas.

Existen diferentes formas de representar la semantica, una de ellas es a travesde las Ontologıas. Las ontologıas permiten el uso de semantica al representar enti-dades a traves de clases, por lo tanto, se forma una estructura jerarquica que per-mite obtener similitudes entre dichas entidades. Agregar la capacidad de busqueda

13

semantica a una aplicacion (e.g., un algoritmo de coincidencia), permitira identifi-car un servicio no solo por su nombre, sino por su significado, haciendo posible lalocalizacion de servicios similares a los que busca el usuario pero usando conside-rando su significado.

Las areas de Computo Ubicuo y Ontologıas proveen una caracterıstica en comuna las aplicaciones; dicha caracterıstica es el contexto. Como se menciono con ante-rioridad, el contexto es la representacion abstracta de una entidad. En el ambitodel Computo Ubicuo, el contexto permite a las aplicaciones proveer al usuario deposibles soluciones, evitandole que tenga que estar actualizando su estado constan-temente con el objetivo de minimizar la interaccion del usuario con la aplicacion.El contexto es respresentado de diversas formas, una de ellas es a traves de onto-logıas, las cuales permiten mediante su estructura disenar el contexto especıfico deuna entidad, para apoyar diferentes tipos de aplicaciones y mejorar su desempeno.Si al algoritmo de coincidencia semantico se le agrega el uso de contexto, es posiblemejorar dicho algoritmo para trabajar bajo un contexto en especıfico y mejorar lainteraccion entre el algoritmo y el usuario (ver Figura 2.3).

Figura 2.3: Union entre las areas y herramientas

La propuesta de trabajo es la localizacion de recursos dentro de una organiza-cion, por lo tanto el contexto que se maneja es colaborativo. Debido a esto, nuestrotrabajo esta inscrito en el ambito del Trabajo Cooperativo Asistido por Compu-tadora (TCAC), porque una parte importante de esta area es la busqueda eficientede los recursos que necesita un equipo de trabajo para alcanzar su objetivo. Esimportante recalcar que, en una organizacion, existen diferentes tipos de recursosy en grandes cantidades. Todos estos recursos son de naturaleza dinamica porquepueden estar o no disponibles, o pueden estar o no cercanos al radio de un usuario.

Por lo tanto, para localizar los recursos en una organizacion, es importante quesus empleados cuenten con una aplicacion que permita buscarlos de forma eficien-te. Dichos recursos deben cumplir con las caracterısticas tecnicas y restriccionesque solicita el usuario, e.g., la localizacion fısica del recurso, si hay una persona

14

cerca de dicho recurso para poder tener acceso a el, etc. Una aplicacion de estetipo debe contar con un algoritmo de coincidencia semantico, regido por las res-tricciones de uso existentes entre las personas involucradas en la organizacion; estopermitira usar el contexto colaborativo necesario y asemejar dicho algoritmo a lavida real. De esta forma, el algoritmo encontrara el mejor recurso para el usuario.

Si se usa el diseno de un algoritmo de coincidencia semantico para la locali-zacion de servicios Web para encontrar recursos dentro de una organizacion, seobtendran las ventajas que dichos algoritmos proveen, mejorando de esta formalos resultados. Ademas, al anadir a este algoritmo el uso del contexto colaborativo,sera posible asegurar que las restricciones que generalmente se dan en la vida real,sean representadas y consideradas por el sistema (ver Figura 2.4).

Figura 2.4: Algoritmo de coincidencia semantico basado en contexto colaborativo

15

16

Capıtulo

3Estado del Arte

En este capıtulo se describe el estado del arte de este trabajo. En la seccion 3.1 serealiza un analisis de las arquitecturas similares a nuestra propuesta (i.e., DAIDA-LOS, AIDAS, UDDI con algoritmo de coincidencia y CASSD). Posteriormente enla seccion 3.2 se hace un estudio comparativo de las arquitecturas descritas en laseccion 3.1.

3.1. Trabajos Relacionados

A continuacion, se describen algunos trabajos relacionados que incluyen un algo-ritmo de coincidencia semantico. Estos trabajos nos sirvieron como referencia parasituar nuestra propuesta en el estado del arte. Es importante resaltar que dichostrabajos han sido desarrollados para la busqueda de servicios Web. Sin embargo,la busqueda de recursos en una organizacion afronta dificultades similares a las dela busqueda de servicios Web, ya que los recursos no se encuentran centralizados.De hecho, los recursos pueden estar ubicados en diferentes edificios dentro de unamisma organizacion, al igual que un servicio Web se puede encontrar en un servidorremoto. Ademas, la cantidad de recursos fısicos, virtuales y humanos es grande enuna organizacion, por lo tanto se requiere de un algoritmo de coincidencia eficientepara buscarlos.

3.1.1. DAIDALOS

Es una arquitectura consciente de contexto para el descubrimiento semantico deservicios. Se basa en las siguientes entidades [2]:

el Usuario es quien inicia el descubrimiento de servicios y recibe la lista delos servicios encontrados;

el Servicio representa el ente que el usuario final esta buscando;

el Ambiente se refiere a la entidad pervasiva en la que el usuario esta invo-lucrado;

el Servidor de Descubrimiento de Servicios almacena la descripcionbasica de cada servicio en un registro y lo filtra con base en la consultabasica;

17

el Proveedor de Servicios se comunica con el Servidor de Descubrimientode Servicios para publicar los servicios de los que es dueno.

El Usuario, Servicio y Ambiente producen informacion que es recolectada porsensores especıficos, los cuales se comunican con el Administrador del Contextomediante Fuentes de Contexto que contienen dichos sensores. El Administrador deContexto almacena la informacion producida por las Fuentes de Contexto.

DAIDALOS es una arquitectura que se basa en el mecanismo de Publicacion-Suscripcion [27]. Esta arquitectura (ver Figura 3.1) provee dos procesos principales:registro y descubrimiento de servicios. En el proceso de registro de un servicio, elProveedor de Servicio:

registra las Fuentes de Contexto del servicio en el Administrador de Contexto;

define los requerimientos del servicio con base en el usuario y el ambiente;

define el servicio basico y la descripcion semantica, la cual es expresadausando un lenguaje semantico (e.g. OWL [16] o WSMO [28]);

almacena en un registro del Servidor de Descubrimiento de Servicios la des-cripcion del servicio, los requerimientos del servicio y el puntero al contextodel servicio.

En el proceso para descubrir un servicio, el usuario:

registra su propia Fuente de Contexto en un Administrador de Contexto;

especifica sus requerimientos en el contexto del servicio y en el contexto delambiente;

especifica la consulta basica para seleccionar el tipo de servicio correcto y lasemantica para seleccionar una lista de servicios que tienen exactamente lascaracterısticas que dicho usuario desea;

envıa al filtro del Servidor de Descubrimiento de Servicios la consulta, susrequerimientos y el puntero de su contexto.

La consulta que realiza el usuario esta formada por dos partes: una consultabasica expresada en un lenguaje de descubrimiento de bajo nivel y una consultasemantica definida mediante un lenguaje de consulta semantico de alto nivel. Unavez que el Servidor de Descubrimiento de Servicios recibe la solicitud del usuario,activa un motor que siempre realiza tres tipos de filtrado:

1. Filtrado basico: toma la consulta basica del usuario y las descripcionesbasicas de los servicios almacenadas en el registro para realizar una evalua-cion entre ellas, usando un protocolo de coincidencia especıfico del motor defiltrado.

18

Figura 3.1: Mecanismo de filtrado de DAIDALOS

2. Filtrado semantico: regresa una lista de servicios con las coincidenciasentre la consulta semantica del usuario y la descripcion semantica de cadaservicio no descartado por el primer filtro.

3. Filtrado por contexto: esta dividido en tres procesos:

se obtienen el contexto del servicio y los requerimientos del usuario paradeterminar si hay coincidencias entre ellos;

posteriormente se evalua la informacion del contexto del perfil del usua-rio para determinar si coincide con su solicitud actual;

finalmente se compara el contexto del ambiente con los requerimientosdel usuario para encontrar coincidencias entre ellos.

La descripcion de los servicios se realiza mediante OWL-S [29], por lo tantono hay problema en almacenar sus caracterısticas en su respectivo perfil, debidoa que estas no cambian. El problema surge cuando se trata de almacenar la in-formacion dinamica del servicio (e.g., la ubicacion del servicio) puesto que cambiaconstantemente, por lo que es manipulada por el Administrador de Contexto.

19

3.1.2. AIDAS

Es un marco de trabajo para usuarios moviles que permite el descubrimientosemantico, centrado en el usuario. AIDAS adopta el uso de lenguajes semanti-cos para modelar las propiedades de las entidades que interactuan con el medioambiente, ademas usa un razonador basado en DL (Logica Descriptiva) para en-contrar coincidencias entre las peticiones de usuarios con las ofertas de servicios. Ladescripcion de propiedades de las entidades involucradas en el proceso de descubri-miento, i.e., los servicios y los clientes, se realiza mediante metadatos semanticosllamados perfiles. AIDAS asocia a cada cliente con su contexto, el cual definecualquier informacion relacionada con el cliente y relevante para el proceso de des-cubrimiento, e.g., idioma hablado para personalizar una caracterıstica tecnica desu dispositivo. Dicho modelo de metadatos se centra en la representacion de lascapacidades y requerimientos del servicio, del usuario y del dispositivo.

Cada servicio es descrito por un perfil estatico y uno dinamico. El perfil dinami-co incluye informacion de las condiciones de operacion del servicio (estado delservicio). El perfil estatico consta de cuatro subpartes:

Identificacion: provee el nombre y la localizacion del servicio.

Capacidades del servicio: representan las unidades logicas funcionales delservicio. Las capacidades del servicios pueden ser de tipo nucleo (describela actividad especıfica del servicio) o funcional (describe como se realiza laactividad).

Requisitos del servicio: representan las condiciones de acceso que un clien-te debe cumplir para poder usar un servicio; los requisitos del servicio seclasifican en obligatorios y flexibles.

Interfaz de servicio: senala la informacion necesaria para la invocacion delservicio actual, tal como una descripcion de entrada/salida o un punto finalde la invocacion.

Los clientes son descritos en terminos de:

Perfiles: estan compuestos por metadatos dinamicos (localizacion y estado).

Preferencias: pueden ser preferencias de valores o de prioridad, las cualesestan compuestas por:

• Identificador: es usada para nombrar y distinguir al usuario.

• Capacidades: representan las habilidades y capacidades del usuario.

• Requisitos: describen las restricciones definidas por el usuario.

20

La arquitectura AIDAS (ver Figura 3.2) provee varios servicios intermediosorganizados en:

Servicios de gestion de descubrimiento: proveen las funcionalidadesnecesarias para apoyar en el descubrimiento y la seleccion de servicios conbase en la informacion del contexto del usuario y en sus preferencias. Eneste conjunto de servicios encontramos el modulo de Perfil del Motor deCoincidencia, el cual es responsable de ejecutar el algoritmo de coincidencia,donde existen dos posibles casos, uno es donde el Modulo de Descubrimientonecesita determinar la lista de servicios visibles para cada usuario y el otrocaso es especıfico cuando el Procesador de Consultas necesita resolver unaconsulta de un usuario.

Gestion de configuracion: proporciona los servicios necesarios para permi-tir que cada dispositivo portatil anuncie las funcionalidades semanticas alo-jadas en dispositivos co-localizados. Este servicio tambien permite descubrirlos servicios de gestion disponibles localmente y elegir si se desea descargaro acceder remotamente a los servicios necesarios con base en las propiedadesde los dispositivos.

Figura 3.2: Arquitectura de AIDAS

El prototipo de AIDAS esta construido sobre un sistema basado en Java, llama-do CARMEN [30], el cual provee servicios dependientes del contexto a dispositivosportables. El algoritmo de coincidencia utiliza un razonador basado en Logica

21

Descriptiva, llamado Pellet [31], y el marco de trabajo Jena [32] para adquirir yadministrar las ontologıas.

El algoritmo de AIDAS toma las capacidades ofertadas y requeridas, y regresaun grado de compatibilidad semantica entre ellas. Cada capacidad es caracterizadapor sus propiedades. Las capacidades ofertadas son individuales, por lo tanto elalgoritmo trabaja sobre una capacidad al momento. El algoritmo de coincidenciareconoce tres tipos de relaciones entre las capacidades requeridas y ofertadas:

Exact: donde la capacidad ofertada es una instancia de la clase de la capaci-dad requerida.

Plug-in: en esta relacion la capacidad ofertada es una instancia de una sub-clase de la capacidad requerida.

Subsumes: relacion donde la capacidad ofertada es una instancia de la super-clase de la capacidad requerida.

La prioridad de preferencias es utilizada para evaluar el grado de relevancia deuna propiedad especıfica cuando se determina el servicio compatible, i.e., determinael orden en el que el algoritmo comparara la compatibilidad de las capacidades [3].

3.1.3. UDDI CON ALGORITMO DE COINCIDENCIA

UDDI por sı solo puede verse como un tipo de directorio telefonico, el cual permiteencontrar el servicio necesario entre miles de servicios disponibles en Internet.Especifica tres tipos de funciones:

Paginas blancas: realiza busquedas por palabras clave.

Paginas amarillas: efectua busquedas por categorıas.

Paginas verdes: lleva a cabo busquedas por tModel [33] (modelo de in-terfaz de servicio que incluye una llave predefinida y ligas al Lenguaje deDescripcion de Servicios Web -WSDL-).

UDDI realiza busquedas sintacticas (basadas en la coincidencia de palabras),por lo tanto se vio la necesidad de enriquecerlo con informacion semantica. Es-ta informacion se encuentra almacenada en un repositorio de servicios Web y, atraves de dicha informacion, los usuarios pueden descubrir las capacidades de cadaservicio [4]. UDDI utiliza el Perfil Semantico de Servicio Web (WSSP) para codi-ficar la informacion semantica mediante el lenguaje WSDL. En particular, WSDLespecifica las interfaces de programacion de los servicios, incluyendo el nombre dela funcion a invocar y los tipos de datos que el servicio espera como entrada ysalida. Los tipos de datos describen el formato de la informacion, dado que hay

22

varias formas de codificarla, sin embargo estos tipos de datos no expresan la in-formacion semantica necesaria de las capacidades de un servicio. Por esta razon,WSSP enriquece a WSDL con informacion semantica basica (mediante ontologıas)para representar las capacidades de los servicios.

El algoritmo de coincidencia de UDDI propone tres casos de coincidencia:

Exact: cuando dos descripciones son totalmente equivalentes.

Plug-in: cuando el servicio que se provee es mas general que el que se requiere.

Relax: es la interpretacion semantica mas debil, la cual indica que existe ungrado de similitud entre el servicio que se provee y la solicitud.

Figura 3.3: Arquitectura de UDDI con algoritmo de coincidencia

Los siguientes cuatro tipos de filtros (ver Figura 3.3) con los que cuenta laversion de UDDI con algoritmo de coincidencia pueden ser seleccionados por losusuarios en cualquier tipo de combinacion, al realizar una busqueda:

1. Filtro de espacio de nombres: determina si el servicio solicitado y algunode los servicios registrados comparten al menos un espacio de nombres, i.e., laURL de una ontologıa. Solo los servicios registrados con al menos un espaciode nombres en comun pasan al siguiente filtro.

23

2. Filtro de texto: identifica los elementos que especifican un servicio, talescomo comentarios y descripciones de texto, mediante una tecnica llamadaTerm frequency inverse document frequency [34]. Esta tecnica ayuda al algo-ritmo a identificar todos los servicios relacionados con el servicio solicitado.

3. Filtro de los parametros de entrada/salida: verifica que las ontologıasde los parametros de entrada y de salida coincidan; este filtro confirma unacoincidencia si:

los tipos y el numero de parametros de entrada y salida son exactos;

cada parametro de salida del servicio solicitado puede subsumir semanti-camente cualquier parametro de salida de un servicio registrado, y elnumero de parametros de salida de los servicios registrados seleccio-nados es mayor que el numero de parametros de salida del serviciosolicitado;

y/o, cada parametro de entrada de un servicio registrado puede subsu-mir semanticamente cualquier parametro de entrada del servicio solici-tado, y el numero de parametros de entrada del servicio solicitado esmayor al numero de parametros de entrada de los servicios registradosseleccionados.

4. Filtro de restriccion: verifica la validez logica de cada restriccion mediantela relacion de subsuncion. Este filtro determina si el servicio registrado esmenos restringido que el servicio solicitado. Una coincidencia ocurre si:

cada restriccion de los parametros de entrada de un servicio registradosubsume cualquier restriccion de los parametros de entrada del serviciosolicitado;

cada restriccion de los parametros de salida de un servicio registradosubsume cualquier restriccion de los parametros de salida del serviciosolicitado.

El algoritmo de coincidencia calcula el grado de similitud como la suma delos puntajes de cada filtro. Cuando un usuario registra un servicio, el algoritmorecibe del cliente un archivo WSDL y automaticamente completa algunos de loscampos de este archivo. Posteriormente, el usuario selecciona la ontologıa paralas entradas y salidas del servicio mediante un visualizador de ontologıas, el cualprovee un editor de reglas que le permite escribir hechos y reglas como si estuvieraescribiendo oraciones en lenguaje natural.

24

3.1.4. CASSD

Esta arquitectura combina las caracterısticas de los protocolos tradicionales de des-cubrimiento de servicios, descubrimiento semantico de servicios, situaciones cons-cientes de contexto y descubrimiento contextual de servicios. Dicha arquitecturase basa en los siguientes actores y modulos:

1. Descubrimiento del Servicio, el cual contiene tres componentes:

Controlador de solicitudes de servicio: convierte la solicitud en unformato que pueda ser usado por el algoritmo de coincidencia.

Algoritmo de coincidencia de servicios: empareja las solicitudesde servicio con los servicios anunciados. Ademas, relaciona las repre-sentaciones de informacion originadas por los proveedores de servicio yun solicitante de servicio para proporcionar un grado de coincidencia.Los requisitos expresados semanticamente son resueltos por un servidorde consulta semantico, en tanto que los requerimientos de contexto sonverificados por el servidor de consulta de contexto.

Controlador de resultados de los descubrimientos: convierte lainformacion de los servicios en un formato entendible para el usuario yposteriormente envia estos resultados al usuario.

2. Servidor semantico: los solicitantes y los proveedores de servicios son acto-res diferentes con conocimiento disjunto, ya que utilizan diferentes terminospara la misma entidad. Este problema de heterogeneidad de terminos es re-suelto a traves de consultas semanticas.

3. Modulo solicitador de servicios: la consulta del servicio es formada usan-do el administrador del servicio solicitado.

4. Solicitador de servicios: registra su perfil en el servidor de registro, esteperfil contiene su informacion estatica (e.g. edad, nombre, direccion, identifi-cador); el solicitante tambien puede especificar sus preferencias en forma dereglas. Cuando el solicitante realiza la consulta de un servicio se cambia a unformato especıfico mediante el Controlador de Solicitudes de Servicio.

5. Proveedor de servicios: es el responsable de publicar servicios. El provee-dor de servicios se inscribe con un Proveedor de Registro, el cual expresa laspreferencias del usuario en forma de reglas.

6. Proveedor de contexto: administra las consultas provenientes del modulode Descrubrimiento del Servicio. El proveedor de contexto adopta un mo-tor de reglas basado en Jess [35]. Este proveedor es responsable de proveercontexto estatico y dinamico al modulo de Descubrimiento del Servicio.

25

El Administrador de Contexto y el Servidor de Registro se basan en la arqui-tectura consciente de contexto de Jess. Dicha arquitectura consta de:

Base de Conocimiento compuesta por tres componentes:

• Base de reglas: formada por reglas con diseno ECA (Event ConditionAction [36]).

• Base de perfil: almacena el perfil del servicio y el del solicitante.

• Base de consultas: esta integrada por diferentes consultas. En casode que los proveedores y solicitantes de servicios tengan requisitos decontexto, dichas consultas se ejecutaran.

Memoria de trabajo: almacena las lecturas (eventos) que generan los sen-sores, por lo tanto se actualiza constantemente. Contiene dos modulos, unopara los solicitadores y otro para los proveedores.

Motor de inferencia: es responsable de ejecutar reglas. El contexto (o lec-turas) que proviene de los sensores crea patrones que corresponden a reglas,las cuales estan relacionadas mediante un algoritmo de coincidencia de patro-nes. Las reglas resultantes son almacenadas en una agenda y posteriormenteejecutadas por este motor.

CASSD se basa en dos algoritmos [5]:

Algoritmo de Deteccion de Eventos: se encarga de detectar los eventos(lecturas) de los sensores, los cuales pueden ser del tipo hardware o software.

Algoritmo de descubrimiento de CASSD: usa la solicitud del servicio ylos servicios disponibles como entradas de datos. Unicamente filtra aquellosservicios que se hayan capturado en el Proveedor de Servicios y que perte-nezcan a la categorıa del servicio solicitado. Finalmente, los resultados sonclasificados de acuerdo al grado de similitud presente entre los parametrosde entrada y salida, y los atributos de servicios solicitados y los publicados.

3.2. Analisis comparativo

A continuacion, se describen las caracterısticas usadas para comparar los trabajosdescritos anteriormente. Se han creado dos tablas comparativas (ver Figuras 3.4 y3.5) basadas en dichas caracterısticas para su mejor comprension.

Los algoritmos de coincidencia operan sobre una base de conocimiento en don-de los servicios son registrados y posteriormente consultados por dicho algoritmo.La descripcion del servicio se refiere a la forma en que los autores describen un

26

Figura 3.4: Analisis de las caracterısticas de los algoritmos de coincidencia de lostrabajos relacionados

servicio, para que posteriormente el algoritmo de coincidencia pueda utilizar estainformacion. Todas las arquitecturas presentadas proveen una descripcion semanti-ca. DAIDALOS propone una plantilla semantica, mientras que UDDI implementael Perfil Semantico de Servicios Web (WSSP) usando el Lenguaje de Descripcionde Servicios Web (WSDL); por su parte CASSD almacena la definicion de cadaservicio en un servidor de registro basado en la arquitectura Jess; finalmente AI-DAS proporciona una descripcion de las condiciones de operacion de los servicios.DAIDALOS y AIDAS son los unicos que basan la descripcion de sus servicios enlas caracterısticas tecnicas de estos.

Cada arquitectura ofrece diferentes filtros disenados para clasificar los resul-tados de la peticion que realiza un usuario. AIDAS es el unico que efectua unfiltrado sencillo, i.e., unicamente usa el perfil del usuario y el de los servicios dis-ponibles para realizar su comparacion. DAIDALOS y CASSD usan tres filtros ensu algoritmo de coincidencia. Sin embargo, DAIDALOS aplica los filtros sobre lasdescripciones basica y semantica de los servicios y sobre su contexto, mientras queCASSD usa los filtros sobre los perfiles de los usuarios y de los servicios; por lotanto, aunque ambas arquitecturas poseen el mismo numero de filtros, los usande diferente forma. Por ultimo, UDDI con algoritmo de coincidencia proporcionacuatro filtros diferentes, los cuales son aplicados a las descripciones de los serviciosregistrados en su base de conocimiento.

La caracterıstica de clasificacion se refiere a la forma en que los filtros delalgoritmo de coincidencia asignan una categorıa o puntaje para jerarquizar losresultados obtenidos. En el caso de AIDAS y UDDI se utiliza la clasificacion de losgrados de coincidencia establecidos por Paolucci [37]: Exact, Plug-in y Subsumes;ademas, UDDI agrega a cada uno de sus filtros un puntaje parcial, para que cuandoel algoritmo termine de las evaluaciones, le asigne a cada recurso un puntaje de

27

similitud con respecto a la solicitud que el usuario realizo; otra arquitectura quese basa en anadir puntaje de acuerdo al filtrado es CASSD. DAIDALOS no realizauna clasificacion especıfica, simplemente muestra las coincidencias existentes. Conbase en lo anterior, podemos decir que la forma de clasificacion de UDDI conalgoritmo de coincidencia es la mas completa de todas las arquitecturas.

Figura 3.5: Analisis de atributos semejantes de los trabajos relacionados

La suscripcion se referiere a la posibilidad de que un usuario registre en laarquitectura su interes en algunos servicios o recursos, con el fin de recibir actuali-zaciones en caso de que un nuevo recurso de su predileccion sea anadido. La opcionde suscripcion es usada en todas las arquitecturas, excepto en la implementacionde UDDI con algoritmo de coincidencia.

Las arquitecturas que usan la distancia semantica pueden obtener la dis-tancia entre las diferentes clases de la ontologıa que implementan para encontrarresultados que podrıan interesarle al usuario aun cuando no sumplan todos susrequermientos. Esta caracterıstica es utilizada unicamente por las arquitecturasAIDAS y UDDI, ya que el algoritmo de coincidencia que proponen se basa enencontrar la distancia entre las clases de la ontologıa para asignar un grado decoincidencia.

La localizacion del servicio se refiere a la ubicacion fısica de cada servicio.Unicamente la arquitectura AIDAS calcula la ubicacion del servicio al momentode ser solicitado.

La caracterıstica localizacion del usuario denota las arquitecturas que utili-zan la ubicacion del usuario para obtener el servicio mas cercano a el. Solo CASSDy AIDAS usan esta caracterıstica. AIDAS provee el estatus de una persona (siesta o no disponible de acuerdo a su estado o ambiente que la rodea), caracterısti-ca relacionada con la localizacion del usuario.

La seguridad se refiere a las restricciones de uso asignadas entre colegas, i.e.,si un colaborador le presta sus recursos a otro. Las restricciones de acceso a los

28

servicios solo son utilizadas por AIDAS; el resto de las arquitecturas no posee estetipo de seguridad.

La composicion es la busqueda de un conjunto de recursos que se encuentranen un mismo sitio y que estan disponibles en un horario especıfico. La composiciones la unica caracterıstica que ninguna de las arquitecturas implementa, i.e., dichasarquitecturas se encargan de buscar un solo recurso, en vez de un conjunto derecursos disponibles para un usuario.

La separacion de registros se refiere a almacenar cada individuo de la on-tologıa en su propio archivo OWL, para que la ontologıa quede unicamente comomodelo, al cual se le cargaran los individuos necesarios para poder ejecutar el algo-ritmo de coincidencia. Ninguna de las arquitecturas mencionadas cuenta con estacaracterıstica.

29

30

Capıtulo

4 Analisis y diseno del algorit-mo de coincidencia semantico

En este capıtulo se describe el analisis que se llevo a cabo del algoritmo de coinci-dencia semantico, ası como su diseno. Particularmente, en la seccion 4.1 se describela arquitectura completa de RAMS. El diseno original del algoritmo de coinciden-cia de la arquitectura RAMS y las modificaciones propuestas son explicadas en laseccion 4.2. Despues, en la seccion 4.3 se examinan las ontologıas disenadas parala arquitectura RAMS y se describen las modificaciones realizadas en ellas. En laseccion 4.4 se explican los estados de disponibilidad que el usuario puede seleccio-nar. Finalmente, en la seccion 4.5 el termino Similitud Semantica es definido,se analizanan los grados de coincidencia mas usados para aplicarlos a nuestro al-goritmo de coincidencia y se define la similitud semantica adecuada entre nuestrasclases de la meta-ontologıa.

4.1. Descripcion de la arquitectura RAMS

La arquitectura RAMS (Resource Availability Management Architecture) disenadapor Garcıa et al. [38] busca administrar el estado de cada colaborador (e.g., presen-cia, localizacion y disponibilidad) y el estado de los recursos de una organizacion(fısicos, virtuales y humanos). RAMS pretende mejorar las funciones del usuariopara permitirle publicar los recursos relevantes que quiere compartir. El usuariocomparte sus recursos con colegas autorizados y limita quienes pueden suscribirsea alguno de sus recursos dependiendo de las restricciones temporales y espacialesque definio al inicio sobre sus recursos.

RAMS no esta definida para un tipo de organizacion en especıfico. Por el con-trario, su diseno fue totalmente pensado para poder servir en organizaciones dediferente ındole y tamano, sin tener que realizar cambios importantes en su estruc-tura principal. Ejemplos de organizaciones donde se planea probar RAMS:

En una agencia de diseno, esta arquitectura ayudarıa sobre todo para lalocalizacion de bibliotecas y componentes reusables (e.g., elementos de Pho-toshop, archivos CSS o scripts de Java), pero tambien podrıa ayudar a laadministracion de los recursos fısicos compartidos.

En hospitales, RAMS facilitarıa la localizacion de un cuarto de juntas, unquirofano disponible, ası como la busqueda de un equipo especıfico y personalcon entrenamiento o conocimiento especıfico.

31

En universidades o centros de investigacion donde los campus generalmenteestan compuestos por una gran cantidad de edificios que almacenan abun-dantes recursos, esta arquitectura permitirıa a un colaborador o visitantereducir el tiempo de busqueda de un recurso en especıfico.

Los modulos que forman la arquitectura RAMS fueron disenados con el objetivode localizar el mejor recurso para un usuario, apoyandose en su localizacion fısica,restricciones de uso y disponibilidad. Dos de los componentes principales de RAMSson un conjunto de ontologıas, que funcionan como base de conocimiento, y unalgoritmo de coincidencia, el cual se encarga de localizar y mostrar al usuario losmejores resultados con base en su solicitud de busqueda.

La arquitectura RAMS fue disenada siguiendo el modelo asıncrono de publica-cion/suscripcion [27]. Este modelo fue elegido para poder intercambiar mensajesentre cada aplicacion principal activa de RAMS y el usuario. Por otro lado, RAMSespecifica dos roles de colaboracion: 1) cuando un usuario toma el rol de pro-ductor puede publicar sus recursos para compartirlos con sus colegas y generareventos que cambian el estado de dichos recursos y 2) si un usuario toma el rolde consumidor podra recibir eventos acerca del estado de los recursos en los queesta interesado, en caso de que estos recursos esten disponibles para el..

Para garantizar la integridad de los recursos, un productor puede especificarquienes pueden usar sus recursos y las restricciones de uso sobre cada uno deellos. De esta forma, el productor puede estar seguro de que sus recursos seranusados por personas en las que confıa y que los trataran correctamente. Esto esparticularmente importante en ambientes colaborativos, donde la disponibilidadde un recurso puede depender de la informacion del consumidor, i.e., del rol queesta ejerciendo en un momento dado, ası como de los derechos de accesos de losque goza dentro de la organizacion.

Los modulos de la arquitectura RAMS (ver Figura 4.1) estan agrupados deacuerdo al tipo de servicios que proveen: Interaccion Humana, Pre-procesamientode Datos y Reconocimiento Humano.

El modulo de Interaccion Humana consiste en un Broker que brinda el soportenecesario para la interaccion entre colaboradores y aplicaciones generadas a partirde esta arquitectura. En este modulo esta el Servicio de Publicacion que envıala informacion de un nuevo recurso al Filtro Basado en Topicos, el cual lo cla-sifica en la ontologıa correcta de acuerdo al tipo de recursos que esta publicando elusuario. Por otro lado, el Pre-procesador de Publicacion estructura la infor-macion recibida del Filtro Basado en Topicos para hacerla comprensible para lasontologıas de RAMS y almacenarla en su Base de Conocimiento.

Cuando un colaborador toma el rol de consumidor puede interactuar conRAMS a traves del Servicio de Suscripcion, el cual le permite describir eltipo de recursos en el que esta interesado. El Pre-procesador de Suscripcionestructura las descripciones de los recursos obtenidas por el Servicio de Suscripcion

32

Figura 4.1: Componentes de la arquitectura RAMS

para hacerlas entendibles por el Servicio de Coincidencia.

Con la informacion relevante proveniente de la Base de Conocimiento, el Servi-cio de Coincidencia selecciona los recursos autorizados, cuyos atributos correspon-den a la descripcion tecnica definida por los colaboradores cuando se suscribieronpara obtener informacion sobre un tipo de recursos. Como resultado de este proce-so de coincidencia, se obtiene un conjunto de recursos que satisface potencialmentela solicitud del usuario. Para verificar la efectiva disponibilidad de un recurso, elServicio de Coincidencia toma en cuenta la informacion dinamica de los recursosalmacenados, la cual se obtiene a traves del Notificador Multimodal y de lasHerramientas de Administracion. El Notificador Multimodal se encarga decomunicar al modulo de Pre-procesamiento de Datos la eleccion del Selector deColaborador, el cual determina la presencia de un recurso humano y su locali-zacion considerando la informacion proveniente del Reconocedor de Voz y delReconocedor Facial. Estos componentes se encargan de determinar la identidady localizacion del usuario. Las Herramientas de Administracion permiten a los pro-ductores modificar en cualquier momento su disponibilidad o la de alguno de susrecursos publicados.

Cuando el consumidor esta buscando un recurso fısico, el conjunto de recursosadecuados y disponibles, seleccionado por el Servicio de Coincidencia, es transmi-tido al Localizador de Recursos Fısicos [39], el cual pregunta al ReconocedorFacial la localizacion actual del consumidor, con el fin de determinar el recurso

33

mas cercano y la ruta que debe seguir para alcanzarlo. El resultado final, ya seadel Localizador de Recursos Fısicos o del Servicio de Coincidencia es enviado alconsumidor.

4.2. Diseno del algoritmo de coincidencia

Inicialmente, el desarrollo del algoritmo de coincidencia se realizo de acuerdo aldiseno original establecido en la arquitectura RAMS [38] (ver Figura 4.2), el cualconsiste en cuatro fases:

Fase Request: recibe la solicitud de un consumidor.

Fase Characteristics Search realiza tres actividades en paralelo:

1. recibe los estados de disponibilidad que el consumidor seleccione (Sec-cion 4.4);

2. recibe las preferencias de contexto (Seccion 4.4.6), la cuales correspon-den a las restricciones de contexto que el usuario determina e inme-diatamente crea reglas de contexto SWRL basadas en la seleccion delconsumidor;

3. y crea una consulta SPARQL para obtener un conjunto de recursos quepotencialmente satisfagan la peticion del consumidor en terminos de lascaracterısticas tecnicas buscadas en un recurso.

Fase State Analysis: de acuerdo a las preferencias de vista (i.e., estados dedisponibilidad) seleccionadas por el consumidor en la fase CharacteristicsSearch, crea simultaneamente una consulta SPARQL y propiedades de objetobasadas en las reglas SWRL creadas en la fase anterior.

Fase Query Execution: la consulta SPARQL es ejecutada para obtener unconjunto de recursos que satisfacen la solicitud del consumidor; y finalmentelos resultados son entregados a dicho consumidor.

Conforme avanzaba el desarrollo del algoritmo de coincidencia, se fueron reali-zando algunos cambios en su diseno original. La version final del trabajo se observaen la Figura 4.3, donde se han mantenido las fases del algoritmo, pero se han mo-dificado algunas actividades declaradas en el diseno original. A continuacion, seencuentra la descripcion del algoritmo modificado:

Fase Request: recibe la solicitud de las caracterısticas tecnicas que el consu-midor desea que un recurso posea, ya sea fısico, virtual o humano.

34

Figura 4.2: Diseno original del algoritmo de coincidencia de RAMS

Fase Characteristics Search: realiza dos actividades simultaneamente; en pri-mer lugar, recibe las preferencia de vista y las preferencias de contexto, demanera similar al diseno original, sin embargo el consumidor primero de-be elegir las vistas de preferencia (estados de disponibilidad) que desea enun recurso y posteriormente puede elegir las preferencias de contexto; si-multaneamente a esta ultima actividad se crea y se ejecuta una consultaSPARQL, la cual es creada a partir de las caracterısticas tecnicas que buscael consumidor. En esta actividad se incluyo en el algoritmo la capacidad derealizar coincidencia semantica (Seccion 4.5) para obtener mas recursos quecumplan con estas caracterısticas.

Fase State Analysis: en esta fase se realizan dos actividades de manera si-multanea: se crea una consulta SPARQL basada en las preferencias de vistay una consulta SQWRL basada en las preferencias contextuales. Ambos es-tados de disponibilidad son seleccionados por el consumidor en la fase Cha-racteristics Search.

Fase Query Execution: finalmente se ejecutan las consultas creadas en la FaseState Analysis para ası obtener un conjunto de recursos satisfactorios, deacuerdo a las preferencias y caracterısticas tecnicas que el consumidor hayaespecificado. Como ultima actividad de esta fase, se entregan los resultadosal consumidor.

35

Figura 4.3: Diseno actual del algoritmo de coincidencia

4.3. Ontologıas de la arquitectura RAMS

Las ontologıas de la arquitectura RAMS [38] fueron disenadas para adaptarse acualquier tipo de organizacion, sin tener que hacer cambios importantes en ellascuando se van a implantar en una organizacion en especıfico. Estas ontologıas alma-cenan y administran tanto informacion estatica (e.g., capacidades y caracterısticastecnicas, restricciones de usuario y derechos de acceso asignados entre colegas)como dinamica (e.g., localizacion actual de las personas) que en conjunto creanla Base de Conocimiento de la arquitectura RAMS. Esta informacion estatica ydinamica proviene de diferentes modulos de esta arquitectura.

Para crear las ontologıas de RAMS se uso el lenguaje OWL-DL [16], el cualconsidera la estructura jerarquica que forman las ontologıas. En este lenguaje, to-das las ontologıas parten de la clase Thing. Las ontologıas originales de RAMS hansido personalizadas para poder ser utilizadas dentro de un centro de investigaciony ası validar nuestra propuesta. A continuacion, se describe cada una de las seisontologıas que forman la Base de Conocimiento de RAMS para el CINVESTAV(Centro de Investigacion y Estudios Avanzados del Instituto Politecnico Nacional).

4.3.1. Ontologıa HumanResource

La ontologıa HumanResource fue disenada para representar a todas las personasque son parte de la organizacion, e.g., trabajadores y visitantes. Esta ontologıaesta constituida por dos clases principales HumanResource y JobPosition (ver Fi-gura 4.4).

36

Figura 4.4: Clases principales de la ontologıa HumanResource

La clase JobPosition se usa principalmente para definir los puestos de traba-jo establecidos en la organizacion. En el caso de un centro de investigacion, seanadieron las siguientes subclases (ver Figura 4.5) para mejorar su definicion: Re-searcherJobPosition, TechnicalManualAdministrativeStaff, Librarian y Researche-rAssistantJobPosition. La subclase ResearcherJobPosition esta formada por lascategorıas en las que puede ser clasificado un investigador dentro del CINVESTAVdonde el rango va desde CinvestavResearcher1A hasta CinvestavResearcher3F. Lasubclase TechnicalManualAdministrativeStaff esta formada por puestos de trabajoque puede tener una persona dentro de este centro de investigacion, desde puestosgenerales (e.g., Janitor, Counter, Messenger) hasta puestos de trabajo especıfi-cos (e.g., SpecialComputerSystemAnalyst, Researcher Assistant). Librarian es unasubclase divida en LibrarianB y LibrarianC. Finalmente, la subclase Researche-rAssistantJobPosition incluye diferentes niveles de asistentes de investigacion, lascuales van desde ResearcherAssistantA a ResearcherAssistantK.

Figura 4.5: Subclases de la clase JobPosition

Por otro lado, la clase HumanResource se divide en dos subclases: Visitor ySupportStaff. La primera es usada para identificar a los visitantes que llegan a la

37

organizacion, mientras que la segunda subclase se refiere al personal que se en-cuentra en todo tipo de organizacion. De la clase Visitor se derivan las subclasesLongTermVisitor y ShortTermVisitor para referirse a los visitantes y a su tiempode estancia en la organizacion, i.e., si va a ser por un periodo corto o largo. Porotro lado, la clase SupportStaff se divide en Administrator, SecurityPersonnel yCleaningPersonnel. En el caso de un centro de investigacion, en la clase Human-Resource tambien se especifican las clases Student y Researcher (ver Figura 4.6).La clase Student se divide a su vez en MasterStudent y PhDStudent para clasi-ficar a los estudiantes de acuerdo al programa en el que estan inscritos; la claseMasterStudent contiene las subclases FirstYearStudent y SecondYearStudent.

Figura 4.6: Subclases agregadas a la clase HumanResource para el caso de un centrode investigacion

4.3.2. Ontologıa PhysicalResource

La ontologıa PhysicalResource se encarga de asignar una categorıa a los distintostipos de recursos fısicos que existen en la organizacion. Su clase principal es Physi-calResource (que se extiende de la clase Thing). De la clase PhysicalResource (verFigura 4.7) se extienden las subclases : Building y PhysicalResource. La clase Buil-

38

ding ayuda a delimitar los espacios fısicos que pueden usar los colaboradores, e.g.,un salon, una sala de juntas, un edificio en especıfico, banos, ademas de agregarlos espacios fısicos necesarios para identificar a la organizacion (e.g., oficinas delos investigadores); y en la clase PhysicalResource son descritos los recursos fısicosque un colaborador puede usar.

Figura 4.7: Clases principales de la ontologıa PhysicalResource

Para el caso especıfico del CINVESTAV (ver Figura 4.8) dentro de la claseBuilding se encuentran las subclases: CellBiologyDepartment, PhysicsDepartment,ComputerScienceDepartment y MathematicsDepartment. En nuestro caso nos in-teresa mas el Departamento de Computacion porque es el departamento en el queactualmente se esta probando la arquitectura RAMS. Dentro de la clase Compu-terScienceDepartment podemos encontrar las subclases Laboratory, StudentArea,Restroom y ResearchersOffice.

Figura 4.8: Subclases de la clase Buildingadaptadas a un centro de investigacion

Dentro de la clase Hardware se encuentran las subclases (ver Figura 4.9): Plot-ter, OpticalDrive, ElectronicalSignaturePad, MultimediaHardware, Handheld, Scan-

39

ner, Multifunctional, ExternalStorage, Projector, Camera, Computer, Display yPrinter.

Figura 4.9: Subclases originales de la clase Hardware

La subclase Handheld contiene las subclases Tablet, Smartphone y PDA. Laclase Computer agrupa las subclases Laptop, Desktop y Server (ver Figura 4.10).La clase Hardware fue personalizada para el CINVESTAV, aumentandole las si-guientes subclases: NetworkDevice y Robot. Por su parte, la clase NetworkDevice

40

subsume a las clases Switch, Router, Hub y WiFiBase. De igual forma, a la claseComputer se agrego la subclase Cluster.

Figura 4.10: Subclases originales de la clase Hardware

En dicha ontologıa, realizamos cambios en la estructura de clases, con el finde poder colocar algunos recursos que no eran subclases de la misma clase peroaun ası compartıan caracterısticas tecnicas o funcionalidad similar, como lo hacendiferentes trabajos con los servicios Web. Al agrupar recursos semejantes, podemosusar la similitud semantica entre clases y mostrar al usuario mas opciones derecursos. Por lo tanto, la clase Hardware tiene ahora la siguiente taxonomıa (verFigura 4.11):

De la clase Computer, se derivan las subclases Cluster, Desktop, Laptop yServer, y se agregaron a esta categorıa las clases Display, OpticalDrive y Ex-ternalStorage, las cuales no representan a una computadora, pero compartenalgunas caracterısticas relacionadas con este tipo de recurso (e.g., capacidadde almacenamiento, tamano de la pantalla).

En la clase Handheld, ademas de encontrar a las clases PDA, Smartphone yTablet, se agrego la clase Camera.

Se agrego una nueva clase, llamada InputDevices, que agrupa las clases Key-board, Mouse y Stylus.

41

La clase Multifunctional ahora subsume a las clases Printer y Scanner. Laclase Printer incluye a su vez la subclase Plotter

Tambien se creo la clase MultimediaHardware para poder agrupar a las clasesMicrophone y Speaker.

De la clase NetworkDevices, se extienden las subclases Hub, Router, Switchy WiFiBase.

Se conservaron las clases Robot, Projector y ElectronicSignaturePad.

Figura 4.11: Subclases modificadas de la clase Hardware

42

4.3.3. Ontologıa VirtualResource

Esta ontologıa se diseno para clasificar a los recursos virtuales que podemos en-contrar dentro de una organizacion, e.g., archivos y software. De la clase principalThing se deriva la clase VirtualResource y a su vez en esta clase se encuentran lassubclases File, DriverPlugins, Databases y Software, como se muestra en la Figura4.12.

Figura 4.12: Clases principales de la ontologıa VirtualResource

De la clase File (ver Figura 4.13) se derivan las clases Document, Forms, Ma-nuals y Multimedia. Por su parte, en la clase Software (ver Figura 4.14) se encuen-tran las subclases: Tools, OperatingSystems, ProgrammingTools, OfficeApplications,Antivirus y MediaPlayer. De las clases mencionadas anteriormente, la clase Toolssubsume a su vez a las clases Burners, ArchiveCompressor, Browsers y Media y laclase OfficeApplications se divide en las subclases WordProcessor, Presentation ySpreadSheet.

4.3.4. Ontologıa Context

Esta ontologıa permite definir las variables necesarias para determinar las relacio-nes entre los colaboradores y las restricciones sobre cada recurso. En esta ontologıase representa el contexto que, como menciona Dey [40], es el encargado de caracteri-zar la situacion de una entidad, la cual es considerada relevante para la interaccionentre un usuario y una aplicacion. Esta ontologıa fue disenada basandose en elcontexto fısico propuesto por Najar et al. [12], pero tambien se agrego el contextocolaborativo. Con base en lo anterior, la ontologıa Context cuenta con la siguiente

43

Figura 4.13: Subclases de la clase File

Figura 4.14: Subclases de la clase Tools

44

taxonomıa. De la clase principal Thing se derivan las clases OrganizationalCon-text y PhysicalContext (ver Figura 4.15). De la clase OrganizationalContext sederivan las subclases Process, Activity, Group, Role y Calendar (ver Figura 4.16).Finalmente, de la clase PhysicalContext se derivan las subclases Restriction, Task,AvailabilityMode, Company y UsageStatus (ver Figura 4.17).

Figura 4.15: Clases de la ontologıa Context

Figura 4.16: Subclases de la clase OrganizationalContext

4.3.5. Ontologıa InstitutionInformation

La ontologıa InstitutionInformation fue creada para ser personalizada en cadaorganizacion en la que la arquitectura RAMS sea utilizada, en esta ontologıa se

45

Figura 4.17: Subclases de la clase PhysicalContext

especifican los departamentos que forman dicha organizacion. Estos departamentosse deben crear como subclases de la clase Department, como se observa en la Figura4.18.

Figura 4.18: Clase principal de la ontologıa InstitutionInformation

Para el caso del centro de investigacion, CINVESTAV, se agregaron las sub-clases ExactScience, BiologicalAndHealthScience, SocialAndHumanScience y Tech-nologicEngineeringScience a la clase Department. Ademas, se agrego otra claseprincipal, llamada ResearcherArea que contiene la clase ComputerScienceRA, lacual a su vez subsume a las clases SystemProgramming, TheoreticalFoundationOf-ComputerScience, ArtificialIntelligence, DigitalSystemsAndComputerArchitecture,ChartingVisualizationAndMultimediaSystems y DatabasesSoftwareEngineeringAn-dInformationSystems que representan las principales areas de investigacion delDepartamento de Computacion (ver Figura 4.19).

46

Figura 4.19: Subclases de la clase Department

4.3.6. Ontologıa MetaOntology

La funcion de esta ontologıa es agrupar las cinco ontologıas anteriores para poderdefinir propiedades de objeto entre ellas. En el caso de la Meta Ontology (ver Figura4.20) personalizada para el CINVESTAV, al agregar las ontologıas disenadas, elprimer nivel de la jeraquıa de clases se compone por: Department, JobPosition,Context, ResearchArea, HumanResource, PhysicalResource y VirtualResource.

4.4. Estados de disponibilidad

Cuando un consumidor realice una busqueda de recursos, podra seleccionar entrepreferencias que representan distintos grados de disponibilidad, los cuales debensatisfacer las reglas establecidas por Garcıa [38]. De esta forma, el usuario solorecibira informacion sobre aquellos recursos que realmente interesan. El caso basede dichas preferencias es Allowed, a partir del cual son disenados los estados: Free,Satisfy Restrictions, Reachable, Available Provider y Satisfy Context Restrictions.

4.4.1. Estado Allowed

Como su nombre lo indica, Allowed es el estado que permite definir si un recursopuede ser utilizado por el consumidor, por lo tanto este es el estado base. Lassiguientes preferencias propuestas o estados son accesibles una vez que el recurso

47

Figura 4.20: Clases que forman MetaOntology

alcanza este estado. Un recurso de cualquier tipo (i.e., fısico, virtual o humano) seencuentra en este estado, si el consumidor tiene permiso de realizar la tarea quebusca y si el recurso a evaluar puede realizar dicha tarea. Este estado se encuentradeclarado a traves de las funciones:

canPerform es una funcion parcial del conjunto de individuos provenien-tes de la clase HumanResource sobre el conjunto de individuos de la claseTask, i.e., el resultado de la funcion canPerform contiene las tareas que unconsumidor puede llevar a cabo.

isPerformedOn es una funcion parcial del conjunto de individuos prove-nientes de la clase Task sobre el conjunto de individuos de las clases Human-Resource, VirtualResource y PhysicalResource, i.e., el resultado de la funcionisPerformedOn contiene los recursos sobre los cuales una tarea puede serrealizada.

isAllowedFor es una funcion parcial del conjunto de individuos de lasclases HumanResource, VirtualResource y PhysicalResource sobre el conjun-to de individuos de la clase HumanResource, i.e., el resultado de la funcionisAllowedFor contiene los consumidores a los que se les permite interac-tuar con un recurso en especıfico.

48

4.4.2. Estado Free

Este estado aplica unicamente para recursos fısicos y virtuales. Este estado describeun recurso que no esta siendo usado por alguien en el momento en que una consultaes realizada. Un recurso se encuentra en el estado Free si satisface las siguientescondiciones:

hasUsageStatus es una funcion total sobreyectiva del conjunto de indivi-duos de las clases VirtualResource y PhysicalResource sobre el conjunto deindividuos de la clase UsageStatus, i.e., cada recurso esta relacionado uni-camente a un estado de uso, mientras que cada estado de uso esta asociadoal menos a un recurso.

isFreeFor es una funcion parcial del conjunto de individuos de las clasesPhysicalResource y VirtualResource sobre el conjunto potencia del conjuntode individuos de la clase HumanResource, i.e., para cada recurso, el resultadode la funcion isFreeFor contiene a los consumidores que pueden ver losrecursos que no estan siendo usados.

4.4.3. Estado Satisfy Restrictions

Un recurso fısico o virtual esta en el estado Satisfy Restrictions si el usuario satisfacelas restricciones de uso especificadas por el responsable del recurso. En el caso deun recurso humano, este estado denota que se respeta el horario que el definio.El recurso solicitado se encuentra en el estado SatisfyRestrictions si satisface lassiguientes condiciones:

hastToSatisfy es una funcion parcial del conjunto de individuos de la cla-se HumanResource sobre el conjunto potencia del conjunto de individuos dela clase Restriction, i.e., el conjunto resultante de la funcion hasToSatisfycontiene restriciones que el consumidor tiene que cumplir.

isAssociatedTo es una funcion parcial del conjunto de individuos perte-necientes a la clase Restriction sobre el conjunto potencia del conjunto deindividuos de las clases HumanResource, VirtualResource y PhysicalResource,i.e., el resultado de la funcion isAssociatedTo contiene las restriccionesasociadas a un recurso.

hasAllowedValue es una funcion parcial del conjunto de individuos per-tenecientes a la clase Restriction sobre el conjunto potencia del conjunto detipos de datos permitidos, i.e., el resultado de la funcion hasAllowedValuecontiene tipos de datos permitidos para una restriccion en especıfico.

49

hasConsumedValue es una funcion parcial del conjunto de individuos per-tenecientes a la clase Restriction sobre el conjunto potencia del conjunto de ti-pos de datos permitidos, i.e., el resultado de la funcion hasConsumedValuecontiene tipos de datos permitidos para una restriccion en especıfico.

isSatisfyBy es una funcion parcial del conjunto de individuos pertenecien-tes a la clase Restriction sobre el conjunto potencia del conjunto de individuosde la clase HumanResource, i.e., el resultado de la funcion isSatisfyBycontiene a los consumidores que satisfacen una restriccion en especıfico.

4.4.4. Estado Reachable

Un recurso fısico o virtual puede estar en el estado Reachable si se localiza en unlugar restringido y el responsable del recurso o dueno del recurso se localiza en elmismo lugar. El recurso solicitado se encuentra en el estado Reachable si satisfacelas siguientes condiciones:

isLocatedAt es una funcion total del conjunto de individuos de las clasesHumanResource y PhysicalResource sobre el conjunto de individuos de laclase Building, i.e., cada recurso del resultado de la funcion isLocatedAtesta asociado a un individuo que representa un lugar. De igual forma, cadalugar proveniente del resultado de la funcion isLocatedAt esta relacionadoal menos con un recurso.

isResponsibleFor es una funcion parcial del conjunto de individuos per-tenecientes a la clase HumanResource sobre el conjunto potencia del conjuntode individuos de las clases VirtualResource y PhysicalResource, i.e., el resul-tado de la funcion isResponsibleFor es un conjunto que contiene losrecursos fısicos y virtuales de los que un recurso humano es responsable.

isOwnerOf es la funcion parcial del conjunto de individuos pertenecientesa la clase HumanResource sobre el conjunto potencia del conjunto de indivi-duos de las clases VirtualResource y PhysicalResource, i.e., el resultado de lafuncion isOwnerOf contiene los recursos virtuales y fısicos que pertenecena un recurso humano.

isReachableFor es una funcion parcial del conjunto de individuos perte-necientes a las clases VirtualResource y PhysicalResource sobre el conjuntopotencia del conjunto de individuos de la clase HumanResource, i.e., el resul-tado de la funcion isReachableFor contiene todos los consumidores quepueden acceder a un recurso.

50

4.4.5. Estado Available Provider

Un recurso humano se encuentra en el estado Available Provider si esta dispues-to a interactuar con alguien mas en un momento especıfico. Por otro lado, unrecurso fısico o virtual se encuentra en este estado si el responsable de dicho re-curso esta dispuesto a ser interrumpido por otros usuarios. El recurso solicitado seencuentra en el estado Available Provider si satisface las siguientes condiciones:

hasAvailabilityMode es una funcion parcial del conjunto de individuospertenecientes a la clase HumanResource sobre el conjunto potencia del pro-ducto cartesiano del conjunto de individuos de la clase Availability y el con-junto de individuos de la clase HumanResource, i.e., el resultado de la funcionhasAvailabilityMode contiene pares ordenados, donde cada par defineel estado de disponibilidad de la persona, de la forma en que un consumidorlo percibe.

hasAvailableProvider es una funcion parcial del conjunto de individuosde las clases HumanResource, VirtualResource y PhysicalResource sobre elconjunto de individuos de la clase HumanResource, i.e., el resultado de lafuncion hasAvailableProvider contiene a las personas disponibles quepueden dar a un consumidor acceso a un recurso.

4.4.6. Estado Satisfy Context Restrictions

Los recursos alcanzan el estado Satisfy Context Restrictions al cumplir las condicio-nes declaradas por el consumidor. Los tipos de restricciones de contexto son:

Organizacionales:

• Process: un consumidor define la accion en la que un recurso de cualquiertipo esta involucrado.

• Role: define el rol con el que un recurso humano esta actuando.

• Group: determina el equipo al que pertenece un recurso humano.

Fısicas: un consumidor puede especificar la localizacion fısica de un recursode cualquier tipo.

4.5. Similitud semantica entre las clases de las

ontologıas

De acuerdo a Paolucci et al. [23], el problema a resolver en la Web es “la localizacionde servicios Web basada en sus capacidades”. Una propuesta de solucion a este

51

problema es usando similitud semantica. La similitud semantica se obtiene a travesde la taxonomıa establecida (diseno creado a partir de las clases de la ontologıa)mediante la relacion de subsuncion entre dos clases de la ontologıa, i.e., cuandouna clase es subclase de otra.

Las relaciones que se usan para definir la subsuncion entre clases y que permi-ten crear una similitud semantica entre recursos son llamadas isSubclassOf. Ası sedefine la taxonomıa de una ontologıa. En la Figura 4.21 las clases File, DriverPlu-gins, Databases y Software son subclases de la clase VirtualResource definidas porla relacion isSubclassOf; por lo tanto, la claseVirtualResource subsume a lascuatro clases mencionadas anteriormente. Mediante este tipo de relaciones de sub-suncion, llamados Grados de Coincidencia [34], se puede definir una escala paradeterminar entre las definiciones de los recursos. Dichos grados son asignados porel algoritmo de coincidencia cuando compara las caracterısticas y/o capacidadestecnicas de un recurso que el consumidor esta busca contra los recursos almace-nados en las ontologıas. Esta comparacion respalda que el algoritmo desarrolladono se basa en la comparacion sintactica de palabras clave, sino en la comparacionsemantica de los recursos a traves de su definicion en la ontologıa.

Figura 4.21: Ejemplo de subsuncion

El algoritmo de coincidencia propuesto, reconoce cuatro grados de coincidenciaentre dos conceptos que representan recursos. Asuma que RequestedResource res-presenta el recurso solicitado y AdvertisedResource es un recurso que se encuentraalmacenado en una de las ontologıa. Los grados de coincidencia que se puedenobtener a traves de la comparacion de RequestedResource con AdvertisedResourceson los siguientes:

Exact: si RequestedResource y AdvertisedResource son iguales, i.e., si existenindividuos en la clase AdvertisedResource que coinciden con RequestedRe-source.

52

Plug-in: si AdvertisedResource subsume RequestedResource, i.e., si Reques-tedResource es una subclase de la clase AdvertisedResource, por lo tantoAdvertisedResource puede ser mostrado en lugar de RequestedResource, con-siderando que los recursos de esta categorıa son mas generales de lo que buscael consumidor.

Subsume: si RequestedResource subsume a AdvertisedResource, i.e., si la claseen la que se encuentra el recurso solicitado no contiene individuos, el algorit-mo busca si tiene subclases, y si en estas subclases encuentra individuos que“satisfacen” el recurso solicitado, entonces se tendra un recurso mas especıfi-co del que realmente se solicito. Por lo tanto, este grado de coincidencia esmenor que el grado Plug-in.

Fail: una coincidencia falla si no hay individuos de la clase AdvertisedResourceque coincidan con RequestedResource, esto quiere decir que ni la clase, sub-clases o clase padre, donde se encuentra clasificado AdvertisedResource, tienealgun individuo que coincide con el recurso que se esta buscando.

De acuerdo a Senvar et al. [22], el orden de preferencia que los grados de coinci-dencia deben tener es: Exact > P lug − in > Subsume > Fail. Tambien asumien-do esta escala, se asignaron los siguientes valores a cada grado de coincidencia, deacuerdo a Senvar et al. [22] y Paolucci et al. [23]:

Exact: a este grado de coincidencia se le asigno el costo total, i.e., el valor 1.

Plug-in: en este caso, asignamos el valor estatico de .75, siguiendo la regla deque el grado Plug-in debe ser mayor que el grado Subsume y menor al gradoExact, ademas de que es el valor normalmente asigando para este grado enlos trabajos mencionados con anterioridad.

Subsume: para este grado, decidimos dividir el valor total (1) entre el total desubclases de la clase que coincide con el recurso solicitado, usando la formuladesarrollada por Bener et al. [41]:

SubsumeV alue =1

numberOfDirectSubclassesClass

(4.1)

Fail: en caso de que el algoritmo determine que no hay ningun individuo quecoincida con el recurso solicitado se considera que la busqueda fracaso y seasigna el valor de 0.

53

54

Capıtulo

5 Implementacion del algoritmode coincidencia en RAMS

En este capıtulo, en la seccion 5.1 se explica la estructura del algoritmo de coin-cidencia propuesto ası como un breve resumen de las principales bibliotecas quesirvieron para el desarrollo de dicho algoritmo en la seccion. En la seccion 5.2esta descrito el desarrollo del algoritmo de coincidencia semantico. En la seccion5.3 se explica detalladamente el desarrollo del modulo de multi-busqueda, y en laseccion 5.4 se explica el modulo de suscripcion implementado. En la seccion 5.5,se muestran las interfaces graficas de usuario de la aplicacion del algoritmo decoincidencia semantico que hemos desarrollados. Finalmente en la seccion 5.6 sepresentan los resultados obtenidos en las pruebas del algoritmo propuesto.

5.1. Estructura y bibliotecas del algoritmo de

coincidencia

En la Figura 5.1 se muestran los paquetes que actualmente conforman el proyectoen Java del algoritmo de coincidencia implementado en la arquitectura RAMS.

Todos los paquetes se derivan del proyecto Matchmaker, llamado ası para iden-tificar el modulo de la arquitectura RAMS al que nos referimos. A continuacion,se describen brevemente los paquetes contenidos en la carpeta llamada Paquetesde fuentes y su funcion en la aplicacion del algoritmo de coincidencia de RAMS:

match.SPARQL: en este paquete se encuentran las clases necesarias paracrear, ejecutar y eliminar una consulta SPARQL; dichas consultas son usadaspara realizar la autentificacion de usuario y para encontrar coincidenciassemanticas entre las caracterısticas tecnicas de los recursos ofrecidos conrespecto a los requeridos.

match.SQWRL: contiene las clases necesarias para crear, ejecutar y mostrarlos resultados obtenidos de las consultas SQWRL; dichas clases son utiliza-das por el algoritmo de coincidencia para obtener los recursos ofrecidos quesatisfagan los estados de disponibilidad y contexto de un usuario.

match.auxObjects: en este paquete estan definidas las clases que proveen losobjetos utilizados para almacenar los datos necesarios para ejecutar los demasmetodos.

55

Figura 5.1: Paquetes del algoritmo

match.matchmaker: Este paquete contiene la clase principal del algoritmo decoincidencia, ademas provee el hilo encargado de la ejecucion de consultasreferentes a las preferencias del usuario.

match.modules: dentro de las clases de este paquete se localizan los meto-dos auxiliares que nos sirven para realizar actividades encargadas de realizaractividades tıpicas del manejo de ontologıas, e.g., carga de ontologıa, obten-cion de direcciones de una ontologıa o individuo, obtencion de propiedadesde datos.

En la Figura 5.2, se listan todas la bibliotecas que se importan al proyecto parapoder usar los metodos que Pellet, Jess, Jena y OWL-API proporcionan.

Las bibliotecas importadas de Pellet [31] anaden al algoritmo de coincidenciael razonamiento con la maxima expresividad de OWL-DL (OWL con Logica Des-criptiva). Pellet es usado principalmente para obtener de forma semi-automaticalas propiedades de dato de una clase. Sin embargo, tambien permite:

calificar restricciones de cardinalidad;

definir propiedades reflexivas, irreflexivas, simetricas y anti-simetricas;

crear propiedades disjuntas;

56

Figura 5.2: Bibliotecas importadas al proyecto

declarar afirmaciones de propiedad negativas;

establecer rangos de datos definidos por el usuario;

Pellet provee todos los servicios de inferencia estandar que son tradicionalmenteproporcionados por razonadores que emplean Logica Descriptiva:

Comprobacion de consistencia: asegura que la ontologıa no contengahechos contradictorios.

Concepto de satisfiability : determina si es posible que una clase tengainstancias.

Clasificacion: calcula las relaciones de subclases entre cada clase nombra-da para crear la jeraquıa de clases completa, la cual puede ser usada parasolucionar consultas.

Comprension: encuentra la clase mas especıfica a la que pertenece un indi-viduo.

Apache Jena (o Jena) es un framework de Java gratuito y de codigo abiertopara la Web semantica y la construccion de aplicaciones de datos ligados. Esteframework se compone de diferentes APIs que interactuan juntas para procesardatos RDF. En nuestra propuesta, Jena es utilizado para administrar y ejecutarlas consultas SPARQL creadas por el algoritmo de coincidencia.

57

Por su parte, Jess es un motor de reglas y un entorno de scripts escrito en JavaOracle. Mediante Jess se puede construir codigo en Java que tiene la capacidadde “razonar”, utilizando el conocimiento que fue suministrado por el creador delsoftware en forma de reglas declarativas. En este proyecto utilizamos Jess para ladeclaracion y ejecucion de consultas SQWRL.

Finalmente, OWL-API es una API de Java e implementacion de referenciapara la creacion, manipulacion y serializacion de ontologıas OWL. Esta API hasido fundamental para el desarrollo del algoritmo de coincidencia.

5.2. Desarrollo del algoritmo de coincidencia

La clase que inicia la ejecucion del algoritmo que se propone, se encuentra en laclase Matchmaker del paquete match.matchmaker. En el Algoritmo 1 se presentael pseudocodigo del algoritmo de coincidencia semantico para la lalocalizacion deun recurso en un ambiente colaborativo.

En la lınea 1 de dicho algoritmo, se declaran las variables globales necesariaspara ejecutar el algoritmo. Estas variables contienen la direccion de los archi-vos en donde las ontologıas principales se encuentran almacenadas. Las variables:ontDepartment, ontPhysicalR, ontHumanR, ontVirtualR, ontContexty ontOriginal; cada una de estas variables almacena respectivamente la direc-cion donde se encuentra el archivo OWL de las ontologıas de: los departamentos,los recursos fısicos, los recursos humanos, los recursos vituales, el contexto y lameta-ontologıa. En esta seccion, tambien se declara la variable pathFile, encar-gada de almacenar la direccion general del proyecto, ası como las variables id yuser que permiten guardar, como su nombre lo indica, el identificador y nombredel usuario.

Posteriormente, en la lınea 2 se permite al usuario eligir el tipo de operacion arealizar (i.e., busqueda de uno o multiples recursos); en este caso, se selecciona lalocalizacion de un solo recurso, el cual puede ser de tipo humano, fısico o virtual.La lınea 3 representa la operacion de cargar, en la meta-ontologıa, las ontologıasnecesarias para iniciar el proceso de autentificacion de usuario. Estas ontologıasson HumanResource y la clase Building de la ontologıa PhysicalResource, paraidentificar la ubicacion fısica del usuario de la organizacion.

En la lınea 4 se pide al usuario que introduzca su ID y nombre de usuario, paraque el algoritmo de coincidencia verifique si tiene permiso de accesar. Actualmenteestos datos son proporcionados de forma manual por el usuario, pero se pretendeque el proceso de autenticacion sea automatico mediante el uso del modulo deReconocimiento Humano [42] el cual realiza un analisis biometrico del usuariopara determinar su identidad. Cuando el usuario termina de capturar sus datosse construye una consulta SPARQL basada en el ID y nombre de usuario paraverificar que estos datos, se encuentren en la ontologıa de recursos humanos, de ser

58

Algoritmo 1 Algoritmo de coincidencia semantico basado en contexto para lalocalizacion de recursos dentro de una organizacion

1: Set variables2: if Choose the type of operation (select simple matchmaker) then3: Load the basic ontologies for the simple matchmaker4: Get username and user ID5: if User is allowed to use the matchmaker then6: Ask the user about the specific resource they are looking for7: Check the type of resource and load the necessary ontologies8: Get the technical characteristics that correspond to the required resource9: Ask the user about their requirements in terms of technical characteristics10: Obtain through semantic similarity other resources11: Get a set of resources that fulfill the user technical characteristics requi-

rements12: if There is at least one resource with such technical characteristics then13: Ask the user about their preferred availability states14: if Context restrictions were selected then15: Ask the user about their context restrictions16: end if17: Execute the queries corresponding to the selected availability states18: if Context restrictions were selected then19: Execute the queries concerning the context restrictions20: end if21: Inform the user about the found resources22: else23: Inform the user that there are not resources with the required technical

characteristics24: end if25: Inform the user that he is not allowed to use the matchmaker26: end if27: end if

59

ası, en la lınea 5 se permite al usuario usar el algoritmo.

La consulta para la identificacion del usuario se genera a traves de la claseQueriesSPARQL. Como se muestra en la Figura 5.3, se crea una variable de tipoString llamada q para almacenar la consulta generada. En esta consulta primerose definen todos los prefijos de las ontologıas como se observa en las lınea 2 a 11.Dichos prefijos permiten a las clausulas de la consulta acceder a las ontologıasnecesarias para ejecutar dicha consulta. Posteriormente, a la misma variable q seanade la clausula SELECT la cual nos permite definir las variables que estamosinteresados en consultar. Como se puede observar en la lınea 14, dichas variableson declarada mediante un signo de interrogacion (?) seguido de su nombre. Final-mente, a la variable q se agrega la clausula WHERE que contiene las restriccionespara formar la consulta que permite autenticar al usuario. En la lınea 16 se indicaque la consulta se va a ejecutar sobre un recurso humano, por lo tanto la consultacreada accede, mediante el prefijo h, a la ontologıa de recursos humanos. Las lıneas18 y 19, establecen que la consulta obtendra tanto el nombre de usuario como elID de un recurso humano, respectivamente. Finalmente, en las lıneas 20 y 21 serealiza el filtro encargado de buscar coincidencias entre las propiedades de dato(caracterısticas) de un individuo de la ontologıa de recursos humanos y los datosque ha proporcionado el usuario que desea ser autenticado.

En caso de que el usuario pueda utilizar el algoritmo, continua con la operacionde la lınea 6 del Algoritmo 1, en caso contrario, como se observa en la lınea 25,se le informa al usuario que no esta autorizado para usar la aplicacion. En lalınea 6 se pregunta al usuario por el recurso que requiere. Despues, en la lınea 7,de acuerdo al tipo de recurso (i.e., fısico, virtual o humano) seleccionado por elusuario, la aplicacion que explota el algoritmo de coincidencia carga la ontologıau ontologıas correspondientes. La ontologıa de recursos fısicos es necesaria pararealizar todas las consultas porque en ella se encuentran los edificios donde selocalizan los recursos virtuales contenidos en un dispositivo fısico extraible, losrecursos fısicos y humanos, por lo tanto esta ontologıa se debe importar en casode no haber sido cargada previamente.

Una vez que se cargaron las ontologıas necesarias, en la lınea 8 se realiza laconsulta correspondiente para obtener las caracterısticas tecnicas del recurso queel usuario desea buscar. Una vez que se obtienen las caracterısticas tecnicas delrecurso, en la lınea 9 se pregunta al usuario en cuales de ellas esta interesado. En lalında 10, se buscan los recursos similares al recurso que el usuario busca medianteel concepto de similitud semantica, de esta forma, es posible brindar un mayornumero de recursos, y en caso de no encontrar el recurso que desea, se muestranposibles opciones de recursos que pueden ser de utilidad para el usuario.

En la Figura 5.4 se describe la estructura basica del segmento de codigo delos hilos Callable. Este tipo de hilos son usados para realizar varias consultasde forma simultanea, y ası obtener los recursos semanticamente similares, con

60

1 begin method createFirstStringSPARQL(String resource, int type,String typeR)

2 String q = "PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>"

3 +"PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>"

4 +"PREFIX owl: <http://www.w3.org/2002/07/owl#>"5 +"PREFIX v: <http://www.owl-ontologies.com/

virtualR.owl#>"6 +"PREFIX p: <http://www.owl-ontologies.com/

physicalR.owl#>"7 +"PREFIX h: <http://www.owl-ontologies.com/

humanR.owl#>"8 +"PREFIX m: <http://www.owl-ontologies.com/

metaOntology.owl#>"9 +"PREFIX k: <http://www.owl-ontologies.com/kim.

owl#>"10 +"PREFIX d: <http://www.owl-ontologies.com/

departments.owl#>"11 +"PREFIX c: <http://www.owl-ontologies.com/

contextNew.owl#>"12

13 begin if type == 114 q = q + "SELECT ?Z ?N ?U \n"15 + "WHERE { \n"16 + "{?Z rdf:type h:HumanResource . \n"17 + "} \n"18 + "?Z h:nameRH ?N . \n"19 + "?Z h:idNumber ?U \n"20 + "FILTER regex(?N, \""+Matchmaker.user+"

\", \"i\" ) \n"21 + "FILTER regex(?U, \""+Matchmaker.id+"\",

\"i\" ) \n"22 + "}"23 end if

Figura 5.3: Consulta de autenticacion del usuario

respecto a las caracterısticas tecnicas que el usuario desea y aquellos recursos que seencuentran en los estados de disponibilidad seleccionados. En la lınea 1 se define elnumero de hilos a utilizar. De la lınea 2 a la 4 se establecen las variables auxiliarespara poder ejecutar este tipo de hilos. En el ciclo for de la lınea 6 a la 11 serealizan las operaciones necesarias para la ejecucion de cada hilo. En el ciclo for

61

de la lınea 13 a la 15 se obtienen los resultados de las operaciones que cada hilorealizo. Finalmente en la lınea 17 se suspenden todos los hilos para evitar problemasfuturos con ellos.

1 ExecutorService poolTC = Executors.newFixedThreadPool(numberThreads);

2 Callable<typeResult> callableTC;3 Future<typeResult> futureTC;4 Set<Future<typeResult>> setTC = new HashSet<Future<

typeResult>>();5

6 for (int y = 0; y < numberThreads; y++) {7 //Necesary operations with threads8 callableTC = new ThreadSPARQL(parameter);9 futureTC = poolTC.submit(callableTC);

10 setTC.add(futureTC);11 }12

13 for (Future<typeResult> future2 : setTC) {14 Get results15 }16

17 poolTC.shutdown();

Figura 5.4: Estructura hilos Callable

Despues de haber encontrado recursos similares, en la lınea 11 se realiza lacomparacion de las caracterısticas tecnicas de los recursos encontrados contradosy las del recurso solicitado, de esta forma se garantiza que los recursos similarescumplan con las restricciones tecnicas que el usuario selecciono al inicio. En casode que se haya encontrado al menos un recurso con las caracterısticas tecnicasque se estan buscando, el flujo normal del algoritmo 1 continua, en caso contrario,como se menciona en la lınea 23, se envıa al usuario un mensaje informandoleque no existe algun recurso especıfico o similar al que esta buscando y termina laejecucion aplicacion que permite explotar el algoritmo de coincidencia. En la lınea13 se pregunta al solictante sobre los estados de disponibilidad en los que desease encuentre dicho recurso. A continuacion se describen los tipos de menus que sepueden presentar al consumidor:

1. en caso de que un recurso virtual o fısico sea solicitado, el usuario pue-de seleccionar uno o mas de los siguientes estados de disponibilidad: Free,SatisfyRestrictions, Reachable, AvailableProvider y/o SatisfyContextRestrictionsdefinidos en la arquitectura RAMS ??;

62

2. por otro lado, en caso de que el usuario haya solicitado un recurso humano,el usuario puede seleccionar uno o varios de los siguientes estados: Satisfy-Restrictions, AvailableProvider y/o SatisfyContextRestrictions.

En caso de que el usuario haya seleccionado el estado de disponibilidad Satisfy-ContextRestrictions se ejecuta la condicion de la lınea 14 del algoritmo 1 y la lınea15 se encarga de mostrar uno de los siguientes menus:

1. en caso de haber seleccionado un recurso humano, el usuario puede elegirel proceso, rol, grupo o ubicacion fısica en que prefiere que el recurso seencuentre.

2. en caso de haber seleccionado un recurso fısico o virtual, el usuario puedeelegir el proceso y la ubicacion f’isica preferidas.

En la lınea 17 del algoritmo 1 se ejecutan las consultas necesarias para saber silos recursos seleccionados que cumplen con las caracterısticas tecnicas se encuen-tran en los estados de disponibilidad que selecciono el usuario. En esta operacionse utilizan hilos del tipo Callable, los cuales permiten la ejecucion concurrentede hilos. En caso de haber seleccionado el estado de disponibilidad SatisfyContex-tRestrictions en la lınea 19, se ejecutan las consultas para localizar los recursos quesatiscen dicho estado. Finalmente, en la lınea 21 del algoritmo 1, se muestran alusuario los resultados obtenidos, tanto de la ejecucion de las consultas sobre losestados de disponibilidad, como del estado SatisfyContextRestrictions, en caso dehaber sido seleccionado.

5.3. Modulo de multi-busqueda

A continuacion, se describe el Algoritmo 2 que corresponde al proceso que se llevaa cabo para realizar la busqueda de multiples recursos. En las lıneas 1 a la 5, serealiza el mismo proceso que en el caso de la busqueda de un solo recurso.

Como en el caso anterior, en la lınea 1 se declaran las variables globales necesa-rias para ejecutar la aplicacion que explota el algoritmo de coincidencia semantico.Posteriormente, en la lınea 2 se pide al usuario seleccione el tipo de operacion arealizar, en este caso, el de la busqueda de multiples recursos. Se cargan las onto-logıas necesarias a la meta-ontologıa en la lınea 3 y en la lınea 4 se pide al usuarioproporcione informacion para verificar que tenga derechos de acceso. En caso deque el usuario pueda utilizar la aplicacion, se sigue con el flujo normal del algorit-mo, de la lınea 6 a la 27, en caso contrario, en la lınea 31 se envia al usuario unmensaje informandole que no puede utilizar el algoritmo y finaliza la aplicacionque permite explotar el algoritmo de coincidencia.

63

Algoritmo 2 Algoritmo de coincidencia semantico basado en contexto para lalocalizacion de mas de un recurso dentro de una organizacion

1: Set variables2: if Choose the type of operation (select multiple matchmaker) then3: Load the basic ontologies for the simple matchmaker4: Get username and user ID5: if User is allowed to use the matchmaker then6: Ask the user about the number of resources he want to look for7: while Number of resources > 0 do8: Ask the user about the specific resource he is looking for9: if The ontology corresponding to the selected resource was not loaded

previously then10: Check the type of resource and load the necessary ontologies11: end if12: Get the technical characteristics that correspond to the required resour-

ce13: Ask the user to provide their preferred values concerning the technical

characteristics of the resource that is being looked for14: Obtain through semantic similarity other resources15: end while16: if There is at least one resource fulfilling the required technical characte-

ristics then17: while Number of resources > 0 do18: Ask the user about their preferred availability states19: if Context restrictions were selected then20: Ask the user about their context restrictions21: end if22: end while23: Execute the queries corresponding to the selected availability states24: if Context restrictions were selected then25: Execute the queries concerning the context restrictions26: end if27: Inform the user about the results28: else29: Inform the user that there are not any resources with the required tech-

nical characteristics30: end if31: Inform the user that he is not allowed to use the matchmaker32: end if33: end if

64

En la lınea 6 se pregunta al usuario el numero de recursos que desea buscar,este numero permite determinar la cantidad devecs que se le pedira al usuario pro-porcione informacion sobre dichos recursos (ciclo de la lınea 7 a la 15). En la lınea8 se pregunta al usuario el recurso que desea buscar. Al llegar a la lınea 9 se evaluauna condicion para verificar cuales son las ontologıas cargadas hasta el momen-to. En caso de que la ontologıa correspondiente al recurso que se ha seleccionadopreviamente no se haya cargado, en la lınea 10 se procede a cargarla. En la lınea12 se verifican las caracterısticas tecnicas que posee el tipo de recurso solicitado yen la lınea 13 se solicita al usuario llenar las caracterısticas que requiere que esterecurso posea. Posteriormente, en la lınea 14 se checa la similitud semantica deltipo de recurso por el que se esta preguntando. Este proceso se repite hasta que seha preguntado por el total de recursos que el usuario busca.

Una vez terminado el primer ciclo donde se pide informacion sobre los recursosa buscar y sus caracterısticas tecnicas, en la lınea 16 se procede a checar si al menosun recurso cumple con las caracterısticas tecnicas que el usuario solicito. En casoafirmativo, se sigue con las instrucciones de la lınea 17 a la 27, en caso contrario sesalta a la lınea 29 y se envia un mensaje al usuario indicandole que ningun recursosatisface sus requerimientos.

En la lınea 17, se inicia un ciclo while el cual se encarga de verificar cadauno de los recursos que el usuario solicito al inicio. Por lo tanto, en la lınea 18 sepregunta para cada recurso solicitado, el o los estados de disponibilidad en los que elusuario desea que dicho recurso se encuentre (Free, SatisfyRestrictions, Reachable,AvailableProvider y/o SatisfyContextRestrictions). En este paso, tambien se llamaun metodo que se encarga de generar las respectivas consultas de los estados dedisponibilidad para su posterior ejecucion. En caso de que haya seleccionado lapreferencia de disponibilidad SatisfyContextRestrictions, se evalua la condicion dela lınea 19, donde se pide al usuario que especifique sus restricciones de contexto.Posteriormente se crean las consultas pertinentes a las restricciones de contexto.

En la lınea 23 se ejecutan las consultas creadas previamente para obtener losresultados de los recursos que satisfacen las preferencias de disponiblidad. En casode que al menos un recurso cumpla con dichos estados de disponibilidad y se hayaseleccionado el estado SatisfyContextRestrictions, entonces en la lınea 25 se ejecutanlas consultas correspondientes. Finalmente, en la lınea 27 se muestran al usuariolos resultados de los recursos que satisfacen tanto las caracterısticas tecnicas comolos estados de disponibilidad seleccionados.

5.4. Modulo de suscripcion

El algoritmo 3 describe el proceso que se lleva a cabo cuando un usuario desea sus-cribirse a la aplicacion que permite el uso del algoritmo de coincidencia semanticopara recibir notificaciones sobre un recurso en el que esta interesado.

65

En la lınea 1 se declaran las variables necesarias para la correcta ejecucion de laaplicacion que hace uso del algoritmo de coincidencia propuesto. Posteriormente,en la lınea 2 se elige el tipo de operacion que se llevara a cabo, en este caso se eligela opcion de suscripcion. Una vez que se selecciono esta opcion en la lınea 3, secargan en la meta-ontologıa, las ontologıas necesarias para mas tarde realizar lasconsultas correspondientes al recurso que le interesa al usuario. En la lınea 4 sepide al usuario proporcionar su ID y nombre de usuario. En caso de que el usuariosea autenticado correctamente, el flujo normal del algoritmo continua de la lınea6 a la 18. En caso contrario, en la lınea 21 se informa al usuario, mediante unaimpresion de mensaje que no esta autorizado a utilizar dicho algoritmo.

Algoritmo 3 Suscripcion al algoritmo de coincidencia semantico basado en con-texto para la localizacion de un recurso dentro de una organizacion

1: Set variables2: if Choose the type of operation (subscription) then3: Load the basic ontologies for the simple matchmaker4: Read user name and user ID5: if User is allowed to use the matchmaker then6: Ask the user about the resource they are looking for7: Check the type of resource and load the necessary ontologies8: Get the technical characteristics that correspond to the required resource9: Ask the user about the required values of such characteristics10: Ask the user about the preferred availability states11: if Context restrictions were selected then12: Ask the user about their context restrictions13: end if14: Save the user preferences15: Wait for any change in the ontology concerning the selected resource16: if There is any change in the ontology then17: Execute the queries to obtain new results18: end if19: else20: Inform the user that he is not allowed to use the matchmaker21: end if22: end if

A partir de la lınea 6 se pregunta al usario por el recurso que desea buscar yen la lınea 7 se cargan la ontologıa correspondiente al tipo de recurso. En la lınea8 son recuperadas las caracterısticas tecnicas del recurso y en la lınea 9 se solicitaal usuario ingrese las caracterısticas tecnicas que desea encontrar en dicho recurso.En la lınea 10 se pide al usuario seleccione los estados de disponibilidad en los quedesea que se encuentre el recurso que solicito. En caso de haber seleccionado el

66

estado SatisfyContextRestrictions, en la lınea 12 se solicita al usuario especifique lasrestricciones de contexto.

Posteriormente, en la lınea 14 se almacenan las preferencias del usuario enun archivo con extension .txt para que, en caso de que el hilo de la lınea 15encuentre un cambio en las ontologıas, se realicen las consultas pertinentes. Estehilo esta verificando constantemente si hay algun cambio en la ontologıa de la cualproviene el recurso que el usuario selecciono; en caso de encontrar algun cambio,extrae inmediatamente la informacion del archivo .txt creado previamente. Estainformacion permite generar las consultas necesarias e ir a la fase State Analisys,la cual se encarga de ejecutar las consultas y finalmente en la fase Query Executionmostrar los resultados al usuario.

5.5. Interfaces graficas de usuario

En esta seccion, se presentan las capturas de pantalla de las interfaces graficas de laaplicacion que explota el algoritmo de coincidencia semantico, los cuales permitenla interaccion entre dicha aplicacion y el usuario. La Figura 5.5 muestra la pantallainicial del algoritmo de coincidencia, donde se pide al usuario que introduzca suID y nombre para identificarlo.

Figura 5.5: Interfaz inicial de la aplicacion que explota el algoritmo de coincidencia

En caso de que el usuario este autorizado a usar la aplicacion que explotael algoritmo de coincidencia, se le muestra la pantalla de la Figura 5.6, la cual

67

despliega un menu en el cual es posible seleccionar la busqueda de un solo recursoo la busqueda de multiples recursos.

Figura 5.6: Interfaz del menu principal de la aplicacion

En caso de seleccionar la busqueda de un solo recurso, la aplicacion que explotael algoritmo procede a preguntar al usuario el tipo de recurso que desea buscar (i.e.,fısico, virtual o humano). Posteriomente se muestran en pantalla todos los posiblesrecursos para que el usuario seleccione el de su interes (Figura 5.7).

A continuacion, se solicita al usuario proporcionar las especificaciones de lascaracterısticas tecnicas que le interesan de dicho recurso (Figura 5.8).

Posteriormente se pregunta al usario sobre los estados de disponibilidad en losque desea se encuentre el recurso que esta buscando. Los estados de disponibilidadque el usuario puede selecionar dependen del tipo de recurso que se este buscando(Figura 5.9).

En caso de que el usuario haya seleccionado el estado SatisfyContextRestrictions,se muestran las posibles opciones que puede seleccionar de acuerdo al tipo derecurso que se busca (Figura 5.10).

Finalmente, en la Figura 5.11, se muestra la interfaz de los resultados obte-nidos por esta aplicacion. En la primer columna se indica el nombre del recursoencontrado, en la segunda columna se encuentran los requerimientos que el recursosatisface; y en la tercera columna se muestra un porcentaje de similitud de acuerdoa las caracterısticas tecnicas que el usuario selecciono.

68

Figura 5.7: Interfaz para la seleccion del tipo de recurso a buscar

Figura 5.8: Pantalla preguntando por las caracterısticas tecnicas

5.6. Resultados del algoritmo

En esta seccion se explica la validacion del algoritmo de coincidencia semanticodesarrollado. Se describe el caso de estudio que se utilizo y las pruebas que sehicieron para validar dicho algoritmo.

69

Figura 5.9: Pantalla de los estados de disponibilidad

Figura 5.10: Pantalla solicitando al usuario las preferencias de contexto

5.6.1. Caso de estudio

El Departamento de Computacion del CINVESTAV unidad Zacatenco cuenta conuna gran variedad de recursos, los cuales se pueden organizar en fısicos, virtualesy humanos a traves de las ontologıas de la arquitectura RAMS 4.3. Actualmente

70

Figura 5.11: Pantalla entregando los resultados finales

las ontologıas de dicha arquitectura cuentan con mas de 380 individuos:

134 individuos en la ontologıa PhysicalResource, incluyendo los edificios queconforman la organizacion.

106 individuos en la ontologıa HumanResource.

87 individuos en la ontologıa VirtualResource.

55 individuos en la clase JobPosition de la ontologıa HumanResource.

La meta-ontologıa cuenta con mas de 250 relaciones que permiten realizar masde 100 tipos de consultas diferentes. La ejecucion del algoritmo de coincidenciasemantico se realizo en una computadora MacBookPro con un procesador de 2.9GHz Intel Core i7, 8 GB de memoria RAM y bajo el sistema operativo OSX version10.9.4

5.6.2. Indicadores de desempeno

Para la validacion del algoritmo, se usaron los indicadores de precision y exhaus-tividad. Estos indicadores permiten evaluar el desempeno de nuestra propuesta.La precision es la fraccion de los servicios encontrados que son considerados comorelevantes y la exhaustividad es la fraccion de los servicios relevantes que fueronencontrados. El valor maximo de ambos indicadores es 1. Las definiciones de pre-cision y exhaustividad de acuerdo a Yang et al. [43] son:

71

Precision =RER

RE(5.1)

Exhaustividad =RER

RR(5.2)

Donde RER se refiere al numero de recursos encontrados y relevantes. RE esel total de recursos encontrados y RR es el total de recursos relevantes.

Ambos indicadores se midieron en dos de las cuatro fases del algoritmo decoincidencia: despues de haber realizado la similitud semantica en la fase Charac-teristics Search 4.2 y al ejecutar las consultas necesarias en la fase Query Execution.En la fase CharacteristicsSearch, la definicion de ambos indicadores se basa en losresultados obtenidos a traves de la similitud semantica, por lo tanto sus definicionesquedan de la siguiente forma:

Precision =RPT

RESS(5.3)

Exhaustividad =RPT

REMSS(5.4)

Donde RPT se refiere al numero de recursos permitidos al consumidor y re-levantes, i.e., estos recursos se encuentran en el estado de disponibilidad Allowedpara el consumidor y ademas son del mismo tipo que el usuario esta buscandoo su similitud es mayor a la de los otros recursos. RESS es el total de recursosencontrados despues de haber aplicado la similitud semantica y REMSS es el totalde recursos relevantes del mismo tipo solicitado o con mayor similitud semanticaa este tipo de recurso.

Finalmente, en la fase QueryExecution se vuelven a obtener estos parametrospara observar su aumento al usar las relaciones definidas en las ontologıas y realizarlas consultas a traves de las restricciones de uso asignadas a cada recurso; estopermite al usuario visualizar unicamente los recursos que puede utilizar y evitaraquellos a los que no tiene permiso de uso o acceso. Las formulas para obtener laprecision y exhaustividad en esta fase son:

Precision =RERU

REFA(5.5)

Exhaustividad =RERU

RPT(5.6)

Donde RERU se refiere al numero de recursos encontrados y relevantes parael usuario, ya sean del mismo tipo o que tengan una similitud semantica mayor.REFA se refiere al total de recursos encontrados en el estado Allowed que pasaronla fase anterior (Characteristics Search) y RPT es el total de recursos permitidosy que coinciden con el tipo de recursos que el consumidor pidio al inicio.

72

5.6.3. Pruebas del algoritmo de coincidencia semantico

A continuacion se muestran tres tablas que describen algunas consultas realizadaspara validar el proceso de similitud semantica del algoritmo de coincidencia basadoen contexto. En las Figuras 5.12, 5.13 y 5.14 se muestran las tablas respectivas alanalisis de similitud semantica de consultas realizadas a recursos fısicos, virtualesy humanos. Dichas tablas poseen los parametros necesarios para analizar los resul-tados obtenidos de esta similitud. En la primera columna se menciona el tipo derecurso fısico seguido del nombre del consumidor. La segunda columna correspondeal nombre de la caracterıstica tecnica seleccionada por el consumidor para buscarun recurso. En la tercera columna se encuentran las clases de recursos similares alque el consumidor busca. En la cuarta columna se mencionan la cantidad y tipo derecursos que coinciden con las caracterısticas tecnicas que el consumidor requiere;se registran tanto los recursos semanticamente similares como el tipo de recursosque se solicito al inicio. La quinta columna indica la cantidad y el tipo de recursosque el consumidor puede usar, i.e., para los recursos que satisfacen el estado dedisponibilidad base Allowed. Finalmente, las columnas sexta y septima contienenla fraccion de precision y exhaustividad correspondiente al recurso solicitado. Es-tos indicadores corresponden a la similitud semantica que se obtuvo mediante lasformulas 5.3 y 5.4 respectivamente.

Figura 5.12: Resultados de la similitud semantica en recursos fısicos

Posteriormente, en las Figuras 5.15, 5.16 y 5.17 se muestran las tablas donde seanalizan los resultados finales obtenidos del algoritmo de coincidencia semanticobasado en contexto. En la primera columna se encuentra el tipo de recurso juntocon el nombre del consumidor. En la segunda columna se mencionan los estadosde disponibilidad que el consumidor selecciono previamente. La tercera columnacorresponde al tiempo de ejecucion de las consultas de cada preferencia de dis-

73

Figura 5.13: Resultados de la similitud semantica en recursos virtuales

Figura 5.14: Resultados de la similitud semantica en recursos humanos

ponibilidad en segundos; este tiempo correponde a la ejecucion de los recursosseleccionados en la fase Characteristics Search para verificar cuales cumplen conlos estados de disponibilidad seleccionados por el consumidor. Finalmente, en lacuarta y quinta columna se registran los resultados correspondientes a la precisiony exhaustividad de los resultados finales del algoritmo de coincidencia semanticobasado en contexto; estos indicadores se basan en las formulas 5.5 y 5.6.

Como se puede observar en las Figuras 5.12 y 5.13, los recursos fısicos y virtualesentregan resultados muy variables, esto se debe al uso de la similitud semantica.Por otro lado, en la Figura 5.14 se muestra que los recursos humanos no presentanesta variacion porque su definicion es la misma, i.e., los recursos fısicos y virtualestienen caracterısticas similares, pero debido a que cuentan con una mayor cantidadde subclases, se van definiendo con mayor precision, mientras que los recursoshumanos, aunque poseen diferentes valores para sus propiedades en comun, suscaracterısticas principales no cambian. Posteriormente, en las Figuras 5.15 y 5.16se puede observar que, usando los estados de disponibilidad que provee el algoritmode coincidencia, los recursos fısicos y virtuales mejoran su precision y exhaustividaden la mayorıa de los casos. Como se muestran en las figuras anteriores, aunqueexista una gran cantidad de recursos que coincidan con las caracterısticas tecnicas

74

Figura 5.15: Resultados del algoritmo de coincidencia en recursos fısicos

Figura 5.16: Resultados del algoritmo de coincidencia en recursos virtuales

Figura 5.17: Resultados del algoritmo de coincidencia en recursos humanos

y que sean semanticamente similares, dicha cantidad se va a reducir debido a lospermisos que el dueno le aplique a sus recursos, e.g., en la tabla de la Figura 5.12,el primer recurso fısico que se busco es una camara que pidio Garcıa y aunque

75

exiten cinco camaras que satisfacen la resolucion de camara que esta solicitando yuna tablet, Garcıa no tiene acceso a todas ellas, unicamente a una camara.

Figura 5.18: Tabla de los tiempos de ejecucion de las tareas principales

En la Figura 5.18 se muestra la tabla de los tiempos en promedio que se tar-dan en ejecutar las actividades principales del algoritmo. La similitud semanticase obtiene en un tiempo promedio de 39.66 milisegundos. Las ontologıas se cargana la meta-ontologıa de acuerdo al tipo de recursos que se va a buscar; en caso deque sea un recurso humano unicamente se cargan las ontologıas HumanResource,Departments y Position. En caso de que sea un recurso fısico, se cargan las onto-logıas HumanResource, Departments, Position y PhysicalResource. Finalmente, sise buscara un recurso virtual, se cargan a la meta-ontologıa todas las ontologıas,i.e., se cargan las ontologıas HumanResource, Departments, Position, PhysicalRe-source y VirtualResource, lo cual se debe a que un recurso virtual esta almacenadoen un recurso fısico y, en caso de que el usuario requiera la localizacion fısica delrecurso virtual, hay que buscar en donde se encuentra almacenado.

76

Capıtulo

6 Conclusiones y trabajo a fu-turo

En este capıtulo primeramente se resume el problema planteado para presentar lasconclusiones y contribuciones a las que se llegaron a partir de la solucion propuestaen esta tesis. En la seccion 6.1 se realiza una breve recapitulacion del problemaplanteado. Posteriormente, en la seccion 6.2 se exponen las conclusiones y con-tribuciones que se alcanzaron mediante el desarrollo de la propuesta planteada.Finalmente en la seccion 6.3 se plantean ideas para mejorar el algoritmo de coin-cidencia semantico que se desarrollo.

6.1. Recapitulacion del problema

Dentro de una organizacion existe una gran diversidad de recursos, los cuales son degran importancia para que una persona o equipo de trabajo realice sus actividadesdiarias. Actualmente existen diversos trabajos para la localizacion de servicios Weba traves de los cuales se puede generar una solucion para la busqueda de recursosdentro de una organizacion. Anteriormente se crearon posibles soluciones para esteproblema, pero unicamente se dedican a la localizacion fısica de recursos, dejandode lado las condiciones del medio ambiente y la interaccion entre las personasque forman parte de dicha organizacion. Estos factores pueden alterar de maneraimportante la disponibilidad de un recurso en cualquier momento.

6.2. Conclusiones y contribuciones

Para resolver el problema de descubrimiento y comparticion de recursos, se disenola arquitectura RAMS, la cual cuenta con un algoritmo de coincidencia semanticobasado en contexto. El objetivo de dicho algoritmo es resolver el problema de lo-calizacion de recursos bajo el contexto colaborativo que brinda una organizacion.Por otro lado, la arquitectura RAMS cuenta con una base de conocimiento de on-tologıas, las cuales fueron apropiadamente disenadas para considerar el contextocolaborativo dentro de una organizacion, i.e., las relaciones que existen entre losempleados de dicha organizacion, ası como las restricciones con las que los provee-dores limitan el uso de los recursos que tiene a su cargo. Con base a las ontologıaspreviamente mencionadas, se crearon preferencias de disponibilidad y restriccionesde contexto, los cuales permiten al usuario manipular la disponibilidad de sus re-cursos, a traves de las relaciones de trabajo y/o personales que ha establecido consus companeros.

77

En este trabajo se desarrollo el algoritmo de coincidencia semantico basadoen contexto disenado principalmente para su uso en la arquitectura RAMS. Elalgoritmo extrae la informacion que necesita de las ontologıas de la arquitecturaRAMS para localizar los recursos adecuados. Mediante las relaciones que se esta-blecen en ellas podemos generar las preferencias de disponibilidad y restriccionesde contexto que el usuario desee. Las preferencias de disponibilidad permiten sa-ber si un usuario tiene permitido utilizar un recurso, si el encargado de un recursose encuentra en el mismo lugar para poder accederlo o bien si dicho recurso noesta siendo utilizado actualmente (estado ideal). Por otro lado, las preferencia decontexto nos permiten definir en que actividad, equipo de trabajo, rol o ubicacionfısica se encuentra el recurso en un momento dado.

Este algoritmo fue modificado para mejorar los resultados obtenidos en labusqueda de recursos, por lo que se le agrego el uso de similitud semantica, lacual fue posible a traves de las clases que conforman las ontologıas. Mediante estasimilitud semantica, el algoritmo puede mostrar al usuario mas opciones de recur-sos que pueden ser de su interes. Para obtener los mejores resultados, el algoritmobasa su busqueda en las caracterısticas tecnicas del recurso, su similitud con otrosrecursos, ası como las preferencias de disponibilidad y restricciones de contexto enlos que se encuentra dicho recurso.

Mediante las preferencias de disponibilidad y restricciones de contexto, se pu-do mejorar la busqueda del usuario. Las restricciones propuestas en el algoritmode coincidencia permiten que los resultados de la busqueda se asemejen a la vi-da real porque permiten agregar restricciones y relaciones personales. Tambien seusa la coincidencia sintactica en las caracterısticas tecnicas, ası como la similitudsemantica para buscar recursos similares o que cuenten con caracterısticas semejan-tes. Debido a estos factores pudimos obtener una precision y exhaustividad alta,i.e., casi 1 en ambos casos, representado un alto ındice de recursos importantesobtenidos.

6.3. Trabajo a futuro

En este trabajo se desarrollo un algoritmo de coincidencia semantico basado en uncontexto colaborativo, con la finalidad de mejorar la localizacion y comparticionde recursos. Si bien el diseno y desarrollo se han concluido, a continuacion serecomiendan algunas ideas para mejorar dicho algoritmo y su uso:

Permitir al usuario que la consulta sea mas natural, i.e., el uso de lenguajenatural para redactar las consultas podrıa mejorar la interaccion entre laaplicacion que explota el algoritmo de coincidencia y el usuario.

Analizar el uso de una arquitectura base como la Grid con el fin de estudiar si

78

mejorara el desempeno de la arquitectura RAMS y sobre todo del algoritmode coincidencia semantico.

Unir el algoritmo de coincidencia desarrollado con el resto de los moduloscreados para la arquitectura RAMS, realizar las pruebas pertienentes y me-jorar su acoplamiento.

Agregar el uso de reglas SWRL al final de la consulta para apartar los recursosseleccionados por el usuario y evitar que sean utilizados por otras personas.

Definir un mejor tipo de datos para las propiedades de datos de cada clase,con el fin de mejorar las consultas de las caracterısticas tecnicas.

Agregar permisos que mejoren el contexto colaborativo del algoritmo a travesde las relaciones establecidas previamente en las ontologıas, e.g., si la personaA es colega de B, A puede utilizar algunos o los mismos recursos a los que Btiene acceso.

Analizar nuevamente la jerarquizacion de las ontologıas PhysicalResource yVirtualResource para averiguar si se puede mejorar la similitud semanticaentre los recursos de cada una de las ontologıas y entre ellas.

79

80

Anexo

AOntologıas

A partir de la aparicion de la Web 2.0 o Web Semantica, las investigaciones enInformatica se han centrado en ella, particularmente en la ingenierıa del conoci-miento para el uso y administracion de ontologıas. En el area de la Informatica, sudefinicion difiere de la que previamente se habıa dado en el area de la Metafısica.

Segun Studer et al. [44] una ontologıa es “una especificacion formal explıcitade una conceptualizacion compartida”que se refiere a un modelo abstracto forma-do por los conceptos de una entidad en el mundo y que dichos conceptos sean deconocimiento entendible por diferentes tipos de personas. La definicion mas refe-renciada es la de Gruber et al. [14] quien dice que “es la conceptualizacion de unaabstraccion, un punto de vista simplificado del mundo que deseamos representarpara algun proposito. Cada base de conocimiento, sistema basado en conocimiento,o agente de nivel de conocimiento esta basado en alguna conceptualizacion explıcitao implıcita. Una ontologıa es una especificacion explıcita de una conceptualizacion.El termino es seguido de una filosofıa, donde una ontologıa es un sistema basa-do en la existencia. Para los sistemas de Inteligencia Artificial, lo existente es loque debe de ser representado”. De estas definiciones podemos deducir que la metade las ontologıas es alcanzar un conocimiento comun y compartido que pueda sertransmitido entre personas y sistemas. Ademas, las ontologıas facilitan la comu-nicacion en sistemas distribuidos porque les permite cooperar entre ellos, aunqueno se hayan disenado para este fin, y tambien permite la inteoperabilidad entreorganizaciones y la Web Semantica.

Segun Guarino [45] los tipos de ontologıas que existen (ver Figura 1) son: dealto nivel, de dominio, de tarea y de aplicacion. Las ontologıas de alto nivel descri-ben conceptos muy generales (e.g., tiempo y espacio) y son independientes de undominio o problema en particular. Las ontologıas de dominio describen el vocabu-lario de un dominio generico (e.g., medicina) para especializar los terminos de unaontologıa de alto nivel. Las ontologıas de tarea describen el vocabulario de unatarea generica o actividad (e.g., diagnostico de enfermedades) para especializar losterminos de una ontologıa de alto nivel. Finalmente, las ontologıas de aplicaciondescriben conceptos especializados, con base en las ontologıas de dominio y detarea. Por lo tanto, mientras mas generales son las ontologıas, resultan mas inde-pendientes del dominio; por el caso contrario, si son mas especıficas dependen masdel dominio.

Las ontologıas se componen principalmente por cuatro elementos:

Concepto: tambien conocido como clase o termino. Es un grupo, conjun-to o coleccion abstracta de objetos, cuyos miembros poseen propiedades en

81

Figura 1: Tipos de ontologıas

comun. Generalmente posee una super-clase (o clase padre) y una o massubclases (clases hijo).

Individuo: tambien conocido como instancia. Es el componente de nivel masbajo. Representa un objeto o elemento especıfico de una clase.

Propiedad: tambien conocida como relacion. Expresa un vınculo entre dosconceptos y representa un rango. Puede ser de tipo propiedad de dato, deobjeto o de anotacion.

Axioma: impone restricciones de valores a las clases o instancias, por loque es expresado usando lenguajes basados en logica (e.g., logica de primerorden). Es utilizado para verificar la consistencia de una ontologıa.

Los tipos de propiedades o relaciones que existen en una ontologıa son:

Taxonomicas: relaciones is a (es un) que permiten formar jerarquıas entrelas clases de una ontologıa.

Profesor textes una Persona

Entre clases, individuos o entre un individuo y una clase.

Alumno texttoma clase Profesor

Inversas: relaciones opuestas al tipo de relacion anterior.

Profesor da clase Alumno

82

Transitivas: relacion donde siempre que un elemento se relaciona con otroy este ultimo con un tercero, entonces el primero se relaciona con el tercero.

A es companero de B ∧ B es companero de C

→ A es companero de C

Simetricas: relacion donde si un elemento esta relacionado con otro, y esteultimo esta relacionado con el primero.

A es companero de B → B es companero de A

Funcionales: relacion que cumplen con la condicion de existencia y unicidad.

Profesor le correponde un solo Jefe de Departamento

Los axiomas modelan una proposicion o sentencia que siempre es verdad, por lotanto proveen un significado adicional al conocimiento generado por una ontologıa.Algunos axiomas embebidos en las clases se generan a traves de clases disjuntaso clases equivalentes. Si A y B son clases disjuntas, entonces un elemento de Ano puede ser elemento de B simultaneamente. Cuando las clases A y B tienen lasmismas instancias se deniminan clases equivalentes. Las ontologıas nos permitentomar en cuenta conocimiento implıcito en las anotaciones durante el proceso deconsulta. Este conocimiento se encuentra a traves de enlaces de subsuncion entretipos de conceptos (clases) y tipos de relaciones (e.g., relaciones distintivas, axiomaso reglas de deduccion).

Para representar ontologıas dentro de un sistema de informacion, se estable-cio un lenguaje por el consorcio W3C para mantener un orden en dichas ontologıas.OWL (Web Ontology Language) cuenta con RDF (Resource Description Frame-work) y RDF Schema (RDFS) que permiten representar y describir los conceptosde un dominio mediante relaciones taxonomicas y jerarquicas de conceptos. OWLes uno de los lenguajes con mayor capacidad expresiva, por lo que se ha convertidoen un estandar para realizar anotaciones de ontologıas en la Web.

La ingenierıa ontologica se encarga de realizar la representacion de un dominio,de forma que capture las distinciones relevantes al mas alto nivel de abstraccion,siendo lo mas claro posible y manteniendo el significado de los terminos. La inge-nierıa ontologica establece que una ontologıa debe ser:

Reutilizables: una ontologıa debe contar con la capacidad de adaptacion acontextos de aplicacion arbitrarios, incluyendo aquellos que no fueron pre-vistos al momento de su creacion.

83

Usables: denota el grado en el que una ontologıa es util para una tarea oaplicacion especifica. El termino tambien tiene la connotacion de facilidadde uso, refiriendose al esfuerzo requerido por un usuario para utilizar dichaontologıa.

Los razonadores son aplicaciones computacionales que permiten realizar infe-rencias (deducciones) y generar conocimiento a partir de un conjunto de axiomasy hechos. Los razonadores utilizan un motor de inferencias y un conjunto de reglasexpresadas en un lenguaje semantico como OWL. El proceso de inferencia constade:

Estado inicial: denota la situacion original de un problema.

Estados finales: representan las situaciones y objetivos que se pretendenalcanzar.

Estados intermedios o memoria de trabajo: contienen la descripcionde la resolucion en curso. La ejecucion de las reglas modifica este estado yanade o elimina hechos.

El proceso de inferencia usa reglas para describir los elementos de deduccionbasica que utilizara un sistema. La forma mas sencilla de representacion es deltipo:

Si condiciones Entonces acciones

Una regla esta formada por un cuerpo y una cabeza; el cuerpo es la parteantecedente y la cabeza la parte consecuente. Tanto el cuerpo como la cabezaconsisten solamente de conjunciones positivas de atomos:

atom ∧ atom · · · → atom ∧ atom

Un atomo es una expresion de la forma:

p(arg1, arg2, · · · argn)

Donde:

p es un sımbolo de predicado.

arg1, arg2, · · · , argn son los terminos o argumentos de la expresion.

Los sımbolos de predicados pueden incluir clases, propiedades o tipos de datos.Los argumentos pueden ser individuos o valores de datos, o variables refiriendosea estos.

Un atomo de clase consiste de una clase nombrada en OWL o una expresionde clase y un argumento unico que representa a un individuo OWL:

84

Person(?p)

Man(Fred)

Donde:

Person y Man son clases nombradas.

p es una variable que representa un individuo.

Fred es el nombre de un individuo.

Los atomos de propiedades individuales consisten de un objeto de propiedadOWL y dos argumentos que representan individuos OWL.

hasBrother(?x, ?y)

hasSibling(Fred, ?y)

Donde:

hasBrother y hasSibling son propiedades de objetos OWL.

?x y ?y son variables que representan individuos OWL.

Fred es el nombre de un individuo.

A continuacion se muestra un ejemplo de una regla SWRL, donde una personacon la propiedad “tiene un hermano” requerirıa capturar los conceptos de persona,femenino, hermano de y hermana de en OWL. Los conceptos de persona y masculinopueden capturarse utilizando una clase llamada Person con una subclase Man. Lasrelaciones de hermana y hermano de pueden expresarse utilizando las propiedadesde objetos de OWL hasSibling y hasBrother con un dominio y rango dePerson.

Person(?p) ∧ hasSibling(?p, ?s) ∧ Man(?s) → hasBrother(?p, ?s)

El uso de SWRL permite crear reglas dentro de la ontologıa que se le indica,por el contrario, las consultas SQWRL unicamente realizan la consulta y muestranlos resultados sin afectar la ontologıa en uso. La ventaja de utilizar SQWRL esque permite el uso de Built-Ins, que es la representacion de una URL que necesitela consulta SQWRL. A continuacion se muestran los Built-In que necesita unaconsulta dentro de su encabezado para poder ejecutarse de manera adecuada:

85

rdf = http://www.w3.org/1999/02/22-rdf-syntax-ns#rdfs = http://www.w3.org/2000/01/rdf-schema#xsd = http://www.w3.org/2001/XMLSchema#

owl = http://www.w3.org/2002/07/owl#sqwrl = http://sqwrl.stanford.edu/ontologies/built-ins/3.4/sqwrl.owl#

Despues de haber agregado los Built-in necesarios, se puede redactar la consultaSQWRL; por ser descendiente de las reglas SWRL se escribe de manera muysimilar:

Person(?p) − > sqwrl : select(?p)

Donde:

Person es el nombre de una de las clases de la ontologıa.

?p se refiere al individuo que estamos buscando.

− > es la parte consecuente que se va a ejecutar despues de haber analizadola consulta de la parte antecedente.

sqwrl es el Built-in que nos permite usar la funcion select.

select es el nombre del Built-in que nos permite obtener el individuo que seencuentra dentro de los parentesis, en este caso ?p.

86

Publicaciones del autor

S. Velasco, S. Mendoza, K. Garcia, D. Decouchant, A User Restrictions-Based Se-mantic Matchmaking Service for Resource Discovery, en 2014 11th InternationalConference on Electrical Engineering, Computing Science and Automatic Control(CCE 2014), IEEE, pp. 240-245, Mexico, 29 Septiembre-3 Octubre 2014.

K. Garcia, S. Velasco, S. Mendoza, D. Decouchant,A Semantic Approach to SharedResource Discovery, en Proceedings 20th International Conference (CRIWG 2014),Springer International Publishing, Vol. 8658, pp. 137-152, Chile, 7-10 Septiembre2014.

K. Garcia, S. Velasco, S. Mendoza, D. Decouchant, A Matchmaking Algorithm forResource Discovery in Multi-user Settings, en 2014 IEEE/WIC/ACM Internatio-nal Joint Conferences on Web Intelligence (WI) and Intelligent Agent Technologies(IAT), IEEE, Vol. 3, pp. 352-359, Polonia, 11-14 Agosto 2014.

87

Bibliografıa

[1] K. Garcia, M. Kirsch-Pinheiro, S. Mendoza, D. Deccouchant. An ontologicalmodel for resource sharing in pervasive environments. In 2013 IEEE/WI-C/ACM International Conference on Web Intelligence (WI’2013), volume 1,pages 179–184, Atlanta, Georgia, USA, November 18-20 2013. IEEE.

[2] V. Suraci, S. Mignanti, A. Aiuto. Context-aware semantic service discovery. In16th IST Mobile and Wireless Communication Summit, pages 1–5, Budapest,Hungary, July 1-5 2007. IEEE Computer Society.

[3] A. Toninelli, A. Corradi, R. Montanari. Semantic-based discovery to supportmobile context-aware service access. Computer Communications, 31(5):935–949, 2008.

[4] T. Kawamura, T. Hasegawa, A. Ohsuga, M. Paolucci, K. Sycara. Web serviceslookup: A matchmaker experiment. IT Professional, IEEE Computer Society,7(2):36–41, March-April 2005.

[5] P. Patel, S. Chaudhary. Context aware semantic service discovery. InSERVICES-2 ’09. World Conference on Services - II, pages 1–5, Bangalo-re, India, September 21-25 2009. IEEE.

[6] C. A. Collazos, J. Mendoza. Como aprovechar el “aprendizaje colaborativo”en el aula. Educacion y Educadores, 9(2):61–76, 2006.

[7] J. Sanchez. Trabajo colaborativo. http://mmpchile.c5.cl/pag/press/TrabajoAccessed: 09-06-2014.

[8] I. Greif. Computer-supported Cooperative Work: A Book of Readings. MorganKaufmann Publishers, 1988.

[9] C. A. Ellis, S. J. Gibbs, G. Rein. Groupware: Some issues and experiences.Communications of the ACM, 34(1):39–58, January 1991.

[10] M. Weiser. The computer for the 21st century. Computer Communications,265(3):19–25, 2002.

[11] E. C. Siddarth. A context aware ontology based middleware framework forservice discovery. IJCSNS International-Journal of Computer Science andNetwork Security, 9(3):61–71, 2009.

89

[12] S. Najar, O. Saidani, M. Kirsch-Pinheiro, C. Souveyet, S. Nurcan. Semanticrepresentation of context models: A framework for analyzing and understan-ding. In CIAO ’09 Proceedings of the 1st Workshop on Context, Informationand Ontologies, New York, NY, USA, June 1 2009. ACM.

[13] R. Chen, X. Shi, W. Han. Process-context aware matchmaking for web servicecomposition. Journal of Network and Computer Applications, 31(4):559–576,November 2008.

[14] T. R. Gruber. A translation approach to portable ontology specifications,April 1993.

[15] D. Benslimane, A. Arara, G. Falquet, Z. Maamar, P. Thiran, F. Gargouri.Contextual ontologies. In 4th International Conference, ADVIS 2006, volume4243, pages 168–176, Izmir, Turkey, October 18-20 2006. Springer.

[16] OWL Working Group. Owl web ontology language guide.http://www.w3.org/TR/owl-guide/. Accessed: 09-06-2014.

[17] RDF Working Group. Resource description framework (rdf).http://www.w3.org/RDF/. Accessed: 17-05-2014.

[18] W3C. Rdf schema 1.1. http://www.w3.org/TR/rdf-schema/. Accessed: 17-05-2014.

[19] O’Reilly Media and MediaLive International, Inc. Web 2.0 conference.http://web.archive.org/web/20040602111547/http://web2con.com/. Acces-sed: 17-05-2014.

[20] W3C. Semantic web. http://www.w3.org/2001/sw/. Accessed: 16-08-2014.

[21] O. Corby, R. Dieng-Kuntz, F. Gandon, C. Faron-Zucker. Searching the seman-tic web: Approximate query processing based on ontologies. IEEE InteligentSystems, 21(1):20–27, 2006.

[22] M. Senvar, A. Bener. Matchmaking of semantic web services using semantic-distance information. In Advances in Information Systems, volume 4243, pages177–186, Berlin, Heidelberg, October 18-20 2006. Springer.

[23] M. Paolucci, T. Kawamura, T. R. Payne, K. Sycara. Semantic matching ofweb services capabilities. In First International Semantic Web Conference,volume 2342, pages 333–347, Sardinia, Italy, June 9-12 2002. Springer.

[24] P. Fu, S. Liu, H. Yang, L. Gu. Matching algorithm of web services based onsemantic distance. In 2009 International Workshop on Information Security

90

and Application (IWISA 2009), pages 465–468, Qingdao, China, November21-22 2009. Journal of Beijing University of Technology.

[25] F. Zhu, M. W. Mutka, L. M. Ni. Service discovery in pervasive computingenvironments. IEEE Pervasive Computing, 4(4):81–90, 2005.

[26] M. Klusch, B. Fries, K. Sycara. Owls-mx: A hybrid semantic web servicematchmaker for owl-s services. Web Semantics: Science, Services and Agentson the World Wide Web, 7(2):121–133, 2009.

[27] G. Muehl, L. Fiege, P. Pietzuch. Distributed Event-Based Systems. Springer-Verlag, 2010.

[28] ESSI WSMO working group. Web service modeling ontology.http://www.wsmo.org/. Accessed: 16-08-2014.

[29] OWL Working Group. Owl-s: Semantic markup for web services.http://www.w3.org/Submission/OWL-S/. Accessed: 17-05-2014.

[30] P. Bellavista, A. Corradi, R. Montanari, C. Stefanelli. Context- aware midd-leware for resource management in the wireless internet. IEEE Transactionson Software Engineering, 29(12):1086–1099, 2003.

[31] Clark & Parsia. Pellet: Owl 2 reasoner for java.http://clarkparsia.com/pellet/. Accessed: 16-08-2014.

[32] The Apache Software Foundation. Apache jena. https://jena.apache.org/.Accessed: 16-08-2014.

[33] B. Benz. XML Programming Bible. John Wiley Sons, 2004.

[34] N. Srinivasan, M. Paolucci, K. Sycara. An efficient algorithm for owl-s ba-sed semantic search in uddi. In Semantic Web Services and Web ProcessComposition, volume 3387, pages 96–110, San Diego, CA, USA, July 6 2005.Springer.

[35] Sandia National Laboratories. Jess. http://www.jessrules.com/. Accessed:16-08-2014.

[36] G. Papamarkos, A. Poulovassilis, P. T. Wood. Event-condition-action rule lan-guages for the semantic web. In EDBT 2006 Workshops PhD, DataX, IIDB,IIHA, ICSNW, QLQP, PIM, PaRMA, and Reactivity on the Web, volume4254, pages 309–327, Munich, Germany, March 26-31 2003. Springer.

91

[37] M. Paolucci, T. Kawamura, T. R. Payne, K. Sycara. Semantic matching ofweb services capabilities. In First International Semantic Web Conference,volume 2342, pages 333–347, Sardinia, Italy, June 9-12 2002. Springer BerlinHeidelberg.

[38] K. Garcıa. Ascertaining the Availability of Shared Resources in UbiquitousCollaborative Environments. PhD thesis, CINVESTAV-IPN, Zacatenco, 2013.

[39] K. Garcıa, S. Mendoza, D. Decouchant, J. Rodrıguez, T. Perez. Determinin-gandlocating the closest available resources to mobile collaborators. ExpertSystems with Applications, Elsevier, 40(7):2511–2529, June 2013.

[40] A. K. Dey, G. D. Abowd. A conceptual framework and a toolkit for suppor-ting the rapid prototyping of context- aware applications. Human-ComputerInteraction, 16(2):97–166, December 2001.

[41] A. B. Bener, V. Ozadali, E. S. Ilhan. Semantic matchmaker with preconditionand effect matching using swrl. Expert Systems with Applications, El Sevier,36(5):9371–9377, 2009.

[42] J. S. Martınez Delgado. Soporte multimodal para el filtrado de informacionen sistemas colaborativos. PhD thesis, CINVESTAV-IPN, Zacatenco, 2012.

[43] S.J.H. Yang , J. Zhang, I.Y.L. Chen. A jess-enabled context elicitation sys-tem for providing context-aware web services. El Sevier Expert Systems withApplications, 34(4):2254–2266, 2007.

[44] R. Studer, V. R. Benjamins, D. Fensel. Data & knowledge engineering: prin-ciples and methods. Data & Knowledge Engineering, 25(1-2):161–197, 1998.

[45] N. Guarino. Formal ontology in information systems. In Proceedings ofFOIS’98, pages 3–15, Trento, Italy, June 6-8 1998. IOS Press.

92

CENTRO DE INVESTIGACION Y DE ESTUDIOS AVANZADOS DEL … · 2014-12-02 · y Marco porque desde el...

Documents

Transcript of CENTRO DE INVESTIGACION Y DE ESTUDIOS AVANZADOS DEL … · 2014-12-02 · y Marco porque desde el...