Concepto de emparejamiento semántico 98

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 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 [Pay01].

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., que el proveedor del servicio habrá comunicado con anterioridad al matchmaker.20 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,

20

Si las peticiones son expresadas en un formato diferente de las realizadas en el anuncios surgirá la necesidad de transformarlas en algún punto del proceso: en el registro de anuncios haciendo que éste acepte y sea capaz de reconciliar las diferencias entre múltiples formatos, en la parte del cliente compilando la petición en algún formato y posteriormente convirtiéndola en el lenguaje de descripción utilizado, o por último en la etapa de transporte, por la acción de intermediarios entre el cliente y el registro.

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 [Pay02] [Mar02].

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 en [Mar02] 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, serán necesarias 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 en [Lei03], 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 en [Mar03] como respuesta a este problema, afirma que para solucionarlo se requiere que se den algunas convenciones:

1) Que el proveedor exprese una clase de servicios usando una expresión lo más general posible.

2) Que el cliente exprese una petición para encontrar el servicio que desea usando una expresión lo más específica que pueda.

3) Cuando un cliente no tenga en cuenta el modo de restringir una propiedad, su petición deberá expresar esta situación.

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. [Pil03], 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.

4.7.6.1 Grados de similitud o match

El emparejamiento entre anuncios y peticiones se considera idóneo cuando ambos son lo suficientemente similares. Un match o emparejamiento vendrá determinado por los diferentes grados de similitud. El grado de similitud depende de la relación entre los conceptos (tomada de las ontologías) que se están comparando, y generalmente se reduce a la mínima distancia entre ellos en el árbol taxonómico.

La denominación de los grados varía según la literatura. [Pao02a],[Abe01],[Lei03],[W3C02]:

• Exact: cuando los conceptos tanto en la petición como en el anuncio son equivalentes.

• Subclass of: determinado por la relación “ser subclase de”. Cuando los conceptos en la petición son subclase (relación directa) de los del anuncio. (En [Pao02a] es considerado como exact matching también.)

• Subsumption, la cual puede ser de dos tipos:

o Plug-in o Contained: cuando los conceptos en el anuncio A incluyen los de la petición P. Formalmente, (P ⊆ A). En este caso, la petición puede ser satisfecha debido a que los conceptos del anuncio son más generales que los de la petición, y por tanto, existe la posibilidad de que el cliente pueda cumplir sus objetivos. Sin embargo, no se considera que exista una relación de subclase directa (grado anterior)

o Subsume o Container: cuando los conceptos en la petición incluyen los del anuncio; formalmente, (A ⊆ P). Este tipo de emparejamiento no satisface completamente la petición pero puede ser considerado como una solución parcial válida ya que puede permitir al cliente que realizó la petición ir alcanzando parcialmente sus objetivos o metas.

• Fail ,nul o Disjoint cuando no hay relación de inclusión entre los conceptos; formalmente, ( A ∩ P) ⊆ ⊥

En [Gon01] se introdujeron nuevos tipos de emparejamiento que más tarde fueron adoptados por Li y Horrocks [Lei03] como extensión a los anteriormente expuestos:

• Intersection u Overlap. Si la intersección de un anuncio A y una petición P se satisface, es decir son compatibles; formalmente, ¬ (A ∩ P ⊆ ⊥). La idea de compatibilidad entre conceptos ya fue expuesta por David Trastour et al. en [Tras02].

Para entender el proceso de emparejamiento mencionado, hay que considerar la definición de “Open World descriptions” aportada por Tommaso Di Noia et al. en [Noi03]: “La ausencia de una característica en la descripción de un anuncio o de una

petición no se debe interpretar como una restricción de ésta. En su lugar, debe ser considerada como una característica que se podría refinar más tarde, o dejarla abierta si se considera irrelevante para el usuario”. Esta definición clarifica la idea de que incluso cuando los servicios anunciados y los requeridos no tienen un emparejamiento exacto, puede ser posible o necesario usarlos en instancias específicas. Por tanto, los emparejamientos parciales también son importantes [W3C02]. Lo anterior es conocido como “emparejamiento flexible” para distinguirlo del exacto, considerado el más restrictivo de todos.

En [Col03] se establecen tres tipos de emparejamientos dados por las diferentes relaciones entre perfiles de petición y ofertados. Para expresarlo formalmente hacen uso de Lógica Descriptiva. Siendo T una ontología común establecida para la descripción de servicios:

• Implicación: T |= (P ⊆ A) y T |= (A ⊆ P)21

. Cada restricción impuesta por P es completada por A y viceversa. Da lugar al emparejamiento exacto.

• Consistencia: (A ∩ P) es satisfactoria en T, donde las restricciones no se excluyen mutuamente. En este tipo de emparejamientos es necesario establecer un límite en la distancia entre ambas descripciones, que se medirá teniendo en cuenta dicha ontología. Es decir, ¿cuántos destalles en P tengo que preguntar a la otra parte A? Emparejamiento potencial.

• Inconsistencia: A ∩ P es insatisfactoria en T, lo que implica que algunas restricciones de una descripción están en conflicto con las de la otra. En este tipo de emparejamientos cabe preguntarse por el grado de inconsistencia de A en P, es decir ¿Cuántos detalles en P tengo que eliminar para poder aceptar A?. Emparejamiento parcial.

4.7.6.2 Diferentes sistemas e investigaciones

La base de toda la investigación relacionada con el emparejamiento semántico de servicios, recae principalmente en los estudios de Ingeniería de Software llevados a cabo por Zaremski y Wing en [Zar95] y [Zar97], en cuanto a la reutilización de software y recuperación de librerías, mediante la especificación y posteriormente emparejamiento de componentes software. En [Zar97] extienden el concepto de signature matching [Zar95], para tener en cuenta las restricciones en las entradas y en las salidas en funciones y módulos. Este concepto es llamado specification matching y provee no solo información de tipo estático sino también descripciones de comportamiento dinámico. Los autores distinguen varios tipos de emparejamientos en la especificación de emparejamientos de software. Establecen diferentes clases de emparejamiento basados en precondiciones y postcondiciones, siendo los diferentes tipos de emparejamientos aquí tratados la base de trabajos posteriores en el área de emparejamiento semántico.

En [Syc99], [Syc02] Sycara et al. describen LARKS, en el cual los servicios son vistos como frames y sus slots input, output, inConstraints y outConstraints pueden ser usados para describir los atributos esenciales de un servicio. Los conceptos usados por

21

Extensión del concepto de equivalencia dado por la visión simplista de tratar únicamente la equivalencia sintáctica.

las descripciones son definidas mediante un lenguaje de descripción de conceptos denominado ITL (Information Terminological Language). El proceso de emparejamiento en LARKS realiza tanto emparejamiento sintáctico como semántico, y se compone de un conjunto de filtros (independientes entre sí) que progresivamente restringen el número de anuncios candidatos a ser emparejados. En este trabajo se utilizan técnicas basadas en “subsumption matching” entre conceptos y en computación de distancias entre ellos, además hacen uso de técnicas de recuperación de información clásicas como TF-IDF (Term Frecuency-Inverse Document Frecuency).

En [Kle01] se describe una aproximación basada en ontologías que emplea las características de una taxonomía de proceso de recuperación sin sacrificar la precisión y la complejidad de cómputo del proceso de recuperación del servicio. Las preguntas también se expresan usando los mismos modelos de proceso. El algoritmo que empareja utiliza la relación semántica codificada en la ontología de proceso al emparejar el modelo del proceso del servicio con requerimientos.

La aproximación usada por [Gon01] para emparejamiento de servicios es un algoritmo basado en el árbol del subsumción dado por un Razonador de Lógicas Descriptivas. Las descripciones del servicio son especificadas en DAML+OIL y puesto que DAML+OIL se basa en Lógica Descriptiva, el razonador de DL es el corazón del algoritmo de emparejamiento. Los diferentes tipos de emparejamiento para un servicio S, se definen como (1) conceptos equivalentes a S, (2) subconceptos de S, (3) superconceptos de S que son incluidos por el concepto en la ontología de descripción del servicio, (4) los subconceptos de cualquier superconcepto directo de S cuya intersección con S sea satisfactoria.

Otra aproximación utilizada es cuando los servicios pueden también ser descritos como un grafo de RDF [Tras01] y el emparejamiento de anuncios se reduce a emparejar grafos de RDF. Este algoritmo se basa en “visitor pattern”. Los anuncios emparejan cuando su nodo raíz lo hace y sus respectivos nodos hijos también emparejan. Esto significa que uno de los nodos es subtipo del otro y una regla que empareja es definida positiva o se cumple una regla por defecto.

El equipo Intelligent Software Agents Group de la Carnegie Mellon University (CMU) diseño una arquitectura basada en ATLAS (Agent Transaction Language for Advertising Services), lenguaje basado en DAML, para emparejamiento de servicios [Pay01]. Éste utiliza dos filtros: emparejamiento de atributos funcionales para determinar la aplicabilidad de los anuncios y emparejamiento de funcionalidades de servicio, para determinar si el servicio anunciado empareja el servicio requerido. El emparejamiento de atributos funcionales es alcanzado mediante la realización conjuntiva de comparaciones de pares guiados para las propiedades (tipo de servicio, calidad del servicio etc.). Diferentes tipos de inferencia son usados para testear cada par. El emparejamiento de la funcionalidad del servicio es llevado a cabo por inferencia de tipo subsumción en el conjunto de entradas y salidas de la petición y el anuncio.

De nuevo en CMU [CMU04], el Daml-s Matchmaker emplea técnicas de recuperación de datos, de IA, y de Ingeniería de Software para procesar la semejanza sintáctica y semántica entre descripciones de capacidad de servicios. El motor que empareja su sistema contiene cinco filtros para la comparación del namespace, la comparación de la frecuencia de la palabra, la semejanza de la ontología, subsumción en la ontología, y

filtro sobre las restricciones (Constraints Filter). El usuario configura estos filtros para alcanzar el grado deseado entre el funcionamiento y la calidad. Especial relevancia tiene el establecimiento de filtros para las restricciones o reglas sobre las entradas y salidas, ya que pocos son los trabajos que abordan este problema debido a la falta de madurez de un lenguaje de reglas. Para la especificación de éstas, hacen uso de RuleML [RuleML03].

Estas investigaciones son las que más se han tomado como base o referencia para otros trabajos [Pao02a]. Su modelo y algoritmo de emparejamiento semántico que plantean es el que ha sido utilizado por la mayoría de investigadores como base para sus sistemas. Plantean un sistema de emparejamiento basado en la semántica descrita en el Profile de los servicios y en la utilización de los registros UDDI para mantener las descripciones de los servicios, aunque el referente para el resto de investigadores ha sido el algoritmo de emparejamiento utilizado. Hacen uso de la ontología perfil del servicio y de DAML- S como lenguaje de especificación para las descripciones del servicio. Se asume que los servicios de la red anuncian sus interfaces (inputs/outputs) usando la misma ontología. En este trabajo se aborda la importancia para la clasificación del emparejamiento de las salidas. Un emparejamiento entre un anuncio y una petición de servicio consiste en emparejar todas las salidas de la petición con las del anuncio; y todas las entradas del anuncio con las de la petición. El de las entradas se usa más que nada para resolver las igualdades que se produzcan (ver tabla 4.4).

Tipo de emparejamiento Entradas Salidas

Exacto out(A) = out(P) in(A) = in(P) Plug in out(A) ⊃ out(P) in(A) ⊂ in(P) Subsumed out(A) ⊂ out(P) in(A) ⊃ in(P) Fallo (ninguno)

Tabla 4.4: Tipos de emparejamiento mediante entradas y salidas. [Pao03b].

El grado de coincidencia entre el proveedor y la petición de servicio del cliente dependerá del grado de similitud entre los parámetros de entrada y salida (IO’s). Una vez comprobado el grado de similitud para cada uno de los IO’s, el siguiente paso es el de ordenar todos los servicios almacenados. Para esta ordenación se diseñó un algoritmo que ordena los servicios resultantes del emparejamiento según el grado de similitud que tienen, y en el que los emparejamientos de los outputs tienen más peso que los de los inputs. El motivo por el que la prioridad de los outputs es mayor, es debido a que es más importante el emparejamiento de lo que el cliente espera obtener como resultado, es decir, la salida del servicio en cuestión. Dados dos servicios, primero se ordenan por el nivel de similitud de los outputs, y solo si se obtiene un empate, se ordenará por el nivel de similitud de los inputs.

En este algoritmo, una vez ordenados los servicios, se devolverá al cliente aquel servicio resultante del algoritmo de ordenación que es el que tenga un mayor grado de similitud o coincidencia.

Para este algoritmo, Paolucci et al. decidieron que en las peticiones del cliente, éste pudiera incluir el nivel de profundidad en los subarboles para los grados de similitud de plugin y subsume.

Una de las ideas más importantes que aportan Paolucci et al. en su algoritmo para que tenga un mejor comportamiento, es la de que tanto clientes como proveedores empleen las mismas ontologías de conceptos para dar valor semántico a cada uno de los IO’s de sus Profiles. De esta manera, se facilita la tarea al motor de inferencia o razonador, porque solo necesita que se carguen las ontologías de conceptos que utilizaron para construir los Profiles para poder medir el grado de similitud que tengan los IO’s que definiesen. Evitamos el caso en el que tanto proveedores como clientes empleen ontologías de conceptos diferentes para definir IO’s que tengan el mismo valor semántico, porque en ese caso el razonador tendría que cargar un “mapping” de los conceptos definidos en diferentes ontologías que tienen el mismo valor semántico. Este algoritmo es la parte principal del sistema emparejamiento que diseñaron. La arquitectura que emplearon para introducirlo fue utilizar UDDI como registro de SW [Pao02b], [Pao03]. Es decir, intentan relacionar ambas tecnologías, añadiendo la capacidad de uso de la semántica en UDDI para poder elaborar mecanismos de emparejamiento mucho más eficientes, que permitan la utilización de registros de servicios en UDDI ya implementados.

Se basan en la compilación de anuncios DAML-S en registros UDDI que permitan el emparejamiento entre ellos. Si UDDI es un registro de servicios que almacena descripciones WSDL de los servicios, sin ningún valor semántico, ellos trataron de modificar la estructura para permitir que aceptase descripciones de servicio como instancias de Profile para poder aportar el valor semántico a las capacidades de un servicio. Por lo tanto, tienen un sistema de emparejamiento que puede utilizar la búsqueda por keywords de UDDI o utilizar el algoritmo anterior para hacer búsqueda semántica por los servicios anunciados en UDDI.