Tesis

Un agente basado en un razonador de ontologas

Autora: Norka Natalia Aguirre Helguero

e-mail: naaguirre@fi.uba.ar

Directora: Lic. Adriana Echeverra

2011
 75.00 Tesis
Agradecimientos

En primer lugar a mis padres, Mario y Norka, mis hermanos,

Marito, Sebastin, Marco y Bernardo y todo el pequeo grupo de familiares por
su contencin, paciencia y continuas palabras de aliento.

A mi directora de tesis, Adriana Echeverra, por darme su

orientacin, sus consejos y comprensin, determinante para la realizacin del
presente trabajo.

A ellos mis esfuerzos y gratitud, de corazn.

2
 75.00 Tesis
INDICE

TESIS ............................................................................................................................... 1

Un agente basado en un razonador de ontologas ............................................................................................. 1

INTRODUCCIN............................................................................................................... 6

CAPTULO I.................................................................................................................... 10

Servicios Web ........................................................................................................................................................... 10

1.1 Generalidades ................................................................................................................................................ 10
1.1.1 Definiciones .......................................................................................................................................... 10
1.1.2 Caractersticas primarias ................................................................................................................... 11
1.1.3 Caractersticas secundarias ................................................................................................................ 13
1.2 Desarrollo orientado a servicios ................................................................................................................ 14
1.2.1 Beneficios .......................................................................................................................................... 14
1.2.2 Diferencias con el desarrollo orientado a objetos ...................................................................... 15
1.2.3 Composicin de servicios ............................................................................................................... 15
1.2.4 Abstraccin de Servicios ................................................................................................................. 16
1.3 Modelos de interoperabilidad en una arquitectura de servicios Web ......................................... 17
1.3.1 Modelo orientado a mensajes - MOM ............................................................................................ 17
1.3.2 Modelo orientado servicios - SOM ................................................................................................. 19
1.3.3 Modelo orientado a recursos ROM .............................................................................................. 21
1.3.4 Modelo de polticas - PM .................................................................................................................. 23
1.4 Arquitectura orientada a servicios .................................................................................................... 24
1.4.1 Generalidades ................................................................................................................................... 24
1.4.2 Directorio de servicios ........................................................................................................................ 26
1.4.3 BPM ......................................................................................................................................................... 26
1.4.4 Gobierno de polticas y procesos ....................................................................................................... 27
1.4.5 Especificaciones ................................................................................................................................... 28
1.5 Servicios Web RESTFul ............................................................................................................................... 30

CAPTULO II .................................................................................................................. 31

Ontologa ................................................................................................................................................................... 31
2.1 Generalidades ................................................................................................................................................ 31
2.2 Folksonomas y ontologas ......................................................................................................................... 33
2.3 Lgica y ontologas ....................................................................................................................................... 35
2.4 Aplicaciones .................................................................................................................................................. 36
2.5 Lenguajes ontolgicos ................................................................................................................................. 39
2.5.1 RDF ..................................................................................................................................................... 39
2.5.1.1 Conceptos Bsicos ........................................................................................................................ 39
2.5.1.2 RDF y la ambigedad semntica XML ....................................................................................... 43
2.5.2 OWL .................................................................................................................................................... 45
2.5.2.1 Conceptos Bsicos ........................................................................................................................ 45
2.5.2.2 Sub-Lenguajes............................................................................................................................... 49
2.5.2.3 Semntica Formal ........................................................................................................................ 51
2.5.3 WSMO ................................................................................................................................................. 51
2.5.3.1 Principios de diseo .................................................................................................................... 52
2.5.3.2 Conceptos bsicos ........................................................................................................................ 52
2.5.4 DAML-S............................................................................................................................................... 53
2.5.5 OWL-S ..................................................................................................................................................... 54
2.5.6 SWSF................................................................................................................................................... 54
2.5.7 WSDL-S............................................................................................................................................... 55
2.5.8 SAWSDL ............................................................................................................................................. 56
2.6 Razonador ...................................................................................................................................................... 57
2.6.1 Clasificacin .......................................................................................................................................... 59

3
 75.00 Tesis
2.6.1.1 Razonadores de lgica descriptiva ............................................................................................. 59
2.6.1.2 Razonadores de programacin lgica ....................................................................................... 60
2.7 SWRL .............................................................................................................................................................. 61
2.7.1 Motivaciones ......................................................................................................................................... 61
2.7.2 DL-Safe Rules ......................................................................................................................................... 62
2.8 Ejemplos ......................................................................................................................................................... 62

CAPTULO III ................................................................................................................. 81

Agentes ...................................................................................................................................................................... 81
3.1 Generalidades ................................................................................................................................................ 81
3.1.1 Agente y entorno ............................................................................................................................. 81
3.1.2 Agentes y objetos ............................................................................................................................. 85
3.1.3 Agentes y sistemas expertos .......................................................................................................... 86
3.1.4 Agentes y servicios .......................................................................................................................... 86
3.2 Clasificacin................................................................................................................................................... 90
3.2.1 Clasificacin dependiendo de la relacin entre percepciones y acciones ............................... 92
3.2.2 Clasificacin de acuerdo al tipo de aplicacin ............................................................................. 92
3.2.3 Clasificacin de acuerdo a caractersticas especiales ................................................................ 92
3.3 Matchmaking entre agentes heterogneos ............................................................................................. 93
3.4 Informacin semntica que registran ...................................................................................................... 94
3.5 Aplicaciones de ontologas en agentes...................................................................................................... 97
3.6 Definicin de las funcionalidades relacionadas con las capacidades esperadas de los agentes
basados en razonadores. .................................................................................................................................... 99
3.7 Razonadores alternativos que puedan ser incorporados en el agente .............................................. 99

CAPTULO IV ............................................................................................................... 102

Composicin dinmica de servicios ................................................................................................................... 102

4.1 Estudio de los ltimos avances en composicin dinmica de servicios como una solucin
eficiente y efectiva. ........................................................................................................................................... 102
4.2 Alternativas de composicin semntica como OWL, Pellet, el algoritmo backward-chaining ...... 105
4.3 Agentes y la composicin de servicios Web ........................................................................................... 106

CAPTULO V ................................................................................................................ 107

Caso prctico .......................................................................................................................................................... 107

5.1 Escenario de aplicacin representativo del problema a resolver ...................................................... 107
5.2 El prototipo construido ............................................................................................................................. 108
5.2.1 Criterio adoptado ................................................................................................................................ 108
5.2.2 Componentes ...................................................................................................................................... 109
5.2.3 Herramientas ...................................................................................................................................... 111
5.3 Resultados ................................................................................................................................................... 114

CAPTULO VI ............................................................................................................... 121

Conclusiones y trabajos futuros ......................................................................................................................... 121

GLOSARIO.................................................................................................................... 124

REFERENCIAS .............................................................................................................. 129

ANEXO I ....................................................................................................................... 132

ANEXO II ...................................................................................................................... 133

4
 75.00 Tesis
Objetivos ................................................................................................................................................................. 133

5
 75.00 Tesis
Introduccin

La visin del prximo paso en la evolucin de la Web es la Web Semntica. En ella la

informacin ser provista de significado explcito facilitando a los ordenadores procesar e
integrar automticamente la informacin disponible en la Web [W3C1; 2009]. La Web puede
alcanzar su mximo potencial si se convierte en un lugar donde la informacin pueda ser
compartida y procesada no slo por personas sino tambin por herramientas automatizadas.

La Web Semntica permite disear agentes para que traten la informacin contenida en sus
pginas de manera automtica a fin de convertir la informacin en conocimiento. Los datos
de las pginas Web son referenciados por esquemas de metadatos consensuados sobre un
dominio particular. Los esquemas de metadatos proporcionan informacin adicional, la cual
permite hacer deducciones y establecer axiomas y si son compartidos, realizar bsquedas de
informacin contextuales as como desarrollar aplicaciones Web ms potentes. Las
ontologas brindan una representacin consensuada de un dominio especfico y legible por
ordenadores [Tello; 2001]

Segn [Herman; 2010], el objetivo de la Web Semntica es crear un medio universal para el
intercambio de informacin, al mismo tiempo que prev la interconexin de las
administraciones de informacin personal, integracin de aplicaciones enterprise y el
intercambio global de informacin comercial, cientfica y cultural. La instalacin de
informacin que se comprensible por los ordenadores en la Web se est convirtiendo
rpidamente en prioridad clave para organizaciones, individuos y comunidades.

La Web Semntica encuentra su propsito en una variedad de reas de aplicacin:

integracin de datos; descubrimiento y clasificacin de recursos (motores de bsqueda);
clasificacin de pginas, sitios Web o bibliotecas digitales; en agentes de software para mayor
intercambio y acceso compartido de informacin; descripcin de los derechos de propiedad
intelectual de pginas Web, etc.

La Web es uno de los repositorios pblicos ms grandes de informacin. Al 18 de diciembre

de 2010, se estima que en la Web existen 13.63 billones de pginas Web2. Esto representa
una cantidad extraordinaria de informacin. Desafortunadamente, la mayora de esa
informacin es inaccesible a las computadoras debido a que fue diseada para consumo
humano [Hebeler et al.; 2009]. Las mquinas fueron diseadas para retransmitir
informacin, no para ser conscientes de los conceptos y relaciones contenidos en ella. Esto
es lo que hace difcil a las aplicaciones utilizar la Web como fuente de informacin de manera
automatizada.

Desde que la Web fue diseada para humanos y basada sobre un concepto simple, la
informacin consiste de pginas de texto y grficos que contienen links [Huhns; 2002]. Cada
link gua a otra pgina con informacin que una persona podra estar interesada en ver. Las
construcciones para la descripcin y codificacin, habitualmente empleadas en las pginas
1
World Wide Web Consortium o Consorcio World Wide Web es una comunidad internacional donde las
organizaciones Miembro, personal a tiempo completo y el pblico en general trabajan conjuntamente para
desarrollar estndares Web. Liderado por el inventor de la Web, Tim Berners-Lee y el Director Ejecutivo (CEO)
Jeffrey Jaffe, la misin del W3C es guiar la Web hacia su mximo potencial.
2
www.worldwidewebsize.com

6
 75.00 Tesis
(HTML) describen su apariencia pero no su contenido, mientras que a los agentes de
software slo les interesara su contenido. Pero a pesar de esta falencia, algunos agentes se las
ingenian para utilizar la Web en esas condiciones. Un shopbot 3 visita catlogos online de
vendedores para retornar precios de artculos segn las preferencias registradas por el
usuario. Los shopbots operan por screen-scraping4, descargan pginas de catlogos y buscan
por nombre de artculo y por el conjunto de caracteres ms cercano a un signo dlar, que
presumiblemente sera el precio del artculo. Los shopbots pueden entregar las mismas
formas que posiblemente entregara una persona y analizar las pginas retornadas que un
comerciante esperara que sus clientes vean. La Web Semntica har la Web ms accesible a
los agentes por utilizar construcciones semnticas como las provistas por ontologas,
representadas en lenguajes bien establecidos, y los agentes podrn comprender lo que hay en
una pgina.

[Berners-Lee et al.; 2006] afirman que los shopbots y los auctionbots5, de uso frecuente en la
Web, son trabajos artesanales de tareas especficas, con poca capacidad para interactuar con
diversidad de datos y tipos de informacin. Es con estndares bien establecidos que los
agentes de software pueden florecer y, en los ltimos cinco aos, estos estndares han
avanzado para expresar la informacin compartida.

En el contexto de la Web Semntica, ontologas, reglas e inferencia brindan soporte para

expresar restricciones adicionales sobre los recursos as como relaciones lgicas.

Las ontologas definen conceptos y relaciones por describir y representar un rea de

conocimiento particular. Con ellas es posible clasificar trminos en una determinada
aplicacin, caracterizar relaciones y definir restricciones sobre esas relaciones. Sin embargo,
no es factible conseguir que todas las personas adhieran a una ontologa. La actitud de la Web
con las ontologas es racionalizar6 la prctica de compartir informacin. Las aplicaciones
pueden interactuar sin tratar de lograr cobertura y consistencia global. No existen
requerimientos de acuerdo global o de traslacin global entre ontologas especficas, excepto
para el subconjunto de trminos relevantes de una transaccin particular, que no es ms que
un acuerdo local. Es importante tener presente que la adopcin de ontologas existentes
favorece la integracin y contribucin de informacin, que algunas son ms utilizadas que
otras y que su evolucin es ms del tipo bottom-up que top-down. [Herman; 2009]

Las reglas ofrecen una forma de expresar restricciones sobre las relaciones definidas por un
3
Agente que sirve para realizar la compra comparativa de programas informticos que el usuario desea adquirir.
Analiza precios y especificaciones de los productos. Incluye caractersticas como heursticas, patrones de
emparejamiento y tcnicas de aprendizaje inductivo que le permiten desenvolverse en cualquier dominio de compra.
4
Screen scrapping consiste en obtener los datos mostrados por pantalla al capturar el texto va software (visto
tambin como alternativa de conseguir los datos sin acceder a las fuentes como bases de datos). Las pginas
Web en formato HTML son un ejemplo. El software a ser utilizado debe ser escrito para reconocer datos
especficos.

5 Agente de subastas. Su propsito es pujar en la red para conseguir productos en las mejores condiciones
posibles. Implementan diferentes tipos de subastas y pueden gestionar varias simultneamente.
6 Significa organizar una actividad social, laboral o comercial de forma de abaratar costos e incrementar el

rendimiento. En este sentido, el W3C proporciona especificaciones y estndares de los lenguajes ontolgicos
que facilitan la codificacin de conceptos mutuamente inteligibles lo que contribuye al progreso de la
comunicacin dentro de la Web y, por lo tanto, al crecimiento de la utilidad Web.

7
 75.00 Tesis
lenguaje ontolgico (como RDF) y pueden ser empleadas para descubrir relaciones nuevas e
implcitas. No es posible definir un lenguaje de reglas para todos los sistemas basados en
reglas pero si un core comprendido por todas. Este core esta basado sobre tipos
restringidos de reglas, llamado reglas Horn, que tienen la forma if-then y establecen
restricciones sobre los tipos diferentes de condiciones y consecuencias. El Rule Interchange
Format (RIF) Working Group est trabajando en una definicin precisa de un lenguaje de
reglas core, su extensibilidad, intercambio de expresiones de reglas entre sistemas y la
definicin de su relacin con OWL7 y su uso con triplas RDF.

A partir de la informacin adicional provista por las ontologas y conjuntos de reglas, los
razonadores pueden llevar a cabo procedimientos automticos para inferir y generar nuevas
relaciones. Existe un amplio rango de razonadores automatizados disponibles y en general, la
inferencia utilizada en este contexto corresponde a lgica de primer orden.

La World Wide Web, inventada en 1989 por Tim Berners-Lee, cambio el modo en que las
personas renen y acceden informacin. Hoy la Web es un enorme repositorio de datos en
continuo crecimiento y existe un cuello de botella cada vez mayor cuando se intenta explotar
la informacin representada, es decir, piezas de informacin especficas. La Web Semntica
fue concebida con el propsito de resolver esta cuestin. Ella apunta a agregar semntica a la
informacin publicada en la Web (establecer el significado de los datos), tal que los
ordenadores puedan procesarla de manera similar a como lo haran los humanos y siendo la
columna vertebral tecnolgica de ello las ontologas.

La Web fue concebida como una fuente de informacin distribuida y luego extendida, con la
aparicin de tecnologas de servicios Web, a una fuente de funcionalidad distribuida. Esto es,
los servicios Web conectan computadoras y dispositivos utilizando Internet para
intercambiar y combinar datos en nuevas formas.

El crecimiento de la Web en tamao y diversidad contribuye a una mayor necesidad para

automatizar aspectos de los servicios Web como descubrimiento, ejecucin, seleccin,
composicin e interoperacin. De hecho, una de las ventajas de los servicios Web es que
hacen posible una composicin dinmica de servicios utilizando componentes de software
reutilizables e independientes. El problema es que las actuales tecnologas (SOAP, UDDI,
WSDL) no proveen el soporte adecuado.

Las aplicaciones que emplean semntica en servicios Web son referidas como servicios Web
semnticos (SWS), los cuales, tambin, son anunciados como uno de los prximos pasos en el
camino hacia la evolucin Web [Snchez-Garca et al.; 2009]. Los SWS describen el contenido
de los servicios mediante anotaciones semnticas con el propsito de que el descubrimiento,
composicin y la invocacin de servicios pueda ser realizado automticamente por agentes
inteligentes al procesar la informacin semntica provista.

Con el propsito de alcanzar estndares en la tecnologa de SWS, el W3C ha recibido y

publicado diferentes presentaciones, algunas de las cuales han sido aprobadas y otras

7 Ontology Web Language o Lenguaje de Ontologa Web.

8
 75.00 Tesis
permanecen como potenciales entradas del proceso del W3C. Entre las primeras se
encuentra el estndar SAWSDL8, aprobado en el ao 2007, realizado por SAWSDL Working
Group y basado en la presentacin WSDL-S, realizada en el ao 2005, por IBM y la
Universidad de Georgia. Entre los segundos siguen: 1) OWL-S, presentado en el ao 2004, por
Nokia, Stanford Research Institute9 (SRI), y las universidades de Carnegie Mellon, Toronto,
Southampton, Yale, entre otras; 2) WSMO, presentado en el ao 2005 por el WSMO Working
Group10; y 3) SWSF, presentado en el ao 2005, por Hewlett Packard (HP), el Massachusetts
Institute of Technology11 (MIT), el National Research Council of Canada12, SRI y las
universidades de Stanford, Zurich, Toronto, California, entre otras.

En la presente tesis se estudiar cmo los servicios Web pueden interoperar combinando de
manera automtica sus funcionalidades a fin de resolver situaciones que as lo requieren. Se
emplear un agente dotado con capacidades semnticas por medio de diferentes razonadores
y de las ontologas adecuadas al escenario elegido para el descubrimiento y combinacin
automtica de los servicios.

El aporte de esta tesis es establecer de qu manera la Web Semntica, descripta a travs de

agentes, ontologas y razonadores podra contribuir a una rea de investigacin activa como
los servicios Web.

La tesis es organizada como sigue: en el captulo I, se realiza una presentacin de los

servicios Web; en el captulo II se desarrollan las ontologas, los lenguajes ontolgicos ms
conocidos y ms citados en las investigaciones de la Web Semntica, los razonadores y, se
adelanta una parte del prototipo construido por detallar las ontologas desarrolladas para el
escenario de aplicacin representativo; en el captulo III se exponen los agentes y su relacin
con el software; en el captulo IV se describen algunas de las investigaciones realizadas
acerca de la composicin dinmica de servicios; el captulo V trata del prototipo construido,
los criterios adoptados, sus componentes y las herramientas empleadas, el captulo VI
enuncia las conclusiones finales y trabajo futuro y al final se anexan los objetivos que
formaron la primera presentacin de este trabajo como propuesta .

8
Desarrollado en la seccin 2.5.8 SAWSDL
9
Instituto de investigacin sin fines de lucro cuya misin es el descubrimiento y la aplicacin de la ciencia y la
tecnologa al conocimiento, el comercio, la prosperidad y la paz. Las reas principales incluyen comunicaciones y
redes, informtica, sistemas de ingeniera, robtica, seguridad y defensa nacional, entre otras.
10
Su misin es alinear los proyectos de investigacin europea en el rea de los SWS, trabajando en la
estandarizacin de lenguajes y una arquitectura y plataforma comn.
11
Instituto de Tecnologa de Massachussets
12
Consejo Nacional de Investigacin de Canad

9
 75.00 Tesis
Captulo I

Servicios Web

1.1 Generalidades

1.1.1 Definiciones

Los servicios Web surgen como la mejor solucin para la ejecucin remota de funcionalidad.,
debido, parcialmente, a propiedades como independencia del sistema operativo y del
lenguaje de programacin, interoperabilidad, ubicuidad y la posibilidad para desarrollar
sistemas dbilmente acoplados. [Garca-Snchez et al.; 2009]

Los servicios Web son diseados para proveer interoperabilidad para diversas aplicaciones.
Los servicios Web son (por su diseo) independientes de las plataformas e interfaces de
lenguaje permitiendo una fcil integracin entre diversos sistemas. Lenguajes Web como
UDDI, WSDL y SOAP definen estndares para descubrimiento, descripcin y protocolos de
mensajes. [Sirin et al.; 2002]

Una perspectiva de negocios, los define como activos IT, como actividades del mundo real o
funciones de negocios reconocibles, posibles de ser accedidos cumpliendo polticas de
servicio (quien o qu es autorizado para acceder un servicio, cuando un servicio est
disponible, el costo de utilizar un servicio, niveles de confiabilidad por tiempo de restitucin,
niveles de seguridad por requerimientos de privacidad e integridad, niveles de performance
por tiempo de respuesta, etc.).

Una perspectiva tcnica, en cambio, los define como activos IT reutilizables, coarse-
grained13, con interfaces o contratos de servicio, que ocultan su implementacin y
desacoplan la relacin usuario-proveedor de servicio, permitiendo que ambos puedan
evolucionar independientemente, mientras los contratos de servicios permanecen sin
cambios (que un usuario pueda utilizar los servicios de otros proveedores o que un
proveedor pueda atender otros usuarios).

Los servicios pueden interactuar de manera consistente e independiente de la tecnologa

gracias a estndares y facilidades provistas por la plataforma de servicios Web, la cual
constituye una infraestructura comn para que usuarios y proveedores puedan localizar y
utilizar los servicios de otros o agregar nuevos servicios de manera estandarizada, siendo su
propsito principal el de facilitar la distribucin de servicios.

Los servicios son un elemento clave en una arquitectura orientada a servicios. Un anlisis
por capas, distingue entre contratos de servicios, servicios tcnicos y lnea de negocios.

13
En este contexto, denota caractersticas generales

10
 75.00 Tesis
La capa de lnea de negocios automatiza, de manera parcial o total, los servicios que una
organizacin presta directa (propios) o indirectamente14 (tercerizacin). La lnea de
negocios establece un dominio de servicio (ingeniera, finanzas, ventas, marketing,
manufacturas, transporte, entre otros) a fin de que los servicios de ese dominio puedan
comunicarse mediante un vocabulario comn y sea posible combinarlos. Generalmente,
servicios de diferentes dominios tendrn inconsistencias o vocabularios contradictorios y
por lo tanto, la plataforma de servicios Web necesitar proveer facilidades de transformacin
de datos para pedidos de dominios diferentes.

La capa de servicios tcnicos se ocupa de definir servicios reutilizables a lo largo de mltiples

lneas de negocios. Por ejemplo, servicios de transformacin de datos, acceso a datos,
auditora, acceso y administracin de identidad (login). Los servicios de esta capa son
valiosos porque responden a un requerimiento especial de negocios como es la mitigacin
del riesgo en escenarios cambiantes.

Cada servicio consta de una interfaz bien definida (es decir de una separacin clara entre
interfaz e implementacin) llamada formalmente, contrato de servicio. El contrato de servicio
es un mecanismo para formalizar un sistema y su alcance, minimizar dependencias,
maximizar adaptabilidad, emplear pruebas de caja negra, seleccionar servicios y cambiar de
proveedores.

Un proveedor de servicios (service provider) es un mdulo de software que implementa un

contrato de servicio. Varios proveedores pueden implementar un mismo contrato de servicio
y ser instanciados por cada vez que son requeridos.

Un usuario de servicio (service requester) es un mdulo de software que invoca el servicio

implementado por algn proveedor y utiliza las facilidades provistas por la plataforma de
servicios Web a fin de localizar el servicio y comunicarse con l.

Los servicios Web proponen un enfoque diferente para resolver algunos de los problemas IT
(especialmente en torno a la integracin) que se desprenden de las nuevas capacidades
ofrecidas por la tecnologa. Cabe destacar que considerando que los servicios Web son
tecnologas de interfaz basadas en XML, la utilizacin adecuada de servicios Web requiere de
un cambio en la forma de pensar la tecnologa, la cual no consiste en simplemente aprender
una nueva gramtica para la misma manera de construir y desplegar sistemas sino en tener
presente que los servicios Web hoy y siempre requerirn de una combinacin de
tecnologas.

1.1.2 Caractersticas primarias

Los servicios Web permiten obtener beneficios de negocios y tcnicos debido a ciertas
caractersticas claves, las cuales deben estar presentes en el diseo, la implementacin y

14
Outsourcing o tercerizacin. Contratar a otra empresa para que realice determinadas tareas que hacen a la
actividad empresarial pero no al ncleo del negocio. Realizado cuando se mejora la eficiencia en los resultados
(reducir costos, mejorar la calidad prestada) y se liberan recursos para reasignarlos a las tareas centrales de la
empresa

11
 75.00 Tesis
administracin. Estas caractersticas por grado de importancia se encuentran agrupadas en
caractersticas primarias, desarrolladas en esta seccin y caractersticas secundarias,
desarrolladas a continuacin.
Las caractersticas primarias son claves en la obtencin de beneficios. Ellas incluyen: dbil
acoplamiento, contratos de servicios bien definidos, tiles para el usuario y basados en
estndares. A continuacin se describen brevemente.

Para que un servicio tenga dbil acoplamiento hay que considerarlo a travs de su interfaz, la
tecnologa y los procesos. Idealmente, un usuario de servicio debera solicitar el servicio a
partir del contrato de servicio publicado y del acuerdo de nivel de servicio (SLA) pero nunca
requerir informacin acerca de su implementacin. La dependencia de tecnologa limitara la
diversidad de usuarios que podran acceder al servicio y la posibilidad de ser exteriorizado
para proveer a terceros. Por ltimo, se debera tratar que los servicios no queden ligados a
procesos de negocios para que luego puedan ser reutilizados en diferentes procesos y
aplicaciones.

Cada servicio cuenta con una interfaz, bien definida llamada contrato de servicio, para definir
capacidades y modos de invocacin, mientras oculta detalles de implementacin. As, un
estndar para contratos de servicios es provisto por WSDL. Por otro lado, un servicio puede
incluir metadatos sobre seguridad, polticas y con otros propsitos, utilizando la familia de
especificaciones WS-Policy15. Es importante destacar que un contrato de servicio debe ser
desarrollado con conocimiento del dominio de negocio y no simplemente derivado de la
implementacin del servicio. Como primer corolario, el contrato de servicio debe ser
independiente de la implementacin y manejado como un artefacto separado. Los contratos
de servicios son ms valiosos que las implementaciones debido a que representan
conocimiento vital de negocios, son la base para compartir y reutilizar servicios y el
mecanismo primario para reducir acoplamiento de interfaz. Los cambios en los contratos de
servicios son ms costosos que los cambios en la implementacin dado que se propagan a los
usuarios, mientras que los cambios de implementacin no tienen esos efectos. Como segundo
corolario entonces, es importante tener un mecanismo formal de extensin y versionado de
contratos de servicios para manejar dependencias y costos.

Servicios tiles son aquellos que poseen contratos de servicios definidos con un nivel de
abstraccin apropiado y con sentido para los usuarios. Un nivel apropiado de abstraccin es
aquel que captura la esencia del servicio sin restringir aplicaciones futuras, evita exponer a
los usuarios detalles tcnicos como estructuras internas o convenciones y utiliza vocabulario
del dominio del servicio para definir el servicio y los documentos de entrada y salida. Una
interfaz abstracta promueve la sustitucin, permitiendo cambiar de proveedores sin afectar a
los usuarios. En general, los servicios tiles ejecutan tareas discretas y proveen interfaces
simples a fin de lograr reutilizacin y dbil acoplamiento.

Los servicios basados en estndares tienen varias ventajas: evitan depender de un vendedor
IT, aumentan las oportunidades que tiene un usuario de utilizar proveedores de servicios
alternativos, las oportunidades de los proveedores de soportar un amplio nmero de usuarios

15
Desarrollado por IBM, Microsoft, SAP y BEA. Polticas expresadas siguiendo un enfoque checklist para asociar
solicitudes con proveedores. Las polticas son declaraciones establecidas por el proveedor que solicitan al usuario
informacin adicional aparte de la provista por WSDL (requerimientos de seguridad, transacciones, etc.) a fin de
poder invocar el servicio.

12
 75.00 Tesis
y de utilizar implementaciones open-source, a su vez, basadas en estndares, en tanto que,
para las comunidades de desarrolladores crecen las oportunidades en torno a las
implementaciones.

Adems de adherir a estndares tecnolgicos, resulta relevante poder respaldar el modelo de

datos y el modelo de procesos con estndares maduros del dominio de negocio y de la
industria vertical.

1.1.3 Caractersticas secundarias

Las caractersticas secundarias de los servicios permiten incrementar los beneficios. Ellas
incluyen:

SLAs,

stateless,

diseo con soporte para mltiples estilos de invocacin,

diseo de contratos de servicios relacionados,

compensacin de transacciones,

implementacin independiente de otros servicios,

descubrimiento y administracin por metadatos.

A continuacin se presenta una descripcin de cada una de estas caractersticas.

Los acuerdos de nivel de servicio (SLA), definen mtricas de servicios (tiempo de respuesta,
rendimiento, disponibilidad, tiempo entre fallas, entre otras) y permiten a los usuarios
determinar si un servicio satisface sus requerimientos no funcionales; a los proveedores
determinar la cantidad de instancias de servicios, provisin dinmica de servicios, servicios
centralizados o distribuidos geogrficamente, entre otras. Un SLA debe ser establecido
tempranamente porque afecta el diseo, la implementacin y la administracin. Su funcin
es establecer, monitorear y permitir renegociar objetivos de negocios despus de finalizada la
implementacin.

Los metadatos permiten que los servicios sean publicados de manera especial para ser
descubiertos y consumidos sin intervencin del proveedor. Esto reduce costos en localizar y
utilizar servicios, errores asociados con su utilizacin y permite una mejor administracin.

Se deben implementar servicios autosustentables para minimizar dependencias entre

servicios, a fin de permitir que puedan interoperar sin dependencias internas y sin
compartir estado.

Una compensacin de transaccin corrige los errores producidos en una transaccin

comercial. Ambas, la transaccin y compensacin, deben ser implementadas
simultneamente por servicios distintos para asegurar consistencia entre ellas.

13
 75.00 Tesis
El diseo y la implementacin de operaciones de servicio deben soportar mltiples estilos de
invocacin a fin de ser utilizadas en un amplio rango de situaciones y procesos de negocios.
En la mayora de los casos la lgica de negocios implementada por un proveedor de servicio es
completamente independiente del estilo de invocacin.

Los servicios stateless (servicios sin estado) son implementaciones donde las invocaciones
son independientes una de la otra y no dependen de un mantenimiento especfico del cliente,
ni de estados persistentes entre invocaciones (no mantienen el estado de los procesos que
ejecutan ni los resultados que generan). Por lo tanto, resulta inmediato que las interacciones
stateless escalan eficientemente al permitir que cualquier pedido pueda ser enrutado a
cualquier instancia de servicio en oposicin a los servicios stateful16 que no escalan
eficientemente dado que el servidor necesita recordar cuales servicios estn sirviendo a cual
cliente y no se puede reutilizar un servicio hasta que ste haya terminado o por timeout.

Dado que los servicios no estn aislados, al disear interfaces de servicios para un dominio de
negocios particular, se disea el modelo de datos a nivel servicio (XML Schema) y
simultneamente todas la interfaces. Esto es porque los servicios de ese dominio de negocios
utilizarn elementos del mismo modelo de datos. Adems, asegura que los elementos de datos
sean definidos y aplicados de manera consistente y evita situaciones donde los servicios
utilicen definiciones similares aunque sutilmente diferentes. Es importante que todos los
servicios compartan el mismo modelo de datos a nivel servicio, incluyendo la estructura y
semntica de los documentos de negocios.

Los servicios deberan ser diseados e implementados con todas sus caractersticas. Sin
embargo esto no siempre es posible y, puede ocurrir que el costo de agregar una
caracterstica particular sea prohibitivo, comparada con los objetivos de la organizacin. Si
esto sucede, se deben privilegiar las caractersticas primarias, las cuales otorgaran los
mayores beneficios.

1.2 Desarrollo orientado a servicios

1.2.1 Beneficios

El desarrollo orientado a servicios es complementario a otros enfoques como el desarrollo

orientado a objetos, el desarrollo por procedimientos, el desarrollo por mensajes y el
desarrollo de base de datos. Entre los beneficios que provee el desarrollo orientado a servicios
se encuentran:

Reutilizacin: capacidad para crear servicios utilizables en mltiples aplicaciones.

Eficiencia: capacidad para crear servicios y aplicaciones a partir de la combinacin de los
servicios existentes y capacidad de enfocarse en los datos a ser compartidos (en lugar de la
implementacin subyacente).

Dbil acoplamiento de tecnologas: capacidad para modelar servicios independientemente

16
Servicios con estado que suelen mantener las decisiones del usuario durante un proceso o una sesin, por
ejemplo un carrito de compras o los diferentes pasos para registrarse en una pgina Web.
14
 75.00 Tesis
de su entorno de su ejecucin y crear mensajes que puedan ser enviados a cualquier
servicio.

Divisin de responsabilidad: permite a los analistas de negocios y tcnicos colaborar en el
desarrollo de servicios mediante los contratos de servicio.

El ltimo beneficio es producto del cambio radical que exige la forma de pensar servicios (en
temas de diseo, desarrollo y despliegue) que conduce a una redistribucin de
responsabilidades en los departamentos IT. Surgen el rol de analista de negocios, responsable
por montar nuevas aplicaciones compuestas y flujos de procesos que aseguren el
cumplimiento de requerimientos operacionales y estratgicos de negocios y, el rol de tcnico,
responsable por manejar la complejidad de la tecnologa de fondo en el despliegue de
servicios, asegurar que las descripciones de servicios XML/Web son las que el usuario
necesita y determinar los datos correctos a compartir.

1.2.2 Diferencias con el desarrollo orientado a objetos

Desarrollar un servicio es diferente a desarrollar un objeto. Un servicio es definido por los

mensajes que intercambia con otros servicios y no por mtodos. Un servicio es definido a un
nivel de abstraccin ms alto (el denominador comn menor) que el empleado en la
definicin de un objeto, precisamente, eso es lo que hace posible que una definicin de
servicio pueda ser implementada en un lenguaje orientado a procedimientos (COBOL), en un
sistema de encolado de mensajes (JMS) o en un sistema orientado a objetos (J2EE o .NET).

La granularidad en la definicin de un servicio marca otra diferencia. Un servicio

generalmente define una interfaz general que acepta ms datos en una invocacin que un
objeto y que consume ms recursos de procesamiento que un objeto a causa de su
necesidad de mapear a un entorno de ejecucin, procesar el XML y permitir acceso remoto.
Aunque las interfaces de objetos pueden ser muy generales, el punto es que los servicios son
diseados para solucionar problemas de interoperabilidad entre aplicaciones y para
componer nuevas aplicaciones (o sistemas de aplicacin) pero no para crear lgica detallada
de negocios para las aplicaciones. [Newcomer y Lomov; 2004]

1.2.3 Composicin de servicios

La Web crece en diversidad y tamao incrementando la necesidad para automatizar aspectos

de los servicios Web como descubrimiento, ejecucin, seleccin, composicin e
interoperacin. [Garca-Snchez et al.; 2009]

Es posible crear una agregacin de servicios Web de forma tal que el servicio Web publicado
encapsule otros servicios Web. As una interfaz general puede ser descompuesta en un
nmero de servicios especficos (o mltiples servicios especficos ser combinados en una
interfaz general). Esto es frecuente en una composicin esttica de servicios efectuada por
medio de WS-BPEL17.

17
Web Services Business Process Execution Language. Es un lenguaje de composicin orientado a procesos
para servicios Web. Depende de WSDL. Un proceso WS-BPEL puede ser expuesto como un servicio definido por
WSDL e invocado como cualquier otro servicio Web. Adems WS-BPEL espera que todos los servicios incluidos
15
 75.00 Tesis
A nivel proyecto, un arquitecto supervisa el desarrollo de servicios reutilizables e identifica
un medio para almacenar, administrar y recuperar descripciones de servicios. Una capa de
servicios separa las operaciones de negocios de variaciones en la implementacin de la
plataforma de software subyacente, de la misma manera que los servidores Web y los
navegadores separan la WWW de variaciones en los sistemas operativos y lenguajes de
programacin. Son los servicios reutilizables, por su capacidad para ser compuestos en
servicios ms grandes rpida y fcilmente, lo que proveen a una organizacin de los
beneficios de la automatizacin de procesos y de la agilidad para responder a condiciones
cambiantes.

1.2.4 Abstraccin de Servicios

Un servicio tiene, en la red, una descripcin de los mensajes que recibe y opcionalmente
retorna. En efecto, un servicio es definido en trminos del patrn de intercambio de
mensajes (MEP) que soporta. Un esquema para los datos contenidos en el mensaje es
utilizado como parte principal del contrato (descripcin) entre el servicio solicitante y el
servicio proveedor. Otros tems de metadatos incluyen la direccin de red del servicio,
operaciones y requerimientos de confiabilidad, seguridad y transaccionalidad.

Usuario de servicio Implementacin de servicio / Agente ejecutable

.NET J2EE

CORBA IMS

Descripcin de servicio Pedido de servicio

Capa traductora
(Mapping Layer)

[Newcomer y Lomov; 2004]. Componentes de servicio.

Las partes de un servicio incluyen la implementacin, una capa de mapeo y la descripcin. La

implementacin puede ser provista por cualquier entorno de ejecucin. La implementacin

en una composicin sean definidos empleando contratos de servicio WSDL. Esto permite a un proceso WS-
BPEL invocar otros procesos WS-BPEL recursivamente.

16
 75.00 Tesis
del servicio tambin es llamada agente ejecutable. El agente ejecutable es responsable de
implementar el modelo de procesamiento definido por las especificaciones. El agente
ejecutable corre dentro de un entorno de ejecucin, el cual es generalmente un sistema de
software o un lenguaje de programacin.

La descripcin se encuentra separada del agente ejecutable. Una descripcin puede tener
mltiples agentes ejecutables asociados. Similarmente, un agente puede soportar mltiples
descripciones. Entre la descripcin y el entorno de ejecucin se encuentra la capa de mapeo
(algunas veces llamada capa de transformacin), que es implementada por medio proxies o
stubs. La capa de mapeo es responsable de aceptar el mensaje, transformar los datos desde el
XML al formato original y despachar los datos obtenidos al agente ejecutable.

Los servicios Web pueden adoptar dos roles, como servicio solicitante, al iniciar la ejecucin
de un servicio por enviar mensajes al servicio proveedor y como servicio proveedor, al
ejecutar el servicio y opcionalmente retornar resultados. Un agente ejecutable puede ocupar
uno o ambos roles.

La abstraccin de servicios permite acceder a una variedad de servicios, incluyendo

aplicaciones legacy18 (wrapped o encapsuladas) y aplicaciones compuestas por otros
servicios.

1.3 Modelos de interoperabilidad en una arquitectura de servicios Web

[Booth et al., 2004] definen una arquitectura de servicios Web (WSA - Web Service
Architecture) como una arquitectura de interoperabilidad, asegurada por identificar los
elementos de una red de servicios Web global. Estos elementos son combinados en cuatro
modelos diferentes.

1.3.1 Modelo orientado a mensajes - MOM

El modelo orientado a mensajes, tambin llamado MOM, por sus siglas en ingls (Message
Oriented Model), se centra sobre aspectos de la arquitectura relacionados a los mensajes y su
procesamiento.
El modelo no refiere el significado semntico del contenido de un mensaje o su relacin con
otros mensajes.
MOM se centra en la estructura de los mensajes, las relaciones entre el emisor y el receptor y
cmo son transmitidos.
Los conceptos y relaciones en MOM son ilustrados a continuacin:

18
Legacy usualmente significa aplicaciones remanentes, en versiones muy anteriores y que se han reemplazado por
ms modernas, pero que siguen funcionando todava.

17
 75.00 Tesis

[Booth et al.; 2004] Modelo orientado mensajes

Algunos conceptos y relaciones son explicados a continuacin.

Direccin: es la informacin requerida por un mecanismo de transporte de mensaje a fin
de entregar el mensaje apropiadamente. Generalmente, la direccin depender del
transporte de mensajes particular. En el caso de transporte de mensajes HTTP, la direccin
tomar la forma de una URL.

Mensaje: es la unidad bsica de datos enviada desde un agente a otro. Las partes
principales de un mensaje son la envoltura, un conjunto de headers y el cuerpo. La
envoltura sirve para encapsular las partes componentes del mensaje y ubicar informacin
de direccionamiento. Los headers contienen informacin auxiliar acerca del mensaje y
facilidades de procesamiento modular. El cuerpo consta del contenido del mensaje.

Cuerpo: provee un mecanismo para transportar informacin hacia el destinatario. La
forma del cuerpo y restricciones sobre el cuerpo pueden ser expresadas como parte de la
descripcin de servicio. En muchos casos, la interpretacin precisa del cuerpo del mensaje
depender de los headers del mensaje.

Correlacin: es la asociacin de un mensaje con un contexto. Asegura que un agente
solicitante puede relacionar la respuesta con el pedido, especialmente cuando mltiples
respuestas son posibles.

Envoltura: encapsula las partes componentes del mensaje, el cuerpo y los headers. En ella
se pueden encontrar la direccin de destino, informacin de seguridad que permite
autenticar el mensaje, informacin de calidad de servicio.

Patrn de intercambio de mensajes: tambin llamado MEP (Message Exchange Pattern).
Es un template que describe un patrn genrico para el intercambio de mensajes entre
agentes. Los mensajes que son instancias de un MEP estn correlacionados, explcita o
implcitamente. Los intercambios pueden ser sincrnicos o asincrnicos. La diferencia
precisa entre un MEP y una coreografa no est resuelta. Algunos sostienen que MEP
consiste de patrones atmicos y una coreografa de una composicin de patrones. Un MEP

18
 75.00 Tesis
es desprovisto de la semntica de la aplicacin mientras que una coreografa incluye la
semntica en la descripcin de patrones. A nivel de escala, una coreografa
frecuentemente utiliza MEP en la construccin de bloques.

Header: contienen informacin acerca del mensaje. Su funcin primaria es facilitar el
procesamiento modular del mensaje. Parte del header puede incluir informacin
pertinente a funcionalidades extendidas de los servicios Web como seguridad, contexto de
transaccin, informacin de orquestacin, informacin de ruteo o administracin. Pueden
ser procesados independientemente del cuerpo del mensaje, cada header puede identificar
un rol de servicio que indica el tipo de procesamiento que debera ser ejecutado sobre el
mensaje. Un mensaje puede tener varios headers identificando roles de servicios
diferentes.

Destinatario: el destinatario de un mensaje es el agente que recibe un mensaje.

Emisor: el emisor de un mensaje es el agente que transmite un mensaje. Aunque cada
mensaje tiene un emisor, la identidad podra no estar disponible en el caso de
interacciones annimas.

Confiabilidad: el objetivo es reducir la frecuencia de error y proveer suficiente
informacin acerca del estado de un envo. Esta informacin permite a un agente
participante tomar decisiones de compensacin cuando se producen errores. Cuando ms
de dos agentes estn involucrados, es necesario utilizar una correlacin de alto nivel como
two-phase commit19. El envo puede ser realizado por una combinacin de
acknowledgement y correlacin. Si un mensaje no ha sido recibido apropiadamente, el
emisor puede intentar un reenvo o alguna accin de compensacin a nivel aplicacin.

Secuencia: conjunto ordenado de mensajes intercambiados entre un agente proveedor y
un agente solicitante durante una interaccin. La secuencia puede ser realizada por un
MEP, usualmente identificado por una URI.

Transporte: mecanismo empleado por los agentes para enviar mensajes. Ejemplos de
transporte de mensajes incluyen HTTP sobre TCP, SMTP, middleware20 orientado a mensajes,
etc.

1.3.2 Modelo orientado servicios - SOM

Se centra sobre aspectos de la arquitectura que relacionan servicio y accin. El propsito de

SOM es explicar las relaciones entre un agente con los servicios que provee y pedidos que
realiza. SOM se construye sobre MOM pero se ocupa de la accin que tiene lugar.
Los conceptos y relaciones en SOM son ilustrados a continuacin.

19
Empleado en el procesamiento de transacciones, bases de datos y redes, es un algoritmo distribuido que coordina
todos los procesos que participan en una transaccin atmica distribuida para el commit o rollback de la transaccin
(tipo de protocolo por consenso). El protocolo es resistente, en muchos casos, a fallas temporales del sistema (por
procesos, nodos de red, comunicacin). Sin embargo no es resistente a todas las posibles fallas de configuracin y
en casos especiales puede requerir la intervencin del usuario.
20
Software de conectividad que ofrece un conjunto de servicios que hacen posible el funcionamiento de
aplicaciones distribuidas sobre plataformas heterogneas. Funciona como una capa de abstraccin de software
distribuida que se sita entre las capas de aplicaciones y las capas inferiores (sistema operativo y red). El
middleware abstrae de la complejidad y heterogeneidad de las redes de comunicacin subyacentes, as como de los
sistemas operativos y lenguajes de programacin, proporcionando una API para la fcil programacin y manejo de
aplicaciones distribuidas.

19
 75.00 Tesis

[Booth et al.; 2004] Modelo orientado a servicios

Los conceptos relacionados con agente proveedor, agente solicitante, entidad proveedor y
entidad solicitante son definidos en la seccin agentes.
Para el modelo, un servicio es un recurso abstracto que representa la capacidad de ejecutar
tareas y posee funcionalidad coherente desde el punto de vista de una entidad proveedor y
solicitante y que para ser utilizado debe ser implementado por un agente proveedor.
Los servicios Web se distinguen de otros recursos Web en que no necesariamente tienen
una representacin. Los servicios Web son interacciones entre agentes proveedor y
solicitante, centrados en acciones, que con propsitos de caracterizar la semntica son
capturadas en trminos de tareas (la semntica de cualquier sistema est ligado al
comportamiento del sistema). Las tareas combinan el concepto de accin con intencin: los
servicios Web son invocados con un propsito, que puede ser expresado como un objetivo de
estado deseado.
Algunos conceptos y relaciones son explicados a continuacin.

Accin: ejecutada por un agente, por recibir un mensaje o enviar un mensaje o cualquier
otro cambio de estado observable que satisface un objetivo de estado deseado.

Coreografa: define la secuencia y condiciones bajo las cuales mltiples agentes
intercambian mensajes a fin de alcanzar el objetivo de estado de la tarea a ejecutar. Se
apoya en interfaces de servicio, puede pertenecer a una tarea, define la relacin entre los
mensajes intercambiados y las tareas de un servicio. Mientras una orquestacin define la
secuencia y condiciones bajo las cuales un servicio Web invoca a otro para realizar alguna
funcin, una coreografa puede ser descripta utilizando un lenguaje de descripcin de
coreografa sobre cmo componer servicios Web, cmo establecer roles y asociaciones en
los servicios Web y cmo manejar el estado de los servicios compuestos.

Capacidad: pieza de funcionalidad soportada o requerida por un agente. Tiene un

20
 75.00 Tesis
identificador URI, una descripcin semntica, puede ser publicada por un agente
proveedor o solicitante y referenciada por una descripcin de servicio.

Objetivo de estado: es el estado deseable de algn servicio o recurso desde el punto de vista
de una persona u organizacin. Asociado con las tareas provistas por un servicio, los
objetivos son caracterizados por predicados que son verdaderos para ese estado.

Descripcin: contiene detalles de la interfaz y del comportamiento esperado del servicio y
puede ser utilizada para facilitar la construccin y despliegue de servicios, por personas
para localizar servicios apropiados y por agentes solicitantes para automticamente
descubrir agentes proveedores.

Interfaz: define los diferentes tipos de mensajes que un servicio enva y recibe, junto con
el patrn de intercambio de mensajes (MEPs) empleado tal como request/response21,
one-way asynchronous22 o publish/subscribe23.

Rol: es un conjunto de tareas de servicio, que puede ser definido en trminos de
propiedades de mensajes y establecido por el propietario del servicio. Un mensaje recibido
por un servicio puede involucrar procesamiento asociado con varios roles. Similarmente,
los mensajes emitidos pueden involucrar ms de un rol de servicio.

Semntica: es el contrato entre una entidad proveedora y una entidad solicitante
concerniente a los efectos y requerimientos pertenecientes al uso de un servicio. Trata
sobre las tareas que constituyen el servicio. Debera ser identificada en una descripcin de
servicio y descripta formalmente por un lenguaje procesable por mquina. Las
descripciones semnticas procesables por mquina proveen un uso sofisticado de los
servicios Web. Aparte del comportamiento esperado de un servicio, otros aspectos de la
semntica de un servicio incluyen restricciones sobre polticas, la relacin entre la entidad
proveedor y la entidad solicitante y cules caractersticas de manejabilidad estn asociadas
con el servicio.

Tarea: es una abstraccin que encapsula los efectos deseados de invocar un servicio. Las
tareas estn asociadas con objetivos de estado. La performance de una tarea es observable
por el intercambio de mensajes entre un agente solicitante y un agente proveedor. El
patrn especfico de mensajes define la coreografa asociada con la tarea. Las tareas
representan una unidad til en el modelado de la semntica de un servicio y de hecho, del
rol de un servicio.

1.3.3 Modelo orientado a recursos ROM

Tambin llamado ROM (Resource Oriented Model). Los recursos son un concepto
fundamental que sustenta gran parte de la Web y gran parte de los servicios Web. Por
ejemplo, un servicio Web es un tipo particular de recurso. El modelo se centra en
caractersticas claves de los recursos tales como propiedad de recursos y polticas
asociadas con recursos. Dado que los servicios Web son recursos, estas propiedades son
heredadas por ellos.
Los conceptos y relaciones en ROM son ilustrados a continuacin:

21
Patrn para el intercambio de dos mensajes entre dos nodos SOAP adyacentes. Un mensaje request es
transferido desde el nodo solicitante al nodo receptor para luego transferir un mensaje response desde el nodo
receptor al nodo solicitante.
22
Patrn para el envo de mensajes que no requiere que el emisor y el receptor estn on-line simultneamente.
Limitado a la transmisin de mensajes desde un nodo emisor a cero o ms nodos SOAP receptores.
23
Patrn por eventos, en el que eventos subscribers indican los eventos de su inters en un broker de eventos para
recibir notificaciones cuando los eventos indicados son generados por los eventos publishers. Permite
interacciones del tipo many-to-many.

21
 75.00 Tesis

[Booth et al.; 2004] Modelo orientado a recursos

Algunos conceptos y relaciones son explicados a continuacin.

Servicio de descubrimiento: utilizado para publicar y buscar descripciones conformes con
ciertos criterios funcionales o semnticos. Facilita a las entidades solicitantes el proceso de
encontrar un agente proveedor apropiado para una tarea particular. Tambin,
dependiendo de la implementacin y polticas de descubrimiento, puede ser utilizado por
entidades proveedoras para publicar sus descripciones de servicio.
En un servicio de descubrimiento dinmico, la interaccin es directa con el agente
solicitante para encontrar el agente proveedor ms conveniente. En un servicio de
descubrimiento esttico, la interaccin es indirecta con una persona a travs de un agente
apropiado, tal como un navegador.

Identificador: la arquitectura utiliza URIs para identificar recursos.

Representacin: pieza de informacin que describe el estado de un recurso.

Recurso: es el corazn de la arquitectura Web. La Web es un universo de recursos. Desde
una perspectiva del mundo real, un aspecto interesante de un recurso es su propiedad. Un
recurso es algo que puede ser apropiado y por lo tanto est sujeto a polticas. Las polticas
aplicadas a recursos son relevantes para la administracin de recursos Web, seguridad de
acceso a servicios Web y otros aspectos del rol que un recurso tiene en el mundo.

Descripcin: procesable por computadora, son utilizadas por los agentes para el
descubrimiento de recursos. Su propsito principal es facilitar descubrimiento de
recursos. Para lograrlo, provee informacin sobre la ubicacin del recurso, accesibilidad y
polticas aplicadas. Cuando el recurso es un servicio Web, la descripcin puede contener
informacin acerca de los efectos esperados de utilizar el servicio. La descripcin de un
servicio es distinta de la representacin. Esta ltima es un snapshot24 que refleja el estado
del recurso, la descripcin consiste de meta-informacin acerca del recurso.

24
En sistemas informticos, es el estado de un sistema en un punto particular en el tiempo.

22
 75.00 Tesis
1.3.4 Modelo de polticas - PM

Tambin llamado PM (Policy Model), se centra en aspectos de la arquitectura relacionados

con polticas y por extensin, a seguridad y calidad de servicio. La seguridad es llevada a
cabo por restricciones sobre el comportamiento de una accin y sobre el acceso a
recursos. Similarmente, la calidad de servicio trata de restricciones sobre el servicio. Hay
otros tipos de restricciones y polticas relevantes para los servicios Web, incluyendo varias
restricciones a nivel de aplicacin.
Los conceptos y relaciones en PM son ilustrados a continuacin:

[Booth et al.; 2004] Modelo orientado a polticas

Algunos conceptos y relaciones son explicados a continuacin:

Guardin: mecanismo que asegura el cumplimiento de polticas. Desplegado en nombre
de un propietario. La arquitectura identifica dos tipos de guardias, a saber, guardia auditor
y guardia de permiso.

Polticas: restringen el comportamiento de agentes, personas u organizaciones, como
permisos y obligaciones, que constituyen tales polticas.

Guardia auditor: mecanismo utilizado en nombre de un propietario para monitorear que
las acciones y los agentes cumplan con la ejecucin de sus obligaciones. No es posible
proactivamente hacer cumplir las obligaciones, por lo tanto, el incumplimiento de una
obligacin resulta en algn tipo de retribucin despus de cometida la falta.

Dominio: conjunto de recursos sujeto a las restricciones establecidas por las polticas.

Obligacin: tipo de poltica que prescribe las acciones y estados de un agente o un recurso.

Permiso: tipo de poltica que prescribe las acciones y estados permitidos de un agente o
recurso.

Guardia de permiso: asegura que los usos de cualquier servicio o recurso son consistentes
con las polticas establecidas por el administrador o propietario del servicio. Ubicado entre
un servicio y un usuario del servicio. Puede permitir o denegar un pedido de acceso. Esto

23
 75.00 Tesis
es posible porque las polticas de permisos son proactivamente controladas.

Descripcin: descripcin procesable de un conjunto de polticas.

1.4 Arquitectura orientada a servicios

1.4.1 Generalidades

Una arquitectura orientada a servicios o SOA (Service Oriented Arquitecture) es definida por
[Newcomer y Lomov; 2004] como un estilo de diseo que dirige los aspectos de crear y
utilizar servicios de negocios a lo largo del ciclo de vida del servicio (desde su concepcin
hasta su retiro). Es tambin una manera para definir y disponer una infraestructura IT que
posibilita a diferentes aplicaciones intercambiar datos y participar en procesos de negocios,
sin considerar los sistemas operativos o lenguajes de programacin que sostienen esas
aplicaciones.

En SOA, los servicios de negocios (servicios para operar con clientes, socios o empleados)
son el principio clave para alinear sistemas IT con los objetivos estratgicos de negocios IT.
Las empresas que implementan sus sistemas IT de esta manera reaccionan ms rpido a
nuevos requerimientos dejando atrs competidores con sistemas ligados a los entornos de
ejecucin. Resulta ms sencillo combinar servicios Web, ms fcil cambiar composiciones de
servicios Web y ms barato cambiar servicios Web y datos XML que cambiar entornos de
ejecucin. Las ventajas de SOA con servicios Web incluyen un mejor retorno de la inversin
(ROI) por los gastos IT en proyectos, proyectos ms rpidos y capacidad para responder en
corto tiempo a nuevos requerimientos de negocios y del gobierno.

La orientacin a servicios reduce los costos y los calendarios de proyectos exitosos por
adaptar la tecnologa a las personas, en lugar de enfocarse en la tecnologa en s. La mayor
ventaja de un desarrollo orientado a servicios es que permite concentrarse en la descripcin
de un problema de negocios en oposicin a enfoques anteriores que prestaban atencin a las
tecnologas de un entorno de ejecucin particular.

El concepto SOA no es nuevo. Lo nuevo es la capacidad para mezclar y asociar entornos de

ejecucin, separando claramente la interfaz de servicio de la tecnologa de ejecucin,
permitiendo que los departamentos IT puedan elegir el mejor entorno de ejecucin para cada
trabajo y vincularlos utilizando un enfoque de arquitectura consistente.

La idea de separar una interfaz de su implementacin para crear un servicio ha demostrado

buenos resultados. Pero la capacidad de separar clara y completamente una descripcin de
servicio de su entorno de ejecucin es nueva, una capacidad otorgada por los conceptos Web
y las tecnologas a los servicios Web. Las implementaciones tradicionales del concepto de
interfaz no consideraron una separacin como sta, debido a las implicaciones negativas de
performance. Sin embargo, algunas veces, la performance es menos importante que la
capacidad para alcanzar ms interoperabilidad, algo que la industria ha luchado por lograr
pero que slo ha conseguido parcialmente [Newcomer y Lomov; 2004].

SOA no depende de avances en software, trados por los servicios Web, sino de un cambio de

24
 75.00 Tesis
enfoque. Separar la descripcin de servicio de la tecnologa de implementacin significa que
los negocios pueden centrarse en pensar y planificar inversiones IT en torno a la realizacin
de consideraciones de negocios, en lugar de ocuparse de las capacidades de un producto
individual o de la tecnologa elegida para ejecutar una descripcin. En este caso, la
descripcin convierte la definicin del conjunto de caractersticas y funciones en el
denominador comn que cualquier producto o tecnologa debe soportar. Sin embargo, esto es
posible si se produce un cambio en la manera de pensar los negocios IT. El mundo es diverso
por naturaleza y un SOA con servicios Web no slo abraza esta diversidad sino que provee la
capacidad para crear sistemas IT acordes con las operaciones de negocios. En un mundo
SOA, las empresas tienen que aprender a pensar servicios como diferentes a entornos de
ejecucin y, adems, a tener que ensamblar aplicaciones a partir de componentes de una
variedad de proveedores IT.

El valor real de SOA proviene de las ltimas etapas de implementacin, cuando nuevas
aplicaciones pueden ser desarrolladas enteramente, o casi enteramente, por componer los
servicios existentes. Es, en este momento, cuando se alcanzan los mayores valores por el
esfuerzo realizado (menores costos, resultados ms rpidos, mejora del ROI). Sin embargo,
toma tiempo alcanzar este punto, adems de una inversin significativa en desarrollo
orientado a servicios.

La clave es determinar el diseo correcto y el funcionamiento de los servicios en bibliotecas

reutilizables, las cuales deben reflejar las caractersticas operacionales de la organizacin.
Estas caractersticas operacionales necesitan ser automatizadas y un proyecto SOA,
finalizado con buen xito, garantiza que los servicios reutilizables se encuentran
apropiadamente alineados con los procesos de negocios operacionales. Una alineacin
correcta de servicios de negocios y su implementacin asegura poder cambiar rpida y
fcilmente los procesos de negocios operacionales a medida que cambios externos causan
que una organizacin se adapte y evolucione.

Las principales dificultades para adoptar SOA incluyen la formacin del personal adecuado y
el mantenimiento del nivel de disciplina que se requiere para garantizar que los servicios
que se desarrollen sean reutilizables. Cualquier tecnologa, por prometedora que sea, puede
ser objeto de abuso y un uso inadecuado. Los servicios deben ser desarrollados no slo para
beneficio inmediato sino principalmente para prestaciones a largo plazo. Dicho de otro
modo, la existencia de un servicio individual no es de mucho valor a menos que se ajuste a
una coleccin ms grande de servicios que puedan ser consumidos por mltiples
aplicaciones y de las cuales nuevas aplicaciones se puedan componer.

Otras dificultades incluyen la gestin de costos a corto plazo. La construccin de un SOA no es

barata; la reingeniera de los sistemas existentes cuesta dinero y el ROI se extiende en el
tiempo. Resulta necesario contar con analistas de negocios para definir los procesos de
negocios, arquitectos de sistemas para convertir los procesos en especificaciones,
ingenieros de software para desarrollar nuevas aplicaciones y lideres de proyecto para
realizar un seguimiento de toda la reingeniera.

Algunas aplicaciones pueden necesitar ser modificadas para participar en SOA y esto podra
representar una dificultad. Estas aplicaciones podran carecer de una interfaz para

25
 75.00 Tesis
convertirlas en servicios. Existen aplicaciones que slo son accesibles va transferencia de
archivos o entrada/salida de datos por lotes y que, por lo tanto, ciertos programas adicionales
resultaran indispensables a fin de habilitarlas como servicios.

1.4.2 Directorio de servicios

Un directorio de servicios permite que ciertos componentes puedan localizar otros

componentes, donde los componentes pueden ser aplicaciones, agentes, proveedores de
servicios Web, usuarios de servicios Web, objetos o procedimientos [Huhns; 2002]. Existen
dos tipos generales de directorios segn sus entradas: white-pages cuyas entradas listan los
nombres de servicios y yellow-pages, cuyas entradas listan las caractersticas y capacidades
de los servicios.

Implementar un directorio bsico es un mecanismo simple como una base de datos que
permite a los participantes insertar descripciones sobre los servicios ofrecidos y consultar
los servicios ofrecidos de otros participantes. Un directorio ms avanzado podra ser ms
activo que otros al proveer no slo bsqueda de servicios sino tambin brokering25 o
facilidades de servicios. Por ejemplo, un participante podra solicitar un servicio de brokering
para reclutar los agentes necesarios a fin de responder una consulta. El servicio de brokering
utilizara la informacin acerca de las caractersticas y capacidades de los proveedores de
servicios registrados para determinar a qu proveedores enviar la consulta. De esta manera,
el directorio podra enviar la consulta a esos proveedores, retornar las respuestas a quien las
solicit y aprender acerca de las propiedades de las respuestas que gestiona.

UDDI es en s mismo un servicio Web basado en XML y SOAP. Provee servicios de white-
pages y yellow-pages pero no facilidades de servicios [Newcomer y Lomov; 2004].

1.4.3 BPM

Un administrador de procesos de negocios (BPM o Business Process Management) denota

un conjunto de sistemas de software relacionados y de metodologas para el desarrollo,
despliegue y manejo de procesos de negocios. Un proceso de negocio puede incluir sistemas
IT que requieran interaccin humana o sistemas IT completamente automatizados.

El objetivo de los sistemas BPM es alinear los sistemas IT con los procesos de negocios y por
lo tanto con los objetivos de negocios.

Todos los sistemas IT implementan procesos de negocios pero BPM separa explcitamente la
lgica de procesos de negocios del cdigo de aplicacin (en contraste con otras formas de
desarrollo de sistema donde la lgica de proceso esta embebida en el cdigo de aplicacin).

25
Desarrollado en la seccin 3.3, Matchmaking entre agentes heterogneos.

26
 75.00 Tesis
Separar la lgica de procesos del cdigo de aplicacin ayuda a aumentar la productividad,
reduce los costos operacionales y mejora la agilidad. Correctamente implementado, las
organizaciones pueden responder rpidamente a condiciones cambiantes del mercado y
aprovechar oportunidades para ganar ventaja competitiva.

BPM simplifica el problema de combinar la ejecucin de mltiples servicios Web para

resolver un problema particular. Si se piensa en un servicio como la alineacin de un sistema
IT con una funcin de negocio, como puede ser el procesamiento de una orden de compra,
BPM estara representado por una capa con varios servicios unidos por un flujo de ejecucin
para completar la funcin. Por definir el flujo de proceso fuera del cdigo de aplicacin, el
proceso de negocio puede ser fcilmente cambiado y actualizado por nuevas caractersticas y
funciones.

El flujo de proceso es dividido en tareas individuales llamadas servicios Web. Cada parte de
un flujo es probado basado en los resultados de ejecutar una tarea.

1.4.4 Gobierno de polticas y procesos

Algunas organizaciones creen haber adoptado SOA simplemente por utilizar tecnologas de
servicios Web como SOAP o WSDL. Sin embargo, SOA no es una aplicacin sino ms bien
una disciplina que abarca casi la totalidad de la actividad IT, incluyendo procesos, mtodos y
herramientas para diseo, desarrollo, administracin y mantenimiento de activos IT.

El propsito de un gobierno26 SOA es alinear los gobiernos de negocios y de software,

incluyendo la coordinacin del desarrollo y la adquisicin de software y su reutilizacin para
lograr mayor agilidad y economa de escala. El gobierno SOA es una extensin del gobierno
IT para manejar servicios y abstracciones a nivel servicios.

La necesidad de un gobierno surge de reconocer que los servicios son activos, proveen una
unidad comn para administracin de requerimientos, acuerdos de servicios (SLA),
performance de negocios y tcnica y reutilizacin de recursos y por lo tanto requieren ser
manejados durante su ciclo de vida.

Un gobierno SOA es un cuerpo dentro de la empresa con representantes de cada dominio de

servicio, de cada unidad de negocio y de expertos en la materia que puedan hablar acerca de
los diferentes componentes tecnolgicos de una solucin.

Entre sus responsabilidades se encuentran establecer las polticas y procesos que permitan
identificar, implementar, desplegar y versionar servicios llevando a cabo un proceso
descentralizado (cada departamento o proyecto es responsable por identificar, implementar y
desplegar servicios) o centralizado (donde el cuerpo de gobierno revisa la adicin,
modificacin y eliminacin de servicios antes de autorizar su implementacin y despliegue),
determinar las herramientas a utilizar (en administracin de proyectos, modelado de
26
Entendido aqu como la accin de dirigir, decidir, guiar.

27
 75.00 Tesis
negocios, modelado de servicios, modelado de datos, desarrollo, administracin de sistemas,
entre otras) y el intercambio de informacin entre ellas y determinar la formacin
obligatoria y opcional de miembros del equipo de SOA y de equipos de proyectos grandes en
la implementacin de procesos y utilizacin de herramientas SOA. En cualquier caso, es
importante que haya algn nivel de estandarizacin que atraviese los departamentos y
proyectos para promover la reutilizacin de servicios.

1.4.5 Especificaciones

Una arquitectura de servicios Web consiste de especificaciones WSDL, SOAP y UDDI, a fin de
soportar interaccin entre un usuario, un proveedor de servicio y algn mecanismo
potencial para descubrimiento de servicios. Un proveedor publica una descripcin WSDL de
sus servicios en un registro UDDI (o algn otro tipo de registro), otro agente accede a la
descripcin publicada y enva un mensaje SOAP al proveedor solicitando la ejecucin del
servicio.

Segn el W3C, WSDL es un protocolo de comunicacin. Define una gramtica XML para
describir los servicios Web como una coleccin de endpoints capaces de intercambiar
mensajes. Es utilizado frecuentemente en combinacin con SOAP. Un programa cliente
conectndose a un servicio Web puede leer su archivo WSDL a fin de determinar cules
operaciones estn disponibles en el servidor. El cliente luego utiliza SOAP para invocar
alguna de las operaciones listadas.

WSDL 2.0 es la ltima versin de la especificacin y fue aprobada en el ao 2007 por el W3C.
Esta especificacin soporta todos los mtodos HTTP request, ubicndola como el mejor
soporte para servicios Web RESTful27, adems de ser mucho ms simple de implementar. Sin
embargo, todava son pocas la herramientas que la incluyen entre sus funcionalidades
ofrecidas y pocas las aplicaciones que la incluyen en sus implementaciones (la ltima versin
de BPEL28 slo soporta WSDL 1.1).

WSDL define un servicio como una coleccin de endpoints (WSDL 2.0) o ports (WSDL 1.1).
Un endpoint, a su vez, es definido por asociar una direccin de red con una interfaz
reutilizable. Los mensajes describen de manera abstracta los datos intercambiados y los
portypes (se explica ms abajo su significado), de manera abstracta tambin, el conjunto de
operaciones disponibles. El protocolo concreto y el formato de datos de un portype particular
constituyen un binding reutilizable, donde las operaciones y los mensajes son vinculados a un
protocolo de red concreto y a un formato de mensaje. De esta manera WSDL define la
interfaz pblica de un servicio. Los elementos que componen WSDL son presentados e
identificados a continuacin, segn su denominacin en WSDL 1.1/WSDL 2.0:

27
Desarrollado en las siguientes secciones
28
El Business Process Execution Language, nombre corto del Web Services Business Process Execution Language
(WS-BPEL) es un lenguaje ejecutable estndar OASIS (consorcio global que dirige el desarrollo, convergencia y
adopcin de estndares e-business y servicios Web) por especificar las acciones que ocurren dentro de los procesos
de negocios con servicios Web. Los procesos en BPEL exportan e importan informacin por utilizar interfaces de
servicios Web exclusivamente.

28
 75.00 Tesis

Types/Types: contiene las definiciones de los tipos de datos utilizados. XML-Schema es
utilizado (inline o por referencia) para este propsito.

Message/No aplica: un mensaje corresponde a una operacin. El mensaje contiene la
informacin necesaria para ejecutar la operacin. Cada mensaje consiste de una o ms
partes lgicas. Cada parte est asociada con un atributo del tipo de mensaje. El atributo
nombre del mensaje provee un nombre nico entre todos los mensajes. El atributo
nombre de la parte provee un nombre nico entre todas las partes que conforman el
mensaje. Las partes son una descripcin lgica del contenido del mensaje. Los mensajes
fueron removidos en WSDL 2.0 donde los tipos XML-Schema para definir los input, output
y faults (entradas, salidas y fallas) son referidos directamente.

Operation/Operation: cada operacin puede ser comparada con la llamada a un mtodo o
funcin en un lenguaje de programacin tradicional. Define las acciones SOAP y la manera
en que el mensaje SOAP es codificado (por ejemplo un valor literal indica que el
mensaje es intercambiado tal cual es, sin informacin de tipo incluida, un valor encoged,
en cambio, indica que se trata de un mensaje con informacin de tipos incluida).

PortType/Interface: el elemento portype fue renombrado en WSDL 2.0 como interface.
Define las operaciones que pueden ser ejecutadas y los mensajes empleados para ejecutar
la operacin.

Binding/Binding: especifica la interfaz, define el estilo de binding SOAP (RPC/Document)
y transporte (protocolo SOAP).

Port/Endpoint: definido por una combinacin binding - direccin de red, a menudo, es
representado mediante un URL HTTP.

Service/Service: coleccin de endpoints relacionados que representa el conjunto de las
funciones de sistema que han sido expuestas basadas en los protocolos Web.

WSDL no introduce un lenguaje para la definicin de tipos sino que debido a la importancia de
incorporar sistemas de tipos poderosos para describir mensajes a largo plazo soporta XSD
como sistema de tipos cannico y permite utilizar otros lenguajes de definicin de tipos va
extensibilidad.

WSDL introduce extensiones especficas de binding para los siguientes protocolos y

formatos de mensajes: SOAP, HTTP GET/POST y MIME.

Segn el W3C, SOAP es un protocolo para intercambiar informacin estructurada en

entornos descentralizados o distribuidos. Emplea tecnologas XML para definir un marco
extensible de mensajes proporcionando una estructura de mensaje que puede ser
intercambiada sobre una variedad de protocolos de transporte.

Las ventajas que ofrece la especificacin SOAP incluyen independencia de cualquier lenguaje
de programacin, independencia del protocolo de transporte, independencia de cualquier
infraestructura de objetos distribuidos, utilizacin de estndares como XML para codificacin
de los mensajes y de HTTP y SMTP como protocolos de transporte y permite
interoperabilidad entre mltiples entornos.

29
 75.00 Tesis

Aparte de las especificaciones principales de servicios Web (WSDL y SOAP) existen otras
especificaciones que extienden los servicios Web como especificaciones de seguridad,
confiabilidad, transacciones, administracin de metadatos y orquestacin, las cuales proveen
soluciones basadas en SOA a un nivel de calidad de servicio empresarial en proyectos
corporativos grandes y de misin crtica.

1.5 Servicios Web RESTFul

En general, los servicios Web son construidos utilizando SOAP y estndares WS-*29 pero los
servicios Web REST30 prescinden de SOAP y utilizan HTTP y XML [Mandel; 2008]. Cada uno
de estos estilos de arquitectura de servicios Web es ampliamente utilizado por la comunidad
de desarrollo.

REST es un estilo de arquitectura que trata a la Web como una aplicacin centrada en
recursos. Los principios de diseo claves de esta arquitectura enuncian que 1) las
aplicaciones RESTFul deben ser stateless, es decir, que cada mensaje HTTP debe contener
toda la informacin necesaria para procesar una peticin. Como resultado, ni el cliente ni el
servidor necesitan recordar ningn estado de las comunicaciones entre mensajes (en la
prctica un nmero de aplicaciones basadas en HTTP utilizan cookies y otros mecanismos a
fin de mantener el estado de la sesin, algunas de las cuales no son permitidas por REST); 2)
un conjunto de operaciones bien definidas mediante el estilo CRUD31 el cual a su vez utiliza
el amplio rango de verbos HTTP (POST, GET, PUT y DELETE); 3) una sintaxis universal para
identificar recursos (URI) y 4) utilizacin de hipermedios, explicado a continuacin.

El Dr. Roy Fielding acu el trmino REST en la disertacin de su Ph.D.32 donde refiri los
hipervnculos como el motor de los estados de la aplicacin. Esto significa que para que una
transicin pueda tener lugar, ya sea por cambiar el estado de un recurso o por transferir a
otro recurso, un recurso debe contener hipervnculos. Mientras los hipervnculos son
pensados para consumo humano, en general, no son utilizados en XML, los cuales, a su vez,
son pensados para ser procesados por computadora. Los servicios Web REST (al igual que
HTML) renen ambas caractersticas por utilizar hipervnculos en XML.

29
Se refiere a las especificaciones que extienden los servicios Web: WS-Addressing, WS-Security, WS-Policy, WS-
Transactions, son algunas de ellas.
30
REpresentational State Transfer refiere a una arquitectura de servicios Web basada en recursos
31
Acrnimo para create, read, update y delete.
32
Philosophy Doctor significa Doctorado en investigacin. Reconocimiento al doctorando sobre su capacidad de
hacer investigacin cientfica a partir de la presentacin de una tesis doctoral que represente una contribucin al
menos modesta al conocimiento humano.

30
 75.00 Tesis
Captulo II

Ontologa

2.1 Generalidades

Un modelo conceptual es la descripcin de un dominio de inters (sus conceptos y

relaciones). En el campo de la informtica, los modelos conceptuales deben transformarse de
tal manera que puedan almacenarse en la memoria de los ordenadores y permitan aplicar
algoritmos.

El propsito de las ontologas (originarias del campo de la Inteligencia Artificial) se apoya en

proporcionar los modelos conceptuales almacenables y computables. En informtica, una
ontologa designa la descripcin de un dominio mediante un vocabulario comn de
representacin.

La definicin ms citada es la de [Gruber; 1993]: una ontologa es una especificacin

explcita de una conceptualizacin. Una conceptualizacin es una visin abstracta,
simplificada del mundo. Toda base de conocimiento, utilizada por un sistema o un agente de
conocimiento est vinculada, explcita o implcitamente, a una conceptualizacin.

Una ontologa es un vocabulario controlado que describe de manera formal los objetos y las
relaciones entre ellos, y proporciona una gramtica para utilizar los trminos del vocabulario
con el fin de expresar algo con significado, dentro del dominio de inters especfico. El
vocabulario puede ser empleado para hacer bsquedas y aserciones.

Los compromisos ontolgicos acuerdan utilizar el vocabulario de una manera consistente a

fin de compartir conocimiento.

Las ontologas pueden incluir glosarios, taxonomas y diccionarios pero normalmente tienen
mayor expresividad y reglas ms estrictas que las anteriores.

Una ontologa formal es un vocabulario controlado que se expresa en un lenguaje de

representacin de ontologas. Es conveniente aclarar que una ontologa formal es una
semntica formal, es decir, describe el significado del conocimiento de manera precisa,
logrando una interpretacin nica por parte de mquinas y personas, y utiliza lgica de
primer orden o un subconjunto de ella (como la lgica descriptiva). Disponer de una
semntica formal resulta indispensable para implementar sistemas de inferencia o de
razonamiento automtico.

Las ontologas son, tambin, una herramienta para compartir informacin y conocimiento,
es decir, para conseguir interoperabilidad. Al definir un vocabulario formal de los conceptos
del dominio y un conjunto de las relaciones entre ellos, permiten que las aplicaciones
comprendan la informacin.

31
 75.00 Tesis
Por lo general, las ontologas toman la forma de una jerarqua de trminos que representan
los conceptos bsicos de un determinado dominio. En el entorno de la Web lo usual es
representarlas en formato XML. A diferencia de las ontologas, XML carece de una semntica
que permita razonamiento automtico.

Segn [Tello; 2001] para representar conocimiento de dominio, las ontologas poseen los
siguientes componentes:

Conceptos: ideas bsicas que se intentan formalizar. Pueden ser clases de objetos,
mtodos, planes, estrategias, procesos de razonamiento, etc.

Relaciones: representan la interaccin y enlace entre los conceptos de dominio. Suelen
formar la taxonoma de dominio: subclase de, parte de, parte exhaustiva de,
conectado a, etc.

Funciones: son un tipo concreto de relacin donde se identifica un elemento mediante el
clculo de una funcin que considera varios elementos de la ontologa. Por ejemplo, pueden
aparecer funciones como categorizar clase, asignar fecha, etc.

Instancias: se utilizan para representar objetos que pertenecen a un concepto
determinado.

Axiomas: proposiciones que se declaran sobre las relaciones que deben cumplir los
elementos de la ontologa. Por ejemplo: Si A y B son de clase C, entonces A no es subclase
de B, Para todo A que cumpla condicin C1, A es B, etc.

Los axiomas, junto a la herencia de conceptos, permiten inferir el conocimiento oculto detrs
de una taxonoma de conceptos.

La Web, vista como una gran fuente de conocimiento, requiere de lenguajes apropiados para
representar ontologas. En este sentido, RDFS soporta algunos aspectos sobre conceptos de
dominio y permite crear, mediante relaciones taxonmicas, una jerarqua. Sin embargo, sirve
mejor como base de lenguajes con mayor expresividad y capacidad de razonamiento. Tello
sostiene que, a fin de potenciar la utilizacin de ontologas en la Web, se debera disponer de
aplicaciones de bsqueda de ontologas a fin de que los usuarios puedan utilizarlas en sus
sistemas.

La unificacin de contenidos semnticos que formalicen conocimiento consensuado y

reutilizable a travs de ontologas, conduce a la Web Semntica y, por lo tanto, a ventajas
como el desarrollo de aplicaciones con esquemas de datos compartidos, fomento de
transacciones entre empresas y bsqueda de informacin por inferencias.

Segn [Dickinson; 2009] RDFS es el lenguaje ontolgico ms dbil. Menciona que con RDFS
es posible construir una jerarqua de conceptos y propiedades simples pero no es posible
construir expresiones interesantes. Afirma que RDFS es suficiente para aplicaciones que
slo necesiten de un vocabulario bsico.

Por otro lado, existen ontologas profundas y poco profundas. Las ontologas profundas
requieren de considerables esfuerzos para construir y desarrollar conceptualizaciones y,

32
 75.00 Tesis
algunos ejemplos se pueden encontrar en ciencia e ingeniera. Las ontologas poco
profundas, en cambio, comprenden algunas conceptualizaciones que son trminos fijos y
que permiten organizar grandes cantidades de datos.

La complejidad asociada a las ontologas profundas ha llevado a buscar diferentes enfoques

como las folksonomas33, las cuales son utilizadas principalmente dentro del contexto de la
Web 2.034.

En el proceso de desarrollo de una ontologa, la dificultad real es comprender el problema a

modelar y lograr un acuerdo a nivel comunidad. En esta lnea, RDFS y OWL proveen el marco
para formalizar ontologas en un lenguaje especfico; el tiempo y la energa necesarias para
aprender y utilizar estos lenguajes es slo una fraccin mnima del tiempo requerido en el
desarrollo de una ontologa. Herramientas de desarrollo de ontologas como Protg o
SWOOP, ocultan la complejidad de sintaxis y permiten al usuario concentrarse en temas de
representacin real.

2.2 Folksonomas y ontologas

El trmino folksonoma deriva de taxonoma y es un neologismo atribuido a Thomas Vander

Wall. Literalmente folksonoma significa clasificacin gestionada por el pueblo.

Una folksonoma es el resultado del tagging35 de informacin y objetos36, el cual es personal,

libre y contempla la posterior recuperacin de informacin por parte de otros usuarios. Este
proceso de tagging conduce a un ndice de tags que sirve como herramienta de bsqueda y
acceso a otros recursos.

Partiendo de premisas como distribucin y desnormalizacin del trabajo de indizacin37, una

folksonoma habilita a los usuarios a indizar recursos utilizando cualquier palabra que
deseen. Esta dimensin colectiva y colaborativa le otorga al proceso de tagging el nombre de
indizacin social. La indizacin social representara un nuevo modelo de indizacin, en el
que los usuarios llevaran a cabo la descripcin de los recursos. Una agregacin de todas las
descripciones (un mismo recurso sera indizado por numerosos usuarios) dara como
resultado una descripcin intersubjetiva y ms fiable que la realizada por el autor del recurso
[Navoni y Gonzlez; 2009].

33
Desarrollado en la siguiente seccin.
34
El trmino es empleado para enfatizar el carcter social de la red. Prcticamente todas las herramientas que
definen la Web 2.0 (blogs, wikis, Flickr, You Tube, RSS, folksonomas, entre otras) son calificadas como software
social a travs de las cuales se crean comunidades, se exponen conocimientos de forma abierta y se desarrolla
aprendizaje colaborativo. El poder de la colectividad es completo en los blogs, las wikis, el editor de videos You
Tube, la herramienta para colgar fotos Flickr, el sistema de gestin de favoritos del.icio.us., los cuales, permiten al
usuario aadir valor, elegir, decidir, ser parte activa del proceso de construccin de la red que ms que nunca tiene al
usuario en el centro de la escena. A diferencia de la Web 1.0, caracterizada, entre otras cosas, por un usuario receptor
pasivo.
35
Etiquetado realizado en un contexto social
36
Aqu refiere a recursos Web
37
Se refiere a un cambio en los mtodos habitualmente aplicados en los procesos de indizacin. La indizacin
consiste en registrar los datos ordenadamente, a fin de elaborar un ndice con ellos.

33
 75.00 Tesis
Las folksonomas tienen a su favor simplicidad en su utilizacin y posibilidades constantes
de expansin y actualizacin. Pero presentan problemas de representacin de informacin
en lenguaje natural y no poseen herramientas de control de vocabulario. Hacer uso de esta
opcin requiere disear sistemas que procuren integrar las folksonomas con los
vocabularios controlados ya existentes de las aplicaciones.

La naturaleza mltiple del tagging y la falta de control de su terminologa hacen que las
folksonomas sean incapaces de representar de forma consistente un dominio o contexto
especfico y de brindar estructuras slidas de navegacin entre conceptos.

Las ontologas se encuentran en las antpodas de las folksonomas. Las ontologas son
diseadas por expertos para hacer explcito y unvoco el significado de los documentos
utilizados en la comunicacin interpersonal, en las interacciones humano-computadora y
computadora- computadora. Expresan conceptualizaciones formales de un rea del
conocimiento a travs de conceptos (clases), casos (individuos) y las relaciones entre ellos.

Las ontologas parten de relaciones jerrquicas como base estructural para disear un
dominio y van ms all permitiendo definir y modelar libremente relaciones entre conceptos
de un mismo dominio, haciendo explcitas todas las interrelaciones posibles y volviendo
transparente su estructura conceptual. Las ontologas son una representacin formal y
explcita de la estructura conceptual del campo sobre el cual se est trabajando, logrando
economizar la codificacin de la informacin al incluir a la herencia38 como mecanismo de
inferencia. Las ontologas funcionan como base de conocimiento de una comunidad (al
contener informacin sobre reas, objetos y contextos), pudiendo ser utilizadas en
aplicaciones de representacin y recuperacin de informacin como estructuras de
navegacin interconceptual para indizar o buscar informacin.

Las ontologas y las folksonomas presentan caractersticas complementarias que, explotadas

de manera conveniente, pueden generar sinergias productoras de ms valor mediante apoyo
mutuo y suma de ventajas.

Las aplicaciones basadas en folksonomas se benefician de su naturaleza dinmica y

extensible y, de su potencial para canalizar la colaboracin entre usuarios (por habilitar
mecanismos sencillos de indizacin).

Las aplicaciones basadas en ontologas explotan su rigor y son capaces de ofrecer una
estructura de conocimiento bien definida, respuestas basadas en razonamiento lgico y el
formalismo necesario para el back-end de la aplicacin.

Como alternativa, las folksonomas pueden ser enriquecidas con ontologas aplicndolas en
el backstage39 del tagging social a fin de realizar recomendaciones por tags relacionados
explcita e implcitamente. Otra alternativa es utilizar las ontologas como mecanismo de

38
Los conceptos superiores transmiten sus caractersticas a los conceptos inferiores.
39
Detrs de escena. Se refiere a una implementacin que ofrezca sugerencias de tagging o asista en las bsquedas
al usuario.

34
 75.00 Tesis
ampliacin de consultas, por medio de tags relacionados, dentro de las plataformas del tagging
social.

De la misma manera, las ontologas pueden ser enriquecidas con folksonomas, brindando
informacin acerca del vocabulario empleado en el tagging de documentos y, por lo tanto,
capturando el lenguaje de uso actual, ayudando a actualizar los sistemas existentes y a evaluar
la oportunidad, perceptibilidad e idoneidad de un sistema de representacin de conocimiento
diseado por profesionales. Los trminos de la folksonoma pueden, de esta forma, utilizarse
como sugerencias para nuevos trminos (conceptos o individuos) controlados.

El tagging, a escala Web es un desarrollo novedoso como fuente potencial de metadatos y

posibilita que las folksonomas puedan emerger como una variante de bsqueda por
palabras claves en el proceso de recuperacin de informacin [Berners-Lee et al.; 2006].
Pero mientras las ontologas son definidas siguiendo un proceso cuidadoso, explcito, de
inferencia lgica y sin ambigedades, los tags, por el contrario, son definidos siguiendo un
proceso arbitrario, implcito, de inferencia estadstica y con la presencia de ambigedades.

2.3 Lgica y ontologas

Los trminos lgica de predicados, lgica descriptiva o lgica son utilizados frecuentemente
cuando se trata la Web Semntica o alguna de sus partes, como las ontologas. En esta seccin
se expone en qu consisten y la utilidad que brindan en este contexto.

Para las mquinas actuales, el trmino comprender no debe entenderse en el sentido de la

comprensin humana40 sino en el de inferir, deducir. Las mquinas son capaces de inferir
conclusiones a partir de datos mediante procesos lgico-matemticos. Estos datos
incorporan informacin en los documentos en la forma de metadatos y por medio de un
lenguaje formal41, posibilitando que las mquinas puedan procesar la informacin mediante
la aplicacin de reglas lgicas y seguidamente extraer inferencias lgicas.

Segn [Abin; 2005] la Lgica resulta de suma relevancia en la Web Semntica por tres
motivos, a saber: 1) permite desarrollar lenguajes formales para representar conocimiento;
2) proporciona semnticas bien definidas42; 3) proporciona reglas de inferencia a partir de
las cuales se pueden extraer consecuencias del conocimiento. Lo que se conoce como
interpretacin semntica automtica de documentos no pasa de ser la aplicacin de reglas
lgicas a datos presentados en algn lenguaje formal (como OWL o DAML+OIL).

Los lenguajes formales (OWL o DAML+OIL) se basan en lgica descriptiva. La lgica

descriptiva proporciona un formulismo para representar y expresar conocimiento humano,
basndose en mtodos de razonamiento bien establecidos y procedentes de un subconjunto
de la lgica de predicados o lgica de primer orden43. Los lenguajes naturales no resultan ser
los ms apropiados para expresar conceptos sin ambigedad. Con la lgica que hay detrs de
los lenguajes de la Web Semntica, las mquinas pueden realizar inferencias de manera

40
Asociacin automtica entre los smbolos y los conceptos que realiza el cerebro humano a partir de la
informacin almacenada a lo largo de la vida de una persona.
41
Lenguaje lgico y axiomtico o lenguaje de representacin de conocimiento.
42
Se refiere a un sistema lgico donde cada smbolo y cada expresin tiene un significado nico y preciso
43
Ms conocido en ingls como First Order Logic o FOL.

35
 75.00 Tesis
similar a los humanos, y justificarlas. Los usuarios de la Web Semntica no tienen que
preocuparse por conocer la lgica formal de los lenguajes, sino modelar mediante dichos
lenguajes, las reas de conocimiento de inters; luego, los lenguajes realizarn las inferencias
correspondientes a los datos introducidos.

La lgica de primer orden permite establecer formalmente sentencias sobre cosas y

colecciones de cosas, sus tipos y propiedades, y tambin, clasificarlas y describirlas.

En la lgica de primer orden, cada sentencia se divide en un sujeto y un predicado, donde el

predicado modifica o define las propiedades del sujeto. En sta lgica, los predicados siempre
se refieren a individuos u objetos y los cuantificadores ( para todo, existe) slo se
permiten para individuos. Las sentencias se expresan en la forma R(x), donde R es el
predicado y x es el sujeto, formulado como variable. R(x) es una funcin proposicional; estas
funciones se convierten en proposiciones sujeto-predicado cuando se asignan valores a sus
predicados. Por ejemplo, Todos los hombres son dbiles se expresa en lgica de primer
orden:

x: P(x) -> M(x)

Donde P representa el predicado es hombre y M representa el predicado es dbil. Por las

reglas del modus ponens, un sujeto Adn por ser hombre es dbil

P(Adn) - > M(Adn)

Ciertos subconjuntos de la lgica de primer orden, especializados en clasificar cosas, se

denominan lgicas descriptivas. Si bien las lgicas descriptivas carecen de la potencia
expresiva de la LPO44 (no pueden expresar tantas cosas como sta) son matemticamente
trazables y computables.

2.4 Aplicaciones

Una de las reas de aplicacin ms prominente de las ontologas es la medicina y ciencias de

la vida, entre las que se destacan las ontologas Systematized Nomenclature of Medicine
Clinical Terms (SNOMED CT)45, GALEN46, el Foundational Modelo of Anatomy (FMA)47, el
National Cancer Institute (NCI) Thesaurus48 y el OBO Foundry49. Todas en OWL. Este tipo
de ontologas estn reemplazando gradualmente a los clasificadores mdicos existentes por
plataformas que renen y comparten conocimiento mdico. Por capturar los registros
mdicos empleando ontologas se reduce la posibilidad de errores de interpretacin en los
datos y posibilita el intercambio de informacin entre diferentes aplicaciones e institutos.

El W3C afirma que las ontologas pueden mejorar las aplicaciones Web existentes y abrir
nuevos usos de la Web y describe seis casos de aplicacin los cuales son desarrollados a
continuacin:

44 Lgica de primer orden.

45
http://www.birncommunity.org
46
http://www.opengalen.org/
47
http://sig.biostr.washington.edu/projects/fm/index.html
48
http://www.cancer.gov/
49
http://www.obofoundry.org/

36
 75.00 Tesis
El primer caso de aplicacin es un portal Web. Un portal Web es un sitio con informacin
sobre algn tema en especial. Las personas interesadas en un determinado tema pueden
recibir noticias, participar de una comunidad o seguir enlaces a otros recursos de inters.
Para que un portal Web sea til debe tener un punto de partida que describa el contenido
interesante del sitio. Habitualmente, el contenido es subido por miembros de la comunidad
y agrupado mediante tagging 50 o indizado bajo algn subtema de inters. No obstante, la
indizacin puede carecer de la habilidad requerida para la bsqueda. Para permitir una
agrupacin ms inteligente, los sitios Web pueden definir una ontologa acorde con la
comunidad y realizar inferencias para obtener resultados imposibles en los sistemas
convencionales actuales. Esta tcnica requiere un lenguaje de ontologa que posibilite
capturar relaciones con alta calidad (mayor detalle). Un ejemplo de un portal basado en
ontologa es OntoWeb51.

El segundo caso de aplicacin corresponde a las colecciones multimedia. Las ontologas

pueden proveer de anotaciones semnticas a las colecciones de imgenes, audio u otros
objetos no textuales. Para los ordenadores es ms difcil extraer significado semntico de la
multimedia que del texto. Estos recursos son indizados mediante captions52 o metatags53.
Las ontologas, idealmente capturaran el conocimiento adicional acerca del dominio para
mejorar la recuperacin de imgenes.

El tercer caso de aplicacin es sobre la administracin de un sitio Web corporativo. Las

corporaciones tienen varias pginas Web concernientes a comunicados de prensa, ofertas
de productos, estudios de casos, procedimientos corporativos, white-papers, etc. Las
ontologas pueden ser utilizadas para indizar estos documentos y prestar mejores medios
de recuperacin. Las corporaciones emplean taxonomas para organizar la informacin, las
cuales resultan insuficientes dado que las categoras constitutivas quedan restringidas a la
representacin de un dominio. La habilidad de trabajar con mltiples ontologas hara a las
descripciones ms completas y las bsquedas por parmetros seran ms tiles que las
bsquedas por palabras claves con taxonomas.

El cuarto caso de aplicacin tiene relacin con la documentacin empleada en ingeniera.

Los documentos sobre diseo, por ejemplo, tienen una estructura diferente a los
documentos de testing o a los documentos de produccin. La definicin y descripcin
completa de algn tem dado es obtenida por seguir la traza de los documentos
relacionados. Las ontologas serviran para construir un modelo de informacin que
permitira la exploracin del espacio de informacin (en trminos de representacin,
asociacin y propiedades de tems), con enlaces a las descripciones y definiciones de tems
a fin de conseguir la documentacin completa. Esto significa que las ontologas y
taxonomas no son independientes de los tems fsicos que representan pero pueden ser
desarrolladas/exploradas en tndems. Este tipo de ontologas tambin podran ser
utilizadas para la visualizacin y edicin de grficos las cuales mostraran capturas del
espacio de informacin, sobre un concepto en particular (diagramas de actividades, reglas
o diagramas de entidad-relacin).

50
Desarrollado en la seccin 2.2 Folksonomas y ontologas.
51
http://www.ontoweb.org/
52
Ttulos
53
Tags sobre los tags

37
 75.00 Tesis
El quinto caso de aplicacin describe un escenario con agentes y servicios. La Web
Semntica provee agentes con la capacidad de comprender e integrar diversos recursos de
informacin. Un ejemplo es un planificador de actividades sociales que toma las preferencias
del usuario (tipos de pelculas, tipo de comidas, etc.) para planear una salida. La tarea de
planificar las actividades depende de la variedad del entorno de servicios ofrecidos y de las
necesidades del usuario. Durante el proceso de bsqueda se pueden consultar comentarios y
tarifas de servicios a fin de encontrar aquellos que mejor se ajusten a las preferencias del
usuario. Este tipo de agente requiere ontologas de dominio que representen los trminos
relacionados a restaurantes, hoteles, etc. y ontologas de servicios con trminos relacionados
a servicios reales, permitiendo capturar informacin interesante para el usuario. Tal
informacin puede ser provista por un nmero de fuentes, como portales, sitios de servicios,
sitios de reservas y la Web en general.
En un escenario como el descripto es necesario resolver cuestiones relacionadas con:

Uso e integracin de mltiples ontologas separadas a travs de diferentes dominios y
servicios,

Ubicacin distribuida de ontologas a travs de Internet,

Ontologas potencialmente diferentes para cada dominio o servicio (traslacin de
ontologas/referencias cruzadas),

Representacin simple de ontologas.

El sexto caso de aplicacin es sobre ubiquitous computing54 El ubiquitous computing es un

paradigma emergente del personal computing55, caracterizado por desplazar la
capacidad de procesamiento de los ordenadores al entorno cotidiano de las personas.
Dispositivos de procesamiento pequeos, wireless y de mano son ejemplos de ubiquitous
computing. La naturaleza wireless y ubicua de estos dispositivos requieren arquitecturas
de red que soporten configuracin automtica y ad-hoc a fin de simplificar al usuario el
manejo de los mismos.

Una tecnologa clave de las redes ad-hoc es el descubrimiento de servicios (funciones

ofrecidas a dispositivos como telfonos celulares, impresoras, etc.). El descubrimiento de
servicios y los mecanismos de descripcin de capacidades estn basados en esquemas de
representacin ad-hoc y dependen fuertemente de la estandarizacin. El objetivo que
persigue ubiquitous computing es la interoperabilidad fortuita, es decir, que dispositivos
que no fueron necesariamente diseados para trabajar juntos (por ser construidos con
diferentes propsitos, por diferentes fabricantes, en diferentes tiempos, etc.) puedan
descubrir y tomar ventaja de la funcionalidad del otro. Los escenarios ubiquitous
computing involucran un nmero considerable de dispositivos y, llevar a cabo una
estandarizacin a priori, de los casos de aplicacin, sera una tarea inmanejable. Por eso
comprender otros dispositivos y razonar acerca de sus servicios/funcionalidad se vuelve
indispensable. Los escenarios de interoperacin son dinmicos por naturaleza (los
dispositivos aparecen y desaparecen en cualquier momento debido al movimiento de los
propietarios). Las tareas en la utilizacin de servicios involucran descubrimiento,
contratacin y composicin. Un contrato de servicios requiere representar informacin
sobre seguridad, privacidad, confianza y detalles relacionados a la compensacin de
servicios.

54
Computacin ubicua. Ubicua denota lo que esta presente al mismo tiempo y en todas partes. Omnipresente.
55
Computacin personal.

38
 75.00 Tesis
En este contexto, un lenguaje de ontologa podra ser de utilidad en la descripcin de las
caractersticas, los medios de acceso, las polticas de uso de los dispositivos y dems
restricciones tcnicas y los requerimientos que afecten incorporar un nuevo dispositivo en
una red ubiquitous computing.

2.5 Lenguajes ontolgicos

2.5.1 RDF

2.5.1.1 Conceptos Bsicos

Segn el W3C, el Resource Framework Description (RDF) es un lenguaje para representar

recursos Web56, apoyndose en ideas de Inteligencia Artificial, grafos conceptuales y de
representacin de conocimiento basado en lgica, entre otras y, cuyo objetivo radica en
especificar datos en XML de manera estandarizada a fin de posibilitar interoperabilidad.
Debido a su carcter general, tambin puede ser utilizado para representar datos
simplemente.

Segn [Dickinson; 2009] es un lenguaje ontolgico dbil que permite construir jerarquas de
conceptos y propiedades siendo suficiente para aplicaciones que slo necesitan establecer un
vocabulario bsico. [Abin; 2005] prefiere definir que si bien RDF es un modelo de
representacin de metadatos puede utilizarse como lenguaje general para la representacin
del conocimiento.

En RDF, la construccin bsica es la tripla (sujeto, propiedad, objeto). Toda tripla RDF
corresponde a una sentencia RDF: la parte que identifica a qu se refiere la sentencia es el
sujeto; la parte que identifica la caracterstica del sujeto es la propiedad o predicado y la parte
que identifica el valor de la propiedad es el objeto.

Los sujetos, las propiedades y los objetos son recursos. Los recursos con los que trabaja RDF
no son necesariamente recursos presentes en la Web. En general, un recurso RDF es
cualquier cosa con identidad. Para identificarlos se recurre a URIs57.

Los URIs no tiene significado por s mismos: son identificadores y la persona u organizacin
que los crea se responsabiliza de otorgarles significado. Un concepto puede tener asociados
diferentes URIs. Dos empresas pueden asignar un significado distinto a una propiedad y
utilizar para ello dos URIs distintos. Dos o ms recursos pueden utilizar el mismo URI,
reflejando una comprensin compartida de un concepto.

56
Los recursos Web refieren aqu a dispositivos fsicos (impresoras, ordenadores, agendas electrnicas) o estructuras
de datos de software (pginas web, imgenes, videos, directorios) accesibles a travs de una red.
57
Uniform Resource Identifier o identificador uniforme de recurso. La principal diferencia con URL es que el
URI no se limita a identificar entidades con localizaciones en la Web o accesibles mediante aplicaciones
informticas. Cualquier organizacin o persona puede crear sus URIs y utilizarlos para trabajar con sus
dominios de inters. Frente a URL, el URI permite referirse a un mismo recurso ubicado en distinta
localizaciones.

39
 75.00 Tesis
Las triplas RDF pueden representarse en forma grfica mediante grafos (los nodos
corresponden a recursos y los arcos a propiedades) o en formato RDF/XML (representacin
XML de RDF). La ventaja de utilizar este ltimo estriba en poder reutilizar todas las
herramientas existentes para XML (analizadores sintcticos, transformaciones XSLT,
representaciones en memoria de objetos XML mediante DOM/SAX, etc.). Es oportuno aclarar
que RDF no est ligado a XML; se puede utilizar otra representacin para RDF, sin que ello
produzca cambios en la sintaxis de triplas y su semntica.

Cada persona u organizacin puede definir su propio vocabulario mediante un esquema RDF
llamado RDFS (RDF Schema). Un esquema permite comprobar si un conjunto de triplas RDF
es vlido para el esquema o no (comprobar si las propiedades aplicadas a los recursos son
correctas y si los valores vinculados a las propiedades tienen sentido). RDFS permite controlar
la validez de los valores y restringir las entidades a las cuales pueden aplicarse ciertas
propiedades.

El modelo de metadatos que RDFS permite expresar coincide con el de los lenguajes de
programacin orientada a objetos pues permite expresar clases e instancias. Cabe sealar
que las propiedades definidas en RDFS son globales; esto es, no estn encapsuladas como
atributos en las definiciones de clases. A diferencia de lo que ocurre en LOO58, RDFS permite
asignar a una clase, sin modificarla, nuevas propiedades.

Las restricciones que RDFS introduce son anlogas a las empleadas en lenguajes OO con
tipos.

Tabla Clases RDF predeterminadas

Clase Descripcin rdfs:type Subclase de
rdfs:Class Clase de todas las clases. Equivalente al rdfs:Class
concepto de clase en LOO
rdfs:Resource Toda cosa descripta por RDF es un recurso rdfs:Class
e instancia de rdfs:Resource
rdfs:Literal Clase para los literales rdfs:Class rdfs:Resource
rdfs:Datatype Clase para los literales tipados como rdfs:Class rdfs:Literal
Datatype
rdf:XMLLiteral Clase para XML literal rdfs:Datatype rdfs:Literal
rdf:Property Clase para las propiedades RDF rdfs:Class
rdf:Statement Clase para representar un statement RDF. rdfs:Class
rdfs:Container Clase para representar contenedores. rdfs:Class
rdf:Bag Clase para indicar un contenedor sin orden rdfs:Class rdfs:Container
rdf:Seq Clase para indicar un contenedor con rdfs:Class rdfs:Container
orden
rdf:Alt Clase para indicar un contenedor donde rdfs:Class rdfs:Container
slo se elige uno de los miembros. La
eleccin por defecto es el valor de la
property rdf:_1
rdf:List Clase para construir listas y otras rdfs:Class
estructuras
[Brickley y McBride; 2004]. Fragmento del vocabulario de clases de RDF Schema
recomendado por el W3C.

58
Lenguajes orientados a objetos.

40
 75.00 Tesis
Una propiedad es un recurso que permite caracterizar clases y establece una relacin entre
dos recursos, sujeto y objeto, constituyendo el primero su dominio y el segundo su rango.

Tabla Properties RDF predeterminadas

Property Descripcin rdfs:type rdfs:domain rdfs:range
rdfs:range Rango de clases vlidas rdf:Property rdf:Property rdfs:Class
que acepta una propiedad
rdfs:domain Dominio de clases vlidas rdf:Property rdf:Property rdfs:Class
sobre el que se aplica una
propiedad
rdfs:type De que clase es instancia rdf:Property rdfs:Resource rdfs:Class
un recurso
rdfs:subClassOf Los recursos instancias de rdf:Property rdfs:Class rdfs:Class
una clase son instancias
de otra. Transitiva
rdfs:subPropertyOf Los recursos instancias de rdf:Property rdf:Property rdf:Property
una propiedad son
instancias de otra.
Transitiva
rdfs:label Versin legible del rdf:Property rdfs:Resource rdfs:Literal
nombre de rdf:subject.
rdfs:comment versin legible de un rdf:Property rdfs:Resource rdfs:Literal
recurso
rdf:subject Sujeto de una tripla RDF. rdf:Property rdf:Statement rdfs:Resource
rdf:predicate Predicado de una tripla rdf:Property rdf:Statement rdfs:Resource
RDF.
rdf:object Objeto de una tripla RDF. rdf:Property rdf:Statement rdfs:Resource
rdfs:seeAlso Informacin adicional rdf:Property rdfs:Resource rdfs:Resource
acerca de rdf:subject.
rdfs:member Super-property de todas rdf:Property rdfs:Resource rdfs:Resource
las properties miembro
del contenedor
rdfs:ContainerMem Tiene como instancias las rdf:Property rdfs:Resource rdfs:Resource
bershipProperty propiedades rdf:_1, rdf:_2,
rdf:_n. Establece que un
recurso es miembro de
un contenedor. Es
subpropiedad de
rdfs:member y subclase
de rdf:Property
rdf:first Primer tem de una lista rdf:Property rdf:List rdfs:Resource
RDF
rdf:rest resto de una lista RDF rdf:Property rdf:List rdf:List
rdf:nil denota una lista vaca rdf:Property
[Brickley y McBride; 2004]. Fragmento del vocabulario de propiedades de RDF Schema
Recomendado por el W3C

Las definiciones de propiedades son independientes de las definiciones de clases y, por

defecto, son de alcance global (no restringidas a clases). Como consecuencia, no es posible
definir una propiedad con diferentes rangos segn sea la clase a la que es aplicada.

RDF puede brindar descripciones adicionales por medio de esquemas pero no prescribe
cmo una aplicacin debera tratar con las descripciones. Los statements en RDFS son

41
 75.00 Tesis
siempre descripciones. Pueden ser prescriptivos (introducir restricciones) slo si a la
aplicacin que los interpreta es requerida tratarlos de ese modo. Todo lo que RDFS hace es
proveer informacin adicional.

RDF es utilizado como base para lenguajes ms expresivos como DAM+OIL o DAML y OWL.

En resumen RDFS proporciona clases, jerarquas de clases, propiedades, jerarquas de

propiedades y restricciones sobre dominios y rangos.

La semntica de RDF y RDFS es expresada mediante lgica de predicados59, un lenguaje

formal que resulta conveniente a fin de evitar ambigedades y hacer la semntica
comprensible a las mquinas, proporcionando una base firme para razonamiento
automtico.

Por eficacia computacional, la semntica de RDF y RDFS es expresada mediante triplas. La

semntica en RDF y RDFS incluye un sistema de inferencia robusto y completo. Las reglas del
sistema de inferencia son de la forma if-then y permiten a una mquina realizar deducciones.

En situaciones con cientos, miles de clases, subclases, instancias, propiedades y

subpropiedades resultar apreciable la verdadera potencia de la interpretacin semntica
automtica, la cual permitir extraer deducciones escondidas entre avalanchas de datos,
aparentemente inconexos.

Es posible construir la Web Semntica con la interoperabilidad sintctica que provee XML y
la interoperabilidad semntica que presta RDFS?

La respuesta a este interrogante es no, no es posible debido a las carencias que RDFS posee:

No es posible declarar restricciones de rango que sean vlidas slo para algunas clases;

No es posible representar ciertas caractersticas de las propiedades (propiedades
transitivas, simtricas, inversas o funcionales);

No es posible reflejar clases disjuntas;

No permite expresar restricciones de cardinalidad (cantidad de valores que puede tomar
una propiedad);

Existen expresiones cuya semntica no es la estndar (es decir que no pueden expresarse
mediante lgica de primer orden) provocando que dado un sistema de axiomas no se
pueda afirmar o negar nada.

RDFS no es completo para describir los recursos de la Web con el detalle que se requiere. Se lo

59 Desarrollado en la seccin 2.3 Lgica y ontologas

42
 75.00 Tesis
utiliza porque es tan general que puede emplearse en muchos dominios y porque sirve como
puente entre vocabularios diferentes.

2.5.1.2 RDF y la ambigedad semntica XML

Por qu se recurre a RDF para describir recursos y no a XML? Antes de responder es

conveniente recordar para qu sirve XML.

XML es un lenguaje de marcado para documentos de toda clase. Permite al programador

definir una gramtica por medio de un DTD60 o XML-Schema utilizando etiquetas
(metadatos) en todas sus combinaciones posibles y, por medio, de un analizador de sintaxis
comprobar si el documento cumple con la gramtica definida (si es un documento XML
vlido).

XML es un gran paso hacia la interoperabilidad sintctica. Cualquier documento y tipo de

dato puede expresarse como un documento XML. Los datos son definidos en forma
independiente del lenguaje de programacin o plataforma utilizada convirtindolo en un
formato universal para el intercambio de datos. Entre sus ventajas cabe sealar:

Un documento XML es autodescriptivo, almacena datos y la estructura de stos y por ser

de fcil procesamiento en un medio para compartir documentos entre personas y empresas.

Un documento XML es customizable. Permite a una empresa desarrollar los DTDs (o XML-
Schema) de los documentos de negocios (facturas, pedidos, rdenes de produccin) y
realizar sus operaciones con clientes y proveedores a travs de los documentos XML
conforme a los DTDs o (o XML-Schema) desarrollados.

La estructura de los documentos XML puede comprobarse automticamente, de manera de
rechazar aquellos documentos que no estn construidos de acuerdo a los DTDs o XML-
Schema exigidos. Si dos empresas trabajan con un conjunto comn de DTDs, XML-
Schema, pueden analizar cualquier documento que una vaya a enviar a la otra y evitar el
envo de documentos incorrectos.

Un documento XML se basa en texto ordinario y lo hace idneo para ser transportado a
travs de Internet, donde conviven muchas plataformas y sistemas informticos, cada una
con sus propios formatos de archivos.

El juego de caracteres predefinido para XML es UNICODE. Esto permite crear documentos
XML internacionalizables (en cualquier lenguajes humano).

XML ha tenido un enorme impacto sobre las tecnologas de las empresas IT. Se ha
convertido en el formato universal para el intercambio de datos entre organizaciones
pblicas y privadas; ha modificado radicalmente el panorama de las transacciones B2B61
(productos compatibles con especificaciones XML para el intercambio comercial
desarrollados por organizaciones como OASIS62, ebXML63, RosettaNet64, etc.), ha logrado
60
Document Type Definition
61
Para denotar el origen y destino de una actividad comercial entre empresas, diferente al B2C.
62
Organization for the Advancement of Structured Information Standards
63
Electronic Business using eXtensible Markup Language. Conjunto modular de especificaciones que posibilita a
las empresas realizar negocios en Internet. http://www.ebxml.org/
64
Define estndares para la cadena de suministro global, los cuales permiten la automatizacin de procesos de
negocios. http://www.rosettanet.org/

43
 75.00 Tesis
imponerse como solucin para la integracin de aplicaciones, sistemas y bases de datos;
se ha introducido como parte clave de las plataformas de software ms difundidas (J2EE y
.NET); ha liberado a las empresas de desarrollar en una plataforma determinada al
permitir desarrollar servicios Web, los cuales al emplear XML son independientes de la
plataforma; la mayor parte de los sistemas de gestin de bases de datos relacionales lo ha
incorporado a sus productos y tambin ha tenido gran impacto en el desarrollo de portales
(distintos portales pueden tener un mismo esqueleto XML y distintas presentaciones en
XSLT65 lo que reduce el trabajo de realizar cambios en el front-end).

A pesar de las ventajas sealadas, XML no incorpora mecanismos para garantizar

interoperabilidad semntica y, en consecuencia, ofrecer una interoperabilidad completa.

Las estadsticas muestran que en Europa el 20-30% de los gastos relacionados con el
comercio electrnico deriva de la falta de interoperabilidad semntica [Abin; 2005]. Este
gasto se debe a que, aunque los SI66 empresariales utilicen las mismas tecnologas (por
ejemplo XML para describir los datos), el significado de sus modelos de negocios suele diferir.
Nociones habituales como pedido o cliente pueden significar cosas muy distintas, en cada
empresa. Como consecuencia el intercambio de informacin entre empresas, en el mejor de
los casos, resulta en un proceso semi-manual. La principal dificultad a la que se enfrenta el
modelado empresarial reside en traducir los objetos de negocio de una empresa a los de otras
y viceversa. Sin esa traduccin, la integracin automtica de los SI de las empresas que
forman parte de una misma cadena de aprovisionamiento resulta imposible sin un
entendimiento comn.

Con XML es posible realizar la especificacin del formato y la estructura de cualquier

documento pero no impone ninguna interpretacin semntica acerca de esos datos. En
consecuencia, desde el punto de vista semntico, XML resulta intil: dado un documento XML
no es posible reconocer en l los objetos y relaciones de un dominio de inters.

El marcado de los documentos XML es efectuado por medio de metadatos. Cuando una
persona lee un DTD, puede extraer la semntica prestando atencin a los nombres de los
elementos o a los comentarios que figuran en l, interpretando semnticamente el DTD. Por
el contrario, para un programa que procesa los documentos XML, las etiquetas, por s solas,
no tienen significado alguno.

Volviendo al planteo que abri esta seccin, cabe responder que XML no es apropiado para
incluir semntica desde que el modelo de datos de un dominio puede ser representado por
diferentes DTDs (o XML Schema) y, al mismo tiempo, un DTD (o XML Schema) puede
representar varios modelos de datos distintos. En cambio, RDFS proporciona una
representacin nica de un modelo de datos, al considerar la semntica de los datos.

Pese a la similitud entre los trminos esquema RDF (RDFS) y esquema XML (XML
Schema), sus significados son muy distintos. Los esquemas XML, al igual que los DTD,
especifican el orden y las combinaciones de etiquetas que son aceptables en un documento

65
Stylesheet Language Transformation, transformacin del lenguaje de hojas de estilo.
66
Sistema de informacin

44
 75.00 Tesis
XML. En cambio, los esquemas RDF especifican qu interpretacin hay que dar a las
sentencias de un modelo de datos RDF; es ms, dejan libre la representacin sintctica del
modelo.

Los esquemas XML modelan datos expresados en XML mientras que los esquemas RDF
(RDFS) modelan conocimiento o dicho de otra manera: XML y los esquemas XML son un
lenguaje de modelado de datos y RDF y RDFS son un lenguaje de modelado de metadatos.

2.5.2 OWL

2.5.2.1 Conceptos Bsicos

El Ontology Web Language (OWL) es una especificacin de lenguaje desarrollado por el W3C
para describir ontologas, es decir, representar el significado y las relaciones de trminos en
vocabularios de manera que la informacin contenida en los documentos pueda ser
procesada por aplicaciones.

Es una extensin de RDFS y mantiene una buena relacin entre eficacia computacional y
poder expresivo.

A continuacin, las tablas muestran algunos de los trminos del vocabulario OWL empleados
en la descripcin de clases, object-properties, data-properties y properties-restriction
respectivamente. [Hebeler et al.; 2009].

Tabla trminos OWL para describir clases

Clase Descripcin
owl:equivalentClass Relacin que especifica que las extensiones de dos clases son equivalentes
owl:Thing Clase de todos los individuos
owl:OneOf La pertenencia a la clase est limitada a los miembros especificados en la
coleccin de individuos
owl:intersectionOf Los miembros de esta clase son miembros de todas las clases especificadas
owl:unionOf Los miembros de esta clase son miembros de al menos alguna de las clases
especificadas
owl:complementOf Los miembros de esta clase no son miembros de la clase especificada
owl:disjointWith Relacin que establece que los miembros de las dos clases especificadas no
comparten individuos
owl:AllDisjointClasses Una clase utilizada con owl:members para especificar un conjunto de clases
que son disjuntas por pares
owl:disjointUnionOf Una relacin que especifica que esta clase es la unin del conjunto de clases
especificadas las cuales son disjuntas por pares
owl:Restriction La clase de todas las restricciones

45

Tabla trminos OWL para describir object-properties
Object-Property
owl:objectProperty
owl:DataProperty
owl:topObjectProperty
owl:bottomObjectProperty
owl:topDataProperty
owl:bottomDataProperty
owl:SymmetricProperty
owl:AsymmetricProperty
owl:equivalentProperty
owl:ReflexiveProperty
owl:IrreflexiveProperty
owl:TransitiveProperty
owl:FunctionalProperty
owl:InverseFunctionalProperty
owl:inverseOf
owl:propertyChain
Owl:propertyDisjointWith
owl:AllDisjointProperties
Tabla trminos OWL para describir data-properties
Data-Property
owl:onDataType
owl:intersectionOf
owl:unionOf
owl:oneOf Propiedad que identifica un conjunto de valores que conforman al datatype
owl:datatypeComplementOf
Una property-restriction describe a la clase de individuos que cumplen con las condiciones
especificadas sobre la propiedad. La restriccin es declarada empleando la construccin
75.00 Tesis
Descripcin
La clase de todas las propiedades que relacionan dos individuos
La clase de todas las propiedades que relacionan un individuo con un valor
literal
Propiedad que conecta todos los posibles pares de individuos
Propiedad que no conecta pares de individuos
Propiedad que conecta todos los posibles individuos con todos los posibles
literales
Propiedad que no conecta ningn individuo con un literal
La clase de todas las propiedades que son simtricas. Para todas las
propiedades simtricas p, el statement (A p B) implica la existencia del
statement (B p A)
La clase de todas las propiedades que son explcitamente no simtricas. Para
todas las propiedades asimtricas p, el statement (A p B) implica la no
existencia del statement (B p A)
Propiedad que especifica que dos propiedades son equivalentes
La clase de todas las propiedades que son reflexivas. Para todas las
propiedades reflexivas p y los individuos A, A esta relacionado a s mismo
por p (A p A)
La clase de todas las propiedades que no son reflexivas. Para todas las
propiedades irreflexivas p y los individuos A, no existe un statement p (A p
A)
La clase de todas las propiedades que son transitivas. Para todas las
propiedades transitivas p, (A p B) y (B p C) implica (A p C)
La clase de todas las propiedades para las cuales un valor de dominio dado
tiene slo un valor de rango
La clase de todas las propiedades para las cuales un valor de rango dado tiene
slo un valor de dominio
Propiedad que especifica que dos propiedades son una la inversa de la otra.
Si una propiedad p1 es la inversa de una propiedad p2, la existencia de un
statement (A p1 B) implica la existencia del statement (B p2 A)
Propiedad que es utilizada para construir una cadena de propiedades que
representa la superproperty en una relacin subproperty-of
Relacin que establece que dos propiedades son disjuntas. Si dos
propiedades p1 y p2 son disjuntas, implica que dos statements con el
mismo sujeto y objeto no pueden tener los predicados p1 y p2
Una clase que es utilizada con owl:members para describir colecciones de
propiedades que son disjuntas por pares.
Descripcin
Propiedad que identifica el datatype al cual se aplican las restricciones
Propiedad que identifica un conjunto de datatypes tal que el datatype
descripto contiene los valores contenidos en todos los datatypes del
conjunto
Propiedad que identifica un conjunto de datatypes tal que el datatype
descripto contiene algn valor que est contenido en al menos uno de los
datatypes del conjunto
Propiedad que especifica que el datatype descripto contiene todos los
valores que no estn en el datatype que la propiedad identifica
46
 75.00 Tesis
owlRestriction y la propiedad a la cual refiere la restriccin es identificada utilizando la
propiedad owl:onProperty. Las restricciones son relacionadas a clases utilizando
rdfs:subclassOf o owl:equivalentClass.

Tabla trminos OWL para describir property resctriction

Property Restrictions Descripcin
owl:onProperty Propiedad que identifica la propiedad a la cual la restriccin aplica
owl:allValuesFrom Propiedad que especifica que todas las instancias en esta clase deben tener
valores solo del rango especificado para la propiedad
owl:someValuesFrom Propiedad que especifica que todas las instancias en esta clase deben tener
al menos una propiedad con un valor del rango especificado
owl:hasValue Propiedad que especifica que todas las instancias de esta clase deben tener
el valor especificado por la propiedad
owl:minCardinality Propiedad que especifica que debe haber al menos N de las propiedades
especificadas sobre cada instancia de esta clase
owl:maxCardinality Propiedad que especifica que debe haber a lo sumo N de las propiedades
especificadas sobre cada instancia de esta clase
owl:cardinality Propiedad que especifica que debe haber exactamente N de las propiedades
especificadas sobre cada instancia de esta clase

Adems OWL dispone de los siguientes trminos para individuos:

owl:sameAs: relacin que especifica que dos individuos son el mismo individuo;

owl:differentFrom: relacin que especifica que dos individuos no son el mismo individuo;

owl:AllDifferent: una clase utilizada con owl:distinctMembers para definir una coleccin
de individuos que son diferentes por pares.

Como puede observarse, OWL tiene mucha ms capacidad expresiva que RDFS. OWL facilita
la importacin y exportacin de clases por medio de propiedades como sameAs,
equivalentClass, equivalentProperty, differentFrom, etc.

OWL soporta una sintaxis abstracta (independiente de cualquier representacin

computacional), una basada en XML y otra basada en RDF.

La primera versin de la especificacin fue OWL 1 (tambin conocida como OWL), la cual fue
aprobada por el W3C en el ao 2004. La segunda fue OWL 2, aprobada en el ao 2009 con el
agregado de nuevas caractersticas mientras mantiene compatibilidad con la anterior.

OWL tiene ms facilidades para expresar significado y semntica que XML, RDF y RDF-S:

XML: provee una base sintctica para documentos estructurados aunque no impone
restricciones semnticas en el significado de esos documentos

XML Schema: extiende XML con datatypes y provee un lenguaje para restringir la
estructura de documentos XML.

47
 75.00 Tesis

RDF: modela recursos y sus relaciones utilizando una representacin y semntica simple
por medio de sintaxis XML

RDF Schema: brinda un vocabulario para describir propiedades y clases de recursos RDF,
con una semntica para la generalizacin de jerarquas de clases y propiedades

OWL: agrega ms vocabulario para describir clases y propiedades. Entre otras: relaciones
entre clases, cardinalidad, igualdad, ms propiedades, caractersticas de propiedades y
enumerados de clases.

OWL es un componente de la actividad de la Web Semntica. Dado que la Web Semntica es

por naturaleza distribuida, OWL permite que la informacin pueda ser reunida desde fuentes
remotas. Esto es parcialmente logrado por relacionar ontologas y permitir importar
informacin desde otras ontologas.

OWL2 es un lenguaje declarativo y utiliza lgica descriptiva en la representacin de cualquier

situacin, lo cual constituye una base formal que propicia el uso de herramientas de
inferencia como razonadores, ampliando la informacin disponible.

Las inferencias son realizadas algortmicamente y no forman parte del documento OWL sino
que dependen de implementaciones especficas. La respuesta correcta a una cuestin es
predeterminada por la semntica formal (Direct Model-Theoretic o RDF-Based).

El tipo de conocimiento capturado por OWL no refleja todos los aspectos de conocimiento
humano sino una parte de l. OWL es considerado como un lenguaje de modelado de
propsito general, poderoso, que como resultado del proceso de modelado logra una
ontologa.

A fin de formular conocimiento explcito, OWL asume que ste consiste de piezas
elementales llamadas statements (o proposiciones). Los statements obtenidos a partir de la
ontologa son llamados axiomas y pueden ser verdaderos o falsos segn la situacin.

Un statement es cierto siempre que los otros statements lo sean. En trminos OWL: un
conjunto de statements A implican un statement a, si en cualquier situacin donde todos los
statements de A son ciertos, tambin lo es a. La semntica formal de OWL especifica las
posibles situaciones en las que un conjunto de statements es verdadero. Existen herramientas
OWL, y razonadores que pueden procesar consecuencias.

Los statements poseen componentes atmicos llamados entidades. Las entidades pueden
representar objetos, categoras o relaciones o en trminos de OWL2 individuos, clases y
propiedades, respectivamente. A su vez, las propiedades se dividen en:

object-property: relaciona individuos. El orden en que los individuos aparecen es

importante.

datatype-property: relaciona individuos con valores de datos y se pueden utilizar datatypes
XML-Schema.

48
 75.00 Tesis

annotation-property: comentarios relacionados con partes de la ontologa, como autor y
fecha de creacin de un axioma. Permite anotaciones de anotaciones. Son empleadas, por
herramientas, en interfaces de ayuda para proveer acceso a texto en lenguaje natural.

Las expresiones son combinaciones de entidades (individuos, clases y propiedades). Una

expresin de clase puede ser utilizada en statements o en otras expresiones. En este sentido,
las expresiones pueden ser vistas como nuevas entidades definidas por sus estructuras.

2.5.2.2 Sub-Lenguajes

OWL es, en general, un lenguaje muy expresivo y puede resultar difcil de implementar y
trabajar con l.
Los sublenguajes fueron diseados como subconjuntos de OWL 2 y lo suficientemente
accesibles para ser utilizados en una variedad de aplicaciones. Al igual que en OWL 2 DL, los
mayores requerimientos de los sublenguajes tienen que ver con consideraciones de
procesamiento.
En la primera versin de OWL se definieron tres sublenguajes:

OWL DL: soporta lgica descriptiva y provee un subconjunto del lenguaje con propiedades
de cmputo propicias para sistemas de razonamiento. Establece restricciones sobre la
combinacin con RDF y requiere separacin estricta de clases, propiedades, individuos y
valores de datos.

OWL Lite: es parte de OWL DL, diseado para una fcil implementacin y proveer a los
usuarios con un subconjunto funcional a fin de iniciarlos en el uso de OWL.

OWL FULL: provee un lenguaje completo y relaja algunas de las restricciones de OWL DL.
A diferencia de OWL DL, permite combinar libremente OWL con RDF Schema y, como
ste, no posee una separacin estricta entre clases, propiedades, individuos y valores de
datos.

Como consecuencia del despliegue de ontologas OWL, estos sublenguajes resultaron

insuficientes para responder a nuevos requerimientos.

Varias aplicaciones, particularmente en las ciencias de la vida, emplean ontologas de gran

tamao (FMA, NCI Thesaurus, SNOMED CT, Gene Ontology y OBO). Tales ontologas, que
necesitan representar entidades complejas o permitir la propagacin de propiedades, poseen
un enorme nmero de clases y hacen uso intensivo de mecanismos de clasificacin para
simplificar el desarrollo y el mantenimiento. Las aplicaciones, por lo tanto, prestan mayor
atencin a la escalabilidad del lenguaje y performance de razonamiento, sacrificando algo de
expresividad por calidad de procesamiento, particularmente clasificacin.

Otras aplicaciones, en cambio, utilizan bases de datos y priorizan la interoperabilidad de

OWL con tecnologas y herramientas de bases de datos. Las ontologas utilizadas en estas
aplicaciones son ligeras y empleadas para ejecutar consultas sobre grandes conjuntos de
individuos almacenados en dichas bases de datos. Por lo tanto existen requerimientos para
acceder a datos directamente va consultas relacionales (es decir, por SQL).

49
 75.00 Tesis
Por otro lado, existen aplicaciones que prestan especial cuidado a la interoperabilidad del
lenguaje de ontologa con mquinas de reglas. Las ontologas utilizadas en estas aplicaciones
son ligeras y permiten consultar grandes datasets siendo conveniente operarlas directamente
en la forma de triplas RDF. Casos tpicos de tales aplicaciones son aquellas que priorizan
eficiencia por expresividad y aplicaciones RDF que necesitan de la mayor expresividad
provista por OWL.

Ninguno de los sublenguajes presentados a continuacin incluye al otro. Idealmente se puede

utilizar un razonador (o una herramienta) conforme a un superlenguaje en un sublenguaje
sin que se observen cambios en los resultados derivados (este principio se mantiene en
OWL2 EL y OWL 2 QL en relacin a OWL 2 DL desde que cada razonador conforme a OWL2
DL es un razonador para OWL 2 EL y OWL 2 QL con las diferencias evidentes en rendimiento
desde que un razonador OWL DL trata un conjunto ms general de casos).

A fin de satisfacer los requerimientos expuestos, la segunda versin de OWL defini tres
nuevos sublenguajes con propiedades tiles de procesamiento, a saber:

OWL EL: fue diseado pensando en las aplicaciones que emplean ontologas de gran
tamao. Captura el poder expresivo en ontologas de gran escala. No permite negacin y
disyuncin de clases, cuantificacin universal sobre propiedades ni propiedades inversas
El acrnimo EL refleja el origen del sublenguaje en la familia EL de lgica descriptiva. Las
herramientas (en proceso de alcanzar conformidad con OWL 2) que ofrecen soporte para
OWL 2 EL son: FaCT++, Hermit, Pellet, CEL, ELLY, REL, entre otras.

OWL QL: fue diseado pensando en aplicaciones que priorizan la interoperabilidad de
OWL con bases de datos. Utilizado en ontologas simples como Thesuari, permite
integracin con RDBMS y la implementacin de razonadores sobre la misma. Este
sublenguaje es adecuado para aplicaciones con ontologas ligeras pero con un gran
nmero de individuos, las cuales necesitan acceder a los datos directamente va consultas
relacionales. El razonamiento puede ser implementado eficientemente mediante tcnicas
de re-escritura de consultas. El acrnimo QL refleja el hecho de que la respuesta a una
consulta puede ser implementada por re-escribir las consultas en el Standard Relational
Query Language. Las herramientas (en proceso de alcanzar conformidad con OWL 2) que
ofrecen soporte para OWL 2 QL son QuOnto, Quill, FaCT++, Hermit, Pellet, entre otras.

OWL 2 RL: fue diseado pensando en aplicaciones que priorizan la interoperabilidad de
OWL con mquinas de reglas. Define un subconjunto sintctico de reglas para su
implementacin a travs de tecnologas basadas en reglas. Tales implementaciones pueden
operar directamente sobre triplas RDF y pueden ser aplicadas arbitrariamente a grafos
RDF. En este ltimo caso no hay garanta de obtener todas las respuestas correctas desde
que la ontologa puede estar incompleta. El acrnimo RL refleja el hecho de que el
razonamiento puede ser implementado utilizando el Standard Rule Language. Las
herramientas (en proceso de alcanzar conformidad con OWL 2) que ofrecen soporte para
OWL 2 RL son: Oracle Database 11g OWL Reasoner, Jena, FaCT++, Hermit y Pellet.

La eleccin de un sublenguaje depende principalmente de la expresividad requerida por la

aplicacin, la prioridad dada al razonamiento sobre clases o datos, el tamao de los datasets y
la importancia de la escalabilidad, entre otros.

50
 75.00 Tesis
Para requerimientos de un sublenguaje escalable en ontologas grandes y con buenos
tiempos de performance en razonamiento ontolgico, la recomendacin es OWL 2 EL. Para
requerimientos de interoperabilidad con sistemas de BD relacionales y razonamiento
escalable sobre grandes datasets, la recomendacin es OWL 2 QL mientras que para
requerimientos de interoperabilidad con mquinas de reglas y reglas extendidas de BD y
razonamiento escalable sobre grandes BD, la recomendacin es OWL 2 RL.

2.5.2.3 Semntica Formal

La semntica formal utilizada en OWL 2 puede ser:

Direct Model-Theoretic (Modelo Terico Directo): provee significado en un estilo lgico
descriptivo. Una ontologa con interpretaciones (I) realizadas por esta semntica es
referida como OWL 2 DL.

RDF-Based: la visin de grafos de OWL 2. Es una extensin de la semntica RDFS. Una
ontologa con interpretaciones (I) realizadas por esta semntica es referida como OWL 2
FULL.

Las diferencias entre ambas son sutiles siendo las inferencias realizadas utilizando el Direct
Model-Theoretic tambin vlidas en RDF-Based, salvo las obtenidas de anotaciones que
mientras para la primera no tienen significado formal para la segunda son una fuente ms de
inferencia.

Conceptualmente, se puede agregar que OWL 2 DL es la versin sintcticamente restringida

de OWL 2 FULL, haciendo el trabajo de desarrollo ms sencillo. OWL DL permite construir un
razonador que, en principio, puede retornar respuestas del tipo si-no, siendo variada la
produccin de razonadores que cubren el lenguaje OWL 2 DL bajo la semntica Direct Model-
Theoretic. En cambio, no existen razonadores para OWL 2 FULL bajo la semntica RDF-
Based.

2.5.3 WSMO

El Web Service Modeling Framework67 (WSMF) satisface requerimientos claves como

mximo desacoplamiento y fuerte mediacin, a fin de definir un modelo conceptual para el
desarrollo y la descripcin de servicios Web.

El Web Service Modeling Ontology68 (WSMO) extiende WSMF proporcionando un marco

conceptual para la descripcin semntica de los aspectos relevantes de los servicios Web
como la automatizacin del descubrimiento, combinacin e invocacin.

Comprende el Web Service Modeling Language69 (WSML), el cual establece la sintaxis y la

semntica formal y se basa en formalismos lgicos (lgica descriptiva, lgica de primer orden
y programacin lgica), y el Web Service Execution Environment70 (WSMX), el cual define

67
Marco de Modelado de Servicios Web
68
Ontologa de Modelado de Servicios Web
69
Lenguaje de Modelado de Servicios Web
70
Entorno de Ejecucin de Servicios Web

51
 75.00 Tesis
una arquitectura SWS prestando una implementacin inicial para descubrimiento, seleccin,
mediacin, invocacin e interoperacin de servicios Web. El objetivo de WSMX es
proporcionar un ambiente de prueba para WSMO y demostrar la viabilidad de utilizarlo
como modelo para alcanzar la interoperabilidad dinmica de SWS.

2.5.3.1 Principios de diseo

Como se mencion, WSMO es un marco para la descripcin de servicios Web, que integra
principios bsicos y semnticos de diseo Web y principios de diseo para procesamiento
distribuido. A continuacin se enumeran los principios de diseo de WSMO:

1. Conformidad Web: abarca el concepto de URI para identificacin nica de recursos, el

concepto de namespaces para denotar espacios de informacin consistentes, XML,
recomendaciones del W3C y recursos descentralizados.

2. Basado en ontologas: refiere a descripciones de servicios e intercambio de datos.

3. Desacoplamiento estricto: cada recurso WSMO deber ser especificado en forma

independiente, sin considerar posibles usos o interacciones con otros recursos.

4. Mediacin centralizada: la mediacin se ocupa de manejar la heterogeneidad que

naturalmente surge en entornos abiertos.

5. Separacin de rol ontolgico: los pedidos de usuario son formulados independientemente

de los servicios Web disponibles.

6. Ejecucin semntica: la ejecucin semntica de implementaciones de referencia como

WSMX proveen realizacin tcnica y verificacin de la especificacin WSMO.

7. Servicios vs. Servicios Web: un servicio Web es una entidad computacional que puede
(por ser invocado) alcanzar un objetivo. Por el contrario, un servicio es el valor actual
provisto por esta invocacin. WSMO no especifica servicios sino servicios Web.

2.5.3.2 Conceptos bsicos

Partiendo de la base conceptual establecida por WSMF, WSMO refina y extiende cuatro
elementos de modelado: ontologas, servicios Web, objetivos y mediadores, adoptando las
definiciones dadas a continuacin.

Las ontologas son un elemento clave al proveer las terminologas especficas de dominio
para describir otros elementos. Cumplen un doble propsito: definir la semntica formal de la
informacin y vincular terminologas humanas y de computadora.

Los servicios Web utilizan protocolos basados en estndares Web para intercambiar y
combinar datos, son independientes de la plataforma y cada servicio Web es visto como una
pieza atmica de funcionalidad que puede ser reutilizada para construir servicios ms
complejos. Adems WSMO incluye tres perspectivas en la descripcin de los servicios Web:

52
 75.00 Tesis
propiedades no funcionales, funcionalidad y comportamiento.

Los objetivos (goals) especifican las funcionalidades que un servicio Web debe proveer desde
la perspectiva del usuario. La co-existencia de objetivos y servicios Web como entidades no
superpuestas asegura el desacoplamiento entre un pedido y un servicio Web. Esta forma de
establecer problemas, en la que el usuario formula objetivos sin considerar los servicios Web
de la solucin es conocido como Goal-Driven Approach71, derivado del AI Racional Agent
Approach72.

Los mediadores resuelven incompatibilidades a nivel de datos, mediando entre diferentes

terminologas, especficamente solucionan problemas a nivel de procesos, de integracin de
ontologas y median entre patrones de comunicacin heterogneos (este tipo de
heterogeneidad aparece durante la comunicacin de servicios Web). Existen cuatro tipos de
mediadores: mediadores de ontologas, de servicios Web, de objetivos y mediadores entre
servicios Web y objetivos.

2.5.4 DAML-S

El Darpa Agent Markup Language for Services73 (DAML-S) es un intento por cerrar la
brecha entre la Web Semntica y los estndares de servicios Web [Paolucci y Sycara, 2003].

Permite una descripcin estndar (WSDL y SOAP) de los servicios Web garantizando que
usuarios y servicios puedan descubrir e invocar otros servicios. Como ontologa, define un
concepto de servicio Web utilizando construcciones DAML+OIL74. Adems, las anotaciones
semnticas y ontolgicas le permiten relacionar descripciones de servicios Web con
descripciones de dominio operacional.

Un servicio Web DAML-S es especificado por cuatro descripciones: el Service Profile, el

Process Model, el Service Grounding y el DAML-S Service Description, el cual es una especie
de contenedor de los anteriores. A nivel mensajes y transporte, DAML-S es consistente con el
resto de los estndares propuestos (WSDL, SOAP y otros protocolos).

El Service Profile provee una visin de alto nivel de un servicio Web, similar a la
representacin de servicio Web UDDI. Ambos proveen informacin del proveedor de servicio
pero el Service Profile soporta propiedades como representacin de capacidades (tareas
ejecutadas por el servicio) que UDDI no soporta. Por otro lado, UDDI describe los puertos que
el servicio Web utiliza, mientras que DAML-S relega esa informacin a otros mdulos de la
descripcin como el Service Grounding.

El Process Model especifica qu tareas ejecuta un servicio Web, el orden en que las ejecuta y

71
Enfoque Dirigido por Objetivos
72
Enfoque de Inteligencia Artificial de Agente Racional.
73
Lenguaje de Marcado de Agentes DARPA para Servicios
74
Lenguaje de marcado semntico para recursos Web, fue construido sobre los primeros estndares del W3C, RDF y
RDFS, extiende estos lenguajes con primitivas de modelado. http://www.w3.org/TR/daml+oil-reference

53
 75.00 Tesis
las consecuencias de las mismas. Un cliente puede utilizar el Process Model para derivar la
coreografa del servicio o el patrn de intercambio de mensajes por seguir las entradas que
espera y cuando y las salidas que produce y cuando. El Process Model tiene un rol similar a
los estndares emergentes como BPEL4WS75 y WSCI76, pero se enfoca ms en los efectos de
ejecutar los componentes de diferentes servicios.

El Service Grounding vincula la descripcin abstracta de intercambio de informacin de un

servicio Web (definido en trminos de entradas y salidas en el Process Model) con una
operacin WSDL explcita, que luego WSDL vincula a mensajes SOAP e informacin de la
capa de transporte.

La dependencia de DAML-S sobre DAML+OIL, as como WSDL sobre SOAP, muestra cmo los
servicios Web pueden ser enriquecidos con informacin semntica. DAML-S agrega a las
especificaciones de servicios Web, representacin formal de contenido y razonamiento
acerca de interacciones y capacidades. DAML-S permite que los servicios Web empleen UDDI,
WSDL y SOAP para descubrir e interactuar con otros servicios y que ellos utilicen DAML-S
para integrar estas interacciones en problemas propios a resolver.

2.5.5 OWL-S

Se trata de una ontologa de servicios Web basada en OWL que permite describir las
propiedades y capacidades de los servicios Web. OWL-S fue construido sobre la
recomendacin OWL del W3C. Las publicaciones anteriores de este lenguaje fueron llamadas
DAML-S y construidas sobre DAML+OIL (predecesor de OWL). La ltima versin de OWL-S
es la 1.2. OWL-S puede ser comprendido a partir de DAML-S, desarrollado en la seccin
anterior.

2.5.6 SWSF
En el ao 2005, el W3C public el Semantic Web Services Framework (SWSF), presentado
por Hewlett Packard (HP), el Massachusetts Institute of Technology (MIT), el National
Research Council of Canada, SRI y las universidades de Stanford, Zurich, Toronto y California,
entre otras.

Dicha publicacin empieza por mencionar la necesidad de estndares para servicios Web
(parcialmente logrados con WSDL, BPEL4WS y UDDI) y al mismo tiempo destaca la
necesidad creciente de especificaciones semnticas ms ricas, basadas en un framework que
extienda el rango completo de conceptos relacionados a servicios Web. Un framework
debera permitir una automatizacin ms completa y flexible en la provisin y utilizacin de
servicios, soportar la construccin de herramientas y metodologas ms poderosas y
promover la utilizacin de razonamientos semnticos acerca de servicios. Dado que un
framework de representacin expresivo permite la especificacin de diferentes aspectos de
los servicios, puede proporcionar una base para un amplio rango de actividades a lo largo del
ciclo de vida de los servicios Web: semnticas ms ricas pueden soportar mayor

75
Business Process Execution Language for Web Services, es un lenguaje para la especificacin formal de procesos
de negocios y protocolos de interaccin de negocios. Por esto, extiende el modelo de interaccin de servicios Web y
lo habilita para soportar transacciones de negocios.
76
Web Service Choreography Interface. http://www.w3.org/TR/wsci/

54
 75.00 Tesis
automatizacin de seleccin e invocacin de servicios, traslacin automtica de contenido de
mensajes entre servicios, enfoques automatizados o semiautomatizados para la composicin
de servicios, enfoques ms comprensivos para monitoreo de servicios y recuperacin de
fallas y una automatizacin ms completa de verificacin, simulacin, configuracin,
administracin de la cadena de proveedores, contratacin y negociacin de servicios [Battle et
al., 2005].

Las tecnologas presentadas en el trabajo SWSF realizan esta visin de Servicios Web
Semnticos. En l exponen sus dos componentes principales: el Semantic Web Services
Language (SWSL) y el Semantic Web Service Ontology (SWSO).

SWSL se utiliza para especificar caracterizaciones formales de los conceptos de servicios

Web y las descripciones de los servicios individuales. Incluye dos sublenguajes: SWSL-FOL,
basado en lgica de primer orden para expresar la caracterizacin formal de conceptos de
servicio Web, y SWSL-Rules, basado en el paradigma de programacin lgica (o reglas), para
soportar la utilizacin de la ontologa de servicio en razonamiento y entornos de ejecucin
basados sobre este paradigma.

SWSO presenta una axiomatizacin (caracterizacin formal) del modelo conceptual

empleado para describir los servicios Web. La axiomatizacin completa se encuentra en
lgica de primer orden utilizando SWSL-FOL en combinacin con el ModelTheoretic
Semantic77 el cual especifica el significado preciso de los conceptos.

La forma FOL de la ontologa es llamada FLOWS78 y la ontologa resultante por trasladar

sistemticamente axiomas FLOWS al lenguaje SWSL-Rules es llamada ROWS79.

Una contribucin clave de la ontologa FLOWS es el desarrollo de un modelo de proceso rico

de comportamiento basado en la ISO 18629 Process Specification Language (PSL)80.

2.5.7 WSDL-S

En el ao 2005, el W3C public el trabajo Web Service Semantics WSDL-S, entregado por
representantes del IBM Research, IBM Software Group y LSDIS Lab of the University of
Georgia.

[Miller et al.; 2004] sostienen que los servicios Web fueron diseados para proveer
interoperabilidad entre aplicaciones de negocios. Las tecnologas actuales requieren de una
gran cantidad de interaccin humana para integrar dos aplicaciones. Esto es debido a que la
integracin de procesos de negocios necesita de la comprensin de los datos y las funciones
de las entidades involucradas. Las tecnologas semnticas apuntan a sumar mayor significado
al contenido Web, por anotar los datos con ontologas. Las ontologas proporcionan un
mecanismo para compartir conceptualizaciones de dominio. Esto permite a los agentes
conseguir una comprensin de los contenidos de los usuarios de la Web y reducir la
interaccin humana en bsquedas Web significativas. Un enfoque similar puede ser
empleado por agregar significado a las descripciones de los servicios Web, las cuales

77
Ver seccin 2.4.2.3 Semntica Formal
78
First Order Logic Ontology for Web Services
79
Rules Ontology for Web Services
80
Originalmente diseado para soportar interoperabilidad entre lenguajes de modelado de procesos, PSL provee una
base para la interoperabilidad entre los modelos de procesos de los servicios Web emergentes mientras soporta la
realizacin de automatizacin de tareas asociadas con la visin de Servicios Web Semnticos.

55
 75.00 Tesis
permiten mayor automatizacin por reducir el involucramiento humano en comprender los
datos y funciones de los servicios.

Debido a la tarda alineacin de OWL-S con WSDL, el diseo de OWL-S puede ser
innecesariamente complejo. WSDL-S busca crear descripciones semnticas de los servicios
Web por agregar semntica por medio de extensiones simples a WSDL. La ontologa de
servicio WSDL-S, es por lo tanto, ms alineada con WSDL 2.0 y ms compacta que OWL-S sin
perder expresividad.

Conceptualmente, la especificacin WSDL 2.0 posee las siguientes construcciones para

representar descripciones de servicios: interface, operation, message, binding, service y
endpoint. Las primeras tres construcciones tratan con la definicin abstracta de un servicio
mientras que las ltimas tres tratan con la implementacin del servicio. WSDL-S se enfoca en
anotar semnticamente la definicin abstracta de un servicio a fin de permitir
descubrimiento, composicin e invocacin de servicios. Para ello, emplea mecanismos de
referencia URI va elementos de extensibilidad en las construcciones interface, operation y
message los cuales apuntan a las anotaciones semnticas definidas en los modelos de dominio
de los servicios.

Los elementos y atributos de extensiblidad que [Akkiraju et al.; 2005] proponen son: 1) un
atributo de extensin, modelReference, para especificar la asociacin entre una entidad
WSDL y un concepto en algn modelo semntico; 2) un atributo de extensin,
schemaMapping, para manejar diferencias estructurales entre los elementos Schema de un
servicio Web y sus correspondientes conceptos en el modelo semntico; 3) dos nuevos
elementos, precondition y effect, las cuales son utilizadas principalmente en el
descubrimiento de servicios y 4) un atributo de extensin sobre el elemento interface,
category, el cual provee informacin de categorizacin al publicar un servicio en un
registro como UDDI.

2.5.8 SAWSDL

Semantic Annotations for WSDL (o SAWSDL) fue aprobado en el ao 2007 como una
recomendacin del W3C y realizado por el SAWSDL Working Group basndose en la
presentacin WSDL-S (desarrollada en la seccin anterior).

SAWSDL propone un enfoque similar a WSDL-S. Define algn WSDL y extiende los atributos
XML-Schema a fin de permitir la descripcin semntica de los componentes WSDL. Esto
requiere vincular los elementos WSDL con modelos semnticos como ontologas. SAWSDL
no est sujeto a ningn lenguaje de representacin semntica pero proporciona los
mecanismos para referenciar conceptos del modelo semntico desde documentos WSDL.

Los principios de diseo de SAWSDL son: 1) permitir anotaciones semnticas en servicios

Web por utilizar el framework de extensibilidad de WSDL; 2) es agnstico81 de los lenguajes
de representacin semntica y 3) permite anotaciones semnticas en los servicios Web no
slo para descubrimiento sino tambin para invocacin.

A partir de estos principios de diseo, SAWSDL define tres nuevos atributos de extensibilidad
para elementos WSDL 2.0 a fin de habilitar la anotacin semntica de componentes WSDL: 1)
un atributo de extensin, modelReference, para especificar la asociacin entre un

81
Sin conocimiento.

56
 75.00 Tesis
componente WSDL y un concepto en algn modelo semntico y 2) dos atributos de
extensin, liftingSchemaMapping y loweringSchemaMapping82, los cuales son agregados
a declaraciones de elementos y a definiciones de tipos de XML-Schema por especificar las
asociaciones entre datos semnticos y XML y utilizados durante la invocacin del servicio.

2.6 Razonador

El desarrollo y aplicacin de ontologas depende de razonamiento. Un razonador es un

componente clave para trabajar con ontologas OWL DL [Horridge; 2009].

Una base de conocimiento (KB)83 se compone de un TBox y un ABox. Un TBox describe

conocimiento intencional en la forma de conceptos (clases) y definiciones de roles
(propiedades) y un ABox describe conocimiento por extensin y consiste de un conjunto
finito de aserciones acerca de los individuos mientras utiliza los trminos de la ontologa.
Conviene notar que un ABox representa un conocimiento incompleto acerca del mundo.

Las clases pueden ser organizadas en una jerarqua de superclases-subclases, conocido como
taxonoma. Las subclases especializan (son subsumidas por) superclases. Estas relaciones
pueden ser procesadas por un razonador en OWL-DL. Virtualmente toda consulta a una
ontologa OWL DL debe ser realizada utilizando un razonador que deduzca conocimiento
implcito. El OWL API incluye varias interfaces para acceder a razonadores OWL DL. La
interfaz OWL Reasoner del OWL API es implementada por FACT++, Hermit, Pellet y
RacerPro, entre otros.

Un razonador tambin es conocido como clasificador por la tarea de computar una jerarqua
de clases inferidas.

Como consecuencia de la naturaleza inherentemente distribuida de la Web, el razonamiento

en OWL DL se apoya en lo que se conoce como Open World Assumption84 (OWA) o como
Open World Reasoning85 (OWR). OWA establece que la verdad de un statement es
independiente de si es conocido, esto es, no saber si un statement es explcitamente
verdadero no implica que el statement sea falso (en todo caso se asume que no se ha
agregado suficiente conocimiento a la base de conocimiento). Bajo OWA, informacin nueva
es manejada de forma aditiva debido a que no se puede remover la informacin afirmada
previamente. OWA impacta el tipo de inferencia que puede ser ejecutada sobre la
informacin. En OWL, esto significa que la inferencia slo puede ser ejecutada sobre
informacin que es conocida. La ausencia de una pieza de informacin no puede ser utilizada
para inferir la presencia de otra informacin. La correcta inferencia de las semnticas de
OWL en el mundo distribuido de la Web Semntica depende sobre la adhesin al supuesto de
mundo abierto.

En oposicin a OWA, el Closed World Assumption86 (CWA) afirma que todo statement que no
sea verdadero es asumido como falso. La mayora de los sistemas operan con supuestos de

82
El primero se refiere a levantar datos desde el XML al modelo semntico y el segundo a bajar datos desde el
modelo semntico al XML. Los mapping son tiles cuando la estructura de los datos de instancia (servicio) no se
corresponden con los de la organizacin de datos semnticos. Los mapping son utilizados cuando cdigo de
mediacin es generado para soportar invocacin de servicios.
83
Las siglas corresponden al trmino en ingls Knowledge Base
84
Supuesto de Mundo Abierto.
85
Razonamiento de Mundo Abierto.
86
Supuesto de mundo cerrado.

57
 75.00 Tesis
mundo cerrado. Ellos asumen que la informacin es completa y conocida. Sin embargo, en
algunos casos CWA puede limitar la expresividad de un sistema debido a que es ms difcil
diferenciar entre informacin incompleta e informacin que es desconocida.

A fin de lograr una Web Semntica robusta, las ontologas deben procurar balancear entre la
complejidad computacional requerida por los mecanismos de razonamiento y el poder
expresivo de los conceptos definidos. RDF y RDFS proveen un poder expresivo muy limitado,
insuficiente para representar la semntica asociada a un dominio. OWL provee mayor poder
expresivo y promueve motores de inferencia por suministrar un soporte de razonamiento
apropiado. Nuevos dialectos que necesitan ms servicios de razonamiento e inferencia,
plantean nuevos desafos para los razonadores DL quienes deben controlar subsuncin,
consistencia y satisfactibilidad de las ontologas.

La inferencia hace un dato mucho ms valioso debido a que podra tener un efecto en la
creacin de nueva informacin y conducir a efectos positivos o negativos. Cada pieza de
informacin tiene la capacidad de agregar gran cantidad de informacin nueva va inferencia.
Por ello, se deben tomar cuidados extras para validar la informacin. El proceso de inferencia,
como todo sistema es vulnerable al fenmeno garbage in, garbage out pero la inferencia
ampla este asunto [Hebeler et al.; 2009].

A continuacin, se exponen las limitaciones encontradas en relacin a la utilizacin de

razonadores, servicios Web e inferencia y finalmente inferencia.

[Fahad et al.; 2008] sostuvieron que un soporte de razonamiento preciso es fundamental

para las ontologas de la Web Semntica, lo cual slo puede ser posible si el estado del arte de
los razonadores de lgica descriptiva es capaz de detectar inconsistencias y ordenar
taxonomas en ontologas. Ellos discutieron errores y anomalas de diseo en ontologas y
realizaron un caso de estudio incorporando esos errores. Evaluaron consistencia,
subsuncin y satisfactibilidad de los razonadores DL. El experimento determin errores
dentro de los algoritmos utilizados por los razonadores. Especialmente errores circulares y
varios tipos de errores de inconsistencia semntica que podran causar graves efectos
colaterales, los cuales deberan ser detectados por los razonadores DL a fin de asegurar un
razonamiento preciso sobre ontologas.

[Li et al.; 2006] propusieron un mecanismo de composicin de servicios para realizar el

modelado semntico y el razonamiento de la composicin de servicios con la incorporacin
de preferencias de usuario. Sus pruebas fueron realizadas utilizando una base de
conocimiento con individuos y un TBox acclico debido a que en un TBox acclico las clases
primitivas determinan de manera unvoca la extensin de las clases definidas mientras que en
un TBox cclico no sucede lo mismo.

[Baader et al.; 2005] propusieron un formalismo que describa la funcionalidad de los

servicios Web partiendo de las investigaciones realizadas en los campos de representacin de
conocimiento, de razonamiento por ingeniera de ontologas y de razonamiento acerca de
acciones. Su formalismo se restringi a una base de conocimiento con individuos y un TBox
acclico dado que un TBox cclico presentaba problemas semnticos. En su trabajo adoptaron
la definicin de un TBox acclico por no utilizar las mismas clases definidas en relacin al

58
 75.00 Tesis
TBox.

2.6.1 Clasificacin

Los razonadores pueden ser agrupados en dos categoras: razonadores de lgica descriptiva y
razonadores de programacin lgica.

2.6.1.1 Razonadores de lgica descriptiva

Como se mencion en la seccin 2.3 Lgica y ontologas, las lgicas descriptivas permiten
representar bases de conocimiento que describen un dominio particular. Una lgica
descriptiva se representa a travs de clases (conceptos), individuos, roles (propiedades).
Adems existe un conjunto de extensiones que incluyen el dominio y rango de las
restricciones. [Rodrguez et al.; 2010].

Los razonadores DL brindan los siguientes servicios de inferencia:

Validacin de la consistencia de una ontologa: el razonador puede comprobar si una

ontologa no contiene hechos contradictorios

Validacin del cumplimiento de los conceptos de la ontologa: el razonador determina si es
posible que una clase tenga instancias. En el caso de que un concepto no sea satisfecho la
ontologa ser inconsistente.

Clasificacin de la ontologa: el razonador computa a partir de los axiomas declarados en el
TBox, las relaciones de subclase entre todos los conceptos declarados explcitamente a fin
de construir la jerarqua de clases.

Posibilita la resolucin de consultas durante la recuperacin de informacin basada en
ontologas: a partir de la jerarqua de clases se pueden formular consultas como conocer
todas las subclases de un concepto, inferir nuevas subclases de un concepto, las
superclases directas, etc.

Precisiones sobre los conceptos de la jerarqua: el razonador puede inferir cules son las
clases a las que directamente pertenece y mediante la jerarqua inferida obtener todas las
clases a las cuales indirectamente pertenece una clase o individuo dentro de la ontologa.

Algunos razonadores DL son Pellet, HermiT, FacT++, Racer Pro. Los tres primeros sern
desarrollados en las siguientes secciones dejando para esta seccin, el razonador RacerPro.

Racer87 fue desarrollado en LISP88. Creado inicialmente por la Universidad de Hamburgo

luego se convirti en software propietario. Su nombre comercial es RacerPro. Soporta OWL
DL excepto para los nominales (clases definidas por enumeracin de sus miembros) y para
tipos de datos no estndar; maneja ABoxes largas en combinacin con TBoxes largas y
expresivas, adems de proveer servicios de inferencia sofisticados. Implementa un
procedimiento de decisin basado en calculus tableaux89 para TBoxes (subsuncin,

87
Renamed ABox and Concept Expression Reasoner
88
Lenguaje de programacin de tipo funcional especificado en 1958 es el segundo lenguaje de programacin ms
viejo de alto nivel. Utilizado frecuentemente en IA.
89
O tablas semnticas se encuentran dentro de lo que se conoce como algoritmos de razonamiento [Rodrguez et al.;
2010] y se basan en las semnticas de las frmulas. De acuerdo a su tipo, una formula genera una extensin en el

59
 75.00 Tesis
satisfactibilidad, clasificacin) y ABoxes (consultas). Soporta la OWL-API, la interfaz DIG,
transformaciones SPARQL y SWRL a nRQL, diferentes formatos y sintaxis, conectividad con
software externo (Protg, etc.), entre otras caractersticas. La ltima versin comercial es
RacerPro 1.9.0 que ser reemplazada por RacerPro 2.0 a liberarse en el 2011.

2.6.1.2 Razonadores de programacin lgica

Entre los razonadores de programacin lgica se encuentran: KAON2, FLORA-2, TRIPLE,
DLV, MINS, Jena, entre otros. A continuacin se desarrollarn algunos.

KAON2 es un razonador con sistema de razonamiento hbrido que soporta SHIQ(D), Datalog y
DL-Safe. Fue desarrollado por la Universidad de Manchester, la Universidad de Karlsruhe y el
FZI90. Dentro de KAON2, las reglas DL-Safe pueden ser agregadas a la salida de un DataLog
disyuntivo y no requieren preprocesamiento adicional, lo que mejora el rendimiento Su
razonamiento es implementado a travs de algoritmos Novel, que reducen una base de
conocimiento SHIQ(D) a un programa de registro de datos disyuntivos. Posee una versin
comercial llamada OntoBroker OWL. KAON2 no maneja nominales ni nmeros grandes en
sentencias de cardinalidad.

FLORA-2 es un sistema basado en conocimiento y un entorno completo para el desarrollo de

aplicaciones que hacen uso de conocimiento. FLORA-2 extiende el clculo de predicados con el
concepto de objeto, clase y tipo, adaptados de la POO.

TRIPLE es un lenguaje de consulta, inferencia y transformacin para la Web Semntica.

Proporciona soporte para RDF y para un subconjunto de OWL Lite. Su sintaxis est basada en F-
Logic y brinda soporte para smbolos de funcin, tratamiento de la igualdad o negacin por
defecto, transformaciones, modelos y extensin sintctica de la lgica de Horn. El motor de
inferencia de TRIPLE se basa en el sistema PROLOG XSB.

Jena es un framework open source para construir aplicaciones de la Web semntica sobre
modelos RDF. Soporta varios formatos como XML/RDF, N3 y N-Triples (formatos para grafos
abreviados). Los grafos son representados internamente como un modelo abstracto, que se puede
consultar mediante el lenguaje de consultas para RDF y SPARQL. Permite el tratamiento del
lenguaje OWL, al utilizar el modelo semntico de RDF y proporciona conexin de forma externa
a travs de la interfaz DIG hacia razonadores DL como Pellet o FaCT++. Jena posee la
capacidad para conectarse con motores de inferencia externos tipo Plug-in a travs de una
interface DIG y tambin ofrece un subsistema de inferencia propio el cual consiste en un motor
hbrido con encadenamiento hacia delante y hacia atrs, utilizando el algoritmo RETE (algoritmo
de reconocimiento de patrones). Ofrece razonadores para RDF, OWL, DAML, razonador
transitivo y motor de reglas multipropsito.

tableaux. La clasificacin de las frmulas son tipo , para las formulas conjuntivas; tipo , para las frmulas
disyuntivas; tipo para las frmulas universales y tipo , para las frmulas existenciales. La base de este mtodo es
el principio de refutacin: dado un conjunto de premisas y una conclusin , mostrar que el conjunto {}
no tiene un modelo que lo satisfaga, demostrando que es una consecuencia de .
90
Universidad en Inglaterra, Universidad en Alemania y una de las ms prestigiosas de ese pas, Organizacin de
investigacin por contratos sin fines de lucro para proveedores de inversin, productos de consumo y servicios de
informacin que soporta el desarrollo de aplicaciones innovadoras, principalmente en ingeniera, sobre la base de
tcnicas recientes y probadas. La organizacin permite a profesores extender sus esfuerzos en la investigacin
acadmica en la direccin de actividades ms orientadas al mercado por prestar una infraestructura tcnica y
organizacional que es congenial a establecer relaciones estrechas con la industria y organizaciones de servicios.
http://www.fzi.de/

60
 75.00 Tesis
2.7 SWRL

El Semantic Web Rule Language se basa en OWL DL y OWL Lite y utiliza el subconjunto de
reglas RuleML del Rule Markup Language91 las cuales son modeladas sobre clusulas Horn. El
propsito de SWRL es extender el conjunto de axiomas OWL al incluir clusulas Horn que
puedan ser combinadas con la base de conocimiento de OWL92.

Las clusulas Horn representan condicionales if-then o ms formalmente implicaciones. De

esta manera, las reglas tienen la forma de una implicacin entre un antecedente (referido
como body en la sintaxis) y un consecuente (referido como head en la sintaxis). Una regla
puede ser interpretada como si las condiciones especificadas en el antecedente son
verdaderas entonces, las condiciones especificadas en el consecuente tambin son
verdaderas.

Ambos, el antecedente y el consecuente consisten de cero o ms tomos. Un antecedente

vaco es tratado trivialmente como verdadero y por lo tanto, el consecuente tambin es
verdadero. Un consecuente vaco es tratado trivialmente como falso y por lo tanto, el
antecedente tambin es falso.

Los tomos pueden ser de la forma C(x), P(x, y), sameAs (x, y), differentFrom (x, y), donde C
es una descripcin OWL, P es una propiedad OWL y x, y pueden representar variables,
individuos OWL o valores de datos OWL. Cabe destacar que OWL DL pierde decidibilidad93
cuando es extendido de esta manera porque las reglas pueden ser utilizadas para simular
asociaciones rol valor.

SWRL utiliza una extensin de la semntica model-theoretic94 de OWL. SWRL es construido

sobre OWL DL y provee ms expresividad que OWL DL slo. Sin embargo, comparte la
semntica formal: las conclusiones alcanzadas por SWRL tienen la misma garanta formal
que las conclusiones alcanzadas por construcciones OWL.

La expresividad adicional de SWRL es lograda a expensas de perder decidibilidad (mientras

es posible garantizar que un razonador OWL completar la clasificacin de una ontologa
OWL, no ocurre lo mismo a partir de la inferencia con SWRL). En general, se debera utilizar
OWL siempre que sea posible y recurrir a SWRL, slo cuando resulte necesario disponer de
expresividad adicional.

[Hebeler et al.; 2009] enuncian a las reglas como un medio para representar conocimiento
que con frecuencia no es posible en OWL 1 o que resulta ms fcil de comprender que las
expresiones que OWL 1 puede ofrecer.

2.7.1 Motivaciones

Segn [Hebeler et al.; 2009] las reglas surgieron por la falta de expresividad de OWL 1.

OWL 1 no presenta soporte para la composicin de propiedades. Este problema tambin es

91
http://ruleml.org/
92
http://www.w3.org/Submission/SWRL/#owls_Rule
93
En lgica, el trmino decidible refiere a la existencia de un mtodo efectivo para determinar la pertenencia a un
conjunto de frmulas, Por ejemplo, los sistemas lgicos, como la lgica proposicional, son decidibles si
efectivamente se puede determinar la pertenencia a los conjuntos de frmulas vlidas lgicamente.
94
Desarrollado en la seccin 2.5.2.3, Semntica Formal.

61
 75.00 Tesis
conocido como uncle problem. Es imposible, en OWL 1, determinar que un individuo A
tiene una relacin uncle con un individuo B debido a la necesidad de dos piezas de
informacin: que A tenga una relacin father con C y que C tenga una relacin sibling con B.
Las reglas soportan la existencia de ambas piezas de informacin que resultan en la creacin
de la relacin uncle. OWL 2 parcialmente resolvi este problema mediante la
owl:propertyChain. Cabe aclarar que SWRL en anterior a OWL 2.

La utilizacin de built-ins permite realizar transformaciones comunes sobre los datos. No es

posible en OWL 1 verificar si una URI tiene una data-property que empieza con una palabra
dada y utilizar esa informacin como base para agregar una nueva propiedad al mismo
sujeto. La asociacin por patrones, operaciones matemticas, verificacin de condicionales o
conversin de unidades son algunas de las necesidades para built-ins.

Las reglas pueden ser utilizadas para limitar el Open World Assumption (OWA) de OWL
(empleando una tcnica conocida como Negation as Failure95 o NAF) o soportar el supuesto
de individuos nicos96.

As, aparte de las ya mencionadas, existen otras carencias en OWL 1 que son superadas por
la utilizacin de reglas.

2.7.2 DL-Safe Rules

Las DL-Safe Rules poseen como propiedad decidibilidad y solucionan algunos de los
problemas asociados con la prdida de decidibilidad que ocasiona SWRL.

Las DL-Safe Rules son un subconjunto de SWRL y asocian instancias conocidas de la base de
conocimiento o la ontologa con las variables utilizadas por las reglas. Si no existe una
instancia que se pueda asociar con una consulta, entonces el consecuente de una regla DL-
Safe no se ejecutar sin importar que las reglas sean perfectamente vlidas. La decidibilidad
slo puede ser garantizada por tener toda la informacin necesaria al momento de evaluar la
regla. Restringiendo las reglas slo a individuos conocidos asegura decidibilidad como fue
demostrado en [Motik et al., 2005].

2.8 Ejemplos

Los trabajos de investigacin estudiados han empleado ontologas sencillas a fin de concentrarse
en los aspectos de una solucin al problema de composicin dinmica de servicios: [Paolucci et
al.; 2002] utilizaron una ontologa de vehculos hecha en DAML; [Li et al.; 2006] eligieron
como escenario el de una biblioteca universitaria, utilizando OWL-S para la descripcin y OWL
para el modelado y razonamiento de la composicin de servicios; en [Yong-Feng et al.; 2007]
utilizaron OWL-S para la composicin de servicios y OWL para describir la interaccin de
agentes; [Fahad et al.; 2008] emplearon una ontologa de automviles en OWL a fin de
evaluar los razonadores DL con respecto a su capacidad para clasificar e identificar
inconsistencias en las ontologas. Por otro lado, el W3C utiliza como ejemplo en sus
publicaciones relacionadas a la Web Semntica una ontologa de vinos (wine.owl). Adems
de las ontologas en el rea de la medicina, mencionadas anteriormente en la seccin 2.4,

95
Por ejemplo if Adan isnt known to have a brother, then assert he is brotherless
96
En OWL los individuos son supuestos ser iguales salvo que explcitamente sea establecido lo contrario.

62
 75.00 Tesis
existen ontologas disponibles en el sitio Semantic Web97, en el sitio del laboratorio LSDIS
del Departamento de Computacin de la Universidad de Georgia98, en DAML99, en el sitio
del proyecto Co-Ode del Departamento de Computacin de la Universidad de
Manchester100 y por medio del buscador semntico Swoogle101 (con 10.000 ontologas
disponibles), entre otras.

La ontologa mostrada a continuacin fue desarrollada en OWL con el editor de ontologas

Protg 4.1.0. Despus de evaluar las ontologas utilizadas en los trabajos mencionados, se
eligi construir una ontologa que describiera la bolsa de trabajo de una facultad.

Jerarqua de clases de http://www.semanticweb.org/ontologies/2010/11/StudentsJobBag.owl.

En el panel izquierdo se puede observar la jerarqua y en el panel central el grafo
correspondiente.

97
http://semanticweb.org/wiki/Ontology
98
http://lsdis.cs.uga.edu/projects/
99
http://www.daml.org/index.html
100
http://www.co-ode.org/
101
http://swoogle.umbc.edu/

63
 75.00 Tesis

Individuos utilizados en las definiciones de las clases Graduate y UnderGraguate en

http://www.semanticweb.org/ontologies/2010/11/StudentsJobBag.owl.

El iri http://www.semanticweb.org/ontologies/2010/11/StudentsJobBag.owl es el identificador en

el contexto de la Web de la ontologa desarrollada, la cual se encuentra almacenada en el archivo
StudentsJobBag.owl. Anteponiendo el iri a cada elemento de la ontologa, se obtiene su nombre
completo. El nombre completo del individuo notice_undergraduate es
http://www.semanticweb.org/ontologies/2010/11/StudentsJobBag.owl#notice_undergraduate. La
ontologa de aqu en adelante ser referenciada en su forma corta como bolsa de trabajo o
StudentsJobBag, indistintamente.

En el panel superior izquierdo se puede observar la jerarqua de clases, la cual se compone de

cinco (5) clases definidas (precedidas por el smbolo y resaltadas en naranja) y nueve (9) clases
primitivas.

Todas las clases permiten describir las actividades ms comunes relacionadas a la bolsa de
trabajo de una facultad y proporcionan la informacin necesaria para el propsito de llevar a
cabo una composicin de servicios Web. Esta seccin se enfoca en la ontologa misma.

Se llaman clases primitivas aquellas que poseen un conjunto de condiciones necesarias, esto es,
si un individuo es definido del tipo de una clase primitiva, necesariamente debe cumplir con las
condiciones de la clase pero si un individuo, del que se desconoce su tipo, cumple con las
condiciones de la clase, su tipo permanece desconocido. Por otro lado, se llaman clases
definidas aquellas que poseen un conjunto de condiciones necesarias y suficientes. A diferencia
de las clases primitivas, las clases definidas permiten que cualquier individuo cuyo tipo sea
desconocido y que cumpla con las condiciones de la clase sea clasificado como miembro de la
clase (el tipo del individuo ya no es ms desconocido). Como se mencion secciones atrs, las

64
 75.00 Tesis
clases definidas proporcionan informacin suficiente para que un razonador DL pueda realizar
clasificacin automtica.

En la ontologa bolsa de trabajo, las clases definidas incluyen la clase Student, la cual representa
al conjunto de individuos de tipo Estudiante; la clase Graduate, para el conjunto de individuos de
tipo Graduado; la clase UnderGraduate, para el conjunto de individuos de tipo No Graduados, la
clase JobOffer, para el conjunto de individuos de tipo Oferta de Trabajo y la clase PostulationJob
para el conjunto de individuos de tipo Postulacin de trabajo.

Los individuos fueron definidos en una ontologa aparte (como se explicar ms adelante en esta
seccin); salvo aquellos individuos que forman parte de las definiciones de las clases Graduate y
Undergraduate; a saber, los individuos notice_graduate y notice_undergraduate, pertenecientes a
la clase Notice.

Las definiciones empleadas en las clases Student, UnderGraduate, Graduate, JobOffer y

PostulationJob son mostradas aqu a continuacin:

TBox = {
Graduate hasNotice value notice_graduate

UnderGraduate hasNotice value notice_underGraduate

Student Graduate New_Student UnderGraduate

JobOffer JobOfferPassant JobOfferProfessional

PostulationJob PostulationJobProfessionalJob
PostulationJobPassantJob
}

La definicin de la clase Graduate afirma que los individuos que tienen una nota de graduado
son graduados. La restriccin value empleada aqu equivale semnticamente a una restriccin
existencial ya que no reduce la propiedad hasNotice a un individuo especfico. Cualquier
individuo que posea la propiedad hasNotice y adems como valor de la misma al individuo
especfico notice_graduate automticamente ser clasificado como miembro de la clase
Graduate. Un individuo miembro de la clase Graduate puede poseer ms valores en su propiedad
hasNotice y seguir siendo miembro de la clase Graduate siempre que mantenga una relacin
hasNotice con un individuo notice_graduate. En general las restricciones value relacionan un
conjunto de individuos con una clase enumerada, la cual incluye al el individuo de la restriccin.

La definicin de la clase UnderGraduate afirma que los individuos con la propiedad hasNotice y
el valor notice_underGraduate son no graduados. La restriccin empleada aqu tambin es una
restriccin value, de manera que los individuos de esta clase pueden tener otros valores en su
propiedad hasNotice, es decir, estar relacionados con otros individuos mientras mantengan la
relacin hasNotice con el individuo especfico notice_undergraduate. La intencin de esta clase
es representar al conjunto de individuos no graduados.

La clase Student es definida por la unin de tres conjuntos de individuos, a saber los individuos
miembros de las clases Graduate, New_Student y UnderGraduate, respectivamente. Un
razonador DL, partiendo de esta definicin, detecta una relacin de subsuncin e inmediatamente
infiere a las clases Graduate, New_Student y UnderGraduate como subclases de la clase Student.
De esta manera, los individuos miembros de cualquiera de las tres clases son tambin
clasificados como miembros de la clase Student.

65
 75.00 Tesis
La clase JobOffer es definida de manera similar a la clase Student. Comprende el conjunto de
individuos resultante de la unin de dos conjuntos de individuos, a saber los individuos
miembros de las clases JobOfferPassant y JobOfferProfessional, respectivamente. Un razonador
DL, siguiendo esta definicin, detecta una relacin de subsuncin e inmediatamente infiere que
las clases JobOfferPassant y JobOfferProfessional son subclases de la clase JobOffer. De esta
manera, los individuos miembros de cualquiera de las dos clases son tambin clasificados como
miembros de la clase JobOffer.

La clase PostulationJob es definida de manera similar a la clase JobOffer. Comprende el

conjunto de individuos resultante de la unin de dos conjuntos de individuos, a saber los
individuos miembros de las clases PostulationJobProfessionalJob y PostulationJobPassantJob,
respectivamente. Un razonador DL, siguiendo esta definicin, detecta una relacin de subsuncin
e inmediatamente infiere que las clases PostulationJobProfessionalJob y PostulationJobPassantJob
son subclases de la clase PostulationJob. De esta manera, los individuos miembros de cualquiera
de las dos clases son tambin clasificados como miembros de la clase PostulationJob.

Como se mencion, las clases primitivas poseen un conjunto de condiciones necesarias y las
clase definidas un conjunto de condiciones necesarias y suficientes. Estas condiciones, tambin
llamadas condiciones de clase, constituyen una parte de los axiomas utilizados por la ontologa y
son las que posibilitan agregar ms informacin sobre la informacin.

En la ontologa bolsa de trabajo, las clases primitivas incluyen la clase Curriculum, la clase
JobOfferPassant, la clase JobOfferProfesional, la clase New_Student, la clase Record, la clase
JobPostulant, la clase Notice, la clase PostulationJob, la clase PostulationPassantJob y la clase
PostulationProfessionalJob. Un razonador no puede inferir que un individuo desconocido que
cumpla con las condiciones de alguna de estas clases primitivas sea miembro de algunas de ellas
debido a que las condiciones son condiciones necesarias pero no suficientes.

En la ontologa se declaran las clases Curriculum, Student, Record y JobOffer como

DisjointClasses (disjuntas). De esta manera, un individuo declarado de tipo Curriculum y
Student provocara una inconsistencia en la ontologa y esto sera detectado por un razonador
DL.
El axioma DisjointClasses (disyuncin) se utiliz para las clases de todos los niveles (las clases
del nivel tres PostulationPassantJob y PostulationProfessionalJob son disjuntas y un individuo no
puede pertenecer a ambas).

A continuacin, se muestra la jerarqua de clases inferidas utilizando Pellet 2.2.1 como razonador
DL.

66
 75.00 Tesis

Jerarqua de clases inferidas en

http://www.semanticweb.org/ontologies/2010/11/StudentsJobBag.owl.

El razonador DL dej en el primer nivel de la jerarqua a la clase Curriculum y a las superclases

JobOffer, Record y Student. La clase JobOffer es una superclase de JobOfferProfessional y
JobOfferPassant; la clase Record es superclase de las clases Notice, JobPostulant y
PostulationlJob, y la clase Student como superclase de las clases (por inferencia) Graduate,
New_Student y UnderGraduate. La clase PostulationlJob, ubicada en el segundo nivel, qued
como superclase de las clases PostulationPassantJob y PostulationProfessionalJob y subclase de
la clase Record.

A continuacin se describen las propiedades.

67
 75.00 Tesis

Jerarqua de object-properties en
http://www.semanticweb.org/ontologies/2010/11/StudentsJobBag.owl.

Como se describi en la seccin 2.5.2.1, la propiedad topObjectProperty (introducida en OWL2)

es la propiedad de nivel superior y representa al conjunto de pares ordenados de todas las
propiedades. De acuerdo con la convencin de utilizar clases definidas para la definicin de
rangos y dominios de las propiedades, no se definieron rangos ni dominio salvo para la
propiedad hasRecord cuyo dominio es representado por la clase definida Student. El motivo de
esta convencin surge a causa de que la definicin del rango o dominio de una propiedad
constituye un axioma, y un razonador puede inferir errneamente el tipo de un individuo por
asociarlo con las clases del rango o dominio, conduciendo a inconsistencias que luego son
difciles de detectar en ontologas ms grandes. El hecho de utilizar axiomas de rangos y
dominios con clases definidas conduce a que un razonador infiera correctamente el tipo de un
individuo por recurrir a la definicin de la clase.

Las propiedades hasJobPostulant, hasNotice y hasPostulationJob son subproperties de hasRecord

o, lo que es lo mismo, hasRecord es una superproperty de ellas. Este tipo de relacin jerrquica
entre propiedades provoca que para un par ordenado de individuos (i1, i2) relacionados por la
propiedad hasNotice (por ejemplo), el individuo i1 sea inferido y clasificado por un razonador
DL como miembro de la clase Student, debido a que el dominio de la propiedad hasNotice es
inferido ser del mismo tipo que el dominio de su superproperty hasRecord, el cual fue definido
de tipo Student y, por otro lado, el mismo par ordenado es clasificado como miembro de la
propiedad hasRecord o sea que, los dos individuos son tambin asociados por la propiedad
hasRecord.

Las propiedades RecordOf, CurriculumOf, JobPostulantOf, NoticeOf y PostulationJobOf son

propiedades inversas de hasRecord hasCurriculum, hasJobPostulant, hasNotice y
hasPostulationJob, respectivamente. Por ser la clase Student dominio de la propiedad hasRecord,
un razonador DL infiere que el rango de la propiedad RecordOf debe ser de tipo Student y al ser
la propiedad RecordOf superproperty de CurriculumOf, JobPostulantOf, NoticeOf y

68
 75.00 Tesis
PostulationJobOf, infiere el mismo rango para estas ltimas.
Las propiedades hasNotice, hasJobPostulant, hasCurriculum, NoticeOf, JobPostulantOf y
CurriculumOf son definidas como propiedades funcionales. Esto significa que un individuo
inscripto en la bolsa de trabajo de una facultad tendr un registro llamado postulacin de trabajo
(JobPostulant) con sus datos. Este registro es nico para cada individuo. Si otro individuo tuviera
el mismo registro un razonador inferir que, por ser la propiedad hasJobPostulant funcional, se
trata del mismo individuo. Si ambos individuos fueran declarados como distintos
(DifferentIndividuals) esto provocara una inconsistencia con la ontologa. De esta manera se
establece que un individuo puede tener solamente un curriculum, puede registrarse una vez en la
bolsa de trabajo y puede tener solamente una nota (de graduado o no graduado para el escenario
planteado y descripto ms adelante).

Hasta aqu se ha utilizado una parte de las posibilidades expresivas que OWL brinda. La
documentacin OWL102 (W3C) es bastante completa al respecto y muchos de los trabajos
consultados por esta tesis han elegido a OWL como el lenguaje de ontologa Web para
comunicar sus servicios y respaldar sus investigaciones.

A continuacin se describen las data-properties.

Jerarqua de data-properties en
http://www.semanticweb.org/ontologies/2010/11/StudentsJobBag.owl.

Un data-property relaciona un individuo con datatypes XML-Schema o literales RDF.

El rango de la propiedad contractType fue definido de tipo string, de manera que un individuo
podra tener como valor de la propiedad contractType el string relacin de dependencia.

El rango de las data-properties fue definido de tipo string, salvo para las data-properties year y
numberReg con rango de tipo int.

102
http://www.w3.org/TR/2009/REC-owl2-primer-20091027/

69
 75.00 Tesis
OWL ofrece variedad de datatypes como float, long, date, decimal, base64binary, QName,
positiveinteger, XMLLiteral, ENTITY, NMToken, ID, IDREF, IDREFS, etc., pero para los fines
de este trabajo fue suficiente con los tipos mencionados.

La jerarqua de data-properties consta de las propiedades contractType, employer, expiration,

horaryJobPosting, matriculate, numberReg, place, profession, reference, registrationDate,
requirements, tasks, university y year.

El iri http://www.semanticweb.org/ontologies/2010/11/membersStudentsJobBag.owl es el
identificador en el contexto de la Web de la ontologa de individuos desarrollada y la misma se
encuentra almacenada en el archivo membersStudentsJobBag.owl. Anteponiendo el iri, se
obtiene el nombre completo de los individuos que componen la ontologa. . La ontologa ser
referenciada de aqu en adelante como individuos o miembros de la bolsa de trabajo
indistintamente.

Como se mencion anteriormente, los individuos fueron definidos en un archivo aparte. [Hebeler
et al.; 2009] sugieren que este tratamiento paralelo produce un razonamiento ms eficiente el
cual resulta ms apreciable en ontologas grandes. La ontologa de individuos se apoya en la
ontologa bolsa de trabajo para realizar la definicin de los individuos. A continuacin, se
muestra la ontologa de miembros de la bolsa de trabajo.

Individuos en
http://www.semanticweb.org/ontologies/2010/11/membersStudentsJobBag.owl

Los individuos son mostrados a partir de su tipo definido. As, el individuo c fue definido de
tipo Curriculum, el individuo jp de tipo JobPostulant, el individuo nt de tipo New_Student, el
individuo n de tipo Notice, el individuo ppas de tipo PostulationPassantJob y el individuo

70
 75.00 Tesis
pprof de tipo PostulationProfessionalJob. Para definir el individuo gd se utiliz la asercin
hasNotice notice_graduate, que afirma que el individuo gd tiene una nota de graduado. Su
tipo permanece desconocido. De la misma manera, el individuo ug fue definido utilizando la
asercin hasNotice notice_undergraduate, que afirma que el individuo ug tiene una nota de
no graduado. Su tipo tambin permanece desconocido. Con estas definiciones y las
presentadas para Graduate y UnderGraduate, un razonador DL puede inferir los tipos para
gd y ug, respectivamente.

Es oportuno aclarar que los individuos de una clase tambin son llamados instancias de la
clase. De aqu en ms se emplear el trmino instancia o individuo indistintamente.

ABox = {
c (Curriculum)

gd (hasNotice notice_graduate)

jp (JobPostulant )

nt (New_Student)

n (Notice)

ppas (PostulationPassantJob)

pprof (PostulantProfessionalJob)

r (Record)

ug (hasNotice notice_undergraduate)

71
 75.00 Tesis
Por ltimo se presentan las mtricas de la ontologa recogidas por Protg.

Mtricas para la ontologa miembros de la bolsa de trabajo

(http://www.semanticweb.org/ontologies/2010/11/membersStudentsJobBag.owl)

Se puede observar que las mtricas contabilizan los axiomas de las ontologas importadas (la
ontologa bolsa de trabajo). Los indicadores reflejan los siguientes valores: 14 clases, 10
object-properties, 14 data properties, y 10 individuos. Para las clases tenemos 5 axiomas de
subclase, 5 axiomas de clases equivalentes, 5 axiomas de clases disjuntas. Para las object-
properties, 6 axiomas de subproperties, 4 axiomas de propiedades inversas, 7 axiomas de
propiedades funcionales, 1 axioma de dominio. Para las data-properties, 1 axioma de dominio
y 14 axiomas de rango. Y para los individuos, 8 axiomas de asercin de clase y 2 axiomas de
asercin de propiedad.

Las clases equivalentes mencionadas en las mtricas corresponden a las clases definidas
Student, JobOffer, Graduate, UnderGraduate y PostulationJob, descriptas anteriormente. Los
axiomas utilizados en la definicin de cada clase son considerados como una clase annima y
por lo tanto, la mtrica de clases equivalentes corresponde a la equivalencia entre las clases
definidas y las clases annimas utilizadas en sus definiciones.

72
 75.00 Tesis
Por ltimo, se mostrarn las reglas DL-Safe Rules las cuales fueron definidas empleando
ontologas separadas.

rulesMatriculate: DL-Safe Rule del servicio Web semntico wsMatriculate en

http://www.semanticweb.org/ontologies/2010/11/rulesMatriculate.owl

El iri http://www.semanticweb.org/ontologies/2010/11/rulesMatriculate.owl es el
identificador, en el contexto de la Web, de la ontologa reglas de matriculacin (almacenada en el
archivo rulesMatriculate.owl), desarrollada para describir las operaciones del servicio Web
Matriculate (o tambin llamado wsMatriculate). La ontologa de reglas se apoyo en las
ontologas anteriores, bolsa de trabajo y miembros de la bolsa de trabajo para la elaboracin de la
misma.

La regla rulesMatriculate es empleada para anotar la operacin proofRegister del servicio

wsMatriculate. Esta regla establece que si un individuo es un nuevo estudiante y presenta una
nota de inscripcin entonces el nuevo estudiante es registrado con la nota de inscripcin
presentada. Por lo tanto, la condicin que debe cumplirse para que la operacin pueda
ejecutarse satisfactoriamente es que previamente exista una instancia nt de la clase
New_Student y una instancia n de la clase Notice. El resultado de la accin realizada por la
operacin proofRegister ser la creacin de la relacin NoticeOf entre n, de la clase Notice con
la instancia nt de la clase New_Student.

En el panel derecho superior se puede observar el enunciado de la regla. A la izquierda se

encuentran las clases, propiedades e individuos importados de las ontologas bolsa de trabajo
y miembros de la bolsa de trabajo, respectivamente.

73
 75.00 Tesis

rulesMatriculate: relaciones inferidas en

http://www.semanticweb.org/ontologies/2010/11/rulesMatriculate.owl

Despus de correr el razonador Pellet integrado a Protg y, como consecuencia de la regla, el

razonador infiere que la instancia n de la clase Notice est relacionada con la instancia nt de la
clase New_Student, por las propiedades NoticeOf y RecordOf. La ltima relacin es inferida
debido a que NoticeOf es subproperty de RecordOf. Luego, como NoticeOf es propiedad
inversa de hasNotice, el razonador tambin infiere, ahora para la instancia nt, la relacin
hasNotice con la instancia n y por ser hasNotice subproperty de hasRecord, tambin la
relacin hasRecord con n. Se puede observar a la izquierda la instancia n (resaltado en azul)
y, a la derecha, sus relaciones inferidas con la instancia nt (resaltado en amarillo).

74
 75.00 Tesis

rulesInscribeJobBag: DL-Safe Rule del servicio Web semntico wsInscribeJobBag en

http://www.semanticweb.org/ontologies/2010/11/rulesInscribeJobBag.owl
.

El iri http://www.semanticweb.org/ontologies/2010/11/rulesInscribeJobBag.owl es el
identificador, en el contexto de la Web, de la ontologa reglas de inscripcin de la bolsa de
trabajo (almacenada en el archivo rulesInscribeJobBag.owl), desarrollada para describir las
operaciones del servicio Web InscribeJobBag (o tambin llamado wsInscribeJobBag). La
ontologa de reglas se apoyo en las ontologas anteriores, bolsa de trabajo y miembros de la bolsa
de trabajo para la elaboracin de la misma

La regla rulesInscribeJobBag es empleada para anotar la operacin applyForJobBag del

servicio wsInscribeJobBag. Esta regla establece que si un nuevo estudiante posee una nota y
existe un curriculum entonces puede inscribirse a la bolsa de trabajo y obtener un registro de
postulante de trabajo. Por lo tanto, la condicin que debe cumplirse para que la operacin
pueda ejecutarse satisfactoriamente es que previamente existan instancias c, n y nt de las
clases Curriculum, Notice y New_Student respectivamente, y que la instancia n est asociada
con la instancia nt (n sea nota de nt). El resultado de la accin realizada por la operacin
applyForJobBag ser la creacin de una nueva relacin entre la instancia jp de la clase
JobPostulant con la instancia nt de la clase New_Student.

En el panel derecho superior se puede observar el enunciado de la regla. A la izquierda se

encuentran las clases, propiedades e individuos de las ontologas bolsa de trabajo y miembros
de la bolsa de trabajo, respectivamente.

75
 75.00 Tesis

rulesInscribeJobBag: relaciones inferidas

http://www.semanticweb.org/ontologies/2010/11/rulesInscribeJobBag.owl

Despus de correr el razonador Pellet integrado a Protg y, como consecuencia de la regla, el

razonador infiere para el individuo nt las relaciones por medio de las propiedades
hasJobPostulant y hasRecord (esta ltima relacin inferida debido a que hasJobPostulant es
subproperty de hasRecord) con el individuo jp. Consecuentemente, como hasJobPostulant es
propiedad inversa de JobPostulantOf, el razonador tambin para el individuo jp las relaciones
JobPostulantOf y RecordOf con nt (esta ltima relacin por ser JobPostulantOf subproperty
de RecordOf). Se puede observar a la izquierda al individuo nt (resaltado en azul) y, a la
derecha, las relaciones inferidas con jp (resaltado en amarillo).

Las relaciones inferidas para el individuo nt, hasRecord y hasNotice con el individuo n de la
clase Notice son debidas al antecedente de la regla InscribeJobBag.

Las relaciones inferidas para el individuo nt, hasRecord y hasJobPostulant con el individuo jp
son debidas al consecuente de la regla InscribeJobBag.

Las relaciones inferidas mostradas son slo algunas. El razonador tambin infiere otras
relaciones para los individuos jp y n.

76
 75.00 Tesis

rulesPostulateJobG: DL-Safe Rule del servicio Web semntico wsPostulateJobG en

http://www.semanticweb.org/ontologies/2010/11/rulesPostulateJobG.owl

El iri http://www.semanticweb.org/ontologies/2010/11/rulesPostulateJobG.owl es el
identificador, en el contexto de la Web, de la ontologa reglas para las postulaciones a trabajos
profesionales en la bolsa de trabajo (almacenada en el archivo rulesPostulateJobG.owl),
desarrollada para describir las operaciones del servicio Web PostulateJobG (o tambin llamado
wsPostulateJobG). La ontologa de reglas se apoyo en las ontologas anteriores, bolsa de trabajo
y miembros de la bolsa de trabajo para la elaboracin de la misma

La regla rulesPostulateJobG es empleada para anotar la operacin postulateJob del servicio

wsPostulateJobG. Esta regla establece que si un nuevo estudiante esta registrado en la bolsa de
trabajo (posee un registro de postulante de trabajo asociado) y adems es graduado entonces
puede postularse a una oferta de trabajo profesional quedando registrado su postulacin de
trabajo profesional. Por lo tanto, la condicin que debe cumplirse para que la operacin
pueda ejecutarse satisfactoriamente es que previamente existan instancias nt y jp de las
clases New_Student y JobPostulant, respectivamente, que la instancia jp est asociada con la
instancia nt y que, a su vez, la instancia nt este asociada con la instancia notice_graduate, de la
clase Notice. El resultado de la accin realizada por la operacin postulateJob ser la creacin
de la relacin hasPostulationProfessionalJob entre una instancia pprof de la clase
PostulationProfessionalJob con nt.

En el panel derecho superior se puede observar el enunciado de la regla. A la izquierda se

encuentran las clases, propiedades e individuos importados de las ontologas bolsa de trabajo
y miembros de la bolsa de trabajo, respectivamente.

77
 75.00 Tesis

rulesPostulateJobG: relaciones inferidas en

http://www.semanticweb.org/ontologies/2010/11/rulesPostulateJobG.owl

Despus de correr el razonador Pellet integrado a Protg y, como consecuencia de la regla, el

razonador infiere para el individuo nt las relaciones hasPostulationProfessionalJob y
hasRecord con el individuo pprof de la clase PostulationProfessionalJob (la ltima relacin es
inferida debido a que hasPostulationProfessionalJob es subproperty de hasRecord). Se puede
observar a la izquierda al individuo nt (resaltado en azul) y, a la derecha, las relaciones
inferidas con pprof y con jp (resaltado en amarillo) y las relaciones afirmadas (resaltadas en
verde).

Las relaciones inferidas para el individuo nt, hasJobPostulant y hasRecord con el individuo jp
son debidas al antecedente de la regla rulesPostulateJobG.

La relaciones inferidas para el individuo nt, hasPostulationProfessionalJob y hasRecord con

el individuo pprof son debidas al consecuente de la regla rulesPostulateJobG.

Las relaciones inferidas mostradas son slo algunas. El razonador tambin infiere relaciones
para el individuo jp y gd. Para el caso de pprof, como RecordOf es propiedad inversa de
hasRecord, el razonador infiere que el individuo pprof tiene una relacin RecordOf con nt.

78
 75.00 Tesis

rulesPostulateJobU: DL-Safe Rule del servicio Web semntico wsPostulateJobU en

http://www.semanticweb.org/ontologies/2010/11/rulesPostulateJobU.owl

El iri http://www.semanticweb.org/ontologies/2010/11/rulesPostulateJobU.owl es el
identificador, en el contexto de la Web, de la ontologa reglas para las postulaciones a trabajos
profesionales de la bolsa de trabajo (almacenada en el archivo rulesPostulateJobG.owl),
desarrollada para describir las operaciones del servicio Web PostulateJobG (o tambin llamado
wsPostulateJobG). La ontologa de reglas se apoyo en las ontologas anteriores, bolsa de trabajo
y miembros de la bolsa de trabajo para la elaboracin de la misma

La regla rulesPostulateJobU es empleada para anotar la operacin postulateJob del servicio

wsPostulateJobU. Esta regla establece que si un nuevo estudiante est registrado en la bolsa de
trabajo (posee un registro de postulante de trabajo asociado) y adems es no graduado
entonces puede postularse a una oferta de pasanta quedando registrado la postulacin de
pasanta efectuada. Por lo tanto, la condicin que debe cumplirse para que la operacin pueda
ejecutarse satisfactoriamente es que previamente existan instancias nt y jp de las clases
New_Student y JobPostulant, respectivamente, que la instancia jp est asociada con la
instancia nt y que, a su vez, la instancia nt este asociada con la instancia
notice_undergraduate, de la clase Notice. El resultado de la accin realizada por la operacin
postulateJob ser la creacin de la relacin hasPostulationPassantJob entre una instancia
ppas de la clase PostulationPassantJob con nt.

En el panel derecho superior se puede observar el enunciado de la regla. A la izquierda se

encuentran las clases, propiedades e individuos de las ontologas bolsa de trabajo y miembros
de la bolsa de trabajo, respectivamente

79
 75.00 Tesis

rulesPostulateJobU: relaciones inferidas en

http://www.semanticweb.org/ontologies/2010/11/rulesPostulateJobU.owl

Despus de correr el razonador Pellet integrado a Protg y, como consecuencia de la regla, el

razonador infiere para el individuo nt las relaciones hasPostulationPassantJob y hasRecord
con el individuo ppas de la clase PostulationPassantJob (la ltima relacin es inferida debido a
que hasPostulationPassantJob es subproperty de hasRecord). Se puede observar a la
izquierda al individuo nt (resaltado en azul) y, a la derecha, las relaciones inferidas con ppas y
con jp (resaltado en amarillo) y las relaciones afirmadas (resaltadas en verde).

Las relaciones inferidas para el individuo nt, hasJobPostulant y hasRecord con el individuo jp
son debidas al antecedente de la regla rulesPostulateJobU.

La relaciones inferidas para el individuo nt, hasPostulationPassantJob y hasRecord con el

individuo ppas son debidas al consecuente de la regla rulesPostulateJobU.

Las relaciones inferidas mostradas son slo algunas. El razonador tambin infiere relaciones
para el individuo jp y ug. Para el caso de ppas, como RecordOf es propiedad inversa de
hasRecord, el razonador infiere que el individuo ppas tiene una relacin RecordOf con nt.

80
 75.00 Tesis
Captulo III

Agentes

3.1 Generalidades

3.1.1 Agente y entorno

La IA es el campo de las ciencias computacionales que trata de mejorar el desempeo de las

computadoras al dotarlas de caractersticas asociadas con la inteligencia humana, como la
capacidad de entender el lenguaje natural o de razonar bajo condiciones de incertidumbre
para tomar mejores decisiones. Los agentes provienen de la IA (robtica, minera de datos,
manipulacin inteligente de base de datos, etc.). [Mansilla Espinosa; 2008]

Autonomous Agents

Biological Agents Robotic Agents Computational Agents

Software Agents Artificial Life Agents

Task-Specific Agents Entertaiment Agents Virus

[Mansilla Espinosa; 2008] Diagrama de tipos de agentes

Segn [Mancilla Espinosa; 2008], un agente es aquello que percibe su ambiente mediante
sensores y responde o acta en l mediante efectores. Un tipo de agente particular son los
agentes de software, un programa de computacin que se ejecuta en un ambiente y realiza
acciones dentro de ste para alcanzar las metas para las cuales fue diseado y sus
percepciones y acciones estn dadas por instrucciones de programas en algn lenguaje en
particular.

Qu es un agente es una cuestin abierta, exhibiendo el riesgo de que cualquier programa

sea denominado agente. Se pueden distinguir dos nociones extremas de agentes: una dbil y
otra fuerte.

81
 75.00 Tesis
Una nocin dbil consiste en definir un agente como una entidad capaz de intercambiar
mensajes utilizando un lenguaje de comunicacin de agentes. Esta definicin es la ms
utilizada dentro de la ingeniera de software con el fin de conseguir la interoperabilidad entre
aplicaciones a nivel semntico utilizando la tecnologa emergente de agentes.

Una nocin ms fuerte surge de una propuesta de programacin orientada a agentes (AOP).
Un agente es visto como una entidad dotada de componentes mentales como creencias,
capacidades, elecciones y acuerdos.

Los agentes inteligentes son considerados una pieza de software que ejecuta una tarea
determinada, utilizando informacin recolectada del ambiente, para actuar de manera
apropiada y completar la tarea de manera exitosa. El software debe ser capaz de auto
ajustarse basndose en los cambios que ocurren en su ambiente, de forma tal, que un cambio
en las circunstancias produzca el resultado esperado.

[Wooldridge; 1998] cit que un agente, situado en algn entorno, es un sistema de

computadora capaz de actuar de manera autnoma en ese entorno a fin de cumplir sus
objetivos.

En la mayora de dominios de complejidad razonable, un agente no tiene control completo

sobre su entorno. En el mejor de los casos, tiene control parcial desde que puede influir en l.

Desde el punto de vista del agente, significa que la misma accin ejecutada dos veces bajo las
mismas circunstancias podra tener efectos diferentes y, en particular, podra fallar en
conseguir el efecto deseado. Los agentes deben estar preparados para la posibilidad de fallas.

Esta situacin es formalmente resumida diciendo que los entornos son no deterministas.
Normalmente, el agente tendr un repertorio de acciones y efectos asociados que
representarn la capacidad del agente para modificar su entorno. Un conjunto de
precondiciones asociadas a las acciones definen situaciones posibles de aplicacin. El
problema clave que deben enfrentar los agentes es decidir cul de esas acciones ejecutar para
satisfacer, de la mejor manera posible, sus objetivos. La toma de decisiones es un proceso
complejo afectado por propiedades del entorno: accesible o inaccesible, determinista o no
determinista, episdico o no episdico, esttico o dinmico, discreto o continuo.

Un entorno accesible permite al agente obtener informacin completa, precisa y actualizada.

La mayora de entornos medianamente complejos (el mundo fsico, Internet) son
inaccesibles. Cuanto ms accesible sea el entorno ms fcil es construir agentes para operar
sobre l. En un entorno determinista cualquier accin tiene un efecto garantizado, no hay
incertidumbre sobre el estado que resultar de ejecutar una accin. El mundo fsico es
considerado no determinista. En un entorno episdico, la performance de un agente es
dependiente de un nmero de episodios discretos sin vnculo entre la performance de un
agente en diferentes escenarios. Un ejemplo de un entorno episdico es un sistema de
ordenamiento de mails. Un entorno esttico permanece sin cambios excepto por la
performance de las acciones realizadas por el agente. Un entorno dinmico tiene otros
procesos operando en l y los cambios estn ms all del control del agente. Un entorno
82
 75.00 Tesis
discreto tiene un nmero de acciones y percepciones fijas y finitas. Un ejemplo de entorno
discreto es el juego de ajedrez y de entorno dinmico la conduccin de un taxi. Los entornos
ms complejos son inaccesibles, no deterministas, no episdicos, dinmicos y continuos.
Como ejemplo de agentes se pueden mencionar los sistemas de control y los daemons de
software.

Un sistema de control simple es el termostato. El termostato tiene un sensor para detectar la

temperatura del lugar. El sensor es ubicado dentro del lugar y produce como salida una de dos
seales: una que indica que la temperatura est demasiado baja y otra que indica que la
temperatura est bien. Las acciones disponibles para el termostato son calentar y no calentar.
La accin calentar tendr el efecto de calentar la temperatura del lugar pero este efecto no
puede ser garantizado (la puerta del lugar podra estar abierta). El componente de toma de
decisiones del termostato (extremadamente simple) implementa las siguientes reglas: si est
fro entonces encender calefactor, si la temperatura est bien entonces apagar el calefactor.
Sistemas de control ms complejos tienen que considerar estructuras de decisin ms ricas
(sondas espaciales autnomas, reactores nucleares).

Los daemons (como los procesos background en UNIX) son otro ejemplo de agentes, ellos
monitorean un entorno de software y ejecutan acciones para modificarlo. Mientras el agente
termostato estaba en un entorno fsico, los daemons estn en un entorno de software. Ellos
obtienen informacin del entorno por ejecutar funciones y acciones de software. El
componente de toma de decisiones es simple como el del termostato. Por lo tanto, los agentes
son simples sistemas de computadora capaces de acciones autnomas de manera de
encontrar sus objetivos de diseo. Un agente tpicamente sensar su entorno (por sensores
fsicos en el caso de agentes ubicados en el mundo fsico o por sensores de software en el
caso de agentes de software) y tendr disponible un repertorio de acciones para modificar su
entorno, las cuales pueden responder en forma no determinista.

Los agentes exhiben proactividad cuando la decisin de tomar la iniciativa contribuya a lograr
sus objetivos. En entornos que cambian y en particular cuando las condiciones de un
procedimiento cambian mientras se est ejecutando, su comportamiento podra quedar
indefinido (con frecuencia se romper). En entornos dinmicos, ejecutar un procedimiento
sin considerar que las condiciones que lo sustentan sean vlidas es una estrategia pobre. En
tales entornos el agente debe ser reactivo. Es decir, debe ser sensible a 1) los eventos que
ocurran en su entorno y que afecten sus objetivos o, 2) a las condiciones que sustentan sus
procedimientos en ejecucin, a fin de alcanzar sus objetivos. La habilidad social permite a los
agentes interactuar con otros agentes como un medio ms hacia la concrecin de sus
objetivos.

En otros casos, un sistema multi-agente (MAS) presenta ventajas sobre agentes individuales
como fiabilidad, robustez, modularidad, escalabilidad, adaptabilidad, concurrencia,
paralelismo y dinamismo. Aparece entonces la necesidad de lenguajes de comunicacin y de
mecanismos que permitan coordinar a un grupo de agentes. En particular, los agentes
pueden cooperar (si tienen los mismos objetivos) o competir (si existe conflicto de
objetivos) distinguiendo de esa manera sistemas que resuelven problemas distribuidos (por
cooperacin entre agentes) de sistemas abiertos (agentes con diferentes objetivos). Los
mecanismos ms habituales en agentes cooperativos son las estructuras organizacionales
(centralizadas y distribuidas), la planificacin multi-agente, contratos y cooperacin de

83
 75.00 Tesis
funcionalidad mientras que en agentes competitivos lo habitual son mecanismos de
negociacin (formacin de coaliciones, mecanismos de mercado, teora de negociacin, voto,
subastas, asignacin de tareas, etc.). Lenguajes de comunicacin de agentes son el
Knowledge Query and Manipulation Language103 (KQML) y Foundations for Intelligent
Physical Agents-Agents Communication Language104 (FIPA-ACL).

La programacin orientada a agentes (AOP) emerge como un nuevo paradigma de

programacin que, basado en un MAS, es apropiado para desarrollar sistemas que operan
en entornos complejos, dinmicos e impredecibles (como control de trfico areo, cuidado de
la salud y sistemas de control industriales). El Agent-Oriented Software Engineering (AOSE)
permite crear metodologas y herramientas que facilitan el desarrollo y mantenimiento de
software basado en agentes. Las metodologas extienden las metodologas tradicionales de
software y son propuestas a fin de aclarar el proceso de desarrollo de un MAS (MAS-
CommonKADS105, ZEUS106, GAIA107, MaSE108, INGENIAS109).

Esfuerzos hacia la estandarizacin de la tecnologa de agentes son llevados a cabo por

organizaciones como FIPA y OMG Agent PSIG. FIPA apunta a producir estndares para la
interoperacin de agentes de software. Las especificaciones desarrolladas identifican roles
necesarios para la plataforma y la administracin de agentes como el Agent Managment
System (AMS) y el Directory Facilitator (DF) los cuales actan como white-pages y yellow-
pages110, respectivamente. Existen diferentes implementaciones de la plataforma de agentes
que adhieren al estndar FIPA como la Java Agent Development Enviroment (JADE) y ZEUS,
entre las ms utilizadas.

Como trabajo futuro en el campo de la tecnologa de agentes [Sanchez-Garca et al.; 2009]

queda la creacin de herramientas, tcnicas y metodologas que soporten el desarrollo de
sistemas de agentes, automatizacin de la especificacin, desarrollo y administracin de
sistemas de agentes, integracin de componentes y caractersticas, definicin del balance
apropiado entre prediccin y adaptabilidad y la vinculacin con otras ramas de la
computacin y disciplinas como economa, sociologa y biologa. En su trabajo destacan que
tendencias emergentes sugieren que las tecnologas de agentes sern vitales en el corto y

103
Lenguaje de Consulta y Manipulacin del Conocimiento.
104
Fundamentos para Agentes Fsicos Inteligentes - Lenguaje de Comunicacin de Agentes.
105
Para el anlisis y desarrollo de sistemas intensivos de conocimiento, proporciona herramientas para la
administracin de conocimiento corporativo, el desarrollo de sistemas de conocimiento para los procesos de
negocios seleccionados, entre otras. http://www.commonkads.uva.nl/
106
Herramienta para construir sistemas multi-agentes colaborativos. Define un enfoque de diseo y soporta un
entorno visual para capturar las especificaciones de agentes que son utilizadas para generar el cdigo Java de los
agentes. http://sourceforge.net/projects/zeusagent/
107
Metodologa para anlisis y diseo de agentes. Aplicable a un amplio rango de sistemas multi-agentes, trata los
aspectos a nivel macro (social) y micro (agente) de los sistemas. Se basa en la visin de un sistema multi-agente
como una organizacin computacional, consistente de varios roles interactuando.
108
Metodologa de propsito general para el desarrollo de sistemas multi-agentes que se basa en principios de la
ingeniera de software. Divide el proceso de desarrollo en dos fases: anlisis y diseo. Para cada fase provee el
conjunto de etapas necesarias: objetivos, casos de uso y roles para el anlisis y creacin de clases, interaccin,
despliegue de clases y diseo del sistema, para el diseo.
109
Metodologa para el desarrollo de sistemas multi-agentes que integra resultados del rea de la tecnologa de
agentes con procesos de desarrollo de software como RUP (Rational Unified Process). La metodologa se basa sobre
la definicin de un conjunto de metamodelos que describen los elementos que forman un MAS y permite definir un
lenguaje de especificacin para MAS. http://grasia.fdi.ucm.es/main/node/220
110
Desarrollado en la seccin 1.4.2, Directorio de Servicios.

84
 75.00 Tesis
mediano plazo como hoy son los servicios Web, grid computing, etc.

Es necesario mencionar que las tecnologas de agentes presentan deficiencias al utilizar

protocolos de comunicacin como IIOP o RMI los cuales no pueden atravesar firewalls
empresariales. Una solucin a este problema implicara la creacin de gateways entre pares
de empresas. No obstante, este enfoque presenta un problema adicional relacionado al
tratamiento de enlaces dinmicos, los cuales no podran ser establecidos entre dos entidades
que no hayan sido preparadas para eso, limitando claramente el dinamismo.

3.1.2 Agentes y objetos

Los programadores acostumbrados a trabajar con objetos, no suelen ver cul es la idea con
agentes. Se hace necesario recordar a los objetos definidos como entidades computacionales
que encapsulan algn estado, que pueden ejecutar acciones o mtodos sobre ese estado y
comunicarse entre ellos mediante el paso de mensajes.

Similitudes y diferencias existen entre objetos y agentes. La primera diferencia trata con el
nivel de autonoma que cada uno posee. Desde que una variable de instancia (o mtodos)
puede ser declarada privada para ser accesible slo desde dentro del objeto, un objeto puede
ser pensado como exhibiendo autonoma (control) sobre su estado pero no sobre su
comportamiento. Si un mtodo m es declarado pblico, el objeto no puede controlar ejecutar
el mtodo o no. Los agentes no son pensados como invocando mtodos sino como solicitando
ejecutar acciones. El foco de control con respecto a la decisin de ejecutar una accin, en el
caso orientado a objetos, se encuentra en el objeto que invoca el mtodo y en el caso de
agentes, en el agente que recibe el pedido. El siguiente slogan, en ingls, destaca esta
diferencia entre objetos y agentes: Objects do it for free; agents do it for money.

Otra diferencia importante tiene que ver con la nocin de comportamiento autnomo y
flexible (reactivo, proactivo, social) de un sistema de agentes. El modelo estndar de objetos
nada menciona acerca de construir sistemas que integren este comportamiento. Se podra
objetar que es posible construir programas orientados a objetos que integren el
comportamiento pero slo se perdera el punto, que es que tal comportamiento no hace a la
programacin orientada a objetos.

La siguiente diferencia es que cada agente tiene su propio hilo de control (en el modelo de
objetos estndar hay un simple hilo de control en el sistema). A pesar de que existen varios
lenguajes que permiten concurrencia en programacin orientada a objetos, no capturan la
idea de agentes como entidades autnomas (con reactividad, proactividad y habilidad social).
Tal vez, lo ms cercano en la comunidad orientada a objetos se encuentre en la idea de
objetos activos. Un objeto activo es el que abarca su propio hilo de control. Los objetos
activos son generalmente autnomos lo que aqu significa que pueden exhibir algn
comportamiento sin que exista otro objeto que los opere por encima. Los objetos pasivos, en
cambio, slo pueden someterse a un cambio de estado cuando explcitamente son operados
por encima. Por lo tanto, los objetos activos son esencialmente agentes los cuales no
necesariamente tienen la habilidad para exhibir comportamiento flexible autnomo.

La visin tradicional de un objeto y de un agente concluye con la lista a continuacin:

85
 75.00 Tesis

Los agentes encarnan una nocin ms fuerte de autonoma que los objetos y en particular
deciden si ejecutar una accin a partir del pedido de otro agente o no.

Los agentes son capaces de comportamiento flexible (reactivo, proactivo, social) y el
modelo estndar de objetos no dice nada al respecto.

Un sistema multi-agente es inherentemente multi-hilo donde cada agente posee al menos
un hilo de control.

3.1.3 Agentes y sistemas expertos

Los sistemas expertos constituyen una etapa de la Inteligencia Artificial. Un sistema experto
es capaz de resolver problemas o dar consejos en algn dominio de conocimiento. Un
ejemplo de un sistema experto es MYCIN, el cual asiste a los mdicos en el tratamiento de
infecciones de la sangre en personas. Un usuario presenta al sistema un nmero de casos, los
cuales el sistema emplea a fin de derivar alguna conclusin. MYCIN acta como consultor: no
opera directamente sobre humanos o sobre algn entorno. Entonces, la diferencia ms
importante entre agentes y sistemas expertos es que los sistemas expertos son
inherentemente incorpreos [Wooldridge, 1998]. Esto significa que los mismos no
interactan directamente con el entorno, ellos no consiguen su informacin va sensores
sino a travs de un usuario actuando como intermediario. De la misma manera, ellos no
actan sobre algn entorno sino ms bien entregan una respuesta o aconsejan a terceros.
Adems, a los sistemas expertos no se les requiere el ser capaces de cooperar con otros
sistemas expertos. A pesar de estas diferencias, algunos sistemas expertos (particularmente
los que ejecutan control de tareas en tiempo real) logran un gran parecido con agentes.

Sistemas expertos Agentes

Sistemas cerrados

Sistemas de decisin centralizados

Interaccin con el usuario bajo peticin del
usuario

Interactan con el entorno

Distribucin de la toma de decisiones:
comportamiento emergente

Mayor grado de interaccin con el usuario

Interaccin con otros agentes

Comparacin entre sistemas expertos y agentes.

3.1.4 Agentes y servicios

A fin de despejar confusiones en torno de agentes y servicios se enuncian primero las

caractersticas desarrolladas hasta ac.

Los agentes poseen conocimiento de s mismos, de su entorno y de mecanismos de

resolucin de problemas, estn fuertemente basados en enfoques tericos; son un recurso
limitado y persistente; proveen a sus pares de servicios en cualquier momento y cuentan con
limitado soporte pragmtico para la comunidad de usuarios (sistemas, software y
herramientas). Esto ltimo es consecuencia de que la investigacin de sistemas multi-agente
se enfoc en desarrollar principios y mecanismos formales para resolver problemas
distribuidos a nivel conocimiento, en trminos de los objetivos que la comunidad multi-
agente deba abarcar y las tareas que podan solucionar.

86
 75.00 Tesis
Los servicios, en cambio, son procesos transitorios y stateless111, que existen slo durante la
ejecucin del servicio. Son instanciados para ejecutar una tarea especfica siendo posible la
provisin de servicios escalables y concurrentes. A diferencia de la tecnologa de agentes, la
investigacin de servicios se enfoc en la comunidad de usuarios, resultando en una
tecnologa bottom-up pragmtica que permita la construccin de sistemas orientados a
servicios. Los puntos principales fueron el desarrollo de estndares para lograr interfaces
bien definidas y declarativas, workflows y protocolos y no en mecanismos que ayudan al
servicio a ejecutar la tarea. Se desarrollaron herramientas para construir y desarrollar
software distribuido a gran escala. El desarrollo de servicios Grid112 se debi al desarrollo
pragmtico de tecnologas, estndares, polticas, ontologas compartidas y plataformas que
permiten la realizacin de entornos distribuidos.

Servicio

Servicio broker Agente

Agente broker

PUBLISH FIND
WSDL ACL UDDI ACL

Proveedor de servicio
Sistema multi-agente
Usuario de servicio
(servicio distribuido
BIND Agente de usuario
cooperativo)
SOAP ACL

[Huhns; 2002] Los servicios Web utilizan tres protocolos diferentes a fin de publicar, buscar
y conectarse. Los agentes, en cambio, utilizan un protocolo para todas sus interacciones, el
Agent-Communication Language (ACL)

Los servicios Web se basan en una trada de funcionalidades, a saber, SOAP provee los
protocolos necesarios para la comunicacin entre sistemas, WSDL describe los servicios en
una forma legible por computadora, especificando nombres de funciones, parmetros
requeridos y resultados, UDDI permite a los clientes (usuarios y negocios) una manera para
encontrar servicios por especificar un registro o un yellow-pages de servicios.
Sin embargo, diferenciar agentes y servicios es problemtico porque alguien podra
argumentar que un agente puede ser implementado empleando tecnologa de servicios Web o
que se puede incorporar mecanismos adaptativos e inteligentes en el diseo de servicios

111
Desarrollado en la seccin 1.1.3 Caractersticas Secundarias.
112
Combinacin de recursos computacionales desde mltiples dominios administrativos a fin de lograr un objetivo
comn. Se distingue de sistemas de procesamiento convencionales y alto rendimiento por ser ofrecer mayor
desacoplamiento, heterogeneidad y dispersin geogrfica. Son construidos con la ayuda de middlewares.

87
 75.00 Tesis
Web. Los investigadores han propuesto muchas definiciones para agentes, no obstante,
siempre aparece un ejemplo que a pesar de satisfacer estrictamente la definicin en espritu,
no es un agente.

[Payne; 2008] distingue agentes y servicios Web al discutir las cinco caractersticas de
agentes propuestas por Jennings.

La primera caracterstica es que los agentes son entidades que resuelven problemas con
interfaces y lmites bien definidos. Los servicios Web existen como workflows claramente
articulados y con protocolos formalmente validados. Los tipos y estructuras de datos definidos
crean los mecanismos para dirigir mensajes y desarrollar herramientas a fin de utilizar
servicios Web. En la visin de agentes, una variedad de mtodos de interaccin pueden ser
utilizados. Esas interacciones ocurren a nivel conocimiento de mensajes en lenguajes
declarativos como KQML o FIPA. Existe nfasis en razonar los mensajes recibidos, obtener
conocimiento del entorno y de las motivaciones y capacidades de sus pares para determinar
dinmicamente como resolver un problema durante una ejecucin. Un agente puede
descomponer un problema en partes y elegir delegar tareas o coordinar con otros agentes
como resolver el problema. Esta descomposicin al no ser prescripta sino realizada
dinmicamente permite una mejor adaptacin a entornos y contextos cambiantes.

La segunda caracterstica es que los agentes son capaces de exhibir una comportamiento
flexible para la resolucin de problemas a fin de cumplir sus objetivos de diseo (reactivo y
proactivo). Los agentes son inherentemente comunicativos y socialmente conscientes. Ellos
responden a cambios en su entorno y a mensajes de pares como resultado de tareas internas
planificadas. Estos disparadores pueden motivar la intencin de lograr algn objetivo,
resultando en comportamiento proactivo cuando es necesario. Los servicios Web, en cambio,
son procesos transitorios cuya instanciacin y existencia es disparada por un Web Server
que recibe un mensaje. Una ventaja de esta instanciacin (factory-based113) por cada
invocacin de servicio recibida es que los proveedores pueden ofrecer servicios
concurrentes en respuesta a pedidos simultneos.

Aunque un servicio Web puede iniciar comunicacin con otro servicio Web cuando ejecuta
su tarea, es todava reactivo porque an forma parte de las acciones preescritas que se
disparan luego del mensaje instanciador original. Aunque se construya un servicio para que
sea proactivo, esto al final introducira nociones de agentes en el diseo de servicios Web.

La tercera caracterstica es que los agentes son diseados para cumplir roles especficos, con
objetivos particulares. Un servicio Web existe para ejecutar una tarea, como sera ofrecer
una funcionalidad e-business. Compaas como eBay y Amazon.com ofrecen acceso a sus
tecnologas por servicios Web, ya sea para facilitar el comercio con terceros o para ofrecer
acceso a sus recursos. El comportamiento de agente es motivado por nociones ms
abstractas, mentales como knowledge, intention, belief y obligation. Tpicamente un agente
es diseado para maximizar alguna utilidad a travs de comportamiento racional. Cuando se
ejecuta una tarea, un agente puede intentar determinar la utilidad ganada en ejecutar su
113
Patrn de diseo creacional en la que una clase implementa mtodos para crear instancias de objetos (las
instancias pueden ser de la misma clase o de otras). Esta clase tiene entre sus responsabilidades la creacin de
instancias de objetos pero puede tener tambin otras responsabilidades adicionales.

88
 75.00 Tesis
accin sobre la base de una posible recompensa o ventaja percibida (considerando los costos
incurridos). Si un agente no percibe ventaja alguna, podra decidir no ejecutar la tarea,
mientras que, un servicio Web recibiendo el mismo pedido ejecutar la tarea.

La cuarta caracterstica es que los agentes son ubicados en un entorno particular, el cual
observan y sobre el cual tienen control parcial; ellos reciben entradas relacionadas con el
estado de su entorno por medio de sensores y actan sobre l por medio de sus efectores.
Esta caracterstica es atribuida a agentes de hardware pero igualmente aplica a agentes de
software. Sin embargo, los sensores pueden proveer slo conocimiento parcial de su
entorno. Adems en entornos dinmicos con numerosos agentes, el conocimiento puede ser
pasado. Como los agentes tienen control parcial sobre su entorno necesitan evaluar su
contexto. Esto, con frecuencia, necesita de la colaboracin entre pares para lograr los
cambios deseados ms all de su esfera de influencia. Los agentes que son conscientes de su
entorno tambin tienen conocimiento de nuevos agentes, los cuales podran utilizar para
resolver problemas futuros. Sin embargo la habilidad para observar e interrogar pares puede
producir un modelo de entorno ms sofisticado, el cual pone en duda si a los agentes puede
ser confiada lograr una tarea o gozar de reputacin para engaar o incumplir contratos. Los
servicios son igualmente limitados con respecto al alcance de observar hechos y las acciones
que pueden ejecutar para manipular y afectar su entorno. Sin embargo porque los servicios
Web son tpicamente reactivos, el conocimiento que ellos procesan es slo el que el
desarrollador consider necesario cuando los dise. Esto elimina la posibilidad de
aprovechar conocimiento oportunista.

La quinta caracterstica es que los agentes son autnomos, ellos controlan su estado interno y
su comportamiento. Autonoma es una caracterstica esencial de los agentes. Los agentes
son conscientes de s mismos. Por adquirir y retener conocimiento en el tiempo, ellos
pueden aprender estrategias alternativas y soluciones a problemas para producir soluciones
ms optimas. Un agente puede evolucionar en sus comportamientos sin direccin del
usuario o su propietario. Los servicios Web raramente son autnomos, salvo que la nocin
de autonoma sea incluida en el diseo del servicio, lo cual involucrara construir servicios
stateful114 y persistentes. Ya algunos investigadores han empezado a explorar esas nociones
de autonoma y comportamiento autnomo para servicios Web, pero hasta ahora se han
utilizado nociones de agentes para lograr tal autonoma.

Agregar persistencia, autonoma e identidad a los servicios Web debilitara la distincin entre
agentes y servicios.

Debido a 1) inconvenientes de las tecnologas de agentes, 2) la necesidad inherente de

entidades de software en entornos de SWS y 3) los beneficios anunciados por tener agentes y
servicios trabajando cooperativamente, numerosos proyectos desarrollaron frameworks
integrando ambas tecnologas[Snchez-Garca et al.; 2009]. Sin embargo, surgen
discusiones sobre la formas de lograr esa integracin. Los escenarios posibles son: 1) que los
servicios Web provean la funcionalidad de bajo nivel y los agentes la funcionalidad de alto
nivel por usar, combinar y coreografiar servicios Web, obteniendo funciones de valor
agregado, 2) que la comunicacin en servicios Web y agentes sea equivalente (agentes como
wrappers de servicios) y 3) ambos tipos permanezcan separados creando un espacio de

114
Desarrollado en la seccin 1.1.3 Caractersticas secundarias

89
 75.00 Tesis
servicios heterogneos e interoperando a travs de gateways y procesos de traslacin.

Tecnologas de agentes inteligentes y servicios Web semnticos permiten alcanzar logros

notables con, en algunos casos, superposicin de funcionalidades [Snchez-Garca et al.;
2009]. Sin embargo, independientemente de los beneficios de estas tecnologas, su
funcionalidad se ve limitada cuando son aplicadas por separado, lo que impide que sean
utilizadas a escala masiva en la sociedad, particularmente en la industria. A pesar de que
los paradigmas de agentes y servicios, a menudo, son considerados similares, y por lo tanto
compitiendo entre s, diferentes investigaciones demostraron que una interaccin
cooperativa puede conducir al desarrollo de mejores aplicaciones. Como ejemplo, los
mecanismos factory115 utilizados por los servidores Web para crear instancias de servicios
(alivian el problema de acceso concurrente por crear nuevas instancias de servicios sobre
demanda) en entornos de recursos limitados (poder de procesamiento bajo o equipamiento
fsico pobre), en proveedores con excesiva demanda o con mltiples partes generando
workflows sin formar compromisos o contratos, conducen a fallas o demoras en la ejecucin
de los servicios, por lo tanto la existencia de mecanismos autnomos para soportar la
cooperacin o refinar la planificacin o el aprovisionamiento de servicios durante su
ejecucin es slo posible a travs de agentes.

El Agents and Web Services Interoperability Working Group116 (AWSI WG) trabaja en la idea
de construir un middleware117 para manejar las principales diferencias entre tecnologa de
agentes y servicios Web, a saber, utilizacin de protocolos de comunicacin (ACL vs. SOAP),
lenguajes de descripcin de servicios (DF-AgentDescription vs. WSDL) y mecanismos de
integracin de servicios (DF vs. UDDI). Si bien esto facilita la integracin, sin cambiar las
especificaciones e implementaciones existentes de ambas tecnologas, hace que los servicios
Web y agentes permanezcan al mismo nivel de abstraccin, Como afirman [Snchez-Garca
et al.; 2009], la funcionalidad provista por agentes y servicios Web es complementaria. La
idea original de las tecnologas de agentes es actuar como entidades autnomas que
incorporan capacidades inteligentes y cognitivas, lo que les permite mostrar un
comportamiento proactivo orientado a objetivos y establecer procesos de interaccin,
cooperativos o competitivos, con otros agentes a fin de conseguir sus objetivos. Por otro lado,
los servicios Web involucran una evolucin en cmputo distribuido y su propsito es
proveer funcionalidad accesible a todo el mundo. Estas diferencias conceptuales entre
tecnologa de agentes y SWS llevan a la necesidad de tener ambas tecnologas trabajando en
entornos integrados y apreciar las ventajas de su combinacin en el desarrollo de sistemas
complejos.

3.2 Clasificacin

Un sinfn de definiciones enuncian caractersticas de los agentes y contribuyen a que

pertenezcan a una clasificacin o no. Las caractersticas ms importantes de los agentes
inteligentes son:

115.Patrones creacionales como el Factory method, Abstract factory, Builder, entre otros.
116
Grupo de Trabajo para la Interoperabilidad de Servicios Web y Agentes.
117
Desarrollado en la seccin 1.3.1 Modelo orientado a mensajes MOM

90
 75.00 Tesis

Autonoma: un agente opera sin intervencin directa humana, adems tiene control
sobre sus acciones y su estado interno.

Habilidad social: capacidad para interactuar con otros agentes inteligentes o el
usuario.

Reactividad: perciben el entorno y responden en un tiempo razonable a los cambios
que ocurren en l.

Proactividad: los agentes pueden reaccionar por iniciativa propia sin necesidad de
que el usuario tenga que activarlo.

Orientacin hacia el objeto final: divide una tarea compleja en varias actividades ms
pequeas a fin de lograr la meta compleja asociada.

Racionalidad: el agente siempre acta para lograr sus metas y nunca de forma de
evitar la consecucin de las mismas.

Adaptabilidad: el agente debe ser capaz de ajustarse a los hbitos, formas de trabajo y
necesidades del usuario.

Colaboracin: el agente debe ser capaz de determinar informacin importante ya que
el usuario puede proporcionar informacin ambigua.

Los agentes inteligentes son racionales, utilizan razonamiento basado en conocimiento.

Suelen considerar una base de conocimiento, que incorpora una serie de hechos y reglas, de
los cuales se vale un motor de inferencias.

Un agente racional ideal tiene un elemento al que hay que prestarle atencin y es la Parte de
Conocimiento Integrado. Si las acciones que emprende el agente se basan exclusivamente
en un conocimiento integrado, haciendo caso omiso de sus percepciones, se dice que el
agente es autnomo. El autntico agente inteligente autnomo debe ser capaz de funcionar
satisfactoriamente en una amplia gama de ambientes, considerando que se le da tiempo
suficiente para adaptarse.

Agent
Tipology

Colaborative Interface Information Mobile Heteroeneous Reactive Hybrid Smart

Agents Agents Agents Agents Agents Agents Agents Agents

[Mansilla Espinosa; 2008] Tipologa de agentes

Una vez que se han revisado las caractersticas de los agentes, es posible encontrar una
91
 75.00 Tesis
tipologa; sin embargo, una reclasificacin ha sido propuesta por [Mansilla Espinosa; 2008]

Su clasificacin general de agentes inteligentes se basa en la relacin existente entre

percepciones y acciones, aplicacin a la que sirven y caractersticas especiales.

3.2.1 Clasificacin dependiendo de la relacin entre percepciones y

acciones

Agentes de reflejo simple: actan encontrando una regla cuya condicin coincida con
la situacin actual (definida por la percepcin) y efectuando la accin que corresponda
a tal regla.

Agentes bien informados de todo lo que pasa: actualizan constantemente la
informacin que les permite discernir entre estados del mundo y su evolucin,
adems de necesitar conocer como las acciones del propio agente estarn afectando al
mundo, as se mantiene informado acerca de esas partes no visibles de l.

Agentes basados en metas: deben ser flexibles con respecto a dirigirse a diferentes
destinos, ya que al marcar un nuevo destino, se crea en el agente una nueva conducta.

Agentes basados en utilidad: la utilidad es una funcin que correlaciona un estado y
un nmero real mediante el cual se caracteriza el correspondiente grado de
satisfaccin.

3.2.2 Clasificacin de acuerdo al tipo de aplicacin

Agente de interfaz de usuario: funciona como un asistente personal, sus

caractersticas principales son la autonoma y aprendizaje. Ensea al usuario a
utilizar una aplicacin en particular, poseen una base de conocimiento donde
almacena el conocimiento adquirido por el usuario o por otros agentes.

Agentes de bsqueda: no se limitan a emplear tcnicas de bsqueda, sino que adems
tienen que interpretar patrones de bsqueda. Deben ser capaces de crear
informacin til para el usuario a partir de pedazos de informacin.

Agentes de monitoreo: avisan a los agentes de interfaz sobre algn cambio en el
contenido de alguna pgina Web.

Agentes de filtrado: trabaja en base al perfil definido por el usuario. Interactan con
los agentes de monitoreo a fin de mantener informacin actualizada de la Web y de los
intereses del usuario.

3.2.3 Clasificacin de acuerdo a caractersticas especiales

Agentes deliberantes o proactivos: son agentes que poseen mucho conocimiento del
entorno en el que se encuentran y son capaces de crear nuevos planes y adelantarse a
lo que va a ocurrir en su entorno. En esta clasificacin se encuentra el modelo BDI118
118
Se trata de un modelo de agentes. Beliefs representa el estado del mundo (computacionalmente puede ser el valor
de una variable o una base de datos relacional), Desires (objetivos) es otro componente esencial del estado del
mundo, representa el estado final deseado (computacionalmente puede ser el valor de una variable o una estructura
de registro), Intentions representan los planes o procedimientos (computacionalmente a un conjunto de hilos
ejecutndose en un proceso a fin de lograr sus objetivos (desires). Beliefs, Desires, Intentions son los componentes
bsicos de un sistema de agentes diseado para un mundo dinmico. Los agentes de un sistema que siga el modelo

92
 75.00 Tesis
(Beliefs, Desires, Intentions) y BVG119 (Beliefs, Values, Goals).

Agentes reactivos: son sistemas estmulo-respuesta que actan a partir de la
observacin directa y continua del entorno. Se adaptan perfectamente a los entornos
dinmicos ya que no tienen que actualizar ninguna representacin interna del
entorno como los agentes BDI.

Agentes estacionarios: son un tipo de agente que no posee la capacidad de
desplazarse y salir del entorno.

Agentes mviles: son agentes que tienen la capacidad de desplazarse a travs de una
red; de esta forma cambian el entorno en el que se ejecutan. Esto reduce el consumo
de recursos en la mquina en la que se encontraba inicialmente el agente.

3.3 Matchmaking entre agentes heterogneos

En un entorno abierto como Internet, donde fuentes de informacin, enlaces de

comunicacin y agentes pueden aparecer y desaparecer, los agentes intermediarios ayudan a
localizar soluciones alternativas. Existen dos tipos de agentes intermediarios, a saber,
matchmakers120 (tambin conocidos como yellow-pages services) y brokers. [Sycara et al.,
1998].

Para que un agente proveedor pueda prestar sus capacidades a otros (servicio de bsqueda,
comercio electrnico) debe primero registrarse con el matchmaker. Para eso, publica sus
capacidades enviando un mensaje en el que describe el tipo de servicio que ofrece. Otro
agente enva al matchmaker un pedido solicitando informacin y servicios.

Cada pedido que el matchmaker recibe es comparado con su coleccin actual de

publicaciones. Si existen coincidencias, el matchmaker retorna un conjunto ordenado con los
proveedores apropiados.

Un agente broker trata de contactar a los proveedores relevantes, transmitiendo el pedido al

proveedor y comunicando los resultados al solicitante.

Un matchmaker devuelve una lista de servicios y a continuacin deja que interacten los
agentes usuario y proveedor. En cambio, un broker interviene de principio a fin en esa
interaccin. Un agente matchmaker reduce cuellos de botella a expensas de producir un
mayor nmero de interacciones entre agentes. Por el contrario, un agente broker reduce el
nmero de interacciones a expensas de producir un cuello de botella entre agentes.

BDI deben tener objetivos explcitos (desires) para alcanzar o manejar eventos, un conjunto de planes (intentions)
para describir como lograr esos objetivos y un conjunto de datos (beliefs) que describan el estado del mundo.
119
Se trata de un modelo de agentes basado en creencias, valores y objetivos (belief, values y goals). En este modelo
los Values (valores) son utilizados como mecanismos de decisin por el agente, los cuales no son rgidos y pueden
cambiar durante la interaccin. Las Beliefs (creencias) representan lo que el agente cree saber, los Goals (objetivos)
lo que el agente quiere y los Values (valores) sus preferencias.
120 Agente intermediario que se ocupa de encontrar el proveedor apropiado.

93
 75.00 Tesis
3.4 Informacin semntica que registran

El proceso de descubrimiento de servicios es posible si existe un lenguaje comn que

describa los servicios, de manera, que otros agentes comprendan las funciones ofrecidas y
como utilizarlas. Las descripciones de servicios y agentes pueden ser depositadas en
directorios similares a las pginas amarillas.

Una forma de lograr una comprensin compartida entre agentes sera intercambiar las
ontologas necesarias para una comunicacin y utilizar nuevas capacidades de
razonamiento. De esta manera se lograra una flexibilidad superior a la provista por
estandarizacin. [Berners-Lee et al.; 2001]

Los agentes muestran un comportamiento dual: por un lado son programas dirigidos por
objetivos que, de manera autnoma y proactiva, resuelven problemas de usuario y por otro,
poseen una dimensin social cuando interactan como parte de un sistema multi-agente.

A fin de resolver problemas de manera autnoma, surge la necesidad de desarrollar un

modelo de su entorno, que les permita razonar acerca de cmo las acciones que ejecutan
afectan su entorno y cmo los cambios que producen conducen a sus objetivos.

Las ontologas proporcionan el framework conceptual que les permite construir esos
modelos: ellas describen el tipo de entidades que pueden encontrar, sus propiedades y que
relaciones existen entre ellas.

En su dimensin social, los agentes en un MAS, interactan unos con otros, pueden competir
por recursos o colaborar hacia la consecucin de objetivos. Mientras algunas interacciones
son accidentales (un agente esperando para acceder a un recurso que otro agente mantiene
ocupado), la herramienta principal que tienen para interactuar es la comunicacin.
Mediante ella pueden intercambiar informacin y pedidos de servicio. Cuando se combina
comunicacin con un problema a resolver, la solucin involucra otros agentes. Las ontologas
prestan la representacin bsica que permite a los agentes razonar acerca de sus
interacciones y comunicarse y trabajar por compartir ese conocimiento.

Diferentes enfoques de ontologa reflejan ese comportamiento dual, a saber, ontologas

privadas y ontologas pblicas.

El propsito de las ontologas privadas es dar al agente un contexto del problema a resolver.
Con frecuencia, resulta difcil distinguir entre ontologas como conceptualizacin del dominio
del agente y ontologas como representacin del conocimiento requerido por su proceso de
resolucin de problemas.

Por otro lado, el propsito de las ontologas pblicas es soportar interaccin de agentes,
especialmente comunicacin e intercambio de informacin. Las ontologas pblicas prestan
una descripcin de un dominio MAS, compartido por todos los agentes, y un vocabulario
compartido, de manera que los agentes pueden comprender el contenido de los mensajes que
94
 75.00 Tesis
intercambian. Las ontologas pblicas deben respetar la heterogeneidad de agentes en un
MAS y, por lo tanto, ser independientes del proceso de resolucin de problemas de cada
agente.

Una parte crucial del dominio de un agente es el MAS al cual pertenece. Otros agentes en el
MAS afectan lo que el agente hace y cmo lo hace. Consecuentemente, las ontologas deben
soportar descripcin de agentes en trminos de capacidades, informacin bsica de contacto,
protocolo de interaccin, confiabilidad, reputacin, seguridad, entre otras. La dimensin
social de un MAS emerge de la necesidad de los agentes de una infraestructura y de servicios
(como registros de ubicacin y protocolos estndares) para interactuar. Por lo tanto, las
ontologas deben, tambin, soportar descripcin de una infraestructura MAS, tipo de registros
empleados, tipo de protocolos, entre otros.

Dado que los agentes inteligentes han sido desarrollados sobre diferentes mecanismos de
resolucin de problemas provistos por la AI121, encontrar un denominador comn entre
ontologas privadas es, virtualmente, imposible.

Por la comunicacin, el trabajo de un agente puede contribuir al trabajo de otro y

proporcionar mecanismos de coordinacin (los agentes negocian cmo compartir recursos
o como colaborar hacia la solucin de un problema). La interaccin y colaboracin de agentes
resulta en la aparicin de una sociedad de agentes, con una estructura social propia. Los
agentes necesitan ser dotados de conocimiento social, que especifique qu agentes trabajan
juntos y normas de comportamiento social aceptable. Las normas actan como una
herramienta para representar, de manera explcita, lo que un agente espera en una situacin
particular; la utilidad de las normas es hacer a los agentes y los MAS predecibles. Es a travs
de normas, que los agentes pueden desarrollar predicciones sobre el comportamiento de sus
pares, lo que a su vez permite mayores niveles de cooperacin. A nivel conocimiento, las
normas especifican restricciones sobre el comportamiento del agente dentro de lo aceptable
por el resto de agentes. Mientras, en principio, las normas pueden ser empleadas para
expresar cualquier restriccin social, ellas encuentran su inmediata aplicacin en la
definicin de conceptos como contratos y dems compromisos, que los agentes desarrollan a
fin de trabajar juntos.

As, las normas, en este caso sociales, suministran una fuente de ontologas para la
especificacin del comportamiento social en una comunidad de agentes. Sin embargo, a
pesar de su importancia, an no se ha desarrollado una representacin ontolgica para estas
normas.

Otras fuentes de ontologa son la representacin de leyes en razonamiento legal. Las tareas
principales en una ontologa de este tipo son la recuperacin de informacin mediante
indizacin de leyes y verificacin de regulaciones. Una ontologa legal provee una nocin
diferente de norma, bsicamente, la descripcin de una ley y los actos a los cuales esas leyes
aplican. Una segunda fuente de ontologa viene de la comunidad e-commerce y sus
necesidades para expresar conceptos como contratos que regulen transacciones electrnicas.

121
Artificial Intelligence

95
 75.00 Tesis
El proceso de descubrimiento de agentes tiene cuatro caractersticas distintivas:

representacin del agente en el sistema,

proceso que identifica similitudes entre un pedido y una publicacin de agente (servicio
ofrecido) en el MAS,

componentes de infraestructura (como registros y protocolos) y,

resolucin de problemas.

Los esquemas de descubrimiento propuestos en la literatura se distinguen por la manera en

que dirigen estos cuatro aspectos, conduciendo a varios niveles de flexibilidad en la
reconfiguracin dinmica y regmenes de coordinacin de agentes en el MAS.

Las ontologas son un ingrediente esencial para descubrimiento de agentes. Proporcionan

los medios para representar diferentes aspectos de los agentes y los mecanismos bsicos
para relacionar pedidos y publicaciones. Desde que los agentes modifican sus entornos, sus
descripciones necesariamente refieren a la descripcin ontolgica de su entorno.

Los agentes pueden estar representados con diferentes niveles de abstraccin. A nivel fsico,
son caracterizados por puertos y protocolos de red (de manera similar a la representacin
provista por las especificaciones WSDL y UDDI para servicios Web). A nivel abstracto, los
agentes interactan por medio de un lenguaje de comunicacin, empleando un conjunto de
ontologas para codificar e interpretar mensajes.

Desde otro punto de vista, los agentes son caracterizados por sus capacidades, sus protocolos
de interaccin, procedimientos de resolucin de problemas, la entidad legal responsable de su
correcto funcionamiento, entre otras. La representacin de las capacidades es crucial para
descubrimiento de agentes (inteligentes y autnomos). En algunos sistemas, los agentes son
conscientes de las necesidades del problema a resolver que emergen durante su
razonamiento pero no conocen otros agentes que puedan satisfacer sus necesidades. La
tarea de un agente es abstraer del problema especfico las capacidades que espera de un
proveedor.

Un nmero de esquemas de representacin de capacidades han sido propuestos por la

comunidad de agentes y, ms recientemente, por las comunidades de servicios Web y la Web
Semntica. Se distinguen entre dos tipos de esquemas de representacin: el primero supone
que las ontologas proveen una representacin explcita de las tareas ejecutadas por los
agentes. En esas ontologas cada tarea es descripta por un concepto diferente, mientras que
los agentes son descriptos por enumerar las tareas que ejecutan. El segundo esquema de
representacin describe agentes por la transformacin de estados que producen, no hay
mencin de la tarea ejecutada por el agente sino que la tarea es implcitamente representada
por informacin de estado de las entradas del agente a las salidas que produce. Los dos
enfoques de representacin brindan dos maneras de utilizar ontologas.

Los esquemas de representacin explcita permiten, dadas las capacidades deseadas del
agente, localizacin simple. Pero requieren que las ontologas asignen un concepto a cada
tarea ejecutada por el agente. Dado que los agentes pueden ejecutar varias tareas, estas
ontologas pueden crecer, volvindose inmanejables, y no escalar al ingresar agentes con

96
 75.00 Tesis
nuevas capacidades. Otro inconveniente de este tipo de esquema es que no representan que
informacin el agente proveedor y el agente solicitante necesitan para interactuar. Estas
ontologas son difciles de construir.

Los esquemas de representacin implcita requieren slo de conceptos que describan la tarea
procesada por el agente y que el agente solicitante provea informacin (en trminos de
entradas y salidas) para interactuar con un agente proveedor. No necesita una codificacin
explcita de tareas en la ontologa sino que proporcionan una expresin natural de tareas al
utilizar los dominios de las ontologas disponibles.

La ventaja de un esquema de representacin explcita es que facilita la asociacin de

solicitudes y publicaciones y no busca una relacin de subsuncin entre solicitud y
publicacin. En cambio, la asociacin por capacidades expresadas implcitamente es ms
compleja. El hecho de que no exista una manera sencilla para clasificar las tareas, hace que la
asociacin requiera una cuidadosa comparacin entre la transformacin de entradas y salidas
descripta en la solicitud con las transformaciones de entradas y salidas descriptas en las
publicaciones.

Otro enfoque para representacin de capacidades utiliza una combinacin de ambas

representaciones, explcita e implcita. Este enfoque combina la facilidad de uso provista por
el primero con la habilidad para describir la capacidad de una agente, provista por el
segundo. El ejemplo ms notable de este enfoque es DAML-S.

3.5 Aplicaciones de ontologas en agentes

En la Web Semntica, las anotaciones semnticas que describen la informacin posibilitan a

agentes procesarla automticamente, presentndose nuevas oportunidades para usuarios y
desarrolladores.

Las tecnologas de SWS dependen de entidades de software de nivel superior con capacidades
cognitivas que puedan acceder al contenido semntico de sus descripciones, que puedan
procesarlas y comprenderlas a fin de hacer un uso apropiado de las funcionalidades provistas.

El marco semntico el cual describe las capacidades de los servicios Web semnticos (OWL-S,
WSMO, etc.) hace que los agentes puedan comprender, procesar y utilizar las capacidades
publicadas que representen un paso hacia el logro de sus objetivos. De esta manera,
mediante la combinacin de agentes y servicios Web semnticos se automatiza la tarea de
descubrir, seleccionar, componer, ejecutar y monitorear servicios Web y la adaptacin a
cambios en el entorno pasa a ser dinmica.

[Yong-Feng y Jason JEN-Yen; 2007] presentaron una descripcin de interaccin de agentes

en un marco de comunicacin delimitado por el lenguaje de ontologas Web (OWL) y la
Foundation of Intelligent and Physical Agents (FIPA). Estos autores sostuvieron que los
servicios Web se convirtieron en recursos extremadamente populares dejando atrs la
publicacin de pginas Web. En la era Web, los servicios suelen ser representados por HTML

97
 75.00 Tesis
y transferidos por HTTP mientras que las tecnologas de servicios Web, como WSDL y SOAP
agregan interoperabilidad a la Web. Su trabajo se centr en la invocacin dinmica de
servicios por describir una interaccin de agentes. Plantearon un escenario donde un
usuario solicitaba a su agente la ejecucin de un servicio (Video Broadcast Service). El
agente buscaba el servicio en un registro OWL/UDDI y como no poda ejecutarlo puesto que
el servicio requera un ancho de banda superior a 2 Mbps solicitaba a otro agente su
ejecucin quin, al cumplir con el requerimiento de ancho de banda, entregaba el servicio al
usuario. En general, la capa de interaccin de agentes consiste de un protocolo preacordado
para el intercambio de mensajes, siendo frecuentemente empleados COOL (COOrdination
Language, basado en KIF/LQML) y IOM/T (Interaction-Oriented Model by Textual
representation). COOL es un framework para conversacin de agentes que provee reglas
conversacionales y reglas de recuperacin de errores. IOM/T sigue la notacin de AUML
(Agent-based Unified Modeling Language) para definir la interaccin. Como el anidamiento
de interacciones en IOM/T era complejo de procesar, definieron una mquina de estados
finita junto con una ontologa OWL para la interaccin de agentes en combinacin con FIPA.

[Paolucci et al.; 2003] propusieron una solucin DAML-S y analizaron los problemas
relacionados con los servicios Web autnomos. Sus resultados fueron que los servicios Web
podan ser desplegados a fin de proporcionar informacin e interactuar dinmicamente y
que una transaccin poda ser llevada a cabo automticamente sin intervencin del
programador. Sostuvieron que tratar con ontologas (en su trabajo utilizaron DAML) era
fundamental porque permita en servicios Web inferir sobre los statements de una
descripcin DAML-S.

Construyeron una arquitectura de servicios Web DAML-S con dos partes principales: el
servicio proveedor y el DAML-S Port, que administraba la interaccin con otros servicios.
Realizar una composicin de servicios o, analizar y elegir de las opciones provistas por el
workflow (descripto en el Process Model) aquellas que estuvieran en lnea con sus objetivos,
requera del servicio tomar decisiones no deterministas. Por tal motivo dotaron al servicio
con el planificador RESINA (basado sobre el paradigma de planificacin HTN).

El DAML-S Port consista de tres mdulos: el DAML Parser (permita cargar ontologas DAML
desde la Web); el DAML-S VM (defina conocimiento a partir de reglas que implementaban la
semntica axiomtica DAML) y el Web service Invocation. La DAML-S VM era el corazn de
la arquitectura. Su tarea principal era comprender el Process Model del proveedor y para ello
haba sido dotada de dos componentes: 1) un Process Model Rules semntico, que contena
normas para la ubicacin del prximo proceso a ejecutar, la extraccin de entradas y salidas
de cada proceso y la administracin de decisiones no deterministas, y 2) el Grounding Rules,
que especificaba la correspondencia de los procesos atmicos del Process Model con
operaciones WSDL y la relacin de entradas y salidas de los procesos atmicos con las del
Process Model.

Sus pruebas se basaron en dos aplicaciones. Una aplicacin B2B en la que un agente de
interfaz permita a un operador interactuar con un agente planificador que se ocupaba de
comparar los costos de diferentes proveedores de hardware. El agente planificador
consultaba dos matchmakers, uno de hardware y otro de finanzas (anlisis de solvencia) a fin
de obtener y organizar una cadena de proveedores de acuerdo con los lmites

98
 75.00 Tesis
presupuestarios y fechas indicadas. Finalmente, el agente planificador contactaba a los
proveedores para negociar plan de pagos y costos. La otra aplicacin fue del tipo B2C, donde
un agente permita a un usuario planificar un viaje a una conferencia (suponan que los
organizadores haban publicado un servicio con informacin de la conferencia como fechas,
lugares, expositores y otros). El agente verificaba la disponibilidad y utilizaba un
matchmaker para encontrar aerolneas, alquilar coches y hoteles. Finalmente retornaba el
viaje programado. Dejaron como cuestin abierta proceder con un modelo computacional
ms simple dado que los requerimientos computacionales de un planificador fueron
sumamente considerables.

3.6 Definicin de las funcionalidades relacionadas con las capacidades

esperadas de los agentes basados en razonadores.

Como se mencion en la seccin 2.6 el desarrollo y aplicacin de ontologas depende de

razonamiento. Por incluir ontologas en los procedimientos que implementan los agentes,
indirectamente se incluye algn razonador dado que las ontologas slo describen de forma
explcita algn vocabulario de dominio y los razonadores obtienen el vocabulario implcito
oculto en las mismas. Los razonadores otorgan a los agentes de un mayor caudal de
informacin a fin de mejorar los resultados de los objetivos que persiguen. A continuacin se
mencionan algunos de los cambios que introduciran en el agente los razonadores:

Realizar inferencias como hacen los humanos y justificarlas. Un agente que tenga
programada la regla las compras de ms de 300 tienen un descuento del 10% podr
justificar lgicamente porque permite descuentos a unos clientes y a otros no.

Realizar bsquedas consultando la Web Semntica por medio de lenguajes que reconozcan
RDF como la sintaxis principal. Con esta base, consultando lenguajes basados en RDF tal
como OWL desde una perspectiva RDF pura no requiere procedimientos especiales o
caractersticas de lenguaje siendo, de esta manera, posible aprovechar los servicios ofrecidos
(seccin 2.6) por un razonador en la resolucin de consultas.

Buscar servicios Web y utilizarlos automticamente sin intervencin humana por acceder a
las ontologas que acompaen a los servicios Web y comprender e integrar esas ontologas.

Buscar productos, negociar compras, acuerdos de nivel de servicio, calidad de datos, cantidad
de datos, localizar servicios de inters para los usuarios. Por el uso de ontologas en las
empresas, los agentes podrn combinarlas con sus algoritmos de negociacin y hacer
negocios electrnicos con otras empresas, de manera automtica.

3.7 Razonadores alternativos que puedan ser incorporados en el agente

Se han estudiado los siguientes razonadores alternativos: HermiT, Pellet, FaCT++.

A continuacin, se describen sus principales caractersticas.

HermiT es uno de los actuales proyectos de investigacin del Laboratorio de Computacin de

la Universidad de Oxford. Aunque puede ser empleado con cualquier ontologa, los
investigadores toman como punto de partida los requerimientos de ontologas mdicas a fin
de construir un razonador potente. Las ontologas mdicas, sostienen, estn fuertemente
relacionadas con las lgicas descriptivas, las cuales constituyen una base formal para muchos

99
 75.00 Tesis
lenguajes de ontologas como OWL. Las ontologas mdicas poseen significantes desafos
para la teora y la prctica de lenguajes basados en DL. Los razonadores existentes pueden
eficientemente tratar con ontologas enormes (como NCI) pero existen otras ontologas
importantes que estn fuera del alcance de las herramientas disponibles (ninguno de los
razonadores existentes puede clasificar correctamente GALEN o FMA). El objetivo del
proyecto HermiT es, por lo tanto, desarrollar algoritmos de razonamiento escalables e
implementar un prototipo que pueda eficientemente manejar 1) ontologas enormes y
complejas y 2) volmenes importantes de datos. El desarrollo de un razonador semejante
ser clave para el xito de aplicaciones basadas en ontologas.

En general, HermiT es un razonador para ontologas escritas empleando OWL y construido

empleando clculo hypertableau a fin de proveer razonamiento ms eficiente. Se anuncia
como un razonador veloz y capaz de resolver ontologas complejas. Utiliza Direct Semantic y
ha superado las pruebas de conformidad de OWL 2 DL, OWL 2 EL, OWL 2 QL y OWL 2 RL. La
ltima versin es HermiT 1.3.1, liberada en octubre de este ao, la cual utiliza la reciente
OWL API 3.1.0. y es compatible con Java 1.5. HermiT es open-source y liberado bajo LGPL122.

Pellet fue desarrollado por el laboratorio Mindswap123 de la Universidad de Maryland (USA)

Empez como una prueba de concepto de sistema para ayudar al W3C a satisfacer los
requerimientos de experiencia de implementacin para OWL y posteriormente se
convirti en una herramienta popular y prctica para trabajar con OWL. Entre sus
caractersticas se destacan que admite la expresividad completa de OWL DL, razonamiento
acerca de nominales (clases enumeradas o definidas por extensin), absorcin, ramificacin
semntica y fue extendido para soportar las nuevas caractersticas propuestas en OWL 1.1 y
OWL 2.

Pellet trata de un razonador DL basado sobre algoritmos tableaux. El ncleo del razonador, es
el algoritmo tableaux (desarrollado para lgicas descriptivas potentes) el cual verifica la
consistencia de la KB124, es decir del par ABox y TBox125. Las ontologas OWL son cargadas al
razonador despus de validar las especies OWL (DL, RL, QL) y reparar ontologas. Este paso
asegura que todos los recursos tienen un tipo de tripla apropiado (un requerimiento para
OWL DL pero no para OWL FULL). Durante la fase de carga, los axiomas acerca de las clases
(subclase, clase equivalente o axiomas disjuntos) son ubicados en el componente TBox y las
aserciones acerca de individuos (aserciones de tipo y propiedad) son almacenadas en el
componente ABox. Los axiomas TBox pasan antes por un preprocesamiento estndar de
razonadores DL y luego por el razonador tableaux.

Esencialmente un razonador tableaux posee slo la funcionalidad de verificar la

satisfactibilidad de un ABox con respecto a un TBox. Todas las otras tareas de razonamiento
pueden ser reducidas a pruebas de consistencia con la KB mediante la transformacin
apropiada. El System Programming Interface (SPI) de Pellet provee funciones genricas para
administrar tales transformaciones.

122
GNU Lesser General Public License.
123
Maryland Information and Network Dynamics Lab Semntica Web Agents Project o MINDSWAP, Laboratorio
Maryland de Informacin y Redes Dinmicas del Proyecto de Agentes de Web Semntica. La informacin del
razonador actualmente se encuentra disponible en el sitio Web http://pellet.owldl.com.
124
Knowledge Base.
125
Desarrollado en la seccin 2.6 Razonador

100
 75.00 Tesis
Este razonador implementa las mejores tcnicas de optimizacin, lo que hace que su
desempeo sea bueno, en especial cuando debe evaluar ontologas con mayor complejidad y
expresividad; sin embargo no es tan eficiente como RacerPro o FACT++ en clasificaciones
[Rodriguez et al.; 2010].

Implementado en Java, soporta la interfaz Jena, la interfaz OWL API, la interfaz DIG y puede
trabajar con el editor Protg. Es ofrecido bajo un modelo de licencia dual126. Ha superado las
pruebas de conformidad de OWL 2 DL, OWL 2 EL, OWL 2 QL y OWL 2 RL. La ltima versin
es Pellet 2.2.2, liberada en septiembre de este ao.

FaCT++, desarrollado por la Universidad de Manchester bajo el proyecto europeo

WonderWeb, es un razonador DL basado en el algoritmo tableaux para lgica descriptiva.
Cubre los lenguajes de ontologa OWL y OWL2.

FaCT++ es un buen razonador para la TBox de una ontologa, sin embargo, carece de soporte
para otros tipos de datos que no sean string o integer (como si ocurre con Pellet) y tampoco
posee soporte para razonamiento con la ABox de una ontologa. En el caso de los tipos de
datos en un entorno Web, es necesario que exista soporte para los tipos de datos de XML
Schema. Entre sus caractersticas se destaca: 1) trabaja de forma eficiente con TBox de
ontologas de tamao grande y mediano y 2) es posible utilizar el lenguaje de consultas para
RDF: SPARQL, el cual permite consultar el modelo inferido de una ontologa OWL-DL.

Mediante el algoritmo tableaux implementa un procedimiento de decisin para TBox y ABox.

Tambin implementa nuevas caractersticas y optimizaciones, que permite personalizar
para adicionar nuevas tcticas de razonamiento y la capacidad de razonar con lgicas
descriptivas ms potentes y cercanas a la expresividad de OWL-DL. Es un software open
source, distribuido bajo los trminos de licencia GPL/LGPL e implementada en C++. Soporta
la OWL-API y la interfaz DIG. Ha superado la mayora de las pruebas de conformidad de OWL
2 en todas sus especies quedando pendiente algunas pruebas. La ltima versin fue FaCT
++ 1.2.3, liberada en el ao 2009.

126
En aplicaciones open source, Pellet puede ser utilizado segn los trminos de la licencia AGPL versin 3 y en
aplicaciones closed source, propietarias u otras aplicaciones comerciales, segn los trminos de licencia
alternativos establecidos por los autores.
101
 75.00 Tesis
Captulo IV

Composicin dinmica de servicios

4.1 Estudio de los ltimos avances en composicin dinmica de servicios

como una solucin eficiente y efectiva.

Una transaccin entre servicios involucra tres o ms componentes: un usuario, uno o ms

proveedores y un registro que soporta los servicios durante la transaccin y posiblemente
acte de mediador entre ambos. La composicin de servicios Web sigue un ciclo que puede
ser segmentado en dos partes: la ubicacin del proveedor y la interaccin entre el usuario y
el proveedor. Un proveedor se inscribe en el registro y hace pblicos sus servicios. La
inscripcin no es parte de la transaccin pero si una condicin necesaria para que la
transaccin tome lugar.

El proceso de localizar un proveedor se compone de tres etapas: el usuario prepara un

pedido y lo enva al registro, el registro busca y enva los servicios candidatos y el usuario
elige el proveedor que ms se ajusta a sus necesidades. El usuario espera que un proveedor
resuelva su peticin pero no conoce proveedores. Para encontrar los proveedores, necesita
consultar el registro a fin de localizar servicios con ciertas capacidades. La compilacin
automtica requiere una abstraccin del problema por las capacidades que el usuario espera
que el proveedor posea para resolver sus requerimientos. Resulta crucial en esta situacin
un lenguaje que posibilite efectuar publicaciones y consultas y permita al registro obtener y
procesar informacin de las capacidades publicadas. La tarea del registro es localizar las
publicaciones que coincidan con un pedido. Diferentes partes con diferentes perspectivas
pueden proveer descripciones radicalmente diferentes del mismo servicio. Por lo tanto, el
proceso de bsqueda no debe restringirse a encontrar una coincidencia exacta entre pedido y
servicio sino a establecer los niveles necesarios a fin de determinar servicios similares. El
resultado es una lista de proveedores potenciales entre los que el usuario elige.

En general, no hay una manera fcil y rpida de elegir un proveedor sino que pasa a ser una
decisin especfica de dominio. Lo ms simple es seleccionar el proveedor con el mayor
puntaje entre los servicios reportados por el registro. Un enfoque ms general podra estar
basado sobre razonamiento terico de decisin, en el cual los usuarios elijan el proveedor
que maximiza alguna funcin de utilidad, sin embargo, en la prctica es poco probable que los
servicios hagan uso de un modelo de utilidad explcito.

Para permitir descubrimiento e interaccin automtica de servicios, [Paolucci et al., 2003]

han propuesto una arquitectura de servicios Web que utilizaba DAML-S y un planificador
HITAP (modelo computacional con soporte de razonamiento no determinista), dejando como
una cuestin abierta encontrar un modelo computacional ms simple con menores
requerimientos de procesamiento (a causa del planificador).

[Qiu et al., 2008] definieron los servicios Web como aplicaciones modulares autnomas, auto
descriptas que pueden ser publicadas, localizadas e invocadas a travs de la Web. En su
trabajo expusieron que con el desarrollo de Internet, emergi un gran nmero de
organizaciones que implementaron sus negocios y los exteriorizaron como servicios Web.
102
 75.00 Tesis
Cuando un slo servicio no puede satisfacer un pedido de usuario, la capacidad para
seleccionar y componer servicios heterogneos a lo largo de diferentes organizaciones,
eficiente y efectivamente, se transforma en un paso importante en el desarrollo de
aplicaciones Web, convirtindose la tecnologa de composicin automtica de servicios en
uno de las principales cuestiones dentro del proceso de desarrollo de una aplicacin Web. La
investigacin para permitir fcil integracin incluye UDDI, WSDL, BPEL4WS, donde la
representacin de composicin de servicios realizada a travs del flujo de proceso y de la
conexin entre servicios es conocida a priori. La composicin de servicios, afirman, es una
tarea compleja debido a 1) el incremento de servicios Web, 2) a cambios on the fly que las
aplicaciones de composicin deben detectar en tiempo de ejecucin a fin de tomar decisiones
correctas sobre informacin actualizada y 3) la falta de un lenguaje nico para definir y
evaluar servicios. Estos autores aseguran que la Web semntica es un paso clave para la
composicin de servicios. En su trabajo, extendieron WSDL con capacidades semnticas,
definieron una ontologa en OWL y elaboraron un plan (a travs de BPEL4WS) para analizar
la estructura de los servicios que mejor combinaba.

Un Framework de composicin y adaptacin dinmica basado en semntica fue propuesto

por [Hibner y Zielinski; 2007]. Como resultado, automatizaron el proceso de orquestacin de
SOA utilizando el algoritmo backward-chaining.

[Thakker et al., 2007] utilizaron una metodologa conocida como Case Based Reasoning
(CBR) para modelar descubrimiento y matchmaking dinmico de servicios Web. Su trabajo
consideraba la experiencia de ejecucin de un servicio Web a fin de determinar si era
adaptable al pedido de un usuario. Desarrollaron un framework con descripciones
semnticas (OWL) para la implementacin de los componentes CBR y matchmaking. Un
proceso CBR es un ciclo de cuatro fases: 1) representacin del caso, que consiste del
problema, el contexto y la solucin; 2) almacenamiento e indizacin de casos, donde se utiliza
una biblioteca de casos; 3) recuperacin de casos, que utiliza ndices para expresar el
contenido del caso y 4) matchmaking, que compara los casos recuperados con el pedido a fin
de verificar si una solucin anterior puede ser reutilizada. Argumentaron que como el
comportamiento de un servicio no puede ser conocido con antelacin, slo puede ser
generalizado si los valores de su ejecucin son almacenados y razonados para decidir la
capacidad del servicio.

A veces los casos anteriores no pueden ser reutilizados sin hacer cambios que requieren
conocimiento especfico del dominio para modelar una adaptacin. Tal conocimiento podra
surgir por relacionar los conceptos definidos en una ontologa utilizando una taxonoma de
relaciones y reglas semnticas. El rol del conocimiento en reparar los casos existentes
requiere relajar las descripciones de servicios o sus parmetros funcionales y los valores de
ejecucin de los casos candidatos (parmetros no funcionales) para encontrar descripciones
de servicios suficientemente similares. Sugirieron, y es ms, dejaron como trabajo futuro el
desarrollo de sustitucin basado en conocimiento para adaptar los atributos funcionales y no
funcionales de los casos candidatos como solucin a un pedido, descartando completamente
un planificador de IA, por ser un recurso sumamente costoso.

[Kster et al., 2005] definieron composicin de servicios como un servicio integrado,

obtenido por combinar componentes de servicios disponibles en situaciones donde un
pedido de cliente no poda ser satisfecho por un slo servicio sino por una combinacin de

103
 75.00 Tesis
ellos. En trminos de ingeniera de software, la composicin automtica de servicios podra
mejorar la capacidad de una arquitectura de servicios porque posibilitara superar
dificultades como 1) especificar y combinar, manualmente, los servicios bsicos a utilizar y
2) fortalecer el proceso de composicin contra la falta de disponibilidad de un servicio o por
la aparicin de otros nuevos. Por otro lado, mencionaron que la composicin de servicios por
sntesis consiste de un plan para lograr el comportamiento deseado al combinar las
habilidades de mltiples servicios y que la composicin de servicios por orquestacin trata
del control y flujo de datos entre varios componentes de software cuando ese plan se ejecuta.
Sostuvieron que la composicin por sntesis era ms relevante en la composicin
automtica, quedando la orquestacin como un elemento complementario. En su trabajo
estudiaron las capacidades requeridas y las generalmente utilizadas en los trabajos de
composicin automtica de servicios para finalmente concluir que: 1) un encadenamiento de
servicios poda introducir un nivel de incertidumbre, que en algunas situaciones era
inaceptable para el usuario, 2) los pedidos con mltiples efectos necesitaban capacidades
como escalabilidad estable y propiedades transaccionales, 3) los problemas relacionados con
falta de conocimiento requeran de servicios que recopilasen la informacin y 4) mejores
descripciones semnticas requeran del desarrollo de bases semnticas slidas, entre otras.

[Aversano et al.; 2004] propusieron un algoritmo para descubrimiento de servicios. El

algoritmo tena por objetivo aumentar la probabilidad de responder a un pedido de servicio
mediante composicin de servicios. Se basaron en el Service Profile de DAML-S y en
ontologas DAML-OIL. La implementacin incluy entradas y salidas de servicio, dejando
como trabajo futuro sus precondiciones y efectos. El algoritmo propuesto tomaba la salida de
un pedido de servicio como objetivo. En el mejor caso, el objetivo poda ser alcanzado por un
slo servicio. Caso contrario, la solucin comprenda el conocido algoritmo backward-
chaining (BCA) con las siguientes variantes: 1) el algoritmo entity matching (EMA) y 2)
seleccin basada en meta-valores (SBM). BCA verificaba la posibilidad de componer varios
servicios, EMA evaluaba similitud entre entidades de distintas ontologas por considerar
entidades por su nombre, por sus caractersticas a nivel semntico (object-properties y data-
properties de DAML-OIL) y por sus relaciones semnticas (utilizaron SuperClass, SubClass,
DisjointWith, DifferentFrom, EquivalentClasses de DAML-OIL). SBM permita establecer un
conjunto de atributos de calidad de servicios (QoS, disponibilidad, tiempo de respuesta, costo,
entre otros) y asignar un peso a cada atributo segn los intereses del usuario. El Service
Profile de DAML-S ha permitido insertar atributos de calidad y los valores deseados.

Como conclusin, mencionaron que los servicios son desplegados por varias personas en el
mundo y es poco probable encontrar un servicio Web que perfectamente proveyese a otro,
que la capacidad de cubrir conceptos utilizados en diferentes ontologas es el tema ms
importante en la Web Semntica y que desde que EMA evaluaba ontologas, la clasificacin de
un servicio Web en un dominio semntico era innecesario.

[Paolucci et al., 2002] destacaron que UDDI y WSDL no prestaban capacidad de bsqueda de
servicios por match semntico al responder a un pedido de usuario y lo propusieron como
mejora. Para representar las capacidades de servicios utilizaron la seccin Profile de DAML-S.
Para realizar inferencias sobre una jerarqua utilizaron las ontologas DAML. Un algoritmo
buscaba salidas de servicios que coincidieran con al menos una salida del pedido de usuario.
Las entradas de servicios eran utilizadas como complemento cuando haba ms de un
servicio que provea las mismas salidas siendo elegido el que tena ms entradas similares
con el pedido. Como resultado daba un conjunto ordenado de servicios de acuerdo al nivel de
104
 75.00 Tesis
matching de cada uno. El algoritmo fue dotado de cierta flexibilidad (configurable por el
usuario) para establecer los niveles de match que podan ser exacto (la salida coincida con el
pedido o era una superclase directa del pedido suponiendo que el proveedor se comprometa
a prestar el servicio publicado a un nivel de profundidad de uno en la jerarqua de clases),
plug-in (superclases del pedido que podan incluirlo), subsumidos (salidas parciales, es decir
que el servicio provea una parte del pedido) y fail (no match).

A partir de lo investigado y expuesto nuestra definicin de servicio para el desarrollo del caso
prctico es: un servicio es un activo que establece prestaciones y calidad a travs de
contratos de servicio. Un servicio Web es funcionalidad disponible en la Web segn
estndares estipulados (SOAP, WSDL, UDDI) a fin de garantizar interoperabilidad. Un servicio
Web semntico posee descripciones realizadas por ontologas las cuales agregan un nivel
ms de procesamiento a fin de optimizar el ciclo de descubrimiento, seleccin, invocacin y
composicin de los servicios Web.

4.2 Alternativas de composicin semntica como OWL, Pellet, el algoritmo

backward-chaining

Una situacin comn es encontrar servicios que generan los efectos pedidos pero que
alguna precondicin no pueda ser cubierta. Una solucin es utilizar encadenamiento de
servicios. El encadenamiento considera recursivamente los efectos de un servicio como las
precondiciones del siguiente hasta que el efecto deseado es alcanzado. Los enfoques de
encadenamiento de servicios incluyen:

Graph-Search: construye una representacin de grafo de todos los servicios disponibles.

Los nodos representan servicios y las aristas las salidas de un servicio que sirven como
entradas de otro. Adems, las aristas son pesadas de acuerdo al nivel de correspondencia de
entradas y salidas asociadas. Una adaptacin del algoritmo de Bellman-Ford es utilizado
para encontrar el camino ms corto entre las entradas del usuario y las salidas deseadas
que represente la mejor composicin disponible. Como desventaja, este tipo de enfoque
no es escalable con el nmero de servicios ofrecidos, llegando a trabajar con complejidades
de orden O(n3) .

Forward-Chaining: tpico de sistemas de planificacin basados en lgica, utiliza el
conocimiento disponible, precondiciones y entradas del servicio para inferir
conocimiento adicional hasta conseguir todos los efectos requeridos. Como desventaja,
para cubrir todos los efectos de un pedido tiende a buscar en direcciones innecesarias por
abarcar el mximo conocimiento posible.

Backward-Chaining: supera la propuesta anterior. Se diferencia del forward-chaining en
que la composicin considera aquellos servicios que generen los efectos deseados en lugar
de esos cuyas precondiciones son concedidas. Cualquier algoritmo recursivamente trata de
crear las precondiciones necesarias usando otros servicios hasta cubrir todas las
precondiciones. Mientras que el backward-chaining implementa una bsqueda dirigida
mejorada, el espacio del problema es todava grande.

Estimated-Regression planning: es un intento por mejorar la performance de la bsqueda
por implementar un forward chaining por una heurstica basada en backward-chaining.

En general, los enfoques de encadenamiento estn basados en sistemas de planificacin de AI,

105
 75.00 Tesis
los que generalmente conducen a problemas de escalabilidad en caso de un incremento en el
nmero de servicios.

4.3 Agentes y la composicin de servicios Web

A fin de conseguir los beneficios anunciados por tener agentes y servicios trabajando
cooperativamente, ambas tecnologas se relacionan en un escenario donde el agente provee
la funcionalidad de alto nivel por utilizar, combinar y coreografiar los servicios Web
obteniendo funciones de valor agregado mientras que los servicios Web prestan la
funcionalidad de bajo nivel.

Los agentes con capacidades semnticas y los servicios Web semnticos permiten
automatizar una situacin en la que fuera necesario ejecutar varios servicios a fin de
proporcionar el servicio requerido.

El agente consulta un registro de servicios a fin de localizar servicios con ciertas capacidades.
La compilacin automtica requiere una abstraccin del problema por las capacidades que se
espera que el servicio posea, a fin de resolver el problema. Un lenguaje como SAWSDL
posibilita realizar publicaciones y consultas y permite al agente obtener y procesar
informacin acerca de las capacidades publicadas. La tarea del agente es localizar las
publicaciones que coincidan con un pedido. El proceso de bsqueda no se restringe a
encontrar una coincidencia exacta entre pedido y servicio sino que previamente se
establecen niveles (desarrollado en la seccin 5.2.1) para que servicios similares puedan ser
elegidos. El resultado es una lista de servicios potenciales que cubren un pedido.

El agente accede a las publicaciones dadas por las descripciones WSDL de los servicios a fin
de conocer lo que hace el servicio. Las ontologas utilizadas por el servicio, sus entradas,
salidas y las reglas requeridas para su ejecucin es lo que permite al agente conocer las
acciones y efectos del servicio. La forma en que el agente logra ese conocimiento es
desarrollado en la seccin 5.2.1.

106
 75.00 Tesis
Captulo V

Caso prctico

5.1 Escenario de aplicacin representativo del problema a resolver

El escenario de aplicacin trata de la bolsa de trabajo de una facultad. Un nuevo estudiante

puede postularse a las ofertas publicadas por la bolsa de trabajo por presentar una nota de
inscripcin, su curriculum y la oferta a la cual postula. Los graduados slo pueden postularse
a ofertas de trabajo profesional y los no graduados a ofertas de pasanta.

El servicio Web semntico wsMatriculate define una interfaz con la operacin Registration
para realizar la inscripcin en la facultad de un nuevo estudiante recibiendo los datos del
nuevo estudiante y una nota de inscripcin. El servicio retorna una nota con la inscripcin
realizada (de tipo nota de graduado o de tipo nota de no graduado).

El servicio Web semntico wsInscribeJobBag define una interfaz con la operacin

ApplyForJobBag para realizar la inscripcin en la bolsa de trabajo de un nuevo estudiante
recibiendo un curriculum y la nota de inscripto en la facultad. El servicio retorna un registro
con la inscripcin realizada en la bolsa de trabajo (de tipo postulacin de trabajo).

El servicio Web semntico wsPostulateJobG define una interfaz PostulateJobOffer con la

operacin postulateJob para realizar la postulacin de trabajo profesional de un nuevo
estudiante graduado recibiendo la oferta de trabajo profesional elegida y el registro de
inscripto en la bolsa de trabajo. El servicio retorna un registro con la postulacin a la oferta de
trabajo profesional realizada (de tipo postulacin de trabajo profesional).

El servicio Web semntico wsPostulateJobU define una interfaz PostulateJobOffer con la

operacin postulateJob para realizar la postulacin de pasanta de un nuevo estudiante no
graduado recibiendo la oferta de pasanta elegida y el registro de inscripto a la bolsa de
trabajo. El servicio retorna un registro con la postulacin a la oferta de pasanta realizada (de
tipo postulacin de pasanta).

Dado un nuevo estudiante graduado que posea un curriculum y desee anotarse a una
bsqueda de trabajo profesional, la combinacin de los servicios wsMatriculate,
wsInscribeJobBag y wsPostulateJobG responderan al pedido.

Para un nuevo estudiante con curriculum e intencin de anotarse a una bsqueda de

pasanta, la combinacin de los servicios wsMatriculate, wsInscribeJobBag y
wsPostulateJobU responderan al pedido.

Como puede observarse, los servicios propuestos ofrecen las posibles salidas requeridas y
cul servicio se ejecutar para resolver el pedido es determinado en tiempo de ejecucin.

Con este escenario se pretende estudiar de que manera los servicios Web semnticos pueden
ser combinados de manera automtica por un agente provisto con las ontologas necesarias.

107
 75.00 Tesis
5.2 El prototipo construido

5.2.1 Criterio adoptado

Se utilizaron estndares en la construccin de los servicios Web como WSDL y SOAP.

Se utilizaron estndares para la anotacin semntica de los servicios Web como SAWSDL a
fin de convertir los servicios Web en servicios Web semnticos.

A fin de dotar a los servicios con informacin acerca de sus pre y postcondiciones de manera
que fuera compatible con el estndar SAWSDL, se eligi emplear el lenguaje de reglas SWRL.

Se implementaron reglas DL-Safe Rules con el propsito de conservar y disponer de las

capacidades de inferencia y clasificacin sobre ontologas, entre otras, ofrecidas por un
razonador DL.

Se empleo el estndar OWL como lenguaje de ontologa para lograr la mxima expresividad
semntica con las ontologas.

Para realizar la asociacin de un pedido de servicio con los servicios ofrecidos se

consideraron los siguientes tipos de asociaciones [Paolucci et al.; 2002]:

exact: cuando el pedido de servicio coincide exactamente con la salida de un servicio o

cuando el pedido de servicio coincide con algn subtipo directo de los tipos utilizados en la
salida del servicio. Esta decisin se sostiene bajo el supuesto de que un proveedor se
compromete a prestar salidas consistentes con cada subtipo inmediato de la salida con la
que publica su servicio.

plug in: cuando la salida de un servicio subsume el pedido de un servicio. Esta relacin
corresponde a un tipo de relacin dbil. El proveedor de servicio podra responder al
pedido de servicio. Esta asociacin ocurre cuando el pedido de servicio es un subtipo no
directo de la salida de servicio (existe una relacin lejana en la jerarqua).

subsume: cuando el pedido de servicio incluye la salida de un servicio. El proveedor de
servicio no cumple completamente con el pedido de servicio. En este caso, el pedido de
servicio subsume la salida de servicio.

fail: cuando ninguna relacin de subsuncin existe entre el pedido y el servicio ofrecido.

Se eligi realizar las asociaciones de acuerdo al primer tipo. Los tipos restantes fueron
implementados y dejados como trabajo futuro.

Lo anterior contempla slo las salidas de un pedido de servicio y de un servicio ofrecido. Para
evaluar la asociacin de las entradas de un pedido de servicio y de un servicio ofrecido se
consider la propuesta de [Akkiraju y Sapkota; 2007] por aceptar que las entradas pueden
ser satisfechas por sus supertipos directos en la jerarqua de clases.

El agente lleva a cabo la composicin mediante el algoritmo de backward-chaining y reglas

DL-Safe Rules.

Una composicin es vlida si el pedido de servicio y las entradas y las reglas de los servicios
elegidos son satisfechos. Los resultados finales son comunicados por el agente.

108
 75.00 Tesis
La ontologa de datos fue construida implementando un TBox acclico127 a fin de evitar los
problemas semnticos que surgen con un TBox cclico.

5.2.2 Componentes

El prototipo consiste de un agente dotado con las capacidades de encontrar, combinar y

comunicar los servicios Web semnticos a fin de responder a un pedido de servicio
determinado, el cul podra ser realizado por uno o varios servicios.

A fin de procesar las anotaciones semnticas incluidas en los documentos WSDL de los
servicios, el agente fue implementado incorporando, como razonador OWL-DL, la versin
Pellet 2.2.1.

Se defini la siguiente estructura de directorios:

/repository/ontologies

/repository/servicesDescription

/AgentClient/request

/AgentClient/response

/AgentClient/temp

El directorio ontologies contiene las ontologas owl de todos los servicios. Cada servicio
incluye en su documento WSDL tres ontologas: una ontologa para anotar los tipos de datos
de sus operaciones, otra ontologa para describir las reglas asociadas a sus operaciones y una
tercera ontologa que permite anotar la categora a la que pertenece el servicio, en el
elemento interface, que integra la especificacin WSDL 2.0.

La ontologa de datos fue presentada en la seccin 2.8, desde la perspectiva del lenguaje de
ontologa OWL y, en la seccin 5.1, por mencionar en detalle el escenario modelado. En la
seccin 2.8, tambin se mencion que la ontologa de datos haba sido dividida en dos partes:
una ontologa para contener los axiomas de clases y propiedades y otra ontologa, para
contener a los individuos. Los archivos StudentsJobBag.owl y membersStudentsJobBag.owl,
que corresponden a las ontologas bolsa de trabajo y miembros de la bolsa de trabajo, fueron
explicadas en esa seccin y se encuentran en este directorio.

[Akkiraju y Sapkota; 2007] sugirieron que, a fin de agregar la categora a la cual perteneca
un servicio, antes de publicarlo en un registro de servicios, los servicios Web podan ser
anotados semnticamente por los mecanismos de extensin provistos con SAWSDL. Para
ello, plantearon las siguientes dos formas:

127
Desarrollado en la seccin 2.6, Razonador.

109
 75.00 Tesis

Categorizacin por URI: a partir de un modelo semntico de categoras existente anotar
semnticamente los elementos operation o interface del documento WSDL 2.0 que
acompaa a un servicio por agregar la categora del servicio. Esta forma presentaba el
inconveniente de que el modelo de categoras no fuera completo y, que fuera necesario
recurrir, a mltiples piezas de informacin para identificar la categora del servicio.

Categorizacin por identificadores: en esta forma los usuarios podan definir la categora
segn sus requerimientos empleando categoras definidas por otros usuarios. As, la
categora del servicio era obtenida por indicar una taxonoma y un identificador dentro de
esa taxonoma.

Se adopt la segunda forma en el prototipo. El modelo de categoras definido fue

categorizacin.owl, el cual utiliz algunas de las categoras publicadas por NAICS128 para
anotar, en primer lugar, los pedidos de servicio y, en segundo lugar, los servicios ofrecidos,
con las categoras ms adecuadas, de manera de que, si el servicio ofrecido resultaba
pertenecer a la misma categora que el pedido, el servicio era elegido y posteriormente
procesado a fin de determinar si poda ser considerado para responder al pedido recibido,
reduciendo de manera considerable los costos de procesamiento.

Las ontologas de reglas, las cuales fueron empleadas para anotar las operaciones de un
servicio, fueron definidas con el propsito de habilitar al agente con la capacidad de decidir
acerca de las condiciones asociadas a la ejecucin de un servicio. Estas reglas fueron definidas
en OWL como DL-Safe Rules del SWRL y explicadas en la seccin 2.8. Sin embargo, es
necesario destacar, que las reglas hacen posible que el agente pueda determinar si un
servicio se ejecutar correctamente o no, y, qu cambios puede producir su ejecucin, de
manera similar, a las pre y post condiciones utilizadas en OWL-S. Adems, si bien para
ejecutar un servicio, ste debe ser invocado con las entradas requeridas por la firma de sus
operaciones, resulta indispensable considerar las condiciones que aseguren su buen
desempeo. Esta ltima verificacin se logra mediante la utilizacin de reglas las cuales
permiten al agente disponer de la informacin necesaria a tal fin.

Las ontologas de reglas empleadas fueron cuatro: rulesMatriculate.owl,

rulesInscribeJobBag.owl, rulesPostulateJobG.owl y rulesPostulateJobU.owl. Para definir las
reglas, estas ontologas importaron las ontologas StudentsJobBag.owl y
membersStudentsJobBag.owl. Las cuatro ontologas de reglas fueron descriptas en la seccin
2.8.

En el directorio servicesDescription se renen los documentos WSDL 2.0 de los servicios

Web semnticos creados. Este directorio acta como un registro de servicios al que el agente
accede para resolver un pedido.

El directorio request es donde el agente recibe los pedidos de servicios. Los pedidos de
servicios fueron construidos siguiendo la propuesta de [Akkiraju y Sapkota; 2007] por
utilizar WSDL 2.0.

128
North American Industry Classification System. http://www.census.gov/eos/www/naics/

110
 75.00 Tesis
El directorio response es donde el agente ubica el resultado de los pedidos recibidos. El
agente informa si encontr el o los servicios que corresponden al pedido, si el o los servicios
se pueden ejecutar por disponer de las entradas requeridas por los mismos y si se cumplen
las reglas asociadas a cada servicio para una ejecucin exitosa.

El directorio temp fue el contenedor temporal de los archivos empleados a lo largo de las
pruebas realizadas durante el desarrollo del prototipo y finalmente movido al directorio
/AgentClient.

El directorio /AgentClient contiene stubs que automticamente generan y envian pedidos a

los servicios Web para los contratos de servicio que implementan como clientes.
Su propsito es presentar pedidos y ejecutar los servicios compuestos encontrados por el
agente.

Finalmente, el archivo agent.properties permite configurar las rutas de la estructura de

directorios definida. Se encuentra en el directorio /AgentClient.

5.2.3 Herramientas

Para construir los servicios Web semnticos se utiliz la herramienta versin Axis2-1.5.2.

Axis2 es un proyecto de la Apache Software Foundation. Es una herramienta open-source

para crear y utilizar servicios Web e incluye SOAP 1.1 y SOAP 1.2, MTOM, XML/HTTP y los
estndares WS-*. Incluye un motor de ejecucin veloz pudiendo desplegar servicios mientras
el sistema se est ejecutando (pueden agregarse nuevos servicios sin necesidad de detener el
servidor). Incorpora flexibilidad para soportar patrones de intercambio de mensajes
(Message Exchange Patterns o MEPs). Soporta la invocacin de servicios Web asincrnicos
por utilizar clientes y transportes no-bloqueantes. Presta soporte para WSDL 1.1 y WSDL
2.0 y permite construir a partir de las descripciones WSDL stubs para acceder a servicios
remotos o exportar automticamente las descripciones de los servicios Web, entre otras
caractersticas. Adems Axis2 puede ejecutarse slo o en algn contenedor de servlets como
Tomcat y posee dos implementaciones: Axis2/C y Axis2/Java.

Axis2 fue desplegado empleando la herramienta Tomcat - 6.0.29 como servidor Web.

Tomcat es otro proyecto de la Apache Software Foundation. Es una implementacin open-

source de las tecnologas Java Servlet y Java Server Pages (especificaciones que son
desarrolladas por la Java Community Process129). Funciona como servidor Web con soporte
para servlets y JSP.

Los servicios fueron construidos empleando la versin WSDL 2.0 y SOAP 1.1 y SOAP 1.2.

129
http://jcp.org/en/home/index

111
 75.00 Tesis
Las descripciones WSDL de los servicios Web fueron obtenidas a partir de su cdigo en java
con la herramienta java2wsdl130 de Axis2. Las descripciones WSDL correspondan a la
versin WSDL 1.1 por lo que hubo que utilizar otra herramienta para obtener la versin
WSDL 2.0, Por medio de la herramienta comercial Altova XMLSPy 2011131 se pudo convertir
las descripciones WSDL 1.1 a descripciones WSDL 2.0, adhiriendo a la recomendacin ms
reciente del W3C.

Una vez obtenidas las descripciones WSDL 2.0 de los servicios y con la herramienta
wsdl2java132 de Axis2 se generaron los skeletons de los servicios. Finalmente los servicios
fueron ejecutados por ubicar el archivo de despliegue de cada servicio (estos archivos poseen
extensin .aar) en el directorio /webapps/axis2/WEB-INF de Tomcat.

Las herramientas presentadas hasta ahora resultaron adecuadas a los fines de conseguir los
servicios con los que el agente trabaj para la composicin de servicios. Adems, hay que
mencionar que dichas herramientas poseen una documentacin completa y clara y son,
debido a una aceptacin relativamente amplia, respaldadas por una comunidad de
desarrolladores que contribuyen con sus aportes a superar inconvenientes durante la
implementacin.

A fin de agregar semntica a los servicios se recurri a la herramienta Woden4SAWSDL.

Woden4SAWSDL es una API provista como parte de la infraestructura de APIs y
herramientas ofrecidas por el proyecto METEOR-S, del laboratorio LSDIS del Departamento
de Computacin de la Universidad de Georgia. Permite la creacin y el manejo de
documentos SAWSDL133 basados en WSDL 2.0.

Las ontologas fueron generadas a partir de la herramienta versin Protg 4.1.0. Protg 134
fue desarrollado por el Stanford Center for Biomedical Informatics Research de la Stanford
University School of Medicine como un editor de ontologas open source. Soporta dos formas
para modelar ontologas: mediante Protg Frames y Protg OWL. Entre sus caractersticas
se pueden mencionar la exportacin de ontologas en una variedad de formatos (RDF, RDFS,
OWL y XML-Schema entre otros), es construido en Java, extensible y provee un entorno plug
and play que lo convierte en una base flexible para prototipado y desarrollo de aplicaciones
veloz.

El Protg Frames es un conjunto de elementos de interfaz personalizables a fin de permitir

a los usuarios modelar conocimiento e ingresar datos de forma amigable. Provee una
arquitectura del tipo plug-in extensible mediante elementos diseados por el usuario como
componentes grficos (grafos y tablas), multimedia (sonido, imagen y video), herramientas
de soporte adicional (visualizacin de ontologas, inferencia y razonamiento, etc.), entre
otras. Dispone de una API basada en Java para acceder, utilizar y visualizar las ontologas

130
Script que genera el archivo WSDL apropiado a partir de la clase java especificada.
131
http://www.altova.com/xmlspy/wsdl-editor.html
132
Script que genera cdigo Java de acuerdo al archivo WSDL especificado a fin de manejar las invocaciones de
servicio (stubs del lado del cliente). El script tambin puede generar los skeletons de los servicios de acuerdo al
WSDL especificado.
133
Desarrollado en la seccin 2.5.8, SAWSDL.
134
http://protege.stanford.edu.

112
 75.00 Tesis
creadas con Protg Frames.

El editor Protg OWL soporta el Ontology Web Language u OWL permitiendo cargar y
almacenar ontologas OWL y RDF, editar y visualizar clases, propiedades y reglas SWRL,
definir expresiones OWL como caractersticas de las clases, ejecutar razonadores como
clasificadores DL y editar individuos OWL.

Adems, Protg cuenta con el respaldo de una gran comunidad de desarrolladores y usuarios
universitarios (University of Manchester), del gobierno (DARPA) y empresas (eBay) quienes
utilizan Protg para soluciones en reas tan diversas como la biomedicina, recopilacin de
informacin y el modelado de empresas.

El razonador empleado fue Pellet 2.2.1 descripto en la seccin 3.7.

Para administrar las ontologas programticamente en las primeras versiones del prototipo
se trabaj con el framework Jena 2.2.3.

Jena135 es un framework java, open-source, que creci como parte del Programa de la Web
Semntica de los laboratorios HP136. Actualmente, el proyecto fue desvinculado debido a la
decisin de la administracin HP Labs de no continuar con el Programa, encontrndose la
propiedad de los derechos del cdigo de Jena en proceso de transferencia desde HP a un
cuerpo comercialmente neutral. Sin embargo, HP asegura la continuidad del proyecto y su
participacin en el papel de colaborador.

El Framework Jena incluye una API RDF, soporta los formatos RDF/XML, N3 y N-Triples, la
OWL API, el motor de consultas SPARQL, manejo de ontologas en memoria y persistencia,
entre otras caractersticas. Pero no provee soporte para DL-Safe Rules. Por este motivo fue
reemplazada por la OWL API versin 3.1.0.

La OWL API versin 3.0.0 en adelante fue desarrollada por la University of Manchester. Es
open-source y la ltima versin se enfoc hacia OWL 2. Es una API Java y una
implementacin de referencia para crear, manipular y serializar ontologas OWL. Entre sus
componentes se encuentran: analizadores de sintaxis y escritura para RDF/XML, OWL/XML,
OWL Functional Syntax, Turtle, KRSS, interfaces para trabajar con razonadores como
FaCT++, HermiT, Pellet y Racer y una API para OWL 2, entre otros.

Con la OWL API, en su versin 3.1.0, fue posible implementar DL-Safe Rules.

135 Tambin desarrollado en la seccin 2.6.1.2, Razonadores de programacin lgica.

http://jena.sourceforge.net/
136 Hewlett-Packard Development Company

113
 75.00 Tesis
5.3 Resultados

La pruebas realizadas utilizaron los pedidos de servicios del directorio temp, los cuales
fueron construidos siguiendo la propuesta de [Akkiraju y Sapkota; 2007] y la especificacin
WSDL 2.0.

Los archivos servicerequestXX.wsdl corresponden a pedidos de servicio, los archivos

reportCompositeServiceServiceRequestXX son reportes de los servicios compuestos
encontrados y estn ubicados en el directorio response/r1 y los archivos
reportRunTimeServiceRequestXX son reportes de las ejecuciones de los servicios
compuestos encontrados y estn ubicados en el directorio response/r2.

Inicialmente, un pedido es ubicado en el directorio temp y movido al directorio request. El

agente levanta el pedido del directorio de entrada (request), lo procesa, elabora el reporte y lo
deposita en el directorio de salida (response). El directorio temp posibilit incrementar los
pedidos a medida que se avanzaron con las pruebas. La ltima prueba fue con un lote de
diecisiete pedidos.

Como se mencion secciones atrs, las reglas se componen de dos partes principales:
antecedente y consecuente. El antecedente y el consecuente estn formados por tomos.
Los tomos comprenden predicados y los predicados argumentos. Los predicados pueden
ser descripciones de clases, propiedades y los argumentos variables o individuos. La
estructura de una regla queda como se muestra a continuacin:

Rule ([ATOM1 (PREDICATE1(ARG1 ,.., ARGN) , ..., ATOMN (PREDICATEN (ARG1, .., ARGN))]) => ([ATOM1
(PREDICATE1 (ARG1, .., ARGN)])

SWS1 wsMatriculate
Rule [New_Student (nt), Notice (n)] => [NoticeOf (n, nt)]
Input {New_Student (a), Notice (n)}
Output {Notice (n)}
Descripcin: realiza la inscripcin en la facultad de un nuevo estudiante recibiendo los datos del nuevo
estudiante y una nota de inscripcin. El servicio retorna una nota de inscripcin realizada (de tipo nota de
graduado o de tipo nota de no graduado).

SWS2 wsInscribeJobBag
Rule [Curriculum(c), NoticeOf (n, nt)] => [hasJobPostulant (nt, jp)]
Input {Notice (n)}, Curriculum (c)}
Output {JobPostulant (jp)}
Descripcin: realiza la inscripcin en la bolsa de trabajo de un nuevo estudiante recibiendo un curriculum y
la nota de inscripto en la facultad. El servicio retorna el registro de inscripcin en la bolsa de trabajo (de tipo
postulacin de trabajo).

SWS3 wsPostulateJobG
Rule [JobPostulantOf (jp, nt), hasNotice (nt, notice_graduate)] => [hasPostulationProfessionalJob (nt, pprof)]
Input {JobPostulant (jp), JobOfferProfessional (joprof)}
Output {PostulationProfessionalJob (pprof)}
Descripcin: realiza la postulacin de trabajo profesional de un nuevo estudiante graduado recibiendo la oferta
de trabajo profesional elegida y el registro de inscripto en la bolsa de trabajo. El servicio retorna un registro con
la postulacin a la oferta de trabajo profesional realizada (de tipo postulacin de trabajo profesional).

SWS4 wsPostulateJobU
Rule [JobPostulantOf (jp, nt), NoticeOf (notice_undergraduate, nt)] => [hasPostulationPassantJob (nt, ppas)]
Input {JobPostulant (jp), JobOfferPassant (jopas)}
Output {PostulationProfessionalJob (pprof)}
Descripcin: realiza la postulacin de pasanta de un nuevo estudiante no graduado recibiendo la oferta de

114
 75.00 Tesis
pasanta elegida y el registro de inscripto a la bolsa de trabajo. El servicio retorna un registro con la postulacin
a la oferta de pasanta realizada (de tipo postulacin de pasanta).

La primera prueba (reportCompositeServiceRequest10) fue un pedido de servicio por una

nota de inscripcin presentando los datos del nuevo estudiante. El agente determin que el
pedido poda ser resuelto por un servicio, el servicio wsMatriculate pero que como el pedido
era incompleto y no cumpla las reglas no poda ser ejecutado. Faltaba la presentacin de una
nota como entrada.

La segunda prueba (reportCompositeServiceRequest11) fue un pedido de servicio por una

nota de inscripcin presentando los datos del nuevo estudiante y una nota. El agente
determin que el pedido poda ser resuelto por un servicio, el servicio wsMatriculate el cual
poda ser ejecutado porque el pedido era completo y cumpla con las reglas del servicio.

SWScompuesto = SWSsimple = {wsMatriculate}

ABoxpedido= { INPUT {x1 (Student), x2 (Notice)},

OUTPUT {x2 (Notice)}
}

ABoxinferido= { x1 (Student) superclass nt (New_Student),

x2 = n (Notice)
}

El reporte reportRunTimeServiceRequest11 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

La tercera prueba (reportCompositeServiceRequest20) fue un pedido de servicio para

realizar una postulacin de trabajo profesional presentando una nota y un curriculum. El
agente determin que el pedido poda ser resuelto por dos servicios, los servicios
wsInscribeJobBag y wsPostulateJobG pero que como el pedido era incompleto y no cumpla
las reglas no poda ser ejecutado. Faltaba la presentacin de la oferta de trabajo profesional a
la cual postulaba.

La cuarta prueba (reportCompositeServiceRequest21) fue un pedido de servicio para

realizar una postulacin de trabajo profesional presentando una nota, un curriculum y la
oferta de trabajo profesional elegida. El agente determin que el pedido poda ser resuelto
por los servicios wsInscribeJobBag y wsPostulateJobG pero que como el pedido no cumpla
las reglas no poda ser ejecutado. La regla asociada del servicio wsInscribeJobBag estableca la
existencia de una nota de graduado inscripto.

La quinta prueba (reportCompositeServiceRequest22) fue un pedido de servicio para

realizar una postulacin de trabajo profesional presentando una nota de graduado, un
curriculum y la oferta de trabajo profesional elegida. El agente determin que el pedido poda
ser resuelto por dos servicios, los servicios wsInscribeJobBag y wsPostulateJobG los cuales
podan ser ejecutados porque el pedido era completo y por cumplir con las reglas de los
servicios.

SWScompuesto = {wsInscribeJobBag, wsPostulateJobG}

ABoxpedido= { INPUT {x1 (Curriculum), notice_graduate (Notice),

x2 (JobOfferProfessional)},
115
 75.00 Tesis
OUTPUT {x7 (PostulationProfessionalJob)}
}

ABoxinferido= { x6 = x3 = notice_graduate = n (Notice),

x1 = c (Curriculum), gd (Graduate) = nt (New_Student),
x4 = jp (JobPostulant),
x7 = pprof (PostulationProfessionalJob)
}

El reporte reportRunTimeServiceRequest22 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

La sexta prueba (reportCompositeServiceRequest30) fue un pedido de servicio para realizar

una postulacin de pasanta presentando un curriculum y la oferta de trabajo elegida. El
agente determin que el pedido poda ser resuelto por tres servicios, los servicios
wsMatriculate, wsInscribeJobBag y wsPostulateJobU pero que como el pedido era
incompleto y no cumpla las reglas no poda ser ejecutado. Faltaba la presentacin de los datos
del nuevo estudiante y una nota de inscripcin.

La sptima prueba (reportCompositeServiceRequest31) fue un pedido de servicio para

realizar una postulacin de pasanta presentando un curriculum, la oferta de trabajo elegida y
una nota de inscripcin. El agente determin que el pedido poda ser resuelto por dos
servicios, los servicios wsInscribeJobBag y wsPostulateJobU pero como el pedido no cumpla
las reglas no poda ser ejecutado. La regla del servicio wsInscribeJobBag exiga la existencia
de una nota de no graduado inscripto.

La octava prueba (reportCompositeServiceRequest32) fue un pedido de servicio para

realizar una postulacin de pasanta presentando un curriculum, la oferta de trabajo elegida y
una nota de no graduado. El agente determin que el pedido poda ser resuelto por dos
servicios, los servicios wsInscribeJobBag y wsPostulateJobU los cuales podan ser ejecutados
porque el pedido era completo y por cumplir con las reglas de los servicios.

SWScompuesto = {wsInscribeJobBag, wsPostulateJobU}

ABoxpedido= { INPUT {x1 (JobOffer), x2 (Curriculum),

notice_undergraduate (Notice)},
OUTPUT {x7 (PostulationPassantJob)}
}

ABoxinferido= { x2 = c (Curriculum),
x3 = x6 = notice_undegraduate = n (Notice),
x4 = jp (JobPostulant), ug (UnderGraduate) = nt (New_Student),
x7 = pprof (PostulationProfessionalJob)
}

El reporte reportRunTimeServiceRequest32 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

La novena prueba (reportCompositeServiceRequest40) fue un pedido de servicio por una

nota de inscripcin de no graduado presentando los datos del nuevo estudiante. El agente

116
 75.00 Tesis
determin que el pedido poda ser resuelto por un servicio, el servicio wsMatriculate pero
que como el pedido era incompleto, el servicio no poda ser ejecutado. Faltaba la
presentacin de una nota.

La dcima prueba (reportCompositeServiceRequest41) fue un pedido de servicio por una

nota de inscripcin de no graduado presentando los datos del nuevo estudiante y una nota de
no graduado. El agente determin que el pedido poda ser resuelto por un servicio, el
servicio wsMatriculate, el cual poda ser ejecutado porque el pedido era completo y cumpla
con las reglas del servicio.

SWScompuesto = SWSsimple = {wsMatriculate}

ABoxpedido= { INPUT {x1 (New_Student), notice_undergraduate (Notice)},

OUTPUT {notice_undergraduate (Notice)}
}

ABoxinferido= { x1 = ug (UnderGraduate) = nt (New_Student),

x2 = x3 = notice_undegraduate = n (Notice)
}

El reporte reportRunTimeServiceRequest41 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

La undcima prueba (reportCompositeServiceRequest50) fue un pedido de servicio por una

nota de inscripcin de no graduado y la inscripcin a la bolsa de trabajo de la facultad
presentando los datos del nuevo estudiante y un curriculum. El agente determin que el
pedido poda ser resuelto por dos servicios, el servicio wsMatriculate y el servicio
wsInscribeJobBag pero que como el pedido era incompleto y no cumpla las reglas no poda
ser ejecutado. Faltaba la presentacin de una nota.

La duodcima prueba (reportCompositeServiceRequest51) fue un pedido de servicio por

una nota de inscripcin de no graduado y la inscripcin a la bolsa de trabajo de la facultad
presentando los datos del nuevo estudiante, un curriculum y una nota de no graduado. El
agente determin que el pedido poda ser resuelto por dos servicios, el servicio
wsMatriculate y el servicio wsInscribeJobBag, los cuales podan ser ejecutados porque el
pedido era completo y cumpla con las reglas del servicio.

SWScompuesto = {wsMatriculate, wsInscribeJobBag}

ABoxpedido= { INPUT {x1 (New_Student), x2(Curriculum),

notice_undergraduate (Notice)},
OUTPUT {notice_undergraduate (Notice), x6 (JobPostulant)}
}
ABoxinferido= { x1 = ug (UnderGraduate) = nt (New_Student),
x2 = c (Curriculum),
x5 = x4 = x3 = notice_undegraduate = n (Notice),
x6 = jp (JobPostulant)
}

El reporte reportRunTimeServiceRequest51 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

117
 75.00 Tesis
La decimotercera prueba (reportCompositeServiceRequest60) fue un pedido de servicio
para realizar una postulacin de pasanta presentando la inscripcin a la bolsa de trabajo y la
oferta de pasanta elegida. El agente determin que el pedido poda ser resuelto por un
servicio, el servicio wsPostulateJobU pero que como el pedido no cumpla la regla del
servicio no poda ser ejecutado. Faltaba la existencia de una nota de no graduado inscripto.

La decimocuarta prueba (reportCompositeServiceRequest61) fue el pedido de servicio para

realizar una postulacin de trabajo de pasanta presentando una inscripcin a la bolsa de
trabajo, la oferta de pasanta y los datos del nuevo estudiante no graduado. El agente
determin que el pedido poda ser resuelto por un servicio, el servicio wsPostulateJobU
pero no poda ser ejecutado porque no se cumpla la regla asociada con el servicio. Faltaba la
presentacin de una nota de no graduado inscripto.

La decimoquinta prueba (reportCompositeServiceRequest62) consisti de un pedido de

servicio para realizar la postulacin a una oferta de pasanta presentando la oferta de
pasanta, el registro de inscripto en la bolsa de trabajo y una nota de no graduado. El agente
determin que el pedido poda ser resuelto por un servicio, el servicio wsPostulateJobU el
cual poda ser ejecutado porque el pedido era completo y cumpla con las reglas de los
servicios.

SWScompuesto = SWSsimple = {wsPostulateJobU}

ABoxpedido= { INPUT {x1(JobPostulant), x2(JobOfferPassant),

notice_underGraduate (Notice)},
OUTPUT {x4 (PostulationPassantJob)}
}

ABoxinferido= { x1 = jp (JobOfferPassant),
x3 = notice_underGraduate = n (Notice),
x4 = ppas (PostulationPassantJob),
ug (UnderGraduate) = nt (NewStudent)
}

El reporte reportRunTimeServiceRequest62 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

La decimosexta prueba (reportCompositeServiceRequest70) consisti de un pedido de

servicio para realizar la postulacin a una oferta de trabajo profesional presentando los datos
del nuevo estudiante, una nota de inscripcin de graduado, un curriculum y la oferta de
trabajo profesional elegida. El agente determin que el pedido poda ser resuelto por tres
servicios, el servicio wsMatriculate, wsInscribeJobBag y wsPostulateJobG los cuales podan
ser ejecutados porque el pedido era completo y cumpla con las reglas de los servicios.

SWScompuesto = {wsMatriculate, wsInscribeJobBag, wsPostulateJobG}

ABoxpedido= { INPUT {x1(Curriculum), x2(JobOfferProfessional),

x3(New_Student), x6 = notice_graduate (Notice)},
OUTPUT {x10 (PostulationProfessionalJob)}
}

ABoxinferido= { x1 = c (Curriculum),

118
 75.00 Tesis
x3 = gd (Graduate)= nt (New_Student),
x4 = x7 = x8 = x9 = notice_graduate = n (Notice),
x5 = jp (JobPostulant),
x10 = pprof (PostulationProfessionalJob)
}

El reporte reportRunTimeServiceRequest70 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

La decimosptima prueba (reportCompositeServiceRequest80) consisti de un pedido de

para realizar la postulacin a una oferta de pasanta y de una nota de inscripcin presentando
los datos del nuevo estudiante, una nota de inscripcin de no graduado, un curriculum y la
oferta de pasanta elegida. El agente determin que el pedido poda ser resuelto por tres
servicios, el servicio wsMatriculate, wsInscribeJobBag y wsPostulateJobU los cuales podan
ser ejecutados porque el pedido era completo y cumpla con las reglas de los servicios.

SWScompuesto = {wsMatriculate, wsInscribeJobBag, wsPostulateJobU}

ABoxpedido= { INPUT {x1(Curriculum), x2(JobOfferPassant),

x3(New_Student), x6 = notice_undergraduate (Notice)},
OUTPUT {x4(Notice), x10 (PostulationPassantJob)}
}

ABoxinferido= { x1 = c (Curriculum),
x3 = ug (UnderGraduate)= nt (New_Student),
x4 = x7 = x8 = x9 = notice_undergraduate = n (Notice),
x5 = jp (JobPostulant),
x10 = ppas (PostulationPassantJob)
}

El reporte reportRunTimeServiceRequest80 con la ejecucin del servicio compuesto se

puede ver en el directorio test/r2.

Para la composicin de servicios el agente fue provisto con el razonador Pellet 2.2.1
desarrollado en la clase ReasonerEngine.java y utilizado por la clase Compositor.java. La
primera otorga al agente la capacidad de realizar inferencias y de encontrar relaciones de
tipo superclase, subclase, subsumido entre entradas y salidas de los servicios y de los pedidos,
todas marcadas con clases o instancias de la ontologa StudentsJobBag.owl. La segunda
otorga al agente la capacidad de componer los servicios para el pedido recibido, utilizando la
clase ReasonerEngine, el algoritmo de backward-chaining y los algoritmos de verificacin de
reglas (DL-Safe Rules).

Se pueden observar en las pruebas la utilizacin de clases superiores de la ontologa como la

clase JobOffer definida, en la ontologa, como superclase directa de las clases JobOfferPassant
y JobOfferProfessional y aceptada ontolgicamente como entrada vlida de los servicios
wsPostulateJobU y wsPostulateJobG respectivamente. De la misma manera, se puede
observar la utilizacin de la instancia notice_graduate, miembro de la clase Notice para
solicitar una nota de inscripcin particular y aceptada ontolgicamente como entrada vlida
de los servicios que requiren una nota para ejecutar un pedido.

Los algoritmos de verificacin de reglas hacen uso de la inferencia permitiendo controlar la

119
 75.00 Tesis
ejecucin correcta de los servicios. En varias pruebas, por ejemplo, al presentar una nota de
graduado, el razonador infera inmediatamente que la instancia gd perteneca a la clase
Graduate y que era igual a la instancia nt de la clase New_Student por tener una nota de
graduado. Con esto satisfaca parte de la regla asociada al SWS wsPostulateJobG. Los axiomas
considerados fueron:

Graduate hasNotice value notice_graduate

en la ontologa StudentsJobBag.owl

gd (hasNotice notice_graduate)
en la ontologa members StudentsJobBag.owl
Rule [JobPostulantOf (jp, nt), hasNotice (nt, notice_graduate)] => [hasPostulationProfessionalJob (nt, pprof)]
en la ontologa rulePostulateJobG.owl.

Inferencias similares fueron realizadas por el agente por medio del razonador DL en el resto
de las pruebas, como se puede observar en los reportes finales ubicados en el directorio test .

El marcado ontolgico de los SWS fue una aproximacin al funcionamiento general que
tendra la bolsa de trabajo de una facultad. Tal aproximacin fue determinante en la
elaboracin de las ontologas que permitieron agregar la semntica necesaria a los servicios
a fin de que el agente pudiera realizar la composicin dinmica de servicios como finalmente
fue presentado en esta seccin.

120
 75.00 Tesis
Captulo VI

Conclusiones y trabajos futuros

Los servicios Web fueron construidos adoptando estndares a fin de asegurar servicios
independientes de la tecnologa y capaces de interoperar con otros servicios Web.

WSDL y SOAP emplean tecnologas XML para 1) describir los contratos de servicio de los
servicios Web y 2) permitir la combinacin de tecnologas complejas en la construccin de
servicios Web.

Los contratos de servicios son ms valiosos que las implementaciones por representar
conocimiento vital de negocios, son el mecanismo primario para reducir acoplamiento de
interfaz y la base para compartir y reutilizar servicios por lo cual deben ser manejados como
un artefacto separado, utilizando un mecanismo formal de extensin y versionado que
permita controlar dependencias y costos.

Los servicios requieren de un cambio radical en la manera de pensarlos. Para esto, el

desarrollo orientado a servicios plantea una divisin de responsabilidades donde surgen los
roles del analista de negocios y el tcnico. El primero es responsable de montar flujos de
procesos a fin de asegurar el cumplimiento de requerimientos operacionales y estratgicos
de negocios. El segundo es responsable de manejar la complejidad de tecnologas en el
despliegue de servicios, asegurar que las descripciones XML/Web son las que el usuario
necesita y determinar los datos correctos a compartir.

Un servicio es un activo que establece prestaciones y calidad a travs de contratos de servicio.

Un servicio Web es funcionalidad disponible en la Web segn estndares estipulados (SOAP,
WSDL, UDDI) a fin de garantizar interoperabilidad. Un servicio Web semntico posee
descripciones realizadas por ontologas las cuales agregan un nivel ms de procesamiento a
fin de optimizar el ciclo de descubrimiento, seleccin, invocacin y composicin de los
servicios Web.

Los servicios Web son recursos Web y son capturados en trminos de tareas, las cuales
combinan el concepto de accin con intencin: los servicios Web son invocados con un
propsito, que puede ser expresado como un objetivo de estado deseado.

Una ontologa es una semntica formal la cual por describir el significado del conocimiento
de manera precisa logra una interpretacin nica por parte de mquinas y personas.
Disponer de una semntica formal resulta imprescindible para implementar sistemas de
inferencia o de razonamiento automtico

Las ontologas actan como una herramienta para compartir informacin y conocimiento, y
por lo tanto, para conseguir interoperabilidad semntica. Las ontologas asisten a la Web
Semntica por unificar contenidos semnticos y formalizar conocimiento consensuado y
reutilizable. Brindan ventajas como el desarrollo de aplicaciones con esquemas de datos
compartidos, el impulso de transacciones entre empresas y la bsqueda de informacin por
inferencias.

121
 75.00 Tesis
Las mquinas son capaces de inferir, mediante procesos lgico-matemticos, conclusiones a
partir de datos representados en un lenguaje formal (lgico y axiomtico). Representar los
datos en un lenguaje formal posibilita que las mquinas puedan realizar inferencias lgicas.

Al anotar las descripciones de los servicios Web con ontologas, se consigue mayor
automatizacin, reduciendo el involucramiento humano en la comprensin datos y
funciones de servicios.

Entre los lenguajes ontolgicos, OWL presta el mejor soporte de razonamiento al proveer
mayor poder expresivo y promover motores de inferencia.

El desarrollo y aplicacin de ontologas depende de razonamiento. Un razonador es un

componente clave para trabajar con ontologas OWL DL. Los razonadores DL verifican
subsuncin, consistencia y satisfactibilidad de ontologas, entre otras.

En el proceso de inferencia, cada pieza de informacin tiene la capacidad de producir nueva

informacin. Dicho proceso es vulnerable al fenmeno garbage in, garbage out y por ello
se deben aplicar cuidados extras a fin de validar la informacin inferida.

La composicin automtica por medio de servicios Web semnticos es conseguida con

ontologas cuidadosamente construidas las cuales reflejen los objetivos de dominio. El proceso
de desarrollo de una ontologa es un proceso iterativo, compuesto de sucesivas
aproximaciones interviniendo en l expertos de dominio hasta conseguir una versin final
de la misma. Este proceso iterativo se extiende a lo largo del ciclo de vida de la ontologa.
Varias metodologas generales existen para desarrollar ontologas, destacndose Diligence,
Competency Questions, Methontology, On-To-Knowledge [Contreras y Comeche; 2007].

La combinacin de agentes y servicios fue realizada en un escenario donde los SW proveen la

funcionalidad de bajo nivel y los agentes la funcionalidad de alto nivel por utilizar, combinar y
coreografiar SW, obteniendo funciones de valor agregado. El agente construido rene las
soluciones ms recientes y distinguidas en relacin a los avances en la composicin de
servicios Web, a saber: implementado segn la recomendacin SAWSDL del W3C (extensin
semntica de WSDL) posee la capacidad de servirse de la informacin provista por servicios
Web semnticos para 1) determinar de qu categora el servicio es miembro reduciendo
costos asociados con la bsqueda de servicios; 2) realizar la correcta utilizacin de los SWS
por incorporar reglas DL-Safe en las operaciones de SWS y 3) utilizar las ontologas
construidas correspondientes al dominio de datos asociado con la actividad dentro de la
categora a la cual pertenecen los servicios.

Respecto del caso prctico, desde el punto de vista ontolgico, 1) las limitaciones impuestas al
incorporar reglas DL-Safe y una ontologa con una base de conocimiento formada por un
TBox acclico y 2) los beneficios otorgados por la eleccin de un razonador DL posibilit al
agente en el primer caso aprovechar la mayor expresividad ofrecida por OWL y en el
segundo, mejorar la bsqueda de servicios al considerar las relaciones semnticas de los
contratos de servicios.

Para ejecutar la composicin de servicios, el agente fue implementado con el algoritmo de

backward-chaining para analizar los tipos de asociacin entre entradas y salidas de servicios
y seleccionar aquellos que resolvieran el pedido. Adems, para dotar al agente con la
capacidad de componer servicios se considero en el diseo de los servicios el formalismo de
122
 75.00 Tesis
acciones desarrollado por [Baader et al.; 2005] quienes basaron en lgica descriptiva y
razonamiento de acciones la descripcin de funcionalidad de los SW.

Como trabajo futuro queda investigar la posibilidad de ampliar los tipos de asociacin
empleados en la composicin de servicios con el fin de mejorar provisin de servicios,
investigar heursticas del algoritmo de backward-Chaining, estudiar la capacidad del agente
para componer servicios en un MAS (sistema distribuido), innovar con la mediacin de
ontologas al indicar en nuevas ontologas equivalencias de clases y de individuos entre las
ontologas que acompaan los SWS. Las ontologas obtenidas deberan ser sencillas y de
carcter pblico.

123
 75.00 Tesis
Glosario

PLATAFORMA
Una plataforma es una base slida sobre la cual construir algo. Puede estar basada sobre
estndares y especificaciones, siendo su grado de apertura a los mismos y la adherencia a ella
por parte de vendedores IT, de considerable importancia. Como ejemplos de plataformas
basadas en especificaciones y estndares se encuentran la plataforma de aplicacin Web
(navegadores, URLs, HTML, CSS y HTTP/S), J2EE y CORBA. Por otro lado, los estndares de
servicios Web (SOAP, WSDL) son elementos claves de ella (pueden ser extendidos utilizando
otros estndares a fin de ajustar requerimientos especficos de negocios, de la industria o de
la organizacin).

URL
RFC 1738137. Los recursos disponibles en Internet son representados mediante secuencias
de caracteres llamadas Uniform Resource Locators (URL).

Los URL son utilizados para localizar recursos. Proveen un identificador abstracto de la
ubicacin de un recurso. Un URL es escrito como sigue:

<scheme>:<scheme-specific-part>

El URL contiene el nombre del esquema empleado seguido por dos puntos y una secuencia
cuya interpretacin depende del esquema. Los componentes de la jerarqua son separados
mediante /.

URL cubre los siguientes esquemas, adems de permitir la especificacin de esquemas

futuros:

FTP: File Transfer Protocol,

HTTP: Hypertext Transfer Protocol,

GOPHER: protocolo Gopher,

MAILTO: Electronic Mail Address,

NEWS: USENET NEWS,

NNTP: USENET NEWS utilizando acceso NNTP,

TELNET: Referencia a sesiones interactivas,

WAIS: Wide Area Information Servers,

FILE: nombre especfico de un archivo en un host y

PROSPERO: directorio de servicios PROSPERO.

137
http://www.faqs.org/rfcs/rfc1738.html

124
 75.00 Tesis
En algunos casos, los URL son utilizados para localizar recursos que contienen punteros a
otros recursos. Esos punteros son representados como enlaces relativos donde la expresin
de ubicacin del segundo recurso est en trminos del primero.

Mientras que el esquema elegido determina la sintaxis del resto del URL, los protocolos
basados en el protocolo IP para especificar un host en Internet utilizan una sintaxis comn
para datos especficos del esquema:

//<user>:<password>@<host>:<port>/<url-path>.

Los datos especficos del esquema comienzan con una doble barra // para indicar su
conformidad con la sintaxis comn de esquemas en Internet. Los componentes usuario y
clave son opcionales, host corresponde al nombre de dominio completo de un host en
Internet, port al nmero de puerto para conectarse y url-path a los datos especficos del
esquema.

El URL con esquema HTTP determina recursos de Internet accesibles utilizando HTTP. Un
URL HTTP es

http://<host>:<port>/<path>?<searchpart>

El valor por defecto de port es 80, <path> representa un selector HTTP y <searchpart> una
cadena de consulta. Los dos ltimos son opcionales y dentro de ellos los caracteres /, ;, ?
son reservados. El carcter / puede ser utilizado dentro de HTTP para designar la estructura
jerrquica.

El URL con esquema file es utilizada para indicar archivos accesibles sobre un host
particular. Este esquema, a diferencia de los otros esquemas de URL, no representa un
recurso universalmente accesible en Internet. Un URL file es

file://<host>/<path>

La parte <host> es el nombre de dominio completo del sistema sobre el cual el path es
accesible y <path> es la jerarqua de directorios.

Un caso especial de <host> es la cadena localhost o la cadena vaca, donde ambas son
interpretadas para referir a la mquina donde el URL es interpretado.

125
 75.00 Tesis
URI
RFC 3986138. El Uniform Resource Identifier (URI) es una secuencia compacta de caracteres
que identifica un recurso abstracto o fsico. La especificacin define la sintaxis genrica del
URI y un proceso para resolver las referencias URI que podran estar en forma relativa, junto
con pautas y consideraciones de seguridad para la utilizacin de URIs en Internet. La sintaxis
URI define una gramtica que es un superconjunto de todos los URIs vlidos, posibilitando
implementar un analizador sintctico de los componentes comunes de una referencia URI,
sin conocer los requerimientos especficos de esquema. La especificacin no define una
gramtica para URIs; esa tarea es ejecutada por las especificaciones individuales de cada
esquema URI.

Un URI es caracterizado como sigue:

Uniform: provee varios beneficios. Permite que diferentes tipos de identificadores de

recursos puedan ser utilizados en el mismo contexto, an cuando los mecanismos
utilizados para acceder a esos recursos puedan diferir. Esto permite una interpretacin
semntica uniforme de convenciones sintcticas comunes, a travs de diferentes tipos de
identificadores de recursos. Permite la introduccin de nuevos tipos de identificadores de
recursos sin interferir con los identificadores existentes. Permite la reutilizacin de los
identificadores en diferentes contextos, brindando a las aplicaciones la posibilidad de
aprovechar un conjunto de identificadores ampliamente utilizados.

Resource: la especificacin no limita el alcance de lo que puede ser un recurso sino que el
trmino es utilizado en un sentido ms general para cualquier cosa que pueda ser
identificado por un URI como un documento electrnico, una imagen, un servicio, etc. Un
recurso no es necesariamente accesible desde Internet (personas, empresas, libros). Del
mismo modo, los conceptos abstractos pueden ser recursos (operadores en una operacin
matemtica, tipos de relacin o valores numricos).

Identifier: incorpora informacin para distinguir aquello que est siendo identificado.

Un URI es un identificador consistente de una secuencia de caracteres que sigue las reglas
definidas por la especificacin. Permite la identificacin uniforme de recursos por medio de
un conjunto extensible de esquemas de nombres. Cada esquema debe determinar cmo
acompaar la identificacin, asignarla o habilitarla.

Los URIs tienen alcance global y son interpretados consistentemente sin importar el
contexto, aunque el resultado de esa interpretacin podra estar en relacin al contexto del
usuario final139. Sin embargo, una accin puede ser realizada sobre la base de que la
referencia tomar lugar en relacin al contexto del usuario final, lo cual implica que una
accin que intenta referir a una cosa nica globalmente debe utilizar un URI que diferencie
ese recurso de todas las otras cosas. Los URIs que identifican en relacin al contexto local del
usuario final deberan ser utilizados slo cuando el contexto mismo es un aspecto definido
del recurso140.

Cada URI comienza con un esquema, que posee su especificacin para asignar

138 http://www.faqs.org/rfcs/rfc3986.html
139
http://localhost tiene la misma interpretacin para cada usuario final de esa referencia, aunque la interfaz de
red correspondiente a localhost puede ser diferente para cada usuario final: la interpretacin es
independiente del acceso
140
Como un manual de ayuda on-line que apunta a un archivo en el sistema de archivos del usuario final
(file:///etc/hosts).
126
 75.00 Tesis
identificadores dentro de ese esquema. As la sintaxis URI, es un sistema de nombres federado
y extensible, donde cada especificacin de esquema puede restringir la sintaxis y semntica
de los identificadores utilizados en el esquema.

Esta especificacin define los elementos de la sintaxis URI requeridos por todos los esquemas
URIs o comunes a muchos esquemas URIs. Define la sintaxis y semntica necesaria para
implementar un analizador sintctico independiente del esquema, por el cual los manejos
dependientes del esquema de un URI pueden ser pospuestos hasta que la semntica
dependiente del esquema sea requerida.

La sintaxis URI genrica consiste de una secuencia de componentes jerrquicos, a saber,

esquema, autoridad, path, query y fragmento.

URI = scheme : hier-part [? query] [# fragment]

hier-part = // autoridad
/ path-absolute
/ path-rootless
/ path-empty

Los componentes path y esquema son requeridos, aunque el path puede estar vaco. Cuando
la autoridad est presente, el path debe empezar con el carcter / o puede estar vaco.
Cuando la autoridad no est presente, el path no puede empezar con los caracteres //.

La especificacin detalla los caracteres, los componentes de la sintaxis, los usos, la resolucin
por referencia, normalizacin y comparacin, entre otras. Ac hemos mencionado slo
algunas partes con el propsito de aclarar y diferenciar lo que URI representa.

IRI

RFC 3987141. El Internationalized Resource Identifier (IRI) extiende la sintaxis URI con un
repertorio ms amplio de caracteres.

El URI es una secuencia de caracteres limitada a un subconjunto dentro del repertorio de

caracteres US-ASCII. Los caracteres en el URI representan palabras en lenguaje natural. Esta
utilizacin tiene varias ventajas: son ms fciles de memorizar, de interpretar, transcribir,
crear y adivinar. Para otros lenguajes diferentes del ingls, un script en lenguaje natural
utiliza caracteres distintos que no estn dentro del rango de caracteres A-Z. Para muchas
personas manejar caracteres en Latn es tan difcil como lo sera para las personas que slo
manejan caracteres del alfabeto latino scripts con otros caracteres. Scripts en otros lenguajes
son transcriptos al latn. Estas transcripciones, con frecuencia, son utilizadas en URIs pero
con la introduccin adicional de ambigedades. La infraestructura para la correcta utilizacin
de caracteres en los scripts locales es provista por sistemas operativos y aplicaciones de
software que pueden manejar simultneamente una amplia variedad de scripts y lenguajes.
El incremento en el nmero de protocolos y formatos conduce a un amplio rango de
caracteres. Por este motivo, la RFC define un nuevo elemento de protocolo, llamado
Internationalized Resource Identifier (IRI) como un complemento del URI. Una IRI es una
secuencia de caracteres del conjunto universal de caracteres (Unicode/ISO 10646). Los IRIs
pueden ser utilizados en lugar de los URIs cuando sea necesario gracias al mapeo definido
por la RFC entre IRI y URI.

141 http://tools.ietf.org/html/rfc3987

127
 75.00 Tesis
Los IRIs han sido diseados para ser compatibles con los URIs. Esta compatibilidad es la
especificacin de mapeos entre una secuencia de caracteres IRI y una secuencia de
caracteres URI.

La RFC describe los mapeos IRIs a URIs, conversin URIs a IRIs, utilizacin de los IRIs, pautas
para el procesamiento IRI y URI, entre otras.

128
 75.00 Tesis
Referencias
http://hermit-reasoner.com/
HermiT OWL Reasoner
http://owlapi.sourceforge.net/index.html
The OWl API
http://www.w3.org/2001/sw/Activity.html
Herman I. 2010, ltima revisin. Semantic Web Activity Statement.
Rodrguez C. M., Montao W. C., Martnez J.M. 2010. Razonadores semnticos: en estado del
arte. Revista Ingenium de la Facultad de Ingeniera, Universidad de San Buenaventura,
Bogot, Colombia. Ao 11. N 21. Enero-Junio de 2010.
http://jena.sourceforge.net/ontology/index.html
Dickinson I. 2009. Jena Ontology API.
http://www.w3.org/2001/sw/SW-FAQ
Herman I. 2009, ltima revisin. W3c Semantic Web Frequently Asked Questions.
http://www.w3.org/standards/techs/owl#w3c_all
W3C. 2009. OWL Web Ontology Language Current Status.
http://lsdis.cs.uga.edu/projects/meteor-s/
METEOR-S: Semantic Web Services and Processes.
http://www.w3.org/2002/ws/sawsdl/
Semantic Annotations for WSDL Working Group
Garca-Snchez F., Valencia-Garca R., Martnez-Bjar R., Fernndez-Breis J. 2009. An
ontology, intelligent agent-based Framework for the provision of semantic web service.
Expert Systems with Applications Vol. 36, Issue 2, Part 2, March 2009. Pages 3167-3187.
Navoni N., Gonzlez P. 2009. Indizacin social y control de vocabulario. II Encuentro
Nacional de Catalogadores. La Cooperacin y las Normas para la Organizacin y Tratamiento
de la Informacin en las Bibliotecas Argentinas.
http://www.ibm.com/developerworks/webservices/library/ws-restwsdl/
Hebeler J., Fisher M., Blace R., Perez-Lopez A. 2009. Semantic Web Programming. 651
pginas. Editorial Wiley Publishing, Inc. ISBN 978-0-470-41801-7.
Mandel L. 2008. Describe REST Web Services with WSDL 2.0.
Ketel M. 2008. Mobile Agents Based Infrastructure for Web services Composition. 978-1-
4244-1884-8/08 IEEE.
Qiu Y., Ge J., Yin S. 2008. Web Services Composition Method Based on OWL. IEEE
International Conference on Computer Science and Software Engineering.
Mansilla Espinosa L. 2008. Qu son los Agentes Inteligentes de Software?. CONCYTEG. Ao
3. Nm. 31, 21 de enero de 2008.
Fahad, M., Qadir, M.A. and Shah, S.A.H., 2008. In IFIP International Federation for
Information Processing, Volume 288; Intelligent Information Processing IV; Zhongzhi Shi, E.
Mercier-Laurent, D. Leake; (Boston: Springer), pp. 1727.
Payne T. 2008. Web Services from Agent Perspective. IEEE Intelligent Systems. Vol. 23. Nro.
2.

129
 75.00 Tesis
Contreras J., Martnez Comeche J.A. 2007. Tutorial Ontologas. Grupo de Trabajo sobre
Normalizacin para la Recuperacin de Informacin en Internet (Normaweb).
http://www.sedic.es/gt_normalizacion.asp
Thakker D., Osman T., Al-Dabass D. 2007. Semantic-Driven Matchmaking and Composition
of Web services Using Case-Based Reasoning. Fifth European Conference on Web services.
Yong-Feng L., Jason Jen-Yen C. 2007. OWL-Based Description for Agent Interaction. 31st
Annual International Computer Software and Applications Conference (COMPSAC 2007)
IEEE.
Akkiraju R., Sapkota B. 2007. Semantic Annotations for WSDL and XML Schema Usage
Guide. W3C Working Group.
http://www.w3.org/TR/sawsdl-guide/#registries
Berners-Lee T., Shadbolt N., Hall W. 2006. The Semantic Web Revisited. IEEE Intelligent
Systems.
Li Y., Yu X., Geng L. Wang L. 2006. Research on Reasoning of The Dynamic Semantic Web
Services Composition. Proceedings of the 2006 IEEE/WIC/ACM International Conference on
Web Intelligence (WI 2006 Main Conference Proceedings) (WI06)
Kster U., Stern M., Knig-Ries B. 2005. A Classification of Issues and approaches in
Automatic Service Composition. Intl. Workshop WESC05.
Elenius D., Denker G., Martin D., Gilham F., Khouri J., Sadaati S., Senanayake R. 2005. THE
OWL-S Editor A Development Tool for Semantic Web Services. Lecture Notes in Computer
Science, Vol. 3532/2005, 78-92. Springer Link.
Martin D., Paolucci M., McIlraith S., Burstein M., McDermott D., McGuinness D., Parsia B.,
Payne T., Sabou M., Solanki M., Srinivasan N., Sycara K. 2005. Bringing Semantics to Web
Services: The OWL-S Approach. SWSWPC 2004. LNCS 3387, pp. 26-42, 2005. Springer-
Verlag.
Battle S., Berstein A., Boley H., Grosof B., Gruniget M., Hull R., Kifer M., Martin D., Mcllraith S.,
McGuinness D., Su J., Tabet S. 2005. Semantic Web Services Framework (SWSF).
http://www.w3.org/Submission/SWSF/
Akkiraju R., Farrell J., Miller J., Nagarajan M., Schmidt M., Sheth A., Verma K. 2005. Web
Service Semantics WSDL-S.
http://www.w3.org/Submission/WSDL-S/#Terminology
Abin M. 2005. El Futuro de la Web, XML, RDF/RDFS, ontologas y la Web Semntica.
http://www.javahispano.org
Motik B., Sattler U., Studer R. 2005. Query Answering for OWL-DL with Rules. Web
Semantics: Science, Services and Agents on the World Wide Web, Volume 3, Issue 1, Rule
Systems, July 2005, Pages 41-60.
Baader F., Lutz C., Milicic M., Sattler U., Wolter F. 2005. Integrating Description Logics and
Action Formalisms for Reasoning about Web Services. LTCS-Report 05-02, Chair for
Automata Theory, Institute for Theoretical Computer Science, Dresden University of
Technology, Germany, 2005.
Miller J., Verma K., Rajasekaran P. Sheth A., Aggarwal R., Sivashanmugam K. 2004. WSDL-S
Adding Semantic to WSDL - White Paper. LSDIS Lab, University of Georgia.
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/
Manola F, Miller E. 2004. RDF Primer. http://www.w3.org/TR/2004/REC-rdf-primer-

130
 75.00 Tesis
20040210/#reification
Booth D., Haas H., McCabe F., Newcomer E., Campion M., Ferris C., Orchard D. 2004. Web
Services Arquitecture.
http://www.w3.org/TR/ws-arch/
Newcomer E.; Lomov G. 2004. Understanding SOA with Web Services. 480 Pags. Editorial
Addison Wesley Professional. ISBN 0-321-18086-0.
Sycara K., Paolucci M. 2004. Ontologies in Agent Arquitectures in Handbook on Ontologies
in Information Systems.
Aversano L., Canfora G., Ciampi A. 2004. An algorithm for Web Service Discovery through
their composition. Proceedings of the IEEE International Conference on Web Services
(ICWS04).
Aversano L., Canfora G., Ciampi A. 2004. An algorithm for Web Service Discovery through
their composition. Proceedings of the IEEE International Conference on Web Services
(ICWS04).
Rao J., Su X. 2004. A Survey of Automated Web Service Composition Methods. In Proceedings
of the First International Workshop on Semantic Web Services and Web Process
Composition, SWSWPC 2004.
Brickley D., Guha R.V. 2004. RDF Vocabulary Description Language 1.0: RDF Schema.
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/
Paolucci M., Sycara K. 2003. Autonomous Semantic Web Services. In IEEE Internet
Computing, vol. 7, #5, Septiembre/Octubre 2003, pp 34-41.
Paolucci M., Kawamura T., Payne T., Sycara K. 2003. Delivering Semantic Web Services. In
Proceedings of the Twelves World Wide Web Conference (WWW2003).
Salazar Serrudo C. 2003. Agentes en Comercio Electrnico. Acta Nova. Vol. 2. Num.3,
Diciembre 2003.
Paolucci M., Kawamura T., Payne T., Sycara K. 2002. Semantic Matching of Web Services
Capabilities. In Proceedings of the 1st International Semantic Web Conference (ISWC2002).
Huhns M. 2002. Agents as Web Services. IEEE Internet Computing Vol. 6. Nro. 4. Pag. 93-95
ISSN: 1089-7801.
Sirin E., Hendler J., Parsia B. 2002. Semi-Automatic Composition of Web Services using
Semantic Descriptions.
Sycara K., Lu J., Klusch M. 1998. Interoperability among Heterogeneous Software Agents on
the Internet. Technical Report CMU-RI-TR-98-22, CMU Pittsburgh, USA.
Wooldridge M. 1998. Intelligent Agents. In Gehard Weiss, editor, Multiagent Systems: A
modern Approach to Distributed Artificial Intelligence, chapter 1, pages 27-77. The MIT
Press, 1999.

131
 75.00 Tesis
Anexo I
El cdigo desarrollado para la construccin del prototipo se encuentra disponible en el cd que
acompaa el presente trabajo. Se recomienda ver los reportes en html utilizando algn navegador
(IE, Mozilla).

132
 75.00 Tesis
Anexo II

Objetivos

1) Aportar al rea de investigacin de la composicin dinmica de servicios una solucin

eficiente y efectiva.

2) Proveer a un agente, que habitualmente acta como un intermediario entre un usuario y

un proveedor, de informacin semntica acerca de los servicios que tiene registrados.

3) Utilizar ontologas apropiadas relacionadas a los servicios registrados para agregar

informacin semntica al agente.

4) Dotar al agente con la funcionalidad de establecer relaciones lgicas, realizar inferencias

a fin de poder vincular servicios de forma correcta para responder a un pedido que no puede
ser resuelto por un solo servicio sino por la combinacin de varios servicios.

5) Determinar un escenario de aplicacin representativo del problema a resolver.

6) Construir un prototipo para llevar a cabo los experimentos y elaborar las conclusiones
finales en relacin a los resultados obtenidos.

7) Utilizar estndares de la industria en relacin a la comunicacin entre servicios como

WSDL y SOAP.

8) Investigar alternativas de composicin semntica como OWL, Pellet, el algoritmo

backward-chaining.

9) Utilizar, preferentemente, herramientas open-source en la construccin de la solucin.

10)Investigar razonadores alternativos que puedan ser incorporados en el agente.

11)Brindar una breve resea acerca de los servicios Web y su creciente utilizacin, en
especial en una arquitectura orientada a servicios.

133