ontologías para la descripción de servicios web: daml-s (owl-s)

ONTOLOGÍAS PARA LA DESCRIPCIÓN DE SERVICIOS WEB:
DAML-S (OWL-S)
Para poder hacer uso de un servicio Web, un agente software necesita una
descripción del servicio que sea interpretable por un computador, y el medio por el cual
es accedido. El uso de DAML-OIL o posteriormente OWL proporciona el marco de
trabajo apropiado para poder desarrollar esto. A continuación se describirá este tipo de
ontologías basándonos en la especificación en el primero de los lenguajes. [Ank02],
[DAMLS05].
Un servicio descrito con DAML-S permite a un agente software localizar,
invocar, interoperar y monitorizar dicho servicio. DAML-S proporciona respuesta a las
principales preguntas que cabe plantearse a la hora de describir un servicio Web:



¿Qué es lo que el servicio requiere de los usuarios, u otros agentes y que les
proporciona?
¿Cómo funciona el servicio?
¿Cómo se puede utilizar el servicio?
Atendiendo a estas cuestiones anteriormente planteadas se hace necesario el desarrollo
de una ontología de orden superior de servicios en la que aparecen determinados
conceptos que intentan responder a estas preguntas.
La ontologia de servicios fue estructurada considerando las funcionalidades arriba
descritas. Esto dio lugar a tres subontologías reunidas en una cuarta que sirve para
identificar el servicio como un concepto Service y que permite relacionar los tres tipos
de conocimientos del servicio descritos por las otras tres.
La clase Service es el punto de referencia para poder anunciar un servicio Web.
Esta clase Service tienen tres propiedades presents, describedby, supports donde los
rangos de estas propiedades son las tres clases asociadas para representar cada parte de
un servicio: ServiceProfile, ServiceModel, ServiceGrounding respectivamente. Cada vez
que queramos anunciar un servicio, deberemos de instanciar cada una de estas clases.



La clase Service es presentada (presents) por ServiceProfile, que nos sirve
para definir que es lo que el servicio necesita del usuario a agente.
La clase Service es descrita (describedby) por ServiceModel, en el que
explica como trabaja el servicio (como debe usar los inputs, el flujo de
datos en un servicio compuesto etc.).
La clase Service es soportada (supports) por ServiceGrounding, nos
indicara como debe de ser invocado el servicio.
La figura 1 representa la ontología de servicios asociada:
Recurso Web
proporciona
Servicio Web
soportado
presentado por
descrito por
Grounding
Servicio
Profile Servicio
Que proporciona
el servicio Web
Process Servicio
Como se accede
al servicio
Como funciona
el servicio
Figura 1 Ontología de servicios Web DAML-S [Mar02b]
Esta ontología DAML-S presenta dos restricciones de cardinalidad en sus
propiedades:


Un servicio web puede ser descrito como mucho por un ServiceModel
Un ServiceModel debe de estar asociado por al menos un ServiceGrounding
En principio para describir un servicio Web se necesitarán las tres propiedades
para hacerlo correctamente, pero no se indica ninguna restricción respecto una
cardinalidad mínima para las propiedades presents, described by, ni máxima
cardinalidad para las propiedades presents, supports (un servicio podrá ser representado
de diferentes formas, así como ser usado o invocado de diferentes formas si se quiere).
A continuación se describen cada una de estas clases, ya que cada una aporta un
conocimiento o información diferente acerca del servicio web.
1.1. Service Profile
El objetivo principal del Service Profile (ver figura 2) es poder determinar si un
servicio coincide con las necesidades de una determinada petición. Por tanto, el Service
Profile puede ser usado para popularizar los registros de servicios, automatizar el
descubrimiento de estos y su selección (emparejamiento). El Profile de DAML-S no se
desarrolló orientado hacia ninguna arquitectura de almacenamiento, pero el tipo de
almacenamiento seleccionado para almacenar Profiles debe de soportar consultas y un
motor de búsqueda semántico.
Service Profile responde a la primera de las preguntas, es decir a “qué es lo que el
servicio requiere de los usuarios, u otros agentes y que cosas proporciona el servicio a
ellos”. Service Profile provee una forma de describir los servicios ofrecidos por los
proveedores y los servicios necesitados por los solicitantes. Esencialmente, es una
pequeña descripción de lo que hace el servicio, describiendo el servicio como una
función de tres tipos básicos de información:



especificación comprensible para un humano del servicio, que contiene
información sobre la organización que provee el servicio y participantes,
especificación de las funcionalidades que proporciona el servicio en términos de
parámetros, y
conjunto de atributos no funcionales que proveen información adicional sobre
las necesidades del servicio (QoS, región donde se aplica el servicio etc.).
Veamos ahora a un sumario de la clase y las propiedades del Profile:





serviceProfile: Es la clase que nos sirve para representar a los Profiles. Cuando
queramos representar un servicio debemos instanciar esta clase. Dos relaciones
entre el servicio y el profile: presents (relaciona una instancia del servicio con
una instancia de Profile, “el servicio es descrito por este perfil”) y presentedBy
(inversa de la anterior).
serviceName: nombre que damos al servicio que ofrecemos (solo se puede dar
un nombre).
textDescription: descripción del servicio de forma que puede ser leída por el
humano. Se puede aprovechar para introducir keys para mejorar la búsqueda
como explicaremos más adelante.
contactInformation: información sobre el proveedor del servicio, es una
instancia de la clase Actor.
Actor: clase que reúne las propiedades que se debe definir de la información de
contacto del proveedor. Estas propiedades son: name (nombre de la persona o
departamento del proveedor), title (cargo en el proveedor), phone, fax, email,
physicalAdress (dirección del proveedor) y webURL.
Parámetros de funcionalidad: son los componentes más importantes del
Profile ya que son los que especifican de verdad las capacidades del servicio que
queramos proveer. Estos parámetros se dividen en dos grupos: los que indican la
transformación de información y los que producen un cambio de estado debido a la
ejecución. Los que indican la transformación de información son los inputs
(información que el servicio pide al usuario) y los outputs (información que devolverá
el servicio). Los que indican el cambio de estado son las precondiciones que se deben
cumplir antes de ejecutar el servicio y los efectos que se tiene al ejecutar el servicio (Ej.:
al comprar un libro el efecto sería el cargo en la tarjeta de crédito).
Por tanto el servicio transformará las entradas de los usuarios u otros servicios en
salidas, pero además puede requerir que algunas precondiciones se cumplan y puede dar
lugar a efectos que cambien el estado del servicio o de la gente/servicios que interactúan
con él.
Los parámetros en DAML-S son1:

1
ParameterDescription: es la clase que utilizamos para identificar, dar valor
semántico y referenciar en el process model todas las IOPE’s (Inputs, Outputs,
Preconditions, Effects). Por lo tanto tiene tres propiedades: parameterName
(identificar), restrictedTo (da un valor semántico) refersTo (da la referencia en el
Process Model).
Para representar las precondiciones y los efectos se recomienda en OWL-S un lenguaje de reglas como
SWRL [SWRL04] para poder definirlos pero, en DAML-S se definen como los inputs y outputs.




Input: especifica una entrada del servicio. Es una instancia de la clase
Parameterdescription donde definimos el identificador del input, a que clase o
valor semántico tiene y a que input se refiere en el Process.
Output: especifica una salida del servicio. Es una instancia de la clase
Parameterdescription donde definimos el identificador del output, a que clase o
valor semántico tiene y a que output se refiere en el Process.
Precondition: especifica una precondición del servicio. Es una instancia de la
clase Parameterdescription donde definimos el identificador de la precondición, a
que clase o valor semántico tiene y a que precondición se refiere en el Process.
Effect: especifica un efecto del servicio tras su ejecución. Es una instancia de la
clase Parameterdescription donde definimos el identificador del efecto, a que
clase o valor semántico tiene y a que efecto se refiere en el Process.
Se debe tener en cuenta que la descripción de efectos/salidas proporciona la posibilidad
de que el servicio pueda ser usado por otros. Tal y como afirman algunos autores la
descripción de los efectos/salidas se convierte en crucial cuando hablamos de la
composición de servicios y deja de ser relevante en la descripción de servicios atómicos,
donde basta con la especificación de entradas y salidas. La cuestión clave reside en la
determinación de la necesidad de efectos en aquellos servicios que sólo aportan
información.2
Atributos o parámetros no funcionales: son atributos que no son obligatorios
ponerlos en todos nuestros servicios, pero sirven para definir alguna propiedad más.
Suelen utilizarse para que los propios proveedores añadan las características especiales
que creen ofrecen sus servicios Web. Se pueden añadir más a los ya definidos por
DAML-S gracias a otras propiedades definidas para la clase Profile, pero los principales
son:



serviceCategory: Es una clase en el que se define un nombre y un código a cada
una de las categorías de servicio. Sirve para clasificar nuestro servicio.
Inicialmente existen dos clasificaciones de servicios que nos pueden servir para
rellenar estos parámetros, la clasificación NAICS [NAICS04] y la UNSPSC.
QualityRating: Información adicional para el usuario acerca de la calidad del
servicio que se le provee (las estrellas de los servicios de hotel, los tenedores de
restaurantes etc ).
GeographicRadius: Sirve para indicar en que región o país es efectivo el servicio
que ofrecemos (por ejemplo un servicio de venta de libros que solo quiere vender
a la región de Valencia).
Para definir un profile de un servicio Web, debemos de instanciar la clase Profile
aquí definida, que completaremos dando valores a las propiedades que describen las
capacidades de nuestro servicio.
2
En el caso de servicios que ofrezcan información de tráfico a un usuario, después de la ejecución del
servicio, el usuario dispondrá del conocimiento requerido, pero este cambio de estado no es un cambio
tangible y por la tanto no queda muy claro la posibilidad de su uso en el proceso de descubrimiento de un
servicio o en la composición, donde las precondiciones de unos servicios se conviertan más tarde en
precondiciones de otros.
Figura 2 Service Profile Ontology [Mar02b]
1.2. Service Model
Responde a la segunda de las cuestiones anteriores, es decir, a “como funciona el
servicio”, es decir, describe que sucede cuando un servicio se lleva a cabo.
El servicio Web que queramos modelar será un ejecutable o un CGI o cualquier
aplicación que sea accesible por web. La perspectiva del servicio Web se vio desde
DAML-S como un proceso. Desde este punto de vista definieron el Process Model con
las propiedades y parámetros apropiados para permitir representar y modelar todos los
servicios Web que se pueden dar en el mundo real. El Process Model se subdivide en
dos componentes:
Process Model: Describe el servicio en términos de sus componentes o
subprocesos. Cada proceso puede ser visto como un único componente o como un
conjunto de procesos que se especifican mediante un conjunto de estructuras de control.
El servicio es descrito en términos de sus entradas, salidas, precondiciones y efectos.
Control Model: permite al agente monitorizar la ejecución del servicio
seleccionado.
Ambos componentes serían usados para automatizar las tareas de invocación,
composición, interoperación y monitorización. El Process Model es conocido como
Ontología Proceso y el ControlModel como Ontología de Control de Proceso.
1.2.1. Process Model
Este componente fue preparado teniendo en cuenta muchas de las fuentes de las que
debe proveer información (inteligencia artificial, sistemas distribuidos, estándares en
modelización de procesos, modelización de verbos semánticos y eventos, etc.), así como
su uso para poder definir cualquier servicio con independencia del dominio al que
pertenezca.
La principal entidad de esta ontología es la clase Process (ver figura 3) y donde
resulta necesario definir las propiedades adecuadas para especificar los inputs
necesarios para poder hacer la invocación del servicio, así como los outputs que
generara el servicio tras su ejecución. Además de estos parámetros, puede ser que se
necesiten que ciertas precondiciones se cumplan antes de pedir o invocar el servicio, por
lo que es necesario definirlas como un parámetro más del process y análogamente tras
la ejecución del servicio además de los outputs es posible que se puedan tener efectos.
Tanto los efectos como los outputs pueden tener condiciones asociadas, porque puede
ser que se den una salida u otra dependiendo del resultado de la ejecución del servicio.
Estas IOPE’s son subpropiedades de parameter (que es la propiedad que tiene
asociada la clase Process), y en principio no se les da ningún tipo de restricción a
ninguna clase concreta, ni de cardinalidad, aunque según el tipo de process que
vayamos a definir se pueden definir si es necesario.
Figura 3 Service Model Ontology [Mar02b]
El Process de los servicios web se puede subdividir (son clasificadas en la
ontología como subclases) en tres tipos de procesos: Atomic, Simple, Composite.

Proceso Atómico (Atomic): Son aquellos que son directamente invocables
(previo paso de mensajes de forma apropiada), no tienen subprocesos y se
ejecutan en un solo paso, desde la perspectiva del cliente. Es decir, toman un
mensaje de entrada, se ejecutan y devuelven un mensaje de salida. Para cada
proceso atómico, se debe de proveer un “grounding” que habilite a un cliente
que solicita el servicio para construir los mensajes.

Proceso Simple (Simple): No son invocables y no son asociados con un
“grounding”, pero como los anteriores, son concebidos para poder ser
ejecutados en un solo paso. Los procesos simples son usados como elementos de
abstracción; un proceso simple puede ser usado para proporcionar una vista de
algún proceso atómico o una representación simplificada de algún proceso
compuesto. En el primero de los casos el proceso simple es realizado por
(realizedBy) el proceso atómico; en el segundo caso, el proceso simple es
expandido a (expandsTo) el proceso compuesto.

Proceso Compuesto (Composite): Son aquellos que son descomponibles en
otros (no descomponibles o compuestos) procesos; su descomposición puede ser
especificada mediante el uso de constructores tales como Sequence, Split, Split +
Join, Choice, Unordered, Condition, If-Then-Else, Iterate, Repeat-While y
Repeat-Until. Es decir, mediante DAML-S es posible especificar servicios
compuestos por procesos que se ejecutan uno tras otro (sequence),
concurrentemente ( Split ), concurrentemente y con sincronización parcial ( Split
+ Join ), cíclicamente hasta terminar y controlando el flujo de ejecución
mediante una estructura if-then-else o repeat-until etc.
1.2.2. Control Model
Un process se instancia cuando va a ser ejecutado. Para controlar y monitorizar esta
ejecución desde DAML-S se quiere escribir una subontología para permitir a agentes
Web interpretar la ejecución. Sus características principales deberán ser:
o
o
o
Proveer unas reglas de mapping entre los inputs y precondiciones y los
correspondientes outputs.
Proporcionar un modelo de estado temporal de la ejecución de un servicio
compuesto (para conocer por donde va la ejecución).
Proporcionar unos mensajes de representación del estado de la ejecución, para que
pueda ser monitorizada. Estos mensajes deben incluir successful, failed and
interrupted para que un agente los entienda y reaccione con la rutina adecuada.
1.3. Service Grounding
El grounding de un servicio sirve para especificar como acceder al servicio (formato de
mensajes, protocolo de interacción, direccionamiento y transporte). Se puede ver como
una correspondencia o mapeo entre la especificación abstracta y la concreta, de aquellos
elementos de descripción del servicio que son requeridos para la interacción con el
servicio (entradas y salidas de los procesos atómicos).
DAML-S no incluye una construcción abstracta para la definición de los mensajes,
pero esta implícitamente declarado si entendemos que los inputs y los outputs de un
proceso atomic serán el contenido de los mensajes.
Los mensajes concretos son especificados explícitamente en un grounding, de tal
manera que la función principal es la de mostrar como las entradas y salidas
(abstracción) de un proceso atómico se concretan mediante el uso de mensajes que
transportan estas entradas y salidas en algún formato que permita dicha transmisión.
Como el área de concretización de mensajes ya estaba bastante avanzado en la
investigación se optó desde la coalición por usar WSDL, debido al gran apoyo que la
industria le está dando.
1.3.1 La relación entre DAML-S y WSDL
El concepto de grounding de DAML-S es consistente con el concepto de enlazado
(binding) de WSDL, por lo que con la ayuda de la extensibilidad de los elementos que
posee WSDL y la idea de grounding que se tenía en DAML-S se pueden combinar
ambas para el grounding de un proceso atomic.
El trabajo de DAML-S/WSDL grounding es primero definir en WSDL los
mensajes y operaciones por los que un proceso atómico es accedido, y entonces
especificar las correspondencias entre procesos atómicos DAML-S y operaciones
WSDL y por otra parte, entre el conjunto de entradas y salidas de un proceso atómico
DAML-S y mensajes WSDL (ver figura 4).
Figura 4 Conexión DAMLS-WSDL [Mar02b]
Por un lado, la definición de procesos en DAML-S permite describir de forma
abstracta cuáles son los parámetros (inputs, outputs) que intervienen en un servicio
Web, ofreciéndonos la posibilidad de expresar estos parámetros con las capacidad y
expresividad semánticas que nos permiten las clases y mecanismos del lenguaje de
ontologías DAML + OIL (mejores que las que ofrece los tipos de XML Schema usado
por WSDL). Por otro lado, WSDL nos ofrece una infraestructura bastante avanzada y
desarrollada para el intercambio de mensajes por la Web utilizando diferentes
protocolos y mecanismos.
Tanto WSDL como la subontología de Grounding de DAML-S son necesarios
para la definición del grounding de un servicio. Ambos lenguajes no abarcan la misma
materia, pero coinciden en ciertos puntos haciéndolos compatibles. Esta zona donde
ambos lenguajes coinciden es aquella parte de los mensajes WSDL llamado “abstract
types” que sirven para especificar los inputs y outputs de un servicio.
Si WSDL emplea en su descripción normal los tipos del XML Schema, ahora se
puede enlazar a las clases de DAML+OIL para cada uno de los inputs y outputs.. Por lo
tanto, los mensajes de WSDL, en la parte de abstract types emplean clases de
DAML+OIL que después son confiadas a las estructuras que enlazan con el formato de
los mensajes.
Se sintetiza la conexión entre DAML-S y WSDL en los siguientes tres puntos:

Un proceso atómico de DAML-S se corresponde con un operation de WSDL. Se
distinguen diferentes casos:




Un proceso atómico con inputs y outputs se corresponde con una operation
de WSDL del tipo request-response.
Un proceso atómico con inputs pero sin outputs se trata de una operation
one-way.
Un proceso atómico con outputs pero sin inputs se corresponde con una
operation notification.
Un proceso compuesto con inputs y outputs, donde los outputs son
devueltos después de haber sido recibidos los inputs, se corresponde con
una operation solicit-response.

El conjunto de inputs y de outputs de una descripción de un proceso DAML-S, se
corresponden con el concepto de mensajes correspondiente de una operation
WSDL.

Los tipos o clases DAML+OIL a las que pertenecen los inputs y outputs de un
proceso DAML-S se corresponden con la parte de abstract type de una
especificación de un mensaje en WSDL.
Por tanto, cuando se construye un grounding de un servicio, deberemos de hacer
uso de ambos lenguajes, y deberemos de especificar la conexión que existe entre ambos,
al igual que hacer el mapeo de los inputs y outputs descritos en el proceso DAML a los
inputs y outputs que se utilizaran para formar el mensaje WSDL. Por lo tanto es
importante identificar en un servicio cuáles son los procesos atómicos, los inputs y
outputs que tendrá y la especificación correspondiente de los tres puntos, señalados
antes a WSDL.
1.3.2 Grounding de un servicio Web con WSDL y SOAP
DAML-S es una ontología escrita en DAML + OIL, un lenguaje basado en XML, y
como ya ha sido expuesto, el grounding de un proceso descrito en DAML-S se puede
enlazar con una descripción WSDL. En la definición de los servicios Web se
recomienda que se emplee el protocolo SOAP para el intercambio de mensajes,
utilizando como mecanismo de trasporte HTTP.
El grounding de un proceso DAML-S con enlazado WSDL y SOAP, obliga a
definir la descripcion del servicio en WSDL con todas sus partes (types, message,
operation, port type, binding y service).
WSDL especifica tipos (campo types) abstractos usando XML Schema así como
la definición de clases OWL o DAML + OIL. Si el tipo es una clase se puede definir
completamente en esta parte del mensaje o puede ser definido en un fichero aparte
indicando aquí un enlace a esa definición mediante la etiqueta DAML-S-parameter. Las
extensiones que incluyeron los desarrolladores de DAML-S a la especificación de la
sintaxis del lenguaje WSDL son las siguientes:



En la definición del mensaje WSDL, el atributo DAML-S-parameter / OWL-sparameter para indicar la descripción completa del input u output
correspondiente del servicio con la del mensaje. Este atributo es empleado si el
tipo del input o output es una clase de DAML + OIL u OWL
Si el tipo es una clase DAML + OIL, se señalará con el atributo encodingStyle la
dirección del lenguaje que se emplea para representar este tipo. En nuestro caso
es “http://www.daml.org/2001/03/daml+oil.daml” para conceptos de este
lenguaje y la correspondiente para conceptos OWL. Todas las partes del mensaje
que empleen este atributo servirá para indicar el lenguaje utilizado para que sea
instanciado.
En cada operación WSDL definida, el atributo DAML-S-process / OWL-sprocess nos sirve para enlazar con el process atómico definido.
1.3.3. La clase DAML-S Grounding
La subontología de DAML-S orientada a grounding esta destinada a enlazar con la
descripción WSDL del servicio, es decir, enlazar las diferentes partes descritas en el
proceso DAML-S con las partes de un mensaje WSDL. Se definien dos clases
principales en esta subontología: WSDLGrounding y WSDLAtomicProcessGrounding.
La primera clase sirve para identificar el grounding del servicio y que a la vez posee
propiedades de instancias de la otra clase que identifican los diferentes procesos
atómicos que componen el servicio.
Cada instancia de WSDLAtomicProcessGrounding posee propiedades propias para
indicar cada una de las partes de un mensaje WSDL a que parte o propiedad de un
proceso se corresponde. Estas propiedades y su correspondencia son:






wsdlVersion: una URI que indica la versión de WSDL que se emplea.
wsdlDocument: una URI a un documento WSDL a la que se refiere el
grounding del servicio.
wsdlOperation: la URI del correspondiente operation de la descripción
WSDL del proceso atómico dado.
wsdlInputMessage: la URI que apunta a la definición del mensaje que
contiene todos los inputs del proceso.
wsdlInputs: un objeto que contiene una pareja de mapping, una por cada
input del mensaje de input definido en la descripción WSDL. Cada pareja es
una instancia de la clase WSDLInputMessageMap. Un elemento de la pareja
es la URI que identifica parte del mensaje WSDL, y la otra es la propiedad
input definida para ese proceso a la que se refiere.
wsdlOutputMessage: análogo a la de inputs pero respecto a los outputs.

wsdlOutputs: como la clase análoga de inputs, solo que ahora para definir las
parejas de la URI de la parte del mensaje WSDL y la URI del output del
proceso es WSDLOutputMessageMap.
Se puede observar que cuando hemos definido el grounding y los mensajes de
entrada y salida del servicio, hemos empleado inputs y outputs, nunca inputs u outputs
condicionales. Esto es debido a que la versión WSDL 1.1 que es la empleada, no
permite que un servicio tenga definidas salidas condicionadas al resultado de la
ejecución del servicio. Es una limitación que desde DAML-S y WSDL se tratará de
resolver.
REFERENCIAS
[Ank02] The DAML Services Coalition: Ankolenkar Anupriya, Bustein Mark, Hobbs
Jerry R, Lassila Ora, Martin David L., McDermott Drew, McIlraith Sheila A.,
Narayanan Srini, Paolucci Massimo, Payne Terry R. and Sycara Katia. DAMLS-S: Web
Service Description for the semantic Web. Appeared in The First International Semantic
Web Conference (ISWC), 2002.
[DAMLS05] “Semantic Web Services Home Page” http://www.daml.org/services.
Última vez accedido el día 31/01/2005
[Mar02b] Martin David. DAML-S: Bringing Semantics to Web Services, AAAI
Workshop, July 2002
[NAICS04] NAICS: North American Industry Classification Systems.
http://www.census.gov/epcd/www/naics.html Última vez accedido el día 06/09/2004
[SWRL04]
“SWRL
0.6:
Semantic
Web
Rules
Languages”
http://www.daml.org/2004/04/swrl/rules-all.html Última vez accedido el día 04/07/2004