Oscar Sena, Alvaro Rodriguez, Gustavo Núñez

Presentación del tema: "Oscar Sena, Alvaro Rodriguez, Gustavo Núñez"— Transcripción de la presentación:

1 Oscar Sena, Alvaro Rodriguez, Gustavo Núñez
OWL-S vs. WMSO Oscar Sena, Alvaro Rodriguez, Gustavo Núñez

2 Arquitectura OWL-S WSMO No definida Claramente definida
En el caso de Owl-S la arquitectura no ha sido un objetivo hasta el presente. WSMO define una arquitectura, basada en MOF (Meta-Object Facility) y en la estructura Goal-WebService-Ontologies,Mediators.

3 Consumidor-Proveedor
OWL-S WSMO No hay una separación explícita en la forma de definir cada uno, el Perfil se usa tanto para definir deseo del cliente y servicio ofrecido. Se separa claramente la descripción del Consumidor a través del Objetivo y del Proveedor a través del Servicio Web. Para OWL-S, la definición de proveedor y consumidor no se efectúan en forma independiente, mediante el Service Profile se promueven y descubren servicios. En cambio para WSMO la definición de los deseos del consumidor es totalmente independiente de la definición de la prestación del servicio, se realiza mediante la definición del objetivo (goal), el servicio se define por otro lado (webservice.).

4 Consumidor-Proveedor
OWL-S WSMO <service:Service rdf:ID=“BravoAir_ReservationAgent”> <service:presents rdf:resource=“BravoAirProfile.owl#Profile_BravoAir_ReservationAgent”/> <service:describedBy rdf:resource=“BravoAirProcess.owl#BravoAir_Process”/> <service:supports rdf:resource=“BravoAirGrounding.owl#Grounding_BravoAir_ReservationAgent”/> </service:Service> goal << webservice << Vista de la definición del Servicio/Consumo en OWL-S, mediante el concepto Service, que conecta Profile, Process y Grounding; y en WSMO mediante la definición del consumo (goal) que se define mediante las propiedades no funcionales, y el servicio mediante las propiedades no funcionales también.

5 Propiedades No Funcionales
OWL-S WSMO La descripción de aspectos no funcionales se limita a la descripción del Servicio. La descripción de aspectos no funcionales se extiende a todos los componentes de WSMO, utilizando terminología aceptada (DCMES). En OWL-S la decripción de aspectos no funcionales se realiza a nivel del ServiceProfile únicamente. En cambio en WSMO las propiedades no funcionales se pueden describir en cualquiera de sus componentes: goal, webservice, ontologies o mediators.

6 Propiedades No Funcionales
OWL-S Service Profile WSMO <profile:serviceName>BravoAir_ReservationAgent</profile:serviceName> <profile:textDescription>This service…</profile:textDescription> <profile:contacInformation> <actor:Actor rdf:ID=“BravoAir-serervation”> … </actor:Actor> </profile:contactInformation> goal << nonFunctionalProperties dc:title hasVAlue “Buying a train ticket from Insbruck to Frankfurt on…” dc:creator hasValue << endNonFunctionalProperties ontology << dc:title hasValue ”International Train Connection Ontology” dc:creator hasValue…. Ejemplo de descripción de propiedades no funcionales en OWL-S a nivel del Service Profile. En WSMO para cualquiera de sus componentes se pueden describir propiedades no funcionales, aquí se muestra un ejemplo de propiedades no funcionales para goal y para ontology.

7 OWL-S Service Profile/Model
Funcionalidades OWL-S Service Profile/Model WSMO Goal/WebService <profile:serviceName>BravoAir… …. <profile:hasInput rdf:resource=“BravoAirProcess.owl#DepartureAirport”> <profile:hasOutput rdf:resource=“BravoAirProcess.owl#FlightsFound”> <model:serviceName>BravoAir… … <process:Input rdf:ID=“Departure Airport”> <process:Output rdf:ID=“FlightsFound”> goal << postcondition axiom_# nonFunctionalProperties endNonFunctionalProperties definedBy […] webservice << capability_# precondition En OWL-S, la funcionalidad se define en el Service Model y son referenciados desde el Service Profile, se descomponen en transformación de la información producida por el servicio (definida como inputs y outputs) y cambio de estado como consecuencia de la ejecución del servicio (precondiciones y efectos, estos últimos como parte de los resultados), a estos elementos se les llama IOPEs. Los inputs y outputs definen que información es requerida y que información es producida por el servicio. Los inputs y outputs se definen en el Service Model y son referenciados desde el Service Profile mediante las propiedades hasInput y hasOutput, el cambio de estado se define en el Service Model como precondiciones y efectos y son referenciados desde el Service Provile mediante la propiedades hasPrecondition y hasResult. En WSMO, la funcionalidad del servicio se define en el webservice “capability” usando precondiciones y poscondiciones, para definir la transformación de la información. El goal solo incluye poscondiciones definidas como el estado del espacio de información que es deseado como consecuencia de la prestacíón del serivicio, el cambio de estado se define a nivel del webserive mediante asumidos y efectos y a nivel del goal mediante efectos.

8 OWL-S ServiceProfile/Model
Funcionalidades OWL-S ServiceProfile/Model WSMO Goal/WebService <profile:serviceName>BravoAir…. … <profile:hasResult> rdf:resource=“BravoAirProcess.owl#HaveSeatResult”> <model:serviceName>BravoAir… …. <process:hasResult> <process:Result> </process:hasResult> goal << effect axiom_# nonFunctionalProperties endNonFunctionalProperties definedBy […] webservice << capability_# assumption Continuación del ejemplo anterior, definiendo el estado del ambiente antes y después, mediante precondiciones y efectos (resultados) en OWL-S (en este ejemplo no hay precondiciones). En WSMO, se definen efectos únicamente a nivel del goal y asumidos y efectos a nivel del webservice.

9 Terminología OWL-S WSMO
La terminología del proveedor y del consumidor debe ser la misma, se entiende como un problema de arquitectura la resolución de heterogeneidad. La terminología del proveedor y del consumidor puede ser diferente, resolviéndose a través de mediadores (bajo acomplamiento, alta mediación). En OWL-S se obliga a adaptarse a la terminología definida, se traslada el problema de la heterogeneidad a la arquitectura, mientras que WSMO resuelve estos conflictos a través de los mediadores de tipo oo.

10 Coreografía OWL-S Service Model WSMO
Descripta detalladamente, a nivel de procesos atómicos, simples y complejos. Carece de semántica formal. Permite una sola forma de interactuar con el servicio. No definido. Algunos principios enunciados: semántica formal, múltiples coreografías (interfaces). OWL-S define en forma detallada la invocación al servicio, haciéndolo además de manera precisa y no permitiendo variantes. WSMO en cambio plantea teóricamente los principios de la interacción entre el servicio y el consumidor, pero no existe aplicación práctica al momento para ejecutar un servicio.

11 Orquestación OWL-S WSMO No definido.
Definido explícitamente el qué (qué otros servicios deben ser utilizados u objetivos que deben participar para alcanzar el servicio) pero no el como. OWL-S no lo define formalmente, existen formas de lograrlo a partir de jerarquías de servicios. WSMO lo define explícitamente, pero al igual que para la orquestación no existe implementación práctica a la fecha.

12 Invocación del Servicio
OWL-S WSMO Definido a través de WSDL. No definido. Como corolario de lo expuesto en las ppt´s anteriores, se muestra la forma de invocación de un servicio en OWL-S utilizando el lenguaje WSDL.

13 Invocación del Servicio
OWL-S WSMO <grounding:WsdlAtomicProcessGrounding rdf:ID=“WsdlGrounding_GetDesiredFlightDetails”/> <grounding:owlsProcess rdf:resource=“BravoAirProcess.owlsGetDesiredFlightDetails”/> grounding:wsdlOperation rdf:resource=“#GetDesiredFlightDetails_operation”/> grounding:wsdlInputMessage rdf:datatype=“#xsd;anyURI”> BravoAirGrounding.wsdl#GetDesiredFlightDetails_Input </grounding:wsdlInputMessage> <grounding:wsdlInput>…. ? OWL-S no indica el mecanismo de invocación “grounding” a ser utilizado, la versión corriente de OWL-S provee una invocación predefinida para WSDL, mapeando los diferentes elementos del servicio web a una interface WSDL.

14 Lenguajes OWL-S WSMO Tiende a combinar diferentes semánticas y notaciones, hay áreas donde se deja la semántica abierta. Proporciona una familia de lenguajes (organizados en diferentes capas, estilo MOF), combinando modelado conceptual con reglas. Menor ambigüedad, bien definida relación entre capas. No todos los lenguajes están desarrollados.

15 Lenguajes OWL-S WSMO SWRL OWL KIF DRS WSML-Core WSML-DL WSML-Flight
WSML-Rule WSML-Full

16 Eligiendo Lenguajes Ya establecidos Nuevas tendencias OIL DAML+OIL OWL
Familia WSMO

17 RDF Schema RDF Schema: Lenguaje de propósito general para representar información en la web. El esquema define propiedades del recurso: Título, Autor, tema, tamaño etc. Propuesto por W3C en Dic 2003 Recomendado por W3C en Feb 2004

18 OWL-Flight OWL-Lite- vence algunas de las limitaciones de OWL-Lite, pero con expresividad reducida No provee Datatypes  OWL-Flight Soporte tipos de datos Restricciones, clases etc.

19 WSML-Core Combina OWL-Lite- y el meta-modelo conceptual para ontologías de WSMO Representa la intersección entre dos paradigmas de representaciones del conocimiento: Description Logic Lenguajes de Reglas

20 Extensiones de Reglas No incluidas en OWL
RDF: TRIPLE, lógica de Horn, F-logic OWL: SWRL, DL + Lite, reglas de Horn

21 OWL-Lite- La OWL-Lite- es un subconjunto propio de OWL-Lite traducible a Datalog Restringe la sintáxis y semántica Extensible directamente para incorporar restricciones para cardinalidad y valor estilo base de dato. En Datalog las reglas pueden ser agregadas sobre la ontología. La OWL-Lite es la especificación menos expresiva Reasoning: incrementa complejidad. Cardinalidad introduce igualdad no intuitiva No hay noción de restricciones No fácilmente extensible para leng. de reglas sin perder garantías computacionales

22 WSML OWL-Lite- OWL-Flight OWL-DL- OWL-Full- WSML-Core
Estos lenguajes se están desarrollando en contextos específicos , principalmente en Descripción de Servicios Web, son valiosos por si mismos Dentro del WSML existen diversos esfuerzos en el tema de lenguajes, con características específicas

23 WSMO Project Web Service Modelling Ontology , proyecto mayoritariamente europeo. En el contexto de tres proyectos europeos: SEKT, DIP, Knowledge Web 2 subproyectos: WSML (Web Service Modelling Language) WSMX (Web Service Execut.Environment)

24 OWL Está en “pruning stage” no se preven modificaciones mayores.
WebOnt: esfuerzos orientados a SWBPD (Semantic Web Best Practices and Deployment Working Group)

25 OWL-FULL Posee vocabulario completo interpretado mas ampliamente que en OWL-DL. Máximo poder expresivo y libertad sintáctica No ofrece garantías computacionales

26 OWL-DL Contiene los constructores del lenguaje pero con restricciones jerárquicas Provee completitud computacional Decidability.. Máximo poder expresivo dentro de Description Logic

27 OWL-Lite Alto nivel: RDF + cardinalidad 0 / 1
Representa un pasaje para migración desde otras taxonomías.Orientado a clasificación de jerarquías y restricciones simples. Se plantea que quede lo mas simple posible para facilitar su desarrollo

28 OWL Lenguaje de ontologías web desarrollado por el WebOnt Group de W3C
Basado en OIL y DAML+OIL Incluye tres sub-lenguajes: OWL-Lite OWL-DL OWL-Full

29 OIL (Unifica tres aspectos procedentes de tres comunidades distintas)
Construido sobre RDF y RDF Schema, avanza en su alcance manteniendo compatibilidad hacia atrás. Provee primitivas para modelado usadas en Ontologías basadas en frames y orientadas a Description Logic Semántica formal y soporte a razonamiento eficiente provisto por Description Logic Primitivas de Modelado ricas desde el punto de vista epistemiológico provistas por la comunidad basada en Frames Propuesta estándar para intercambio sintáctico provisto por la comunidad Web Ya no evoluciona más

30 DAML+OIL (Heredero natural de OIL)
Lenguaje ontológico diseñado específicamente para Web Semántica Explota estándar de facto como XML y RDF Agrega primitivas ontológicas de OO y de Frame + rigor de Description Logic Ya no evoluciona mas.. (últimos drafts de 2001)

31 Conclusiones OWL-S WSMO
No define arquitectura. Menor desarrollo en orquestación. Fuerte en aspectos de utilización tales como, coreografía, invocación. En general es posible alcanzar los mismos objetivos que WSMO, en forma menos intuitiva. Aspectos básicos de utilización desarrollados. Fuerte en arquitectura, flexibilidad para el consumidor, con definiciones sobre aspectos importantes como orquestación, lenguajes, mediación. No maduro en aspectos fundamentales de utilización, definidos pero no desarrollados. Propicia utilización terminología estandarizada.

32 Conclusiones Sería deseable trabajar bajo el marco definido por WSMO a partir del grado de desarrollo actual de OWL-S

33 Bibliografía [LARA 2004] Lara R, Polleres A, Roman D, 'D4.2v0.1 Formal Comparison WSMO/OWL-S', DERI working draft 15 march 2004, ed: Lara R, Polleres A, disponible en Internet: < accedido el 26/07/2006 [LARA1 2004] Lara R, Polleres A et al, 'D4.2v0.1 Formal Mapping and Tool to OWL-S', WSMO working draft 17 december 2004, ed: Lara R, Polleres A,disponible en Internet: < accedido el 26/07/2006