Transcript 'Semantic' Web Services Karl Aberer

Some Requirements for Semantic Web Serivce
from CROSSFLOW and OPELIX
Karl Aberer - EPFL
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
Background CROSSFLOW - www.crossflow.org
•
CROSSFLOW – EU Project, Sep 98 – Sep 00
Cross-Organizational Workflow Support in Virtual Enterprises
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
Background OPELIX – www.opelix.org
•
OPELIX – EU Project: Jan 2000 – Jun 2002
An Open Personalised Information Commerce System
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
Preliminary: Basic Service Description
•
The following is assumed to be standard in the following
–
–
–
–
–
Roles of participants
Basic actions/interactions (including data/message types)
Initial and final state conditions
Constraints on action-role assignment
Execution constraints (pre- and postconditions)
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
CrossFlow Case Studies
•
Insurance Scenario
•
Logistics Scenario
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
(Contract) Requirements from CrossFlow
•
General
–
–
–
–
–
•
support search and matchmaking
serve as legal agreement (parties, duration)
specify process structure and parameters
support multiple service instantiations (constraints on instances and time)
generate communciation links and invoke services
QoS Requirements (Quality of Service)
– Which parameters, activities, aggregate information can be monitored at
what time
– Push or pull access to monitored parameters, temporal constraints
•
LoC Requirements (Level of Control)
– stop, abort, continue the provider process
– compensation capabilities
– parameter changes (which, when)
•
FCC Requirements (Flexible Change Control)
– the non-structural goals of the service (duration, cost, quality)
– relative importance of non-structural vs. structural goals, activities
– ordering constraints between activities of the service (and their importance)
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
OPELIX Case Studies: Commercial Web Portals
•
Scenario (both Logon and Culturall)
– Web portal on object technology/software/events
– providing different categories of information depending on the user profile
– flexible definition of business models (offers, negotiation, order processing,
payment)
– different roles in i-commerce (Vendor, Broker, Buyer, Searching agent
provider, Multiplier, Associations, Partners,Associates, Supplier, Virtual
community, Third party marketplace, Mediator, Administrator)
– various delivery modalities for information (push, pull, periodic, conditional)
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
"Business Offer Language"
•
Model Conceptually typical information business activities
– modelling negotiation of offers, delivery modalities, dependencies and
obligation, payment, authentication etc. uniformly treated as information
services
– complex business models
•
Design influenced by
–
–
–
–
–
–
•
Agent communication languages, ICE standard, EDI protocols, deontic logic
Basic abstraction for state-change is a communciation act
Basic primitives: who, what, how
Rule-based specification of pre-conditions
Implicit state changes (without communication) can be specified in contract
Atomic promise-request-delivery model to capture negotiation and obligation
(-> autonomy)
Ongoing work
– implementation of execution environement exists
– precise semantics in transaction logics currently elaborated
– reasoning using logic-based semantics
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
Example
roles: OMG_member, Logon;
goods: base_info(at: TIME, url: URL) : Logon -> OMG_member;
registration(email: EMAIL) : OMG_member -> Logon;
rules:
requested(Logon, OMG-member, registration(e),t) and NOW < t+1d ->
[deliver(OMG_member, Logon, registration(e))]
« After the request for registration the OMG member may register within one day »
requested(OMG_member, Logon, base_info(t, https:…), t1) and
delivered(OMG_member, Logon, registration(e)), t2) and t>=t2
-> [deliver(Logon, OMG_member, base_info(NOW, https:…))]
« After registration by OMG member, Logon must deliver the information any time it
is requested provided the request refers to information related to time after
registration»
substitution:
[deliver(OMG_member, Logon, payment(a, t))]^m ==>
[deliver(OMG_member, Logon, payment(m*a, t))]
"this gives the OMG member the freedom to choose payment granularity"
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
Scope of BOL
Cooperation and coordination
Data and processes
Electronic commerce
Information commerce
ICE
Netbill
©2003, Karl Aberer, EPFL, School of Computer
and Communication Sciences
RosettaNet
FBCL
KQML
Scope of BOL
Reasoning on execution properties
Secure contract
protocols
BOL
Micropayment
markup
ICE protocol
Conceptual
models
Expressivity of model
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences
Summary: What's relevant for SWSL
•
Contract notion
– coordination by specification of local interaction
– supports also decentralized architectures
•
Nonstructural properties of processes
– in particular their composition properties
•
Dynamic process specification
– dynamically evolving execution constraints and termination goals
– dynamic parameter determination
•
•
Monitoring and Control capabilities
Pragmatic dimension
– negotiation, obligation, conflict resolution
– legal significance of service specification
©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences