Slide3 : Contents & Timeline MORNING SESSION:
09.00 - 10.00: Introduction to Semantic Web Services
10.00 - 10.30: AM coffee break
10.30 - 12.30: WSMX – system presentation and hands-on
12.30 - 14.00: lunch break
AFTERNOON SESSION:
14.00 - 15.30: IRS & IRS hands-on Part I
15.30 - 16.00: PM coffee break
16.00 - 17.00: IRS & IRS hands-on Part II
17.00: wrap up - closing
INTRODUCTION – Semantic Web Services – : INTRODUCTION – Semantic Web Services – Michael Stollberg
The Vision : Static 500 million users
more than 3 billion pages WWW
URI, HTML, HTTP The Vision
The Vision : WWW
URI, HTML, HTTP Deficiencies in Automated Information Processing
finding
extraction
representation
interpretation
maintenance Semantic Web
RDF, RDF(S), OWL Static The Vision
The Vision : WWW
URI, HTML, HTTP Enable Computing over the Web Semantic Web
RDF, RDF(S), OWL Dynamic Web Services
UDDI, WSDL, SOAP Static The Vision
The Vision : WWW
URI, HTML, HTTP Automated Web Service Usage Semantic Web
RDF, RDF(S), OWL Dynamic Web Services
UDDI, WSDL, SOAP Static Semantic Web
Services The Vision
Web Services : Web Services web-based SOA as new system design paradigm
Deficiencies of WS Technology : Deficiencies of WS 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 Web data interpretation (Semantic Web aspect)
define semantically driven technologies for automation of the Web Service usage process (Web Service aspect)
Slide13 : Web Service Usage Process
The Web Service Modelling Ontology – WSMO – : The Web Service Modelling Ontology – WSMO – Michael Stollberg
Dumitru Roman
Web Service Modeling Ontology : Web Service Modeling Ontology Comprehensive Framework for SESA Semantically Empowered Service-Oriented Architecture
top level notions = SESA core elements
conceptual model + axiomatization
ontology & rule language
International Consortium (mostly European)
started in 2004
78 members from 20 organizations
W3C member submission in April 2005
WSMO Working Groups : WSMO Working Groups Conceptual Model & Axiomatization for SWS Formal Language for WSMO Ontology & Rule Language for the Semantic Web Execution Environment for WSMO www.wsmo.org
WSMO Top Level Notions : WSMO Top Level Notions Objectives that a client wants to
achieve by using Web Services 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 W3C submission 13 April 2005
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 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 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
Specification Language: WSML : Specification Language: WSML
WSML Conceptual Syntax : WSML Conceptual Syntax wsmlVariant _”http://www.wsmo.org/wsml/wsml-syntax/wsml-flight”
namespace {_”http://www.example.org/example#”,
dc _”http://purl.org/dc/elements/1.1/”}
ontology _”http://www.example.org/exampleOntology”
concept ID
attr1 ofType A
[...]
goal _”http://www.example.org/exampleGoal”
[...]
webService _”http://www.example.org/exampleWS”
[...]
WSML Logical Expressions : WSML Logical Expressions Frame- and FOL based concrete syntax
Elements:
Function symbols (e.g. f())
Molecules (e.g. Human subClassOf Animal, John memberOf Human, John[name hasValue “John Smith”]).
Predicates (e.g. distance(?x,?y,?z))
Logical connectives (or, and, not, implies, equivalent, impliedBy, forall, exists)
Example:
?x memberOf Human equivalent
?x memberOf Animal and ?x memberOf LegalAgent.
WSMO Web Services : WSMO Web Services 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 data level mismatch resolution
WG Mediator: link to a Goal wherefore service is not usable a priori
Shared Variables: scope is entire capability
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)
Example VTA Web Service : Example VTA Web Service Web service for booking tickets or complete trips
WSMO capability precondition capability VTAcapability
sharedVariables {?item, ?passenger, ?creditCard, ?initialBalance, ?reservationPrice}
precondition
definedBy
exists ?reservationRequest
(?reservationRequest[
reservationItem hasValue ?item,
passenger hasValue ?passenger,
payment hasValue ?creditcard]
memberOf tr#reservationRequest and
(?item memberOf tr#trip or ?item memberOf tr#ticket) and
?passenger memberOf pr#person and
?creditCard memberOf po#creditCard and
(?creditCard[type hasValue po#visa] or
?creditCard[type hasValue po#mastercard]) ) .
Example VTA Web Service : Example VTA Web Service WSMO capability assumption:
the provided credit card is valid
the balance of the credit card before executing the service is higher than the price of the reservation (= purchased item) that is retrieved after executing the Web service. assumption
definedBy
po#validCreditCard(?creditCard) and
?creditCard[balance hasValue ?initialBalance] and
(?initialBalance >= ?reservationPrice) .
Example VTA Web Service : Example VTA Web Service capability description (post-state) postcondition
definedBy
exists ?reservation(?reservation[
reservationItem hasValue ?item,
price hasValue ?reservationPrice,
customer hasValue ?passenger,
payment hasValue ?creditcard]
memberOf tr#reservation and
?reservationPrice memberOf tr#price) .
effect
definedBy
?creditCard[po#balance hasValue ?finalBalance] and
(?finalBalance = (?initialBalance - ?reservationPrice)).
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
Ontologized Abstract State Machines : Ontologized Abstract State Machines Description
Vocabulary:
ontology constructs 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:
state transition
general structure: if (condition) then (update)
condition on current state, update = changes in state transition
all GT(ω) whose condition is fulfilled fire in parallel
Usage:
partners A, B commence interaction with empty ΩA, ΩB
ΩA, ΩB are updated via Guarded Transitions in each state
interaction termination state when A, B have no further transition rules
Example Hotel Web Service : Example Hotel Web Service choreography interface (state signature) interface htl#BookHotelInterface
choreography
stateSignature
importsOntology htl#simpleHotelOntology
in
htl#HotelRequest withGrounding _"http://...",
htl#HotelConfirm withGrounding _"http://...",
htl#HotelCancel withGrounding _"http://..."
out
htl#HotelNotAvailable withGrounding _"http://...",
htl#HotelOffer withGrounding _"http://..."
shared
htl#Hotel,
htl#HotelAvailable,
htl#HotelBooked
Example Hotel Web Service : Example Hotel Web Service choreography interface (transition rules) ctl_state {htl#start,htl#offerMade,htl#noAvail,htl#confirmed,htl#cancelled}
transitionRules
if (ctl_state = htl#start) then
forall {?req,?date,?loc,?client} with
?req[trv#date hasValue ?date, trv#location hasValue ?loc,
htl#client hasValue ?client] memberOf htl#HotelRequest
do
add(htl#offer(?req)[trv#date hasValue ?date,
trv#hotelName hasValue ?name, trv#location hasValue ?loc,
htl#client hasValue ?client] memberOf htl#HotelOffer)
ctl_state := htl#offerMade
|
add(htl#notAvailable(?req)[trv#date hasValue ?date,
trv#location hasValue ?loc] memberOf htl#HotelNotAvailable)
ctl_state := htl#noAvail
endForall
endIf
WSMO Goals : WSMO Goals 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
Goal-driven Approach, derived from AI rational agent approach
ontological de-coupling of Requester and Provider
‘intelligent’ mechanisms detect suitable services for solving the Goal
service re-use & knowledge-level client side support
Usage of Goals within Semantic Web Services
A Requester (human or machine) defines a Goal to be resolved independently (i.e. subjectively) on the knowledge level
SWS techniques / systems automatically determine Web Services to be used for resolving the Goal (discovery, composition, execution, etc.)
Goal Resolution Management is realized in implementations client objective specification along with all
information needed for automated resolution
Goal-driven Architecture : Goal-driven Architecture Goal
objective (desired final state)
input for service usage
goal resolution constraints,
preferences, and policies Goal Resolution Plan
- goal resolution algorithm
decomposition (optional)
service usage / invocation corresponds to /
creation of defines (Web) Service
Implementation
(not of interest here)
functional behavioral service detection & composition Client-Side Service-Side Domain Knowledge Ontology Ontology Ontology Ontology service usage
Goal Specification :
Item Description & Terminology Import
non-functional properties
imported Ontologies & used mediators
Requested Capability
specifies objective (with PAPE)
instantiation for concrete request (concrete input data)
Client Choreography
counterpart of Web service choreography interface
for invocation and consumption of Web services
one for each usable Web service
described as a WSMO choreography
Goal Decomposition
defines “desired workflow”
collection of subgoals with control- & data flow
described as WSMO orchestration
Goal Specification
Web Service Discovery : Web Service Discovery detect directly usable Web services
out of available ones
Discovery Techniques
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
Selection: choose most appropriate Web Service with respect to:
Quality of Service (security, robustness, availability)
context (regional, business / social communities)
preferences and policies
financial
… Ease of provision Attainable Accuracy
Semantic Matchmaking : Semantic Matchmaking 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.
Web Service Composition : Web Service Composition combine several Web services
for solving a request
composition of Web services is needed
if no directly usable Web service exists …
a WS can satisfy goal, but goal cannot invoke WS
several WS need to be combined in order to achieve goal
composition techniques:
functional = suitable composition wrt functionalities
behavioral = suitable composition wrt behavioral interfaces
need to be integrated:
skeleton by functional composition
refinement + executable code by behavioral composition
Choreography Discovery : internal business logic of Web Service
(not of interest in Service Interface Description) Choreography Discovery internal business logic of Web Service
(not of interest in Service Interface Description) a valid choreography exists if:
1) Signature Compatibility
homogeneous ontologies
compatible in- and outputs
2) Behavior Compatibility
start state for interaction
a termination state can be reached without any additional input
Behavior Compatibility Example : Behavior Compatibility Example ΩG(ωØ) = {Ø} ΩG(ω1) = {request(out)} ΩG(ω2a) =
{offer(in), changeReq(out)} if Ø then request ΩVTA(ωØ) = {Ø} ΩVTA(ω1) =
{request(in), offer(out)} if request then offer if cnd1(offer) then changeReq ΩG(ω2b) =
{offer(in), order(out)} if cnd2(offer) then order ΩVTA(ω2a) =
{changeReq(in),offer(out)} if changeReq then offer ΩVTA(ω2b) =
{order(in), conf(out)} if order then conf ΩG(ω3) = {offer(in), conf(in)} if conf then Ø Goal Choreography Interface WS Choregraphy Interface
WSMO Mediators : WSMO Mediators 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 resolve mismatches independent of content
mediation cannot be fully automated (integration decision)
Levels of Mediation within Semantic Web Services:
(0) Representation: heterogeneous Languages & Protocols
Data Level: heterogeneous Data Sources
Functional Level: heterogeneous Functionalities
Process Level: heterogeneous Communication Processes
Representation & Protocol Level Mediation : Representation & Protocol Level Mediation interoperability problems due to
different representation formalisms
different technical communication protocols
adaptors for transformation
syntactic transformation
mappings between language constructs
usage:
interoperability between systems with different languages (e.g. OWL – WSML, etc.)
grounding for Semantic Web services (lifting & lowering between syntactic and semantic level)
Data Mediation Techniques : Data Mediation Techniques Ontology Integration Techniques
semi-automatic
human intervention needed for “integration decision
graphical support for ontology mapping as central technique
Functional Level Mediation : Functional Level Mediation requested and provided functionalities do not match precisely
=> conditions under which Web Service is usable for solving a Goal
usage constraint explication
goal refinement
goal adjustment
delta-relations = relation & difference of functional descriptions
Process Level Mediation : Process Level Mediation not a priori compatible behavior interfaces for communication & information interchange
partially resolvable by “process mediation patterns”
WSMO Mediators Overview : WSMO Mediators Overview OO Mediator O O / G /
WS / M 1 .. n 1 GG Mediator G G 1 .. n 1 ..n WG Mediator G xor WS WS xor G 1 .. n 1 ..n Process Level
(Communication) WW Mediator WS WS 1 1 ..n terminology representation & protocol Δ-Relation Mediation data level mediation Δ-Relation Mediation Process Level
(Communication) Δ-Relation Mediation technique used imports / reuses correlation Legend Process Level
(Cooperation)
Other Approaches : Other Approaches WSMO is not the only proposal for an SWS Framework …
OWL-S:
upper ontology for semantically describing Web services
chronologically first, consortium mainly USA
SWSF:
process model for Web Services
result of SWSI (international working group)
WSDL-S:
semantic annotation of WSDL descriptions
LSDIS Lap (Amit Seth Group) and IBM
Discussed here:
Central Features
Commonalities and Differences
OWL-S : OWL-S Upper Ontology for Web Service Descriptions capability description (IOPE)
non-functional properties
usage: (1) WS advertisement, (2) WS request formulation specification of service access information
builds upon WSDL to define message structure and physical binding layer
specifies communication protocols & language, transport mechanisms, etc. describes internal processes of the service
defines service interaction protocol for (a) consumption and (b) WS interaction
process types: simple, atomic, composite
specifies: (1) abstract messages (ontological content), (2) control flow constructs, (3) perform construct
OWL-S and WSMO : OWL-S and WSMO OWL-S = ontology and language to describe Web services
WSMO = ontology and language for core elements of Semantic Web Service systems
OWL-S Profile ≈ WSMO capability +
non-functional properties OWL-S Grounding current WSMO Grounding OWL-S Process Model WSMO Service Interfaces Main Description Elements Correlation: Goals and Mediators not in scope
deficiencies in Service Model (process description model / language not adequate) => SWSF
OWL and WSML : OWL and WSML WSML aims at overcoming deficiencies of OWL 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
SWSF : SWSF Process Model for Web Services (FLOWS)
although self-contained, commonly understood as extension of OWL-S / refinement of Service Model
WSDL-S : WSDL-S Semantic annotation of WSDL descriptions
annotate XML Schema with domain ontology
pre-conditions & effects for operations
WS categorization by ontology-based keywords
Commonalities & Differences : Commonalities & Differences similar ontological structure for WS descriptions
Functional Descriptions (preconditions & effects)
Behavioral Descriptions (consumption and interaction)
Grounding to WSDL (automated execution)
central conceptual differences
formal models for capabilities
interfaces vs. business process
behavioral aspects:
state-based process models operation-level capabilities
WSMO defines “core elements for SESA” while all others are only concerned with describing Web Services
The Web Service Execution Environment WSMX : The Web Service Execution Environment WSMX Omair Shafiq
WSMX Introduction : WSMX Introduction Software framework for runtime binding of service requesters and service providers
WSMX interprets service requester’s goal to
discover matching services
select (if desired) the service that best fits
provide mediation (if required)
make the service invocation
Is based on the conceptual model provided by WSMO
Has a formal execution semantics
Service Oriented and event-based architecture
based on microkernel design using technologies as J2EE, Hibernate, Spring, JMX, etc.
WSMX Motivation : WSMX Motivation Middleware ‘glue’ for Semantic Web Services
Allow service providers focus on their business
Reference implementation for WSMO
Eat our own cake
Environment for goal based discovery and invocation
Run-time binding of service requester and provider
Provide a flexible Service Oriented Architecture
Add, update, remove components at run-time as needed
Keep open-source to encourage participation
Developers are free to use in their own code
Define formal execution semantics
Unambiguous model of system behaviour
WSMX Usage Scenario : WSMX Usage Scenario
WSMX Usage Scenario - P2P : WSMX Usage Scenario - P2P A P2P network of WSMX ‘nodes’
Each WSMX node described as a SWS
Communication via WSML over SOAP
Distributed discovery – first aim
Longer term aim - distributed execution environment
WSMX Usage Scenario - P2P : WSMX Usage Scenario - P2P
Design Principles : Design Principles Strong Decoupling & Strong Mediation
autonomous components with mediators for interoperability
Interface vs. Implementation
distinguish interface (= description) from implementation (=program)
Peer to Peer
interaction between equal partners (in terms of control) WSMO Design Principles == WSMX Design Principles == SOA Design Principles
Benefits of SOA : Benefits of SOA Better reuse
Build new functionality (new execution semantics) on top of existing Business Services
Well defined interfaces
Manage changes without affecting the Core System
Easier Maintainability
Changes/Versions are not all-or-nothing
Better Flexibility
Service Oriented State : Service Oriented State The interface to the service is implementation-independent
The service can be dynamically invoked
Runtime binding
The service is self-contained
Maintains its own state
Messaging : Messaging Messaging is peer-to-peer facility
Distributed communication
Loosely coupled
Sender does not need to know receiver (and vice versa)
Asynchronous mechanism to communicate between software applications
WSMX Architecture : WSMX Architecture
Messaging Application Management Service Oriented
Architectures
Selected Components : Selected Components Adapters
Parser
Invoker
Choreography
Process Mediator
Discovery
Data Mediator
Resource Manager
Reasoning
Adapters : Adapters To overcome data representation mismatches on the communication layer
Transforms the format of a received message into WSML compliant format
Based on mapping rules RosettaNet 2 WSML WSML 2 RosettaNet EDI 2 WSML WSML 2 EDI UBL 2 WSML WSML 2 UBL Inward Outward Adapter Pool Adapter Manager / Selector Validator ( Message , Protocol ) ... ... ... ... ... ... 2 WSML 2 WSML 2 WSML WSML 2 WSML 2 WSML 2 Metadata Repository
Parser : Parser WSML compliant parser
Code handed over to wsmo4j initiative http://wsmo4j.sourceforge.net/
Validates WSML description files
Compiles WSML description into internal memory model
Stores WSML description persistently (using Resource Manager)
Communication Mgr – Invoker : Communication Mgr – Invoker WSMX uses
The SOAP implementation from Apache AXIS
The Apache Web Service Invocation Framework (WSIF)
WSMO service descriptions are grounded to WSDL
Both RPC and Document style invocations possible
Input parameters for the Web Services are translated from WSML to XML using an additional XML Converter component. Network Invoker Apache AXIS XML Converter Mediated WSML Data XML Web Service SOAP
Choreography : Choreography Requester and provider have their own observable communication patterns
Choreography part of WSMO
Choreography instances are loaded for the requester and provider
Both requester and provider have their own WSMO descriptions
Choreography Engine
Evaluation of transition rules - prepares the available data
Sends data to the Process Mediator - filters, changes or replaces data
Receives data from PM and forwards it to the Communication manager - data to be finally sent to the communication partner
Process Mediator : Process Mediator Requester and provider have their own communication patterns
Only if the two match precisely, a direct communication may take place
At design time equivalences between the choreographies’ conceptual descriptions is determined and stored as set of rules
The Process Mediator provides the means for runtime analyses of two choreography instances and uses mediators to compensate possible mismatches
Process Mediator – Addressed mismatches : Process Mediator – Addressed mismatches
Discovery : Discovery Responsible for finding appropriate Web Services to achieve a goal (discovery)
Current discovery component is based on simple matching
Keywords identified in the NFP of the goal
Matched against NFPs of the published WSs
Variable set of NFPs to be considered for this process
To be extended
Values in NFPs might be concepts from ontologies
More elaborate string matching algorithms
Advanced semantic discovery in prototypical stage
Discovery : Discovery 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 Service
Descriptions invoke Web Service
Data Mediator : Data Mediator Ontology-to-ontology mediation
A set of mapping rules are defined and then executed
Initially rules are defined semi-automatic
Create for each source instance the target instance(s)
Design-time : Design-time Inputs
Source Ontology and Target Ontology
Features
Graphical interface
Set of mechanism towards semi-automatic creation of mappings
Capturing the semantic relationships identified in the process
Storing these mappings in a persistent storage
Output
Abstract representation of the mappings
Design-time Phase : Design-time Phase
Design-time Phase - Approach, Decomposition and Mapping Context : Design-time Phase - Approach, Decomposition and Mapping Context Bottom-up -> training set
Top-down -> decomposition, context
Ontology Mapping Language : Ontology Mapping Language Language Neutral Mapping Language
mapping definitions on meta-layer (i.e. on generic ontological constructs)
independent of ontology specification language
“Grounding” to specific languages for execution (WSML, OWL, F-Logic)
Main Features:
Mapping Document (sources, mappings, mediation service)
direction of mapping (uni- / bidirectional)
conditions / logical expressions for data type mismatch handling, restriction of mapping validity, and complex mapping definitions
mapping constructs (ex: classMapping, classAtrributeMapping, instanceMapping)
mapping operators
Mapping Language Example : Ontology O2
Mapping Language Example Human
- name Adult Child Person
name
age michael memberOf Person
name = Michael Stollberg
age = 28 classMapping(unidirectional o2:Person o1.Adult
attributeValueCondition(o2.Person.age >= 18)) this allows to transform the instance ‘michael’ of concept person in
ontology O2 into a valid instance of concept ‘adult’ in ontology O1 Ontology O1
Run-Time Data Mediator : Run-Time Data Mediator Main Mediation Scenario: Instance Transformation
Inputs
Incoming data
Source ontology instances
Features
Completely automatic process
Grounding of the abstract mappings to a concrete language
WSML
Uses a reasoner to evaluate the mapping rules
MINS
Outputs
Mediated data
Target ontology instances
Resource Manager : Resource Manager Stores internal memory model to a data store
Decouples storage mechanism from the rest of WSMX
Data model is compliant to WSMO API
Independent of any specific data store implementation i.e. database and storage mechanism
Reasoner : Reasoner Mins
Datalog + Negation + Function Symbols Reasoner Engine
Features
Built-in predicates
Function symbols
Stratified negation WSMO4J
validation, serialization and parsing
WSML2Reasoner
Reasoning API
mapping fromWSML to a vendor-neutral rule representation
Contains:
Common API for WSML Reasoners
Transformations of WSML to tool-specific input data (query answering or instance retrieval)
WSML-DL-Reasoner
Features:
T-Box reasoning (provided by FaCT++)
Querying for all concepts
Querying for the equivalents, for the children, for the descendants, for the parents and for all ancestors of a given concept
Testing the satisfiability of a given concept with respect to the knowledge base
Subsumption test of two concepts with respect to the knowledge base
Wrapper of WSML-DL to the XML syntax of DL used in the DIG interface
System Entry Points : System Entry Points
achieveGoal (WSMLDocument): Context
getWebServices (WSMLDocument): Context
invokeWebService (WSMLDocument, Context): Context
Define “Business” Process : Define “Business” Process
Generate Wrappers for Components : Generate Wrappers for Components
Context Data : Context Data
Event-based Implementation : Event-based Implementation
Web Services Modeling Toolkit : Web Services Modeling Toolkit The aim of the Web Services Modeling Toolkit (WSMT) is to provide high-quality tools for designing, mediating and using Semantic Web Services, through the WSMO paradigm.
The focus is currently on the following areas:
Creation of ontologies, web services, goals and mediators in WSMO
Creation of mappings between pairs of ontologies to allow runtime instance transformation
Management of Execution Environments for Semantic Web Services like WSMX and IRSIII
WSML Perspective : WSML Perspective Perspectives in the Eclipse framework allow for a number of Editors and views to be grouped and positions.
The WSML perspective offers editors and views related to engineering of semantic descriptions in WSMO through the WSML language.
Other General features include:
WSML file validation
Problems view (errors and warnings on files in the workspace)
Label highlighting (marking of errors and warnings in navigator view)
WSML Perspective: Editors & Views : WSML Perspective: Editors & Views Editors
WSML Text Editor
WSML Conceptual Editor
WSML Visualizer
Views
Navigator view
Problems view
WSML Reasoner
WSML Perspective: Editors & Views : Editors
WSML Text Editor
WSML Conceptual Editor
WSML Visualizer
Views
Navigator view
Problems view
WSML Reasoner WSML Perspective: Editors & Views
WSML Perspective: Editors & Views : Editors
WSML Text Editor
WSML Conceptual Editor
WSML Visualizer
Views
Navigator view
Problems view
WSML Reasoner WSML Perspective: Editors & Views
WSML Perspective: Editors & Views : Editors
WSML Text Editor
WSML Conceptual Editor
WSML Visualizer
Views
Navigator view
Problems view
WSML Reasoner WSML Perspective: Editors & Views
WSML Perspective: Editors & Views : Editors
WSML Text Editor
WSML Conceptual Editor
WSML Visualizer
Views
Navigator view
Problems view
WSML Reasoner WSML Perspective: Editors & Views
WSML Perspective: Editors & Views : Editors
WSML Text Editor
WSML Conceptual Editor
WSML Visualizer
Views
Navigator view
Problems view
WSML Reasoner WSML Perspective: Editors & Views
WSML Perspective: Editors & Views : Editors
WSML Text Editor
WSML Conceptual Editor
WSML Visualizer
Views
Navigator view
Problems view
WSML Reasoner WSML Perspective: Editors & Views
Abstract Mapping Language: Editors & Views : Abstract Mapping Language: Editors & Views Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View
Abstract Mapping Language: Editors & Views : Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View Abstract Mapping Language: Editors & Views
Abstract Mapping Language: Editors & Views : Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View Abstract Mapping Language: Editors & Views
Abstract Mapping Language: Editors & Views : Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View Abstract Mapping Language: Editors & Views
Abstract Mapping Language: Editors & Views : Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View Abstract Mapping Language: Editors & Views
Abstract Mapping Language: Editors & Views : Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View Abstract Mapping Language: Editors & Views
Abstract Mapping Language: Editors & Views : Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View Abstract Mapping Language: Editors & Views
Abstract Mapping Language: Editors & Views : Editors
AML Text Editor
AML Conceptual Editor
AML View Based Editor
Views
Concept 2 Concept View
Attribute 2 Attribute View
Concept 2 Attribute View
Attribute 2 Concept View
Status View Abstract Mapping Language: Editors & Views
Conclusions : Conclusions Conceptual model is WSMO
End to end functionality for executing SWS
Has a formal execution semantics
Real implementation
Open source code base at SourceForge
http://sourceforge.net/projects/wsmx/
Event-driven component architecture
WSMT – emerging tool to handle semantics
Slide110 : WSMX Hands-on Session overview Download URL: www.wsmo.org/TR/d17/tutorials/aswc06-swstutorial.html Omair Shafiq
Emilia Cimpian
Dumitru Roman
Michal Zaremba
Use Case : Use Case Blue company
Service Requestor, wants to buy computers and accessories
Moon company
Service Provider, selling computer products
WSMX
Acting as middleware to bring together Blue and Moon companies and to manage conversation between them
Why WSMX ? : Why WSMX ? Blue company wants to buy computers but does not know any vendors
Service discovery required
Blue does not want to change the data format with which it communicates or the order of the messages it exchanges
Data mediation and process mediation required
Blue does not want to be bound to any one provider
Application Scenario : Application Scenario WSMO Goal
Description WSMO Service
Description
Discovery Scenario Overview : Discovery Scenario Overview Blue’s Goal
Purchase:
20 power supplies for IBM R50 Notebooks
20 SDRAM modules à 512 MB.
Shipment
5 Notebooks R50 to customer in Bristol, UK
Moon’s Service
Sells and ships computers and accessories
Interaction Scenario : Interaction Scenario
Solution: Overview of Integration Stages : Solution: Overview of Integration Stages 1 – Sending Request
Blue sends PO request
2 – Discovery and Conversation Setup
Discovery of service, setup of conversation
3 – Conversation with Requestor
Blue RosettaNet System: accepting purchase order request
4 – Conversation with Provider
CRM and OMS systems: opening order, adding line items, closing order
5 – Conversation with Requestor
order confirmation, end of conversation
Implementation & Demonstration : Implementation & Demonstration Blue company Moon company
The Internet Reasoning Service IRS III : The Internet Reasoning Service IRS III John Domingue
Liliana Cabral
Slide119 : The Internet Reasoning Service is an infrastructure for publishing, locating, executing and composing Semantic Web Services
Design Principles : Design Principles Ontological separation of User and Web Service Contexts
Capability Based Invocation
Ease of Use
One Click Publishing
Agnostic to Service Implementation Platform
Connected to External Environment
Open
Complete Descriptions
Inspectable
Interoperable with SWS Frameworks and Platforms
Features of IRS-III (1/2) : Features of IRS-III (1/2) Based on Soap messaging standard
Provides Java API for client applications
Provides built-in brokering and service discovery support
Provides capability-centred service invocation
Features of IRS-III (2/2) : Features of IRS-III (2/2) Publishing support for variety of platforms
Java, Lisp, Web Applications, Java Web Services
Enables publication of ‘standard code’
Provides clever wrappers
One-click publishing of web services
Integrated with standard Web Services world
Semantic web service to IRS
‘Ordinary’ web service
IRS-III Framework : IRS-III Framework
IRS-III Architecture : IRS-III Architecture LispWeb Server IRS-III Server WS Publisher Registry SOAP Handler SOAP Publishing Platforms Web Service Java Code Web Application SOAP WSMO
Studio
Publishing Platform Architecture : Publishing Platform Architecture IRS-III Publishing Platform HTTP Server SOAP Handler Service Registrar Service
Invoker WS Service Registry IRS-III Server Invocation Client SOAP SOAP SOAP Web Service 1 Web Service 2 Web Service 3
IRS-III/WSMO differences : IRS-III/WSMO differences Underlying language OCML
Goals have inputs and outputs
IRS-III broker finds applicable web services via mediators
Used mediator within WS capability
Mediator source = goal
Web services have inputs and outputs ‘inherited’ from goal descriptions
Web service selected via assumption (in capability)
SWS Creation & Usage Steps : SWS Creation & Usage Steps Create a goal description
(e.g. exchange-rate-goal)
Add input and output roles
Include role type and soap binding
Create a wg-mediator description
Source = goal
Possibly add a mediation service
Create a web service description
Used-mediator of WS capability = wg-mediator above
Specify Operation <-> Lisp function mapping in Choreography Grounding
Publish against web service description
Invoke web service by ‘achieve goal’
Multiple Web Services for goal : Multiple Web Services for goal Each WS has a mediator for used-mediator slot of capability
Some WS may share a mediator
Define a kappa expression for assumption slot of WS capability
Kappa expression format
(kappa (?ws) )
Getting the value of an input role
(wsmo-role-value ?ws )
Defining a Mediation Service : Defining a Mediation Service Define a wg-mediator
Mediation-service -> WSMO Goal
Mediation goal
Mediation goal input roles are a subset of wg-mediator source goal input roles
Define corresponding mediator and WS for the mediation goal above
Valid Relations : Valid Relations Classes are unary relations
e.g. (country ?x)
Slots are binary relations
e.g. (is-capital-of ?x ?y)
Standard relations in base (OCML toplevel) ontology
=, ==, <, >, member
European Currency Assumption : European Currency Assumption (kappa (?ws)
(member
(wsmo-role-value ?ws
'has_source_currency)
'(euro pound)))
Goal Based Invocation : Goal Based Invocation Instantiate Goal Description
Exchange-rate-goal
Has-source-currency: us-dollars
Has-target-currency: pound Web Service Discovery
European-exchange-rate-ws
Non-european-exchange-rate-ws
European-bank-exchange-rate-ws Solve Goal Goal -> WG Mediator -> WS/Capability/Used-mediator Web service selection
European-exchange-rate Mediate input values
‘$’ -> us-dollar WS -> Capability -> Assumption
expression Mediation Invoke selected web service
European-exchange-rate Invocation
WSMO Studio : WSMO Studio Integrated Service Environment for WSMO
Provide easy to use GUI for various WSMO tasks
Working with ontologies
Creating WSMO descriptions: goals, services, mediators
Creating WSMO centric orchestration and choreography specifications
Import (export) from (to) various formats
Front-end for ontology and service repositories
Front-end for runtime SWS environments (WSMX, IRS-III)
http://www.wsmostudio.org
WSMO Studio : WSMO Studio Java based implementation
Open Source core
LGPL
3rd party contributors are free to choose their respective licensing terms
Modular design
an Eclipse based plug-in architecture
Extensible
3rd parties may contribute new functionality (plug-ins) or modify existing functionality
Editing a Goal in WSMO Studio : Editing a Goal in WSMO Studio
WSMO Studio view onto IRS-III : WSMO Studio view onto IRS-III
Hands-On Session with IRS III : Hands-On Session with IRS III Liliana Cabral
John Domingue
European Travel Scenario : European Travel Scenario
European Travel Demo : European Travel Demo
Goal Description in Tutorial : Goal Description in Tutorial Goal Capability Interface Precondition Assumption Postcondition Effect Choreography Orchestration State Signature Transition Rules State Signature The steps that go into describing a goal in the tutorial are:
Ontological description of the communications (request and response);
Creation of a goal;
Attachment of a choreography; Attachment of a state signature
Attachment of communications to state signature:
request as OUT mode; response as IN mode
Web Service Description in Tutorial : Web Service Description in Tutorial The steps that go into describing a service in the tutorial are:
Ontological description of the communications (may be reused from goal);
Creation of a service; possibly attachment of an assumption
Attach a used-mediator (wg-mediator);
Attachment of a choreography; Attachment of a state signature
Attachment of communications to state signature
request as IN mode, grounded to LISP function;
response as OUT mode Capability Interface Precondition Assumption Postcondition Effect Choreography Orchestration State Signature Transition Rules Web Service
Mediator Description in Tutorial : Mediator Description in Tutorial The steps that go into describing a mediator in the tutorial are:
Creation of a wg-mediator (possibly involving a mediation service);
The mediation service is another SWS (goal, mediator, and ws descriptions)
Attachment of a source (the goal defined before) WG-Mediator Source Target Mediation Service Mapping Rules
IRS-III Hands On Task : IRS-III Hands On Task Develop the SWS for an application for the European Travel scenario. The application should support a person booking a train ticket between 2 European cities at a specific time and date
The following WSMO Studio tasks are involved:
Retrieve domain ontologies from IRS;
Create WSML ontology concepts to describe communications;
Create WSMO descriptions for Goals, WG-mediators and Web service descriptions;
Export these definitions to the IRS;
Create WSML ontology instances of the requests;
Achieve the goals against these instances.
Tutorial Setup : Tutorial Setup Travel Services
(3001) IRS Lisp Publisher IRS Server
(3000) Domain Models WSMO Studio
Travel Related Knowledge Models : Travel Related Knowledge Models
Key Classes, Relations, Instances : Key Classes, Relations, Instances Is-in-country e.g.
(is-in-country berlin germany) -> true
(student ) -> true, for john matt michal
(business-person ) -> true, for liliana michael
Goals : Goals 1- Get train timetable
Inputs: origin and destination cities (city), date (date-and-time, e.g. (18 4 2004))
Output: timetable (string)
2- Book train
Inputs: passenger name (person), origin and destination cities, departure time-date (list-date-and-time, e.g. (20 33 16 15 9 2004))
Output: booking information (string)
Services : Services 1 service available for goal 1
No constraints
6 services available for goal 2
As a provider write the constraints applicable to the services to satisfy the goal (assumption logical expressions)
1 wg-mediator mediation-service
Used to convert time in list format to time in universal format
Service constraints : Service constraints Services 2-5
Services for (origin and destination) cities in determined countries
Service 4-5
Need a mediation service to map goal time-date to service time-date
Services 6-7
Services for students or business people in Europe
Available Functions (1/3) : Available Functions (1/3) 1- get-train-times
paris london (18 4 2004)
"Timetable of trains from PARIS to LONDON on 18, 4, 2004
5:18
…23:36"
2- book-english-train-journey
christoph milton-keynes london (20 33 16 15 9 2004)
"British Rail: CHRISTOPH is booked on the 66 going from MILTON-KEYNES to LONDON at 16:49, 15, SEPTEMBER 2004. The price is 169 Euros."
3- book-french-train-journey
sinuhe paris lyon (3 4 6 18 8 2004)
"SNCF: SINUHE is booked on the 511 going from PARIS to LYON at 6:12, 18, AUGUST 2004. The price is 27 Euros."
Available Functions (2/3) : Available Functions (2/3) 4- book-german-train-journey
christoph berlin frankfurt 3304251200
"First Class Booking German Rail (Die Bahn): CHRISTOPH is booked on the 323 going from BERLIN to FRANKFURT at 17:11, 15, SEPTEMBER 2004. The price is 35 Euros."
5- book-austrian-train-journey
sinuhe vienna innsbruck 3304251200
"Austrian Rail (OBB): SINUHE is booked on the 367 going from VIENNA to INNSBRUCK at 16:47, 15, SEPTEMBER 2004. The price is 36 Euros. "
Available Functions (3/3) : Available Functions (3/3) 6- book-student-european-train-journey
john london nice (3 4 6 18 8 2004)
"European Student Rail Travel: JOHN is booked on the 916 going from LONDON to NICE at 6:44, 18, AUGUST 2004. The price is 94 Euros. "
7- book-business-european-train-journey
liliana paris innsbruck (3 4 6 18 8 2004)
"Business Europe: LILIANA is booked on the 461 going from PARIS to INNSBRUCK at 6:12, 18, AUGUST 2004.
The price is 325 Euros."
8- mediate-time (lisp function) or
JavaMediateTime/mediate (java)
(9 30 17 20 9 2004)
3304686609
Wrap-Up Standardization Market Prospect Future Issues : Wrap-Up Standardization Market Prospect Future Issues Michael Stollberg
Tutorial Wrap-up : Tutorial Wrap-up The targets of the presented tutorial were to:
understand aims & challenges within Semantic Web Services
understand WSMO and other frameworks
design principles & paradigms
core elements
commonalities and differences
understand semantic techniques for automated Web service usage
and give:
.. Semantic Web Service Tools and System Presentation
.. do-it-yourself Hands-On Session
=> you should now be able to assess technologies & products for Semantic Web Services and utilize these for your future work
History I : History I late 90s: TBL wants the Internet to develop further
HTML is unstructured => not processable by machines
New kinds of Web Technologies needed
=> “turn the internet from a world-wide information repository for human consumption into a device of world-wide distributed computation” (Fensel & Bussler, WSMF)
American Scientific Article “The Semantic Web”
Pete & Lucy: a future example
Core Technologies:
Ontologies: unambiguous terminology definition in machine- readable format (“Semantics”)
Web Services: functionality evocable over the Internet, re-usable and combinable distributed software components
Agents: electronic representatives that perform tasks on behalf of his owner
Rising attention in Research & Industry ..
History II : History II 1999: first W3C Recommendations
Specifications of XML Technologies (XSL, XTL,…)
Semantic Web Layer Cake
Languages: XML, RDF
2000 – 2001: first R&D-activities
1. Web Service Technology Specifications: SOAP, WSDL, UDDI
related research areas become interested (AI / Knowledge Engineering; distributed computing, etc.), first projects: DAML (US), OnToKnowledge, etc.
“1st Semantic Web Working Symposium”, Stanford (USA), ca. 100 participants
2002 – 2003: research & industry sets off
SDK-Cluster (Europe), DAML efforts (USA)
initial research results, still very chaotic / without a “framework”
industrial efforts on Web services
ISWC 02 / 03: double number of participants each year
2004 ff: the hot phase
W3C recommendations (OWL, XML + RDF revisions, others)
first set of research & development results
rising industrial & commercial attention
Standardization Efforts W3C : Standardization Efforts W3C 1st set of recommendations in 1999 / 2000, currently revised
Semantic Web Services
Member Submissions: OWL-S, WSMO, SWSF, WSDL-S
Working Groups:
Semantic Web Service Interest Group
Semantic Annotations for WSDL Group
=> standardization need acknowledged, but no agreement yet on what & how
Layer Cake - Revised : Layer Cake - Revised W3C Semantic Web Language Layer Cake
revised version, Tim-Berners-Lee 2005
Industrial Efforts : Industrial Efforts Semantics & SOA Developments
Microsoft Longhorn / Vista / Biztalk Server 2006 / …
IBM IBM SOA Foundation
SAP Net Weaver
Oracle Oracle SOA Suite
Sun SOA Initiative (future developments)
OASIS
non-profit, joint industrial for e-business technology development & standardization
committees for Web Services & SOA (ebSOA, FWSI, SEE, etc.)
Market Prospects : Market Prospects Application Areas
Knowledge Management
Enterprise Application Integration
E-Commerce (B2C and B2B)
E-Government
… many more
SESA = enabling technology for the 21st century
Market Prospects:
2006 / 07: Technology Development & Dissemination
2008: Break Even Point / ROI
2010: Commercialization (40 – 60 billion dollar market)
Slide161 : Market Development (Gartner)
Estimated Market in 2010 : Estimated Market in 2010 $ 52.4 billion dollar market
Future Items : Future Items proof of concept & applicability
current works developed & tested in mainly academic settings
which approaches techniques are
adequate (functional, scalable, etc.)
realizable
large scale real world use cases needed
Ontology & WS description management
Ontologies as data model
=> the (Web) world needs to be ontologized
Web service descriptions must be correct & maintained
complicated task
can not be automated (knowledge level lifting)
qualified Knowledge Engineers needed
References Acknowledgements : References Acknowledgements
References Foundations : References Foundations [Alonso et al., 2004] Alonso, G., Casati, F., Kuno, H., and Machiraju, V. (2004). Web Services: Concepts, Architectures and Applications. Data-Centric Systems and Applicatio