![]() |
![]() |
![]() |
![]() |
![]() |
|
|
||||
Descripción generalArquitectura desarrolladaDescripción del prototipo propuestoDocumentosDocumentos anexos del trabajoSWSEjemplos de diferentes descripciones de SWSEmparejamiento SemánticoConceptos más importantes del emparejamientoEmparejamientoGrados de similitudAlgoritmo utilizadoOntologíasDiferentes ontologías empleadas en las descripciones de SWS y en las comparaciones realizadas por el emparejador semánticoONTOSERVICEOtrosMemoria y otros documentos de interés |
Concepto de emparejamiento semántico El sistema de localización o de descubrimiento de servicios, debe estar basado en un emparejamiento semántico de las capacidades y descripciones de los SW.
El concepto de emparejamiento semántico consiste en la búsqueda de dos descripciones de servicios con propiedades similares o exactamente las mismas. Este tipo de emparejamiento tiene a su favor respecto al emparejamiento implementado por sistemas basado en XML la independencia de contexto. En la tarea de buscar un servicio individualmente o buscar un servicio que forma parte de un proceso de la Web es importante que las entradas y las salidas del servicio del candidato emparejen a las exigidas por el consumidor. La aproximación más común es utilizar ontologías para describir el servicio requerido. De acuerdo con esta aproximación, la mayoría de investigación se ha hecho en esta área. Este proceso de emparejar consiste en el proceso de podar el espacio de posibles emparejamientos entre posibles servicios ofertados y peticiones. Un servicio de match requiere tanto metadatos ricos y flexibles como algoritmos de emparejamiento. El proceso general que se sigue en el emparejamiento de servicios ofertados y requeridos se basa en que cuando un agente envía una petición a un agente matchmaker o emparejador, éste le devolverá posteriormente como resultado, información respecto al servicio que mejor se adapta a la descripción dada en el requerimiento. Esta información incluirá las IOPEs (Inputs, Outputs, Preconditions, Effects) las cuales están reflejadas en el perfil del servicio así como información adicional de parámetros de servicio, información del proveedor etc, las cuales el proveedor del servicio habrá comunicado con anterioridad al matchmaker. De esta forma si como resultado hay varias correspondencias, entonces el cliente que solicita el servicio (o el agente en su lugar) puede usar esta información para refinar su elección de servicio a usar. Haciendo uso de esta información suplementaria permitirá a los clientes restringir su búsqueda, especificando la categoría de servicio (B2B, B2C etc.), recursos que pudiera recurrir, grado de calidad del servicio etc. Aparece por tanto un conjunto extensible de parámetros de servicio, que restringen la búsqueda, alcanzando el objetivo de que los servicios devueltos satisfagan las necesidades. En la práctica el cliente debería ya conocer las IOPEs y lo que no sabrá es el tipo de proceso, si será atómico o por el contrario se tratará de una composición de servicios en cuyo caso habrá que realizar pasos intermedios que consultarán el modelo de proceso para identificar el flujo de trabajo desde la entrada a la salida (con la posibilidad de que la salida de un proceso intermediario sea usada como entrada en el siguiente proceso atómico en la secuencia dada) hasta que todos los procesos involucrados sean ejecutados. Por tanto los agentes que realizan la petición de servicio, deberán ser capaces de interpretar el contenido de la ontología de proceso y el grounding para poder comunicarse con un agente proveedor de tal servicio. La idea principal que subyace en la aproximación de emparejamiento viene dada por la búsqueda de un servicio basada en el tópico o categoría y después en el uso de los parámetros de salida etc. El problema tal y como apuntaba Massimo Paolucci es que el uso de categorías de servicio puede no tener significado si las categorías permitidas en la ontología son demasiado amplias. Por otra parte, para dotar de significado se necesitará especificar muchas clases diferentes, una por cada tipo de servicio. El uso de los parámetros de entrada y salida permitirán solventar este problema, permitiendo una definición implícita de los servicios. Esto requerirá el uso de ontologías menos precisas, aunque por el contrario requerirán de descripciones de servicios más esmeradas y un proceso de emparejamiento más complejo. La idea por tanto es soportar ambos tipos de emparejamiento, debido al resurgimiento de grandes ontologías y clasificaciones de servicios. Como afirma David Martin, en la jerarquía de clases que refleja los diferentes tipos de servicios, existe la posibilidad de introducir propiedades adicionales, específicas para cada tipo de servicio, de manera que estas propiedades podrían ser usadas para establecer la correspondencia. Lei y Horrocks describen algunos problemas derivados del diseño de la especificación de un perfil de servicio. Ellos afirman que mediante éste, se puede dar demasiada información acerca de un servicio de tal forma que esto puede dificultar el uso de un razonamiento automático que procese los emparejamientos entre descripciones semánticas. David Martin como respuesta a este problema, afirma que para solucionarlo se requiere que se den algunas convenciones:
Limitando la búsqueda semántica de servicios a estas convenciones se restringe de manera notable su funcionalidad. El uso de anuncios lo más generales posibles que engloben la mayoría de requerimientos dados para un determinado tipo de servicio, dejará fuera bajo estas restricciones a algunos servicios en los que el cliente también pueda haber estado interesado, como por ejemplo servicios mucho más restrictivos o servicios con características similares pero con distintos valores para las propiedades de las restricciones. Thomi Piliora et al. establecen los requerimientos que se han de tener en cuenta en el proceso de emparejar. Los autores afirman que deberían de ser tratados tanto aspectos sintácticos como semánticos, pero que primero debería examinarse la compatibilidad semántica antes que la sintáctica debido a la necesidad de que la petición y el anuncio de servicio deben de "hablar" del mismo tema. |
|||
| Mas información: Webmaster |
Tesis Doctoral: Ontologías para servicios Web semánticos de información de tráfico:Descripción y herramientas de explotación |
|||