Slide1 : Katia Sycara
Massimo Paolucci Christoph Bussler
Emilia Cimpian
Matthew Moran
Michael Stollberg
Michal Zaremba Liliana Cabral
John Domingue Daniela Berardi
Massimo Mecella
Slide2 : Agenda Part I: Introduction to Semantic Web Services
Part II: Semantic Web Service Ontologies
OWL-S
WSMO
differences & commonalities
Coffee Break: 10.30 – 11.00
Part III: Addressing Semantic Web Service Challenges
Discovery
Composition
Lunch: 12.30 – 14.00
Part IV: Semantic Web Service Tools & Systems
CMU OWL-S Browser
Service Composer
WSMX
Coffee Break: 15.30 – 16.00
Part V: Hands-On Session
PART I: Introduction to Semantic Web Services : PART I: Introduction to Semantic Web Services Michael Stollberg
Slide4 : Contents
The vision of the Semantic Web
Ontologies as the basic building block
Current Web Service Technologies
Vision and Challenges for Semantic Web Services
The Vision : Static 500 million users
more than 3 billion pages WWW
URI, HTML, HTTP The Vision
The Vision : WWW
URI, HTML, HTTP Serious Problems in
information finding,
information extracting,
information representing,
information interpreting and
and information maintaining. Semantic Web
RDF, RDF(S), OWL Static The Vision
The Vision : WWW
URI, HTML, HTTP Bringing the computer back as a device for computation Semantic Web
RDF, RDF(S), OWL Dynamic Web Services
UDDI, WSDL, SOAP Static The Vision
The Vision : WWW
URI, HTML, HTTP Bringing the web to its full potential Semantic Web
RDF, RDF(S), OWL Dynamic Web Services
UDDI, WSDL, SOAP Static Semantic Web
Services The Vision
Slide9 : The Semantic Web the next generation of the WWW
information has machine-processable and machine-understandable semantics
not a separate Web but an augmentation of the current one
Ontologies as basic building block
Ontology Definition : Ontology Definition
formal, explicit specification of a shared conzeptualization
commonly accepted understanding conceptual model of a domain (ontological theory) unambiguous terminology definitions machine-readability with computational semantics
Slide11 : Ontology Technology To make the Semantic Web working we need:
Ontology Languages:
expressivity
reasoning support
web compliance
Ontology Reasoning:
large scale knowledge handling
fault-tolerant
stable & scalable inference machines
Ontology Management Techniques:
editing and browsing
storage and retrieval
versioning and evolution Support
Ontology Integration Techniques:
ontology mapping, alignment, merging
semantic interoperability determination
and … Applications
Web Services : Web Services loosely coupled, reusable components
encapsulate discrete functionality
distributed
programmatically accessible over standard internet protocols
add new level of functionality on top of the current web
The Promise of Web Services : The Promise of Web Services web-based SOA as new system design paradigm
WSDL : WSDL Web Service Description Language
W3C effort, WSDL 2 final construction phase describes interface for
consuming a Web Service:
- Interface: operations (in- & output)
- Access (protocol binding)
- Endpoint (location of service)
UDDI : UDDI Universal Description, Discovery, and Integration Protocol
OASIS driven standardization effort Registry for
Web Services:
- provider
- service information
- technical access
SOAP : SOAP Simple Object Access Protocol
W3C Recommendation XML data transport:
- sender / receiver
- protocol binding
- communication aspects
- content
Lacks of Web Service Technology : Lacks of Web Service Technology current technologies allow usage of Web Services
but:
only syntactical information descriptions
syntactic support for discovery, composition and execution
=> Web Service usability, usage, and integration needs to be inspected manually
no semantically marked up content / services
no support for the Semantic Web
=> current Web Service Technology Stack failed to
realize the promise of Web Services
Semantic Web Services :
Semantic Web Technology
+
Web Service Technology
Semantic Web Services
=> Semantic Web Services as integrated solution for realizing the vision of the next generation of the Web allow machine supported data interpretation
ontologies as data model automated discovery, selection, composition,
and web-based execution of services
Semantic Web Services : Semantic Web Services define exhaustive description frameworks for describing Web Services and related aspects (Web Service Description Ontologies)
support ontologies as underlying data model to allow machine supported data interpretation (Semantic Web aspect)
define semantically driven technologies for automation of the Web Service usage process (Web Service aspect)
Semantic Web Services : Semantic Web Services Usage Process:
Publication: Make available the description of the capability of a service
Discovery: Locate different services suitable for a given task
Selection: Choose the most appropriate services among the available ones
Composition: Combine services to achieve a goal
Mediation: Solve mismatches (data, protocol, process) among the combined
Execution: Invoke services following programmatic conventions
Semantic Web Services : Semantic Web Services Execution support:
Monitoring: Control the execution process
Compensation: Provide transactional support and undo or mitigate unwanted effects
Replacement: Facilitate the substitution of services by equivalent ones
Auditing: Verify that service execution occurred in the expected way
PART II: Semantic Web Service Ontologies : PART II: Semantic Web Service Ontologies Katia Sycara
Michael Stollberg
Dumitru Roman
Slide23 : Contents
OWL-S
Upper Ontology
Service Profile
Process Model
Service Grounding
WSMO
WSMO top level notions
Choreography and Mediation
Mediation
Differences and Commonalities
OWL-S : OWL-S Katia Sycara
OWL-S Ontology : OWL-S Ontology OWL-S is an OWL ontology to describe Web services
OWL-S leverages on OWL to
Support capability based discovery of Web services
Support automatic composition of Web Services
Support automatic invocation of Web services
Complete do not compete
OWL-S does not aim to replace the Web services standards
rather OWL-S attempts to provide a semantic layer
OWL-S relies on WSDL for Web service invocation (see Grounding)
OWL-s Expands UDDI for Web service discovery (OWL-S/UDDI mapping)
OWL-S Upper Ontology : OWL-S Upper Ontology Mapping to WSDL
communication protocol (RPC, HTTP, …)
marshalling/serialization
transformation to and from XSD to OWL Control flow of the service
Black/Grey/Glass Box view
Protocol Specification
Abstract Messages Capability specification
General features of the Service
Quality of Service
Classification in Service
taxonomies
Service Profiles : Service Profiles Service Profile
Presented by a service.
Represents
what the service provides
Two main uses:
Advertisements of Web Services capabilities
Request of Web services with a given set of capabilities
OWL-S Profile in a Nutshell : OWL-S Profile in a Nutshell Describes Web service
What capabilities it provides:
What transformation the service computes
Type of service and products
General features such as
Agent providing the service
Security requirements
Quality guarantees of service
Primary role: to assist discovery
Allows capability based search
Allows selection based on requirements of the requester
Profile does not specify use/invocation
OWL-S Service Profile Capability Description : OWL-S Service Profile Capability Description Preconditions
Set of conditions that should hold prior to service invocation
Inputs
Set of necessary inputs that the requester should provide to invoke the service
Outputs
Results that the requester should expect after interaction with the service provider is completed
Effects
Set of statements that should hold true if the service is invoked successfully.
Service type
What kind of service is provided (eg selling vs distribution)
Product
Product associated with the service (eg travel vs books vs auto parts)
OWL-S Service Profile Additional Properties : OWL-S Service Profile Additional Properties Security Parameters
Specify the security capabilities of a Web service (eg support X509 Encryption)
Specify the security requirements of a Web service (eg a client should be able to provide X509 Encryption)
Quality rating
What level of service quality does the Web service provide?
Description with standard business taxonomies
How would the service be classified in standard taxonomies such as UNSPSC or NAICS?
This is not a closed set, new properties can be added using existing ontologies
Process Model : Process Model Process Model
Describes how a service works: internal processes of the service
Specifies service interaction protocol
Specifies abstract messages: ontological type of information transmitted
Facilitates
Web service invocation
Composition of Web services
Monitoring of interaction
Viewpoints of Process Model : Viewpoints of Process Model Three viewpoints of a Web service
Glass Box:
The Web service reveals all its internal structure
Which parts of the service it performs in-house, which one it subcontracts, etc
Black Box:
The Web service model does not reveal anything about the internal working of the service
It just specifies what data it gathers and what data it sends back
Grey Box:
The Web service selectively hides some parts of its Process Model, while it publicizes others
Definition of Process : Definition of Process A Process represents a transformation (function). It is characterized by four parameters
Inputs: the inputs that the process requires
Preconditions: the conditions that are required for the process to run correctly
Outputs: the information that results from (and is returned from) the execution of the process
Results: a process may have different outcomes depending on some condition
Condition: under what condition the result occurs
Constraints on Outputs
Effects: real world changes resulting from the execution of the process
Motivation for Results : Motivation for Results Processes may terminate in exceptional states:
The credit company may fail to charge the credit card
The book may be out of stock
The deliver of the goods may fail
Results support modeling of non-deterministic outcomes of Web services
The condition specifies when an outcome is generated
Each outcome is characterized by
a set of constraints on outputs
a set of effects
Example of Process : Example of Process
correctLoginInfo(AccName,Password)
loggedIn(AccName,Password)
Inputs / Outputs Result Condition Effect Output Constraints Precondition
Ontology of Processes : Ontology of Processes Process Atomic Simple Composite Provides abstraction,
encapsulation etc. Defines a workflow composed of process performs Invokable
bound to grounding
Process Model Organization : Process Model Organization Process Model is described as a tree structure
Composite processes are internal nodes
Simple and Atomic Processes are the leaves
Simple processes represent an abstraction
Placeholders of processes that aren’t specified
Or that may be expressed in many different ways
Atomic Processes correspond to the basic actions that the Web service performs
Hide the details of how the process is implemented
Correspond to WSDL operations
Composite Processes : Composite Processes Composite Processes specify how processes work together to compute a complex function
Composite processes define
Control Flow
Specify the temporal relations between the executions of the different sub-processes
Data Flow
Specify how the data produced by one process is transferred to another process
Example of Composite Process : Example of Composite Process
Sequence
BookFlight Depart Arrive Flights Airline Airline Flight Perform
Get Flights
Flight Perform
Select
Flight Flights Control Flow Links
Specify order of
execution Data-Flow Links
Specify transfer of data Perform statements
Specify the execution of a process
Perform Construct : Perform Construct Perform provides invocation mechanism
Specify context of process execution
input data flow
hooks for output data flow
Distinction between definition and invocation of a process
Definition specifies the process’ I/P/R
Perform specify when the process is invoked and with what parameters
Control Flow : Control Flow Processes can be chained to form a workflow
OWL-S supports the following control flow constructs
Sequence/Any-Order: represents a list of processes that are executed in sequence or arbitrary order
Conditionals: if-then-else statements
Loops: while and repeat-until statements
Multithreading and synchronization: split process in multiple threads, and rendezvous (joint) points
Non-deterministic choices: (arbitrarily) select one process of a set
Data Flow : Data Flow Dataflow allows information that is transferred from process to process.
OutputInput:
The information produced by one process is transferred to another in the same control construct
Input Input:
The information received by a composite process is transferred to the sub-processes
OutputOutput:
The information produced by a subprocess is transferred to a super-process
Process Model: take home lesson : Process Model: take home lesson Service Model describes
Set of processes that define the operations performed by the Web service
Control flow describing the temporal flow of processes
Data flow describing the transfer of information between sub-processes
Service Grounding : Service Grounding Service Grounding
Provides a specification of service access information.
Service Model + Grounding give everything needed for using the service
Builds upon WSDL to define message structure and physical binding layer
Specifies:
communication protocols, transport mechanisms, communication languages, etc.
Rationale of Service Grounding : Rationale of Service Grounding Provides a specification of service access information.
Service Model + Grounding give everything needed for using the service
Service description is for reasoning about the service
Decide what information to send and what to expect
Service Grounding is for message passing
Generate outgoing messages, and get incoming messages
Mapping XML Schemata to OWL concepts
Builds upon WSDL to define message structure and physical binding layer
Mapping OWL-S / WSDL 1.1 : Mapping OWL-S / WSDL 1.1 Operations correspond to Atomic Processes
Input/Output messages correspond to Inputs/Outputs of processes
Example of Grounding : Example of Grounding
Sequence
BookFlight Depart Arrive Flights Airline Airline Flight Perform
Get Flights
Flight Perform
Select
Flight Flights Get Flights Op Depart Arrive Flights WSDL Airline Flight
Select
Flight op Flights
Result of using the Grounding : Result of using the Grounding Invocation mechanism for OWL-S
Invocation based on WSDL
Different types of invocation supported by WSDL can be used with OWL-S
Clear separation between service description and invocation/implementation
Service description is needed to reason about the service
Decide how to use it
Decide how what information to send and what to expect
Service implementation may be based on SOAP an XSD types
The crucial point is that the information that travels on the wires and the information used in the ontologies is the same
Allows any web service to be represented using OWL-S
For example: Amazon.com
Handling stateful vs stateless Web services : Handling stateful vs stateless Web services Stateless Web services
The server does not maintain the state of the computation
Dataflow links specify how the client communicate the state to the service
Stateful Web services
The service does maintain the state
No need of dataflow links since transfer of information is opaque to the client
Representing Stateful Web services : Representing Stateful Web services
Sequence
BookFlight Flights Airline Airline Flight Perform
Get Flights
Flight Perform
Select
Flight Flights Get Flights Op Arrive Flights Server Flight
Select
Flight op Flights Stateless: no information is transferred between the two operations Client Server
Representing Stateless Web services : Representing Stateless Web services
Sequence
BookFlight Flights Airline Airline Flight Perform
Get Flights
Flight Perform
Select
Flight Get Flights Op Arrive Flights Server Flight
Select
Flight op Flights Client Stateful: information is recorded by the server, no need of transfer between the two operations
Conclusion OWL-S section : Conclusion OWL-S section OWL-S provides a language for the description of Web services
Service Profile provides description of capabilities of Web Service
Allows capability-based discovery
Process Model provides the description of how to use a Web service
Allows automatic invocation of Web service
Service Grounding maps Atomic Processes into WSDL operations
Allows separation between description and implementation
Supports description of arbitrary Web services
Web Service Modeling Ontology WSMO : Web Service Modeling Ontology WSMO Michael Stollberg
Outline : Outline WSMO
aims & objectives
working structure
Design Principles
Top Level Notions
Ontologies
Web Services
Goals
Mediators
WSMO is .. : WSMO is .. a conceptual model for Semantic Web Services :
Ontology of core elements for Semantic Web Services
a formal description language (WSML)
execution environment (WSMX)
… derived from and based on the Web Service Modeling Framework WSMF
a SDK-Cluster Working Group
(joint European research and development initiative)
WSMO Working Groups : WSMO Working Groups A Conceptual Model for SWS A Formal Language for WSMO A Rule-based Language for SWS Execution Environment for WSMO
WSMO Design Principles : Web Compliance
Ontology-Based
Strict Decoupling
Centrality of Mediation
Ontological Role Separation
Description versus Implementation
Execution Semantics WSMO Design Principles
WSMO Top Level Notions : WSMO Top Level Notions Objectives that a client wants to
achieve by using Web Services Provide the formally specified terminology
of the information used by all other components Semantic description of Web Services:
Capability (functional)
Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities WSMO D2, version 1.2, 13 April 2005 (W3C submission)
Non-Functional Properties : Non-Functional Properties every WSMO elements is described by properties that contain relevant, non-functional aspects
Dublin Core Metadata Set:
complete item description
used for resource management
Versioning Information
evolution support
Quality of Service Information
availability, stability
Other
Owner, financial
Non-Functional Properties List : Non-Functional Properties List Dublin Core Metadata
Contributor
Coverage
Creator
Description
Format
Identifier
Language
Publisher
Relation
Rights
Source
Subject
Title
Type Quality of Service
Accuracy
NetworkRelatedQoS
Performance
Reliability
Robustness
Scalability
Security
Transactional
Trust Other
Financial
Owner
TypeOfMatch
Version
WSMO Ontologies : WSMO Ontologies Provide the formally specified terminology
of the information used by all other components Semantic description of Web Services:
Capability (functional)
Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to
achieve by using Web Services
Ontology Usage & Principles :
Ontologies are used as the ‘data model’ throughout WSMO
all WSMO element descriptions rely on ontologies
all data interchanged in Web Service usage are ontologies
Semantic information processing & ontology reasoning
WSMO Ontology Language WSML
conceptual syntax for describing WSMO elements
logical language for axiomatic expressions (WSML Layering)
WSMO Ontology Design
Modularization: import / re-using ontologies, modular approach for ontology design
De-Coupling: heterogeneity handled by OO Mediators
Ontology Usage & Principles
Ontology Specification :
Non functional properties (see before)
Imported Ontologies importing existing ontologies where no heterogeneities arise
Used mediators OO Mediators (ontology import with terminology mismatch handling)
Ontology Elements:
Concepts set of concepts that belong to the ontology, incl.
Attributes set of attributes that belong to a concept
Relations define interrelations between several concepts
Functions special type of relation (unary range = return value)
Instances set of instances that belong to the represented ontology
Axioms axiomatic expressions in ontology (logical statement) Ontology Specification
WSMO Web Services : WSMO Web Services Provide the formally specified terminology
of the information used by all other components Semantic description of Web Services:
Capability (functional)
Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to
achieve by using Web Services
WSMO Web Service Description : WSMO Web Service Description
Web Service
Implementation
(not of interest in Web Service Description)
Choreography --- Service Interfaces --- Capability
functional description Advertising of Web Service
Support for WS Discovery client-service interaction interface for consuming WS
External Visible
Behavior
- Communication
Structure
- ‘Grounding’ realization of functionality by aggregating
other Web Services
functional
decomposition
WS composition Non-functional Properties
DC + QoS + Version + financial complete item description
quality aspects
Web Service Management Orchestration
Capability Specification : Capability Specification Non functional properties
Imported Ontologies
Used mediators
OO Mediator: importing ontologies with mismatch resolution
WG Mediator: link to a Goal wherefore service is not usable a priori
Pre-conditions What a web service expects in order to be able to
provide its service. They define conditions over the input.
Assumptions Conditions on the state of the world that has to hold before
the Web Service can be executed
Post-conditions
describes the result of the Web Service in relation to the input,
and conditions on it
Effects
Conditions on the state of the world that hold after execution of the
Web Service (i.e. changes in the state of the world)
Choreography & Orchestration : Choreography & Orchestration VTA example:
Choreography = how to interact with the service to consume its functionality
Orchestration = how service functionality is achieved by aggregating other Web Services
Choreography Aspects : Choreography Aspects External Visible Behavior
those aspects of the workflow of a Web Service where Interaction is required
described by workflow constructs: sequence, split, loop, parallel
Communication Structure
messages sent and received
their order (communicative behavior for service consumption)
Grounding
executable communication technology for interaction
choreography related errors (e.g. input wrong, message timeout, etc.)
Formal Model
reasoning on Web Service interfaces (service interoperability)
allow mediation support on Web Service interfaces Interface for consuming Web Service
Orchestration Aspects : Orchestration Aspects decomposition of service functionality
all service interaction via choreographies Control Structure for aggregation of other Web Services
Web Service Business Logic
1 2 3 4
WSMO Web Service Interfaces : WSMO Web Service Interfaces service interfaces are concerned with service consumption and interaction
Choreography and Orchestration as sub-concepts of Service Interface
common requirements for service interface description:
represent the dynamics of information interchange during service consumption and interaction
support ontologies as the underlying data model
appropriate communication technology for information interchange
sound formal model / semantics of service interface specifications in order to allow operations on them.
Service Interface Description : Service Interface Description Ontologies as data model:
all data elements interchanged are ontology instances
service interface = evolving ontology
Abstract State Machines (ASM) as formal framework:
dynamics representation: high expressiveness & low ontological commitment
core principles: state-based, state definition by formal algebra, guarded transitions for state changes
overcome the “Frame Problem”
further characteristics:
not restricted to any specific communication technology
ontology reasoning for service interoperability determination
basis for declarative mediation techniques on service interfaces
Service Interface Description Model : Service Interface Description Model Vocabulary Ω:
ontology schema(s) used in service interface description
usage for information interchange: in, out, shared, controlled
States ω(Ω):
a stable status in the information space
defined by attribute values of ontology instances
Guarded Transition GT(ω):
state transition
general structure: if (condition) then (action)
different for Choreography and Orchestration
Service Interface Example : Service Interface Example Ωin hasValues {
concept A [
att1 ofType X
att2 ofType Y]
…} a memberOf A [
att1 hasValue x
att2 hasValue y] a memberOf A [
att1 hasValue x,
att2 hasValue y]
b memberOf B [
att2 hasValue m] IF (a memberOf A [
att1 hasValue x ])
THEN
(b memberOf B [
att2 hasValue m ]) State ω1 Guarded Transition GT(ω1) State ω2 Ωout hasValues {
concept B [
att1 ofType W
att2 ofType Z]
…} Vocabulary:
- Concept A in Ωin
- Concept B in Ωout received ontology
instance a Communication Behavior of a Web Service sent ontology
instance b
Future Directions : Future Directions Ontologies as data model:
- every resource description based on ontologies
- every data element interchanged is ontology instance Formal description of service interfaces:
- ASM-based approach
- allows reasoning & mediation workflow constructs as basis for describing service interfaces:
- workflow based process models for describing behavior
- on basis of generic workflow constructs (e.g. van der Aalst) Choreography:
- interaction of services / service and client
- a „choreography interface“ describes the behavior of a
Web Service for client-service interaction for consuming
the service Orchestration:
- how the functionality of a Web Service is achieved by
aggregating other Web Services
- extends Choreography descriptions by control & data flow
constructs between orchestrating WS and orchestrated WSs. Grounding:
- making service interfaces executable
- currently grounding to WSDL Conceptual models User language
- based on UML2 activity diagrams
- graphical Tool for Editing & Browsing Service Interface Description
WSMO Goals : WSMO Goals Provide the formally specified terminology
of the information used by all other components Semantic description of Web Services:
Capability (functional)
Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to
achieve by using Web Services
Goals : Goals
Ontological De-coupling of Requester and Provider
Goal-driven Approach, derived from AI rational agent approach
Requester formulates objective independently
‘Intelligent’ mechanisms detect suitable services for solving the Goal
allows re-use of Services for different purposes
Usage of Goals within Semantic Web Services
A Requester (human or machine) defines a Goal to be resolved
Web Service Discovery detects suitable Web Services for solving the Goal automatically
Goal Resolution Management is realized in implementations
Goal Specification : Goal Specification Non functional properties
Imported Ontologies
Used mediators
OO Mediators: importing ontologies with heterogeneity resolution
GG Mediator:
Goal definition by reusing an already existing goal
allows definition of Goal Ontologies
Requested Capability
describes service functionality expected to resolve the objective
defined as capability description from the requester perspective
Requested Interface
describes communication behaviour supported by the requester for consuming a Web Service (Choreography)
Restrictions / preferences on orchestrations of acceptable Web Services
WSMO Mediators : WSMO Mediators Provide the formally specified terminology
of the information used by all other components Semantic description of Web Services:
Capability (functional)
Interfaces (usage) Connectors between components with mediation facilities for handling heterogeneities Objectives that a client wants to
achieve by using Web Services
Mediation : Mediation Heterogeneity …
Mismatches on structural / semantic / conceptual / level
Occur between different components that shall interoperate
Especially in distributed & open environments like the Internet
Concept of Mediation (Wiederhold, 94):
Mediators as components that resolve mismatches
Declarative Approach:
Semantic description of resources
‘Intelligent’ mechanisms that resolve mismatches independent of content
Mediation cannot be fully automated (integration decision)
Levels of Mediation within Semantic Web Services (WSMF):
Data Level: mediate heterogeneous Data Sources
Protocol Level: mediate heterogeneous Communication Patterns
Process Level: mediate heterogeneous Business Processes
WSMO Mediators Overview : WSMO Mediators Overview
Mediator Structure : Mediator Structure WSMO Mediator
uses a Mediation Service via Source
Component Source
Component Target
Component 1 .. n 1 Mediation
Services as a Goal
directly
optionally incl. Mediation
OO Mediator - Example : OO Mediator - Example OO Mediator
Mediation Service Train Connection
Ontology (s1) Purchase
Ontology (s2) Train Ticket
Purchase Ontology Mediation
Services Goal:
“merge s1, s2 and
s1.ticket subclassof s2.product” Discovery Merging 2 ontologies
GG Mediators : GG Mediators Aim:
Support specification of Goals by re-using existing Goals
Allow definition of Goal Ontologies (collection of pre-defined Goals)
Terminology mismatches handled by OO Mediators
Example: Goal Refinement GG Mediator
Mediation Service Source Goal
“Buy a ticket” Target Goal
“Buy a Train Ticket” postcondition:
“aTicket memberof trainticket”
WG & WW Mediators : WG & WW Mediators WG Mediators:
link a Web Service to a Goal and resolve occurring mismatches
match Web Service and Goals that do not match a priori
handle terminology mismatches between Web Services and Goals
broader range of Goals solvable by a Web Service
WW Mediators:
enable interoperability of heterogeneous Web Services
support automated collaboration between Web Services
OO Mediators for terminology import with data level mediation
Protocol Mediation for establishing valid multi-party collaborations
Process Mediation for making Business Processes interoperable
Slide85 : OWL-S and WSMO Commonalities and Differences
Outline : Outline Perspectives
Relation of Ontology Elements
Interoperability and Mediation
Semantic Representation
OWL-S Perspective : OWL-S Perspective OWL-S is an ontology and a language to describe Web services
guiding lines for the development of OWL-S
Strong relation to Web Services standards
rather than proposing another WS standard, OWL-S aims at enriching existing standards
OWL-S is grounded in WSDL and it has been mapped into UDDI
Based on the Semantic Web
Ontologies provide conceptual framework to describe the domain of Web services and an inference engine to reason about the domain
Ontologies are essential elements of interoperation between Web services
Build upon 30 years of AI research on Knowledge Representation and Planning
WSMO Perspective : WSMO Perspective WSMO is a conceptual model for the core elements of Semantic Web Services
core elements: Ontologies, Web Services, Goals, Mediators
ontology for precise, unambiguous, element description
language for semantic element description (WSML)
reference implementation (WSMX)
Focus on solving the integration problem
Mediation as a key element
Ontologies as data model
every resource description is based on ontologies
every data element interchanged is an ontology instance
Based on Knowledge Engineering and B2B Integration experience
OWL-S and WSMO : OWL-S and WSMO Request
OWL-S uses Profiles to express existing capabilities (advertisements) and desired capabilities (requests)
WSMO separates provider (capabilities) and requester points of view (goals)
Conceptually, OWL-S requested profile and WSMO goal are not exactly the same
Requested service profile vs requester objectives OWL-S profile ≈ WSMO capability +
goal +
non-functional properties
OWL-S and WSMO : OWL-S and WSMO Perspective:
OWL-S Process Model describes operations performed by Web Service, including consumption as well as aggregation
WSMO separates Choreography and Orchestration
Formal Model:
OWL-S formal semantics has been developed in very different frameworks such as Situation Calculus, Petri Nets, Pi-calculus
WSMO service interface description model with ASM-based formal semantics
OWL-S Process Model is extended by SWRL / FLOWS
both approaches are not finalized yet
OWL-S Process Model WSMO Service Interfaces
OWL-S and WSMO : OWL-S provides default mapping to WSDL
clear separation between WS description and interface implementation
other mappings could be used
WSMO also defines a mapping to WSDL, but aims at an ontology-based grounding
avoid loss of ontological descriptions throughout service usage process
‘Triple-Spaced Computing’ as innovative communication technology
OWL-S Grounding current WSMO Grounding
OWL-S and WSMO
Mediation and Interoperation : Mediation and Interoperation Interaction of Web services is bound to produce many forms of mismatch
Data mismatch: the interacting parties do not agree on the data format that they are using
Ontology mismatch: the interacting parties refer to different ontologies
Protocols mismatch: the interacting parties expect information at different times
Goals Mismatch: the interacting parties attempt to achieve very different goals
Interpretations Mismatch: The interacting parties interpret the same information in very different ways
These mismatches need to be reconciled for the interoperation to succeed.
Mediators are the components that reconcile these mismatches
Mediation in OWL-S and WSMO : Mediation in OWL-S and WSMO OWL-S does not have an explicit notion of mediator
Mediation is a by-product of the orchestration process
E.g. protocol mismatches are resolved by constructing a plan that coordinates the activity of the Web services
…or it results from translation axioms that are available to the Web services
It is not the mission of OWL-S to generate these axioms
WSMO regards mediators as key conceptual elements
Different kinds of mediators:
OO Mediators for ensuring semantic interoperability
GG, WG mediators to link Goals and Web Services
WW Mediators to establish service interoperability
Reusable mediators
Mediation techniques under development
Semantic Representation : Semantic Representation OWL-S and WSMO adopt a similar view on the need of ontologies and explicit semantics
but they rely on different logics
OWL-S is based on OWL/SWRL
OWL represent taxonomical knowledge
SWRL provides inference rules
FLOWS as formal model for process model
WSMO is based on WSML a family of languages with a common basis for compatibility and extensions in the direction of Description Logics and Logic Programming
OWL vs WSML : OWL vs WSML WSML aims at overcoming deficiencies of OWL
Relation between WSML and OWL+SWRL to be completed OWL Lite OWL DL OWL Full WSML Flight WSML DL WSML Core WSML Rule WSML Full Description Logics full RDF(S) support subset Description Logics Logic Programming First Order Logic
Summary : Summary
PART III: Addressing Semantic Web Service Challenges : PART III: Addressing Semantic Web Service Challenges Michael Stollberg
Daniela Berardi
Slide98 : Contents
Aspects of Semantic Web Services
Discovery
Problem of Discovery
Existing approaches overview
Composition
Problem of Composition
Existing approaches overview
Challenges : Challenges Web services as loosely coupled components that shall interoperate dynamically and automatically
Techniques required for:
Discovery
How are Web services found and selected?
Composition
How to aggregate Web Services into a complex functionality?
Conversation
How to ensure automated interaction of Web Services?
Invocation
How to access and invoke Semantic Web Services?
Mediation and Interoperability
How are data and protocol mismatches resolved?
Discovery Problems & Approaches Overview : Discovery Problems & Approaches Overview Michael Stollberg
Outline : Outline Aspects of Discovery
Terminology
Discovery Process
Discovery Techniques
keyword-word based retrieval
controlled vocabulary / pre-filtering
Semantic Discovery
Matchmaking Notions
Approaches & Prototypes
Aspects of Discovery : Aspects of Discovery find appropriate Web Service for automatically
resolving the objective of a requester
Aims:
high precision discovery
maximal automation
effective discoverer architectures
Requirements:
infrastructure that allows storage and retrieval of information about Web services
description of Web services functionality
description of requests or goals
algorithms for matching requesters for capabilities with the corresponding providers
Terminology : Terminology Web Services:
abstract Web Services
provides access to concrete Web Services
has a description
concrete Web Services
a concrete execution of a Web Service with given input values
corresponds to an abstract Web Service
Goals / Requests:
predefined goals (Goal Templates)
generic structure of user requests
ease goal / request creation by users
defined in Goal Ontologies
concrete goals (Goal Instances)
concrete objectives
serve as client for automated service usage
based on “Conceptual Architecture for Semantic Web Services”, C. Preist, ISWC 2004
Overall Discovery Process : Overall Discovery Process Goal
Template Requester Desire Selected Goal Template Concrete Goal abstract
WS usable abstract
Web Services Goal
Discovery Goal Refinement Abstract
Service Discovery Concrete Web Service ease of goal
description efficient
filtering accuracy
Goal Repository Service Repository Concrete Service
Discovery & Selection Keller, U.; Lara, R.; Lausen, H.; Polleres, A.; Fensel, D.: Automatic
Location of Services. In Proc. of the 2nd European Semantic Web
Symposium (ESWS2005), Heraklion, Crete, 2005.
Discovery Techniques : Discovery Techniques different techniques available
trade-off: ease-of-provision <-> accuracy
resource descriptions & matchmaking algorithms
Key Word Matching
match natural language key words in resource descriptions
Controlled Vocabulary
ontology-based key word matching
Semantic Matchmaking
… what Semantic Web Services aim at Ease of provision Possible Accuracy
Keyword-based retrieval: UDDI : Keyword-based retrieval: UDDI Service Information by:
provider
services + binding templates
categories
T-Models allow creating specific information models on resources
standard API for finding & retrieving information on services and providers => allows finding all information on available Web Service
=> Web Service usage / integration to be done manually
Semantic Web Services in UDDI : Semantic Web Services in UDDI Mapping semantic resource descriptions into UDDI
OWL-S Service Profile mapping to UDDI
WSMO elements to UDDI mapping (for all top level elements)
mapping semantic descriptions to syntactic repository
allows retrieval of structural information
M. Paolucci, T. Kawamura, T. Payne, and K. Sycara: Importing the Semantic Web into UDDI. In Proc. of E-Services and the
Semantic Web Workshop.
Herzog, R.; Lausen, H.; Roman, D.; Zugmann, P.: WSMO Registry. WSMO Working Draft D10 v0.1, 26 April 2004.
Controlled Vocabulary OWL-S Profile Hierarchies : Controlled Vocabulary OWL-S Profile Hierarchies hierarchy of Web Services
functional similarities (domain, in- / outputs)
allows pre-filtering of services on basis of categorization Web Services E-commerce Book Selling Airline Ticketing Ticketing Event Ticketing Information Web Search Weather http://www.daml.org/services/owl-s/1.0/ProfileHierarchy.owl
Controlled Vocabulary WSMO non-functional properties : Controlled Vocabulary WSMO non-functional properties Ontology keywords in non-functional properties
dc#subject contains main ontology concepts related to Web Service
allows pre-filtering similar to OWL-S Profile Hierarchy, but on basis on ontologies (“controlled vocabulary”) Example
a Web Service for selling train tickets in Austria
dc#subject hasValue _{tc#trainticket, po#purchase, loc#austria}
does not precisely describe Web Service functionality
=> accuracy of discovery result meager
Lara, R., Lausen, H.; Toma, I.: (Eds): WSMX Discovery. WSMX Working Draft D10 v0.2, 07 March 2005.
Semantic Matchmaking : Semantic Matchmaking usability determination on basis of
precise semantic descriptions
OWL-S Profile provides capability description & request
Functional capabilities (what the Web services does)
Quality parameters (how the Web service does it)
Capability description & request are both Profile-based
OWL-S reliance on OWL provides basis for semantic matching
WSMO separates requester and provider viewpoints
WSMO goals describe requester objectives
WSMO capabilities describe WS functionality
Non-functional properties used for security, trust, etc.
OWL-S Profile Matching : OWL-S Profile Matching Adverstisement (service provider) and request described as OWL-S Service Profiles
Matching inputs and outputs of
advertisement and request
Five degrees of match:
Exact
PlugIn R A
Subsumed A R
Intersection (A R)
Fail when disjoint A R
this is ontology-subsumption
matching
Thing Vehicle Car Truck Sedan Coupe subsume plug-in exact Mid-Size Luxury Price M. Paolucci, T. Kawamura, T. Payne, and K. Sycara: Semantic matching of web services capabilities. Proceedings of the
First International Semantic Web Conference, Springer-Verlag, 2002; pp 333-347.
Li, L. and Horrocks, I.: A software framework for matchmaking based on semantic web technology. In Proc.
of the 12th International Conference on the World Wide Web, Budapest, Hungary, May 2003.
WSMO Capabilities: Set-based Modeling : WSMO Capabilities: Set-based Modeling Information Space
all possible instances
of used ontologies capability as state-relation (pre- & post state of service usage)
each capability description element restricts the information space to the set of possible instances that satisfy the element
used in both goals and service descriptions Assumption Effect Precondition Postcondition shared variables computational non-computational pre-state post-state
Matchmaking Notions & Intentions : Matchmaking Notions & Intentions Exact Match:
G, WS, O, M ╞ x. (G(x) <=> WS(x) )
PlugIn Match:
G, WS, O, M ╞ x. (G(x) => WS(x) )
Subsumption Match:
G, WS, O, M ╞ x. (G(x) <= WS(x) )
Intersection Match:
G, WS, O, M ╞ x. (G(x) WS(x) )
Non Match:
G, WS, O, M ╞ ¬x. (G(x) WS(x) ) = G = WS Keller, U.; Lara, R.; Polleres, A. (Eds): WSMO Web Service Discovery. WSML Working Draft D5.1, 12 Nov 2004.
Discovery Approach : Discovery Approach Matchmaking Notion to be used defined for each goal capability element
Basic Procedure: Goal Capability Web Service Capability Assumption Precondition Effect Postcondition Assumption Precondition Effect Postcondition Plug-In Exact Intersection Exact valid pre-state? valid post-state? abort yes no abort yes no Match
Prototype with TA/Flora2 : Prototype with TA/Flora2 Realization
F-Logic Reasoner with Transaction Logic Support
Resource Modeling
Service Capability: set of rules for each element
Goal Capability: pre-state as facts, post-state as queries
State: model of a logical theory (facts & rules)
State-Transitions: Update of the logical theory
Insertion & Deletion of Facts and/or Rules
Matchmaking on basis of current state M. Kifer, R. Lara, A. Polleres, C. Zhao, U. Keller, H. Lausen and D. Fensel: A Logical Framework for Web Service Discovery. Proc. 1st. Intl. Workshop SWS'2004 at ISWC 2004,Hiroshima, Japan, November 8, 2004, CEUR Workshop Proceedings, ISSN 1613-0073 Procedure:
Goal pre-state satisfies Service pre-state?
Insert Goal pre-state into Knowledge Base (KB)
Can KB satisfy Service post-state (hypoth. execution)?
If yes, can Service post-state satisfy Goal post-state?
Prototype with VAMPIRE : Prototype with VAMPIRE Realization
FOL Theorem Prover
Universe as Knowledge Definition:
ontology schemas (concepts, relations, axioms)
generic instances for all concepts and relations
Matchmaking: Proof Obligations
Goal and Service descriptions as logical theories
Matchmaking Notions as Proof Obligations
not bound to DL / LP reasoning support
Universe Definition:
supports matchmaking without knowledge creation / insertion at runtime
handling of incomplete facts (modeling
intention ≠ semantics in logics)
Stollberg, M.; Keller, U.; Fensel. D.: Partner and Service Discovery for Collaboration on the Semantic Web. Proc. 3rd Intl. Conference on Web Services (ICWS 2005), Orlando, Florida, July 2005. Generic Instance Incomplete Facts concept Person [
age ofType integer
sex ofType string] ?x memberOf Person[
age hasValue ?A]
and ?A = 80 . Ontology Goal
Conclusions : Conclusions Discovery as central Semantic Web Services technology
Approaches from OWL-S and WSMO are converging
Integrated Discoverer Architectures admired: Resource Repository
(UDDI or other) Keyword-/ Classification-based
Filtering Controlled Vocabulary
Filtering Semantic
Matchmaking usable Web Service efficient narrowing
of search space
(relevant services
to be inspected) retrieve Serivce
Descriptions invoke Web Serivce
Automatic Service Composition: A Conceptual Perspective : Automatic Service Composition: A Conceptual Perspective Daniela Berardi
based on joint work with Diego Calvanese,
Giuseppe De Giacomo, Maurizio Lenzerini, Massimo Mecella
Composition : Composition Deals with the implementation of an application (in turn offered as a service) whose application logic involves the invocation of operations offered by other services
The new service is the composite service
The invoked services are the component services
Synthesis and Orchestration : Synthesis and Orchestration (Composition) Synthesis: building the specification of the composite service (i.e., the composition schema)
Manual
Automatic
Orchestration: the run-time management of the composite service (invoking other services, scheduling the different steps, etc.)
Composition schema is the “program” to be executed
Similarities with WfMSs (Workflow Management Systems)
Composition Schema : Composition Schema A composition schema specifies the “process” of the composite service
The “workflow” of the service
Different clients, by interacting with the composite service, satisfy their specific needs (reach their goals)
A specific execution of the composition schema for a given client is an orchestration instance
Service Composition System : Service Composition System
Service Composition : Composition Synthesis: Input:
client request
set of available services
Output:
specification of composite service
2. Orchestration:
Input:
specification of composite service
Output:
coordination of available services
according to the composition schema
data flow and control flow monitoring Service Composition How to model client request ? How to model available services ? How to orchestrate the composite service ?
Service Description : Service Description Services export a view of their behavior
I/O interface
Data Access
focus on data
for information gathering
Atomic Actions
focus on actions
world altering services
Complex Behavioral Description
(typically represented using finite states, e.g., TSs) information oriented services services as atomic actions services as processes
The Whole Picture : Composition as (classical) planning The Whole Picture Knoblock’s group Traverso’s group The Roman group Statics of the system Dynamics of component services Dynamics of target service Diagram inspired from Hull&Su 2004 SIGMOD tutorial Hull’s group
Key Dimensions in Service Composition (1) : Key Dimensions in Service Composition (1) Statics of the composition system (i.e., static semantics):
e.g, ontologies of services (for sharing semantics of data/information), inputs and outputs, etc.
Dynamics of component services (i.e., dynamic semantics, process):
e.g., behavioral features, complex forms of dataflow, transactional attitudes, adaptability to varying circumstances
Key Dimensions in Service Composition (2) : Dynamics of the target service (i.e., dynamic semantics, process)
The target service exposed as:
single step
(set of) sequencial steps
(set of) conditional steps
while/loops, running batch
while/loops, running under an external control Key Dimensions in Service Composition (2)
Key Dimensions in Service Composition: the 4thdimension : Key Dimensions in Service Composition: the 4thdimension Degree of (in)completeness in the specification of:
Static Aspects (of the composition system)
Dynamic Aspects (of component services)
Target service specification
Note: Orthogonal to previous dimensions For simplicity not shown in the following slides
What is Addressed from the Technical Point of View? : What is Addressed from the Technical Point of View? Automatic composition techniques?
Which formal tools?
Sound and complete techniques?
Techniques/Problem investigated from computational point of view?
Analyzed Works : Analyzed Works Knoblock’s group (information oriented services)
Composition as Planning (services as atomic actions)
Traverso’s group
McIlraith’s group
Hull’s group
The Roman group as called by Rick Hull in his SIGMOD 2004 tutorial (services as processes)
Knoblock’s Group : Knoblock’s Group available service: data query
basic idea: informative services as views over data sources
each service described in terms of I/O parameters (of course, the latter being provided by the data source), binding patterns and additional constraints on the source
client request:
data query, expressed in terms of inputs provided by the client and requested outputs
Knoblock’s Group : Knoblock’s Group service composition problem:
Input: (i) available services modeled as data-sources, and (ii) client request as user query
Output: (automatically obtained) composite service as integration plan for a generalized user query, so that all the user queries that differ only for intensional input values can be answered by the same (composite) service. Integration plan as a sequence of source queries, taking binding pattern into account
Knoblock’s Group : Knoblock’s Group Statics of the system Dynamics of component services Dynamics of target service
Composition as Planning : Composition as Planning available services: atomic actions
client request: client (propositional) goal
service composition problem: planning problem
Input: (i) client goal (also encodes initial condition)
(ii) available services as atomic actions
Output: composite service as a (possibly conditional) plan, i.e., sequence of actions that transform the initial state into a state satisfying the goal.
Sirin, Parsia, Wu, Hendler & Nau [Sirin etal ICWS03]
ICAPS 2003 Planning for Web Services workshop [P4WS03]
ICAPS 2004 Planning for Web and Grid Services workshop [P4WGS04]
NOTE: the client has not influence over the control flow of the composite service
Example (1) : Example (1) Component Services
S1: True ! {S1:bookFlight} FlightBooked Æ MayBookLimo
MayBookLimo ! {S1:bookLimo} LimoBooked
S2: True ! {S2:bookHotel} HotelBooked
HotelBooked ! {S2:bookShuttle} ShuttleBooked
S3: True ! {S3:bookEvent} EventBooked
Ontology:
TravelSettledUp ´ FlightBooked Æ HotelBooked Æ EventBooked
CommutingSettled ´ ShuttleBooked Ç LimoBooked Ç TaxiAvailablilityChecked
...
Client Service Request:
Find a composition of the actions (i.e., a sequence, a program using such actions as basic instructions) such that a given property is fulfilled
Example (2) : Example (2) Component Services
S1: True ! {S1:bookFlight} FlightBooked Æ MayBookLimo
MayBookLimo ! {S1:bookLimo} LimoBooked
S2: True ! {S2:bookHotel} HotelBooked
HotelBooked ! {S2:bookShuttle} ShuttleBooked
S3: True ! {S3:bookEvent} EventBooked
Ontology:
TravelSettledUp ´ FlightBooked Æ HotelBooked Æ EventBooked
CommutingSettled ´ ShuttleBooked Ç LimoBooked Ç TaxiAvailablilityChecked
...
C