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.
75.00 Tesis 3 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 75.00 Tesis 4 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 75.00 Tesis 5 Objetivos ................................................................................................................................................................. 133
75.00 Tesis 6 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 [W3C 1 ; 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 Web 2 . 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 75.00 Tesis 7 (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-scraping 4 , 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 auctionbots 5 , 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 racionalizar 6 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. 75.00 Tesis 8 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 OWL 7 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. 75.00 Tesis 9 permanecen como potenciales entradas del proceso del W3C. Entre las primeras se encuentra el estndar SAWSDL 8 , 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 Institute 9 (SRI), y las universidades de Carnegie Mellon, Toronto, Southampton, Yale, entre otras; 2) WSMO, presentado en el ao 2005 por el WSMO Working Group 10 ; y 3) SWSF, presentado en el ao 2005, por Hewlett Packard (HP), el Massachusetts Institute of Technology 11 (MIT), el National Research Council of Canada 12 , 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 75.00 Tesis 10 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- grained 13 , 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 75.00 Tesis 11 La capa de lnea de negocios automatiza, de manera parcial o total, los servicios que una organizacin presta directa (propios) o indirectamente 14 (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 75.00 Tesis 12 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-Policy 15 . 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. 75.00 Tesis 13 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.
75.00 Tesis 14 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 stateful 16 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. 75.00 Tesis 15 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-BPEL 17 .
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 75.00 Tesis 16 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.
[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.
J2EE .NET
CORBA IMS
Implementacin de servicio / Agente ejecutable Usuario de servicio
Descripcin de servicio
Capa traductora (Mapping Layer)
Pedido de servicio
75.00 Tesis 17 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 legacy 18 (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. 75.00 Tesis 18
[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 75.00 Tesis 19 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 commit 19 . 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, middleware 20 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. 75.00 Tesis 20
[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 75.00 Tesis 21 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/response 21 , one-way asynchronous 22 o publish/subscribe 23 . 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. 75.00 Tesis 22
[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 snapshot 24 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. 75.00 Tesis 23 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 75.00 Tesis 24 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 75.00 Tesis 25 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 75.00 Tesis 26 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 brokering 25 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. 75.00 Tesis 27 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 gobierno 26 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. 75.00 Tesis 28 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 RESTful 27 , 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 BPEL 28 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. 75.00 Tesis 29 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. 75.00 Tesis 30
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 REST 30 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 CRUD 31 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. 75.00 Tesis 31 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. 75.00 Tesis 32 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, 75.00 Tesis 33 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 folksonomas 33 , las cuales son utilizadas principalmente dentro del contexto de la Web 2.0 34 .
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 tagging 35 de informacin y objetos 36 , 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 indizacin 37 , 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. 75.00 Tesis 34 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 herencia 38 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 backstage 39 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. 75.00 Tesis 35 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 humana 40 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 formal 41 , 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 definidas 42 ; 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 orden 43 . 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. 75.00 Tesis 36 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 LPO 44 (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 , GALEN 46 , el Foundational Modelo of Anatomy (FMA) 47 , el National Cancer Institute (NCI) Thesaurus 48 y el OBO Foundry 49 . 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/ 75.00 Tesis 37 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 OntoWeb 51 .
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 captions 52 o metatags 53 . 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 75.00 Tesis 38 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 computing 54 El ubiquitous computing es un paradigma emergente del personal computing 55 , 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. 75.00 Tesis 39 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 Web 56 , 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 URIs 57 .
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.
75.00 Tesis 40 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 LOO 58 , 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 concepto de clase en LOO rdfs:Class rdfs:Resource Toda cosa descripta por RDF es un recurso e instancia de rdfs:Resource rdfs:Class rdfs:Literal Clase para los literales rdfs:Class rdfs:Resource rdfs:Datatype Clase para los literales tipados como Datatype rdfs:Class rdfs:Literal 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 orden rdfs:Class rdfs:Container rdf:Alt Clase para indicar un contenedor donde slo se elige uno de los miembros. La eleccin por defecto es el valor de la property rdf:_1 rdfs:Class rdfs:Container rdf:List Clase para construir listas y otras estructuras rdfs:Class [Brickley y McBride; 2004]. Fragmento del vocabulario de clases de RDF Schema recomendado por el W3C.
58 Lenguajes orientados a objetos. 75.00 Tesis 41 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 que acepta una propiedad rdf:Property rdf:Property rdfs:Class rdfs:domain Dominio de clases vlidas sobre el que se aplica una propiedad rdf:Property rdf:Property rdfs:Class rdfs:type De que clase es instancia un recurso rdf:Property rdfs:Resource rdfs:Class rdfs:subClassOf Los recursos instancias de una clase son instancias de otra. Transitiva rdf:Property rdfs:Class rdfs:Class rdfs:subPropertyOf Los recursos instancias de una propiedad son instancias de otra. Transitiva rdf:Property rdf:Property rdf:Property rdfs:label Versin legible del nombre de rdf:subject. rdf:Property rdfs:Resource rdfs:Literal rdfs:comment versin legible de un recurso rdf:Property rdfs:Resource rdfs:Literal rdf:subject Sujeto de una tripla RDF. rdf:Property rdf:Statement rdfs:Resource rdf:predicate Predicado de una tripla RDF. rdf:Property rdf:Statement rdfs:Resource rdf:object Objeto de una tripla RDF. rdf:Property rdf:Statement rdfs:Resource rdfs:seeAlso Informacin adicional acerca de rdf:subject. rdf:Property rdfs:Resource rdfs:Resource rdfs:member Super-property de todas las properties miembro del contenedor rdf:Property rdfs:Resource rdfs:Resource rdfs:ContainerMem bershipProperty Tiene como instancias las 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:Property rdfs:Resource rdfs:Resource rdf:first Primer tem de una lista RDF rdf:Property rdf:List rdfs:Resource 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 75.00 Tesis 42 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 predicados 59 , 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 75.00 Tesis 43 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 DTD 60 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 B2B 61
(productos compatibles con especificaciones XML para el intercambio comercial desarrollados por organizaciones como OASIS 62 , ebXML 63 , RosettaNet 64 , 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/ 75.00 Tesis 44 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 XSLT 65 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 SI 66 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 75.00 Tesis 45 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
75.00 Tesis 46 Tabla trminos OWL para describir object-properties Object-Property Descripcin owl:objectProperty La clase de todas las propiedades que relacionan dos individuos owl:DataProperty La clase de todas las propiedades que relacionan un individuo con un valor literal owl:topObjectProperty Propiedad que conecta todos los posibles pares de individuos owl:bottomObjectProperty Propiedad que no conecta pares de individuos owl:topDataProperty Propiedad que conecta todos los posibles individuos con todos los posibles literales owl:bottomDataProperty Propiedad que no conecta ningn individuo con un literal owl:SymmetricProperty 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) owl:AsymmetricProperty 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) owl:equivalentProperty Propiedad que especifica que dos propiedades son equivalentes owl:ReflexiveProperty 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) owl:IrreflexiveProperty 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) owl:TransitiveProperty 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) owl:FunctionalProperty La clase de todas las propiedades para las cuales un valor de dominio dado tiene slo un valor de rango owl:InverseFunctionalProperty La clase de todas las propiedades para las cuales un valor de rango dado tiene slo un valor de dominio owl:inverseOf 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) owl:propertyChain Propiedad que es utilizada para construir una cadena de propiedades que representa la superproperty en una relacin subproperty-of Owl:propertyDisjointWith 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 owl:AllDisjointProperties Una clase que es utilizada con owl:members para describir colecciones de propiedades que son disjuntas por pares.
Tabla trminos OWL para describir data-properties Data-Property Descripcin owl:onDataType Propiedad que identifica el datatype al cual se aplican las restricciones owl:intersectionOf Propiedad que identifica un conjunto de datatypes tal que el datatype descripto contiene los valores contenidos en todos los datatypes del conjunto owl:unionOf 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 owl:oneOf Propiedad que identifica un conjunto de valores que conforman al datatype owl:datatypeComplementOf Propiedad que especifica que el datatype descripto contiene todos los valores que no estn en el datatype que la propiedad identifica
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 47 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. 75.00 Tesis 48 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. 75.00 Tesis 49 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). 75.00 Tesis 50 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.
75.00 Tesis 51 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 Framework 67 (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 Ontology 68 (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 Language 69 (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 Environment 70 (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 75.00 Tesis 52 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: 75.00 Tesis 53 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 Approach 71 , derivado del AI Racional Agent Approach 72 .
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 Services 73 (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+OIL 74 . 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 75.00 Tesis 54 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 BPEL4WS 75 y WSCI 76 , 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/ 75.00 Tesis 55 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 Semantic 77 el cual especifica el significado preciso de los conceptos.
La forma FOL de la ontologa es llamada FLOWS 78 y la ontologa resultante por trasladar sistemticamente axiomas FLOWS al lenguaje SWSL-Rules es llamada ROWS 79 .
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. 75.00 Tesis 56 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 agnstico 81 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. 75.00 Tesis 57 componente WSDL y un concepto en algn modelo semntico y 2) dos atributos de extensin, liftingSchemaMapping y loweringSchemaMapping 82 , 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 Assumption 84 (OWA) o como Open World Reasoning 85 (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 Assumption 86 (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. 75.00 Tesis 58 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 75.00 Tesis 59 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.
Racer 87 fue desarrollado en LISP 88 . 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 tableaux 89 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 75.00 Tesis 60 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 FZI 90 . 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/ 75.00 Tesis 61 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 Language 91 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 OWL 92 .
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 decidibilidad 93
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-theoretic 94 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. 75.00 Tesis 62 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 Failure 95 o NAF) o soportar el supuesto de individuos nicos 96 .
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. 75.00 Tesis 63 existen ontologas disponibles en el sitio Semantic Web 97 , en el sitio del laboratorio LSDIS del Departamento de Computacin de la Universidad de Georgia 98 , en DAML 99 , en el sitio del proyecto Co-Ode del Departamento de Computacin de la Universidad de Manchester 100 y por medio del buscador semntico Swoogle 101 (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.
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 75.00 Tesis 65 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
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. 75.00 Tesis 66 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.
75.00 Tesis 67
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.
75.00 Tesis 68
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 75.00 Tesis 69 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 OWL 102 (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/ 75.00 Tesis 70 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 75.00 Tesis 71 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)
}
75.00 Tesis 72 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.
75.00 Tesis 73 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.
75.00 Tesis 74
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).
75.00 Tesis 75
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.
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.
75.00 Tesis 77
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.
75.00 Tesis 78
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.
75.00 Tesis 79
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 75.00 Tesis 80
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.
75.00 Tesis 81 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]
[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. Autonomous Agents Software Agents Computational Agents Robotic Agents Biological Agents Artificial Life Agents Task-Specific Agents Entertaiment Agents Virus 75.00 Tesis 82 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 75.00 Tesis 83 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 75.00 Tesis 84 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 Language 103 (KQML) y Foundations for Intelligent Physical Agents-Agents Communication Language 104 (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- CommonKADS 105 , ZEUS 106 , GAIA 107 , MaSE 108 , INGENIAS 109 ).
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- pages 110 , 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. 75.00 Tesis 85 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: 75.00 Tesis 86 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.
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. 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 75.00 Tesis 87 Los servicios, en cambio, son procesos transitorios y stateless 111 , 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 Grid 112 se debi al desarrollo pragmtico de tecnologas, estndares, polticas, ontologas compartidas y plataformas que permiten la realizacin de entornos distribuidos.
[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. BIND SOAP ACL PUBLISH WSDL ACL FIND UDDI ACL Servicio broker Agente broker Proveedor de servicio Sistema multi-agente (servicio distribuido cooperativo) Usuario de servicio Agente de usuario Servicio
Agente 75.00 Tesis 88 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-based 113 ) 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. 75.00 Tesis 89 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 stateful 114 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 75.00 Tesis 90 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 factory 115 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 Group 116 (AWSI WG) trabaja en la idea de construir un middleware 117 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
75.00 Tesis 91 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.
[Mansilla Espinosa; 2008] Tipologa de agentes
Una vez que se han revisado las caractersticas de los agentes, es posible encontrar una Agent Tipology Interface Agents Colaborative Agents Information Agents Hybrid Agents Smart Agents Heteroeneous Agents Mobile Agents Reactive Agents 75.00 Tesis 92 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 BDI 118
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 75.00 Tesis 93 (Beliefs, Desires, Intentions) y BVG 119 (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, matchmakers 120 (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.
75.00 Tesis 94 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 75.00 Tesis 95 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 AI 121 , 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 75.00 Tesis 96 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 75.00 Tesis 97 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 75.00 Tesis 98 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 75.00 Tesis 99 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 75.00 Tesis 100 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 LGPL 122 .
Pellet fue desarrollado por el laboratorio Mindswap 123 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 KB 124 , es decir del par ABox y TBox 125 . 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 75.00 Tesis 101 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 dual 126 . 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. 75.00 Tesis 102 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. 75.00 Tesis 103 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 75.00 Tesis 104 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 75.00 Tesis 105 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(n 3 ) . 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, 75.00 Tesis 106 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.
75.00 Tesis 107 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.
75.00 Tesis 108 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.
75.00 Tesis 109 La ontologa de datos fue construida implementando un TBox acclico 127 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.
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. 75.00 Tesis 110 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 NAICS 128 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/ 75.00 Tesis 111 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 Process 129 ). 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 75.00 Tesis 112 Las descripciones WSDL de los servicios Web fueron obtenidas a partir de su cdigo en java con la herramienta java2wsdl 130 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 2011 131 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 wsdl2java 132 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 SAWSDL 133 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. 75.00 Tesis 113 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.
Jena 135 es un framework java, open-source, que creci como parte del Programa de la Web Semntica de los laboratorios HP 136 . 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 75.00 Tesis 114 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:
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 75.00 Tesis 115 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.
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.
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.
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 75.00 Tesis 117 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.
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.
El reporte reportRunTimeServiceRequest51 con la ejecucin del servicio compuesto se puede ver en el directorio test/r2. 75.00 Tesis 118 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.
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.
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.
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 75.00 Tesis 120 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.
75.00 Tesis 121 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. 75.00 Tesis 122 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 75.00 Tesis 123 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.
75.00 Tesis 124 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 1738 137 . 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 75.00 Tesis 125 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.
75.00 Tesis 126 URI RFC 3986 138 . 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 final 139 . 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 recurso 140 .
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). 75.00 Tesis 127 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.
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 3987 141 . 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
75.00 Tesis 128 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.
75.00 Tesis 129 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. 75.00 Tesis 130 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. 31 st
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- 75.00 Tesis 131 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 1 st 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.
75.00 Tesis 132 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).
75.00 Tesis 133 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.
Excel para principiantes: Aprenda a utilizar Excel 2016, incluyendo una introducción a fórmulas, funciones, gráficos, cuadros, macros, modelado, informes, estadísticas, Excel Power Query y más
Ciberseguridad: Una Simple Guía para Principiantes sobre Ciberseguridad, Redes Informáticas y Cómo Protegerse del Hacking en Forma de Phishing, Malware, Ransomware e Ingeniería Social