1. ©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences Some Requirements for Semantic Web Serivce from CROSSFLOW and OPELIX Karl Aberer - EPFL

2. ©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

3. ©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

4. ©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)

5. ©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences CrossFlow Case Studies Insurance Scenario Logistics Scenario

6. ©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)

7. ©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)

8. ©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

9. ©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 [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(a, t))]^m ==> [deliver(OMG_member, Logon, payment(m*a, t))] [deliver(OMG_member, Logon, payment(m*a, t))] " this gives the OMG member the freedom to choose payment granularity"

10. ©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences Scope of BOL Information commerce Electronic commerce Cooperation and coordination Netbill ICE RosettaNet KQML Data and processes FBCL

11. ©2003, Karl Aberer, EPFL, School of Computer and Communication Sciences Scope of BOL Expressivity of model Reasoning on execution properties Secure contract protocols Conceptual models Micropayment markup ICE protocol BOL

12. ©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