The THOMAS Architecture: A Case Study in Home Care Scenarios.
Sara Rodríguez
Una aplicación de Thomas para la monitorización de personas dependientes, tanto en sus domicilios como en unidades especializadas, como residencias o centros de día. Empieza explicando la arquitectura Thomas, que por razones obvias me voy a saltar :-)
¿Cómo se ha aplicado Thomas a este problema? Se plantea la conexión entre los pacientes, su entorno y el personal médico. Se han identificado 4 roles: paciente, médico, proveedor (genérico) y familiar. El segundo paso es la definición de la estructura organizacional. Se han identificado 3 suborganizaciones: homecare, localization y alert. Una vez especificados, se identifican los servicios que se proporcionan. Por último, se definen las reglas que establecen las acciones que los agentes pueden realizar dentro del sistema y los servicios que pueden/deben solicitar/proporcionar.
A continuación analizan varios escenarios. Se asume que al principio la organización está vacía (vaya, ya no se puede implementar esto con la versión sobre Magentix2 :-(
Alberto
Coordinación de servicios en entornos abiertos: identificación de necesidades, localización y selección del proveedor, negociación de los términos e invocación. Se centra en la parte de descubrimiento. Habitualmente se emplea el mismo lenguaje para describir y solicitar servicios, pero incluso así se encuentran diferencias semánticas.
Su trabajo busca incluir técnicas de alineamiento semántico dentro de un dominio de búsqueda de servicios. El alineamiento semántico se debe realizar en dos niveles: conceptos y el propio lenguaje de descripción de servicios. Pero en el primero son simples usuarios. Así que se centran en el alineamiento de modelos. Los servicios pueden describirse c on multitud de lenguajes: OWL-S WSMO, WSDL, SAWSDL… De todos ellos se ha buscado un conjunto común que permite mapear de los distintos lenguajes a este lenguaje común y, a partir de ese momento, emplearlo como lenguaje. Una vez tenemos los modelos alineados, debe establecerse el grado de encaje (matching) entre la descripción y la solicitud, habitualmente empleando relaciones de subsumpción y distancia semántica. El resultado es una categorización con un valor entre 0 y 1 que define el grado de similitud entre ambos.
Cosas interesantes abiertas: (i) posiblemente cuando alguien desea un servicio no sabe cuales son sus entradas. Se sabe qué quiero, pero no qué necesito. Eso obligaría a un proceso de dos fases: primero indico qué necesito, el proveedor indica qué datos debo facilitarle para conseguirlo y luego el cliente selecciona el servicio en función también de la información que tiene disponible. Más cosas abiertas son el distribuir la gestión de los servicios (hablar con Alberto de lo que estamos haciendo Elena y yo). Enriz hace preguntas interesantes: palabras clave que son realmente clave, o poder establecer preferencias en la selección del servicio. Como estamos usando cosas que ya están hechas y simplemente somos clientes de la parte semántica, sería interesante plantear alguna de estas cosas. Creo que alguna de ellas no sería difícil.
J. Santiago Pérez
¡Hombre, si existen!… era bromita. Van a hablar de ??? ¿de qué van a hablar? Ah, parece que es un enfoque orientado a organizaciones para resolver problemas de coordinación entre agentes. La propuesta para coordinar roles y servicios entre organizaciones usa la noción de acuerdos. Fases
- una arquitectura para un MAS orientado a servicios y soportado por organizaciones
- definir una metodología con la organización como nexo entre servicios y agentes y
- proporcionar coordinación interna basada en la noción de acuerdo.
Emplea la organización como base para la composición de servicios, o más bien como la descomposición funcional de servicios lleva a una estructura organizacional: el workflow de un servicio compuesto define la jerarquía entre distintas organizaciones (ups, pero la parte interesante es la inversa, como a partir de servicios individuales las organizaciones pueden emerger de coreografías de servicios). Su aportación: cambiar la «tarta» por un pentágono :-S
Un caso de estudio: lo fundamental: poner la palabra «agreement» muchas veces. Ya casi ha terminado y no ha contado nada. No voy a preguntar ni a pasarme, porque el que presenta no tiene la culpa del morro de sus «jefes». (NOTA: escribir esto un poco más polite)
M. Rebollo
Me ha tocado a mi. Y me han metido caña con lo del CSP.
J. Durán
Define patrones para la clasificación de acuerdos. Tres dimensiones: fase (selección, negociación, ejecución…), duración, tópico (provisión de servicios o uso de bienes), normativo y de tomas de decisiones. Estructura del patrón nombre y alias definición del problema y sus objetivos ejemplos de dominios (aplicaciones que justifican la necesidad de un patrón) contexto (precondiciones a la solución) contexto resultante (postcondiciones) fuerzas (elementos relacionados con la decisión) participantes (roles que participan) solución patrones relacionados
Pone como ejemplo el problema de selección de un servicio
Jorge
Este también me lo sé, pero bueno :-) Se trata de definir un modelo de organización virtual usando MDD de forma que es pueda definir un modelo de organización que permita luego su implementación sobre diversas plataformas. Empieza hablando de organizaciones virtuales y MDD. La aportación es que, aunque hay metodologías de diseño de agentes que usan MDD, ninguna utiliza esta técnica para modelar la organización.
Los metamodelos de pi-VOM (cachondeo con el nombre :-D) se dividen en 6 visiones: estructura, funcionalidad, dinámica, normativa y entorno. Después de ver los modelos, explica las reglas de transformación de PIM a Thomas y e-institutions como PSM.
Acaba mostrando su aplicación a un ejemplo rarísimo… una agencia de viajes ;-)
Ramón
Acuerdos basados en la reputación. La visión típica actual es la de ver cómo las mediadas de reputación se comparten o se transmiten en una red (pero sigue siendo una medida ‘personal’ del agente). Sin embargo, en aplicaciones ‘reales’ existen medidas globales de reputación (como en eBay o TripAdvisor) a partir de las opiniones de los usuarios individuales.
La idea es disponer de un mecanismo de reputación dentro de la organización que recoja las opiniones de los agentes. Y esta información (i) se emplea para definir acuerdos; y (ii) los agentes puedan recibir información sobre los acuerdos que se han alcanzado.
Define los valores de reputación sobre situaciones, que son tuplas S=(Ag,R,Ac,T), que modelan a un agente Ag desempeñando un rol R para una acción AC durante un periodo T. La reputación se informa enviando mensajes formados por una tupla que contiene Y estas valoraciones permiten construir acuerdos basados en la reputación.
Propiedades
- completo: todos los participantes han participado
- alpha-consistence: homogeneidad de la información (valores altos)
- completitud: es completo y es 1-consistente
- consistencia de rol: todos los agentes que participan tienen el mismo rol (busco opinión de agentes como yo)
- XXX (me falta esta!!)
- completitud de rol: si es r-completo y 1 consistente
Inciso: Carlos y yo no estamos muy seguros de que el nombre de agreement para esto sea el mejor.
Acaba con casos de aplicación de RBA. Uno de los más interesantes es cómo solucionar el problema de arranque en frío cuando un agente llega a un sistema por primera vez y no tiene contactos (medidas de reputación) ni experiencias pasadas.
