Your SlideShare is downloading. ×
Ai Planning For Semantic Web Service Composition
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ai Planning For Semantic Web Service Composition


Published on

Ai Planning For Semantic Web Service Composition

Ai Planning For Semantic Web Service Composition

Published in: Education, Technology

1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • My background: I joined DERI one year ago, ome from a different field. Worked in application of Logic Programming techniques for planning, and analyzing theory/complexity of Planning. Currently: Involved in WSMO/WSML efforts where we build up a framework for semantically describing all relevant aspects of Web Services.
  • Transcript

    • 1. AI Planning for Semantic Web Service Composition? Survey of current approaches, challenges and open questions presented by Axel Polleres [email_address]
    • 2. Let's start with a pessimistic view…
      • I would point out that the mapping of web services to compositions has largely been done in the past, even in the best work in
      • this area, with some simplifications that generally "twist" web services into a planning framework -- there's huge parts of the
      • web service world that need to be explored before we can really say AI planning has shown a success in web services other
      • than as an evocative idea -- the reason is that a real web services engine will need to deal with (at least):
      • scaling issues way beyond anything we've seen in planning to date (there may be thousands of services each with multiple ports, optional arguments, etc.)
      • the issues Dana mentioned ( side effects, change in the world , etc.) that make Strips-operators planning an approximation at best (the assumption that change occurs only through the operators under the control of this planner is clearly wrong)
      • issues of interaction with users - web service planning better be more mixed-initiative
      • issues of preferences v. constraints
      • issues of interaction between planning agents out there (you buy the book I'm in the process of planning to buy)
      • knowledge engineering issues (when planners take ebXML and WSDL as inputs, instead of requiring specialized planning-like languages like
      • OWL-S, then we'll see a lot more excitement on the outside - OWL-S is an interesting starting place, but we fool ourselves if we think it really is going to be widely used for process specification in its current form)
      • In fact, I'll wager that it will be absolutely trivial to prove that web services planning, even w/simplifications, is inherently
      • undecidable, so we'll need to explore a lot of the issues from the old " dynamic planning " world as well. All this, by the way, I
      • see as good news - it means this is a fertile and exciting research area for those of us in planning, with good heuristic solutions
      • being transitionable. That said, in the past I have tried to get AI planning people to think outside the box and failed miserably,
      • and I'll be surprised if the web services planning stuff doesn't become an "applied" area being ignored by the bulk of the
      • research community (who, if you'll apologize my saying so, still have their heads up their you-know-whats worrying about
      • scaling simple problems in all the wrong ways)
      • Forgive my pessimism, but the planning community has spent many years resisting change - I don't see why just because we
      • have a new and potentially revolutionary problem that could expand the field greatly, the leopards will change their spots...
      • -Jim Hendler
      Jim Hendler's opinion: 01/02/2004
    • 3. … and let's see what still might be achieved:
      • AI Planning vs. Web Service Composition
      • Non-classical Planning
      • Planning approaches for WSC
      • Open Questions & Challenges
      • Relations with our current WSMO efforts
    • 4. AI Planning…
      • … is more than Blocks World!
      • The Classical Planning Problem:
      • - Complete Knowledge of the world
      • Atomic actions with, deterministic effects
      • Set of actions finite and static
      • Full observability
      • Only sequential plans
      • Goals mostly simple conjunctions of propositions
      • Domain description uses a fixed terminology , mostly a finite set of state variables (often called fluents)
      A B C A B C move(a,table) move(c,a) move(b,c) "Given a set of actions, their preconditions and positive and negative effects, a complete description of the initial state and a user goal find a sequence of actions achieving the goal".
    • 5. Classical Planners:
      • STRIPS like domains
      • Forward-chaining, backward chaining and combinations (Graphplan, etc.)
      • Successful heuristics, but problems of limited real-world value (IPC: bi-annual competition, combined with AIPS,ICAPS)
      • However, Can maybe serve as an approximation at a high level of abstraction in semi-automatic approaches.
    • 6. Semantic Web Services on the other hand:
      • Semantics descriptions of Web services, where:
      • The number of available services is huge…
      • ( shallow and broad search space vs. narrow and deep search space for which most planning algorithms are tailored)
      • … and results possibly unknown, only the type
      • (need for typing, conceptual reasoning over types, ontologies, take information gathering into account, selection step for sets of information)
      • Services might expose complex interfaces with complex message exchange patterns… (choreography, multi-agent collaboration rather than single-agent planning)
      • … but without full insight
      • (incomplete knowledge, non-determinism)
      • Need to compose complex services (i.e., " pre-defined plans " orchestration, cf. OWL-S process models)
    • 7. Non-classical Planning: Loosen the restrictions to complete knowledge, and deterministic actions:
      • Conditional Planning [Peot,Smith,92]: construct a branching plan(-tree) taking all possible contingencies into account .
      • Conformant Planning [Goldman,Boddy,96]:
      • find a plan which works in any initial situation even under incomplete knowledge or when non-deterministic effects .
      • Hierarchical Task Network Planning (HTN) [Erol et al. 1994]: views a plan as a hierarchical network of tasks (however, mostly only simple sequences, no complex control structures like in OWL-S, BPEL4WS, etc.)!
      • Dealing with Non-classical Goals : Maintainance goals, preferences, etc.
    • 8. Non-classical planners:
      • Planning as model checking ([Jensen,Veloso,2001], [Cimatti, et al.,97] and subsequent extensions):
        • compact representation of belief states in BDDs for planning under incomplete knowledge.
        • Complex plans (strong and weak plans, branching plans, cyclic plans)
        • Complex goals (EaGLe)
      • Scalability for huge sets of actions? Composing of pre-canned plans? [Son,McIlraith,2002]
    • 9. Planning for WS, examples:
      • [McDermott,2002]:
        • suggests extension of PDDL with a polymorphic typing system for information gathering actions as a representation language for planning
        • Sketches how classical goal-regression planner can be extended to create conditional plans "on demand" (scalability not touched, assume number of branches is low).
        • Description of interface as a set of planning operations instead of a process definition! Extension to multiple-agents then of course trivial! Does not (yet?) assume but mention that ontological differences have to be resolved first
      • [Pistore, et al.,2004]:
        • Based on planning as model-checking
        • Automatic composition of BPEL4WS processes given a desired user process
        • Also leaves ontological differences out
        • Currently reported performance not usable for complex protocols
      • [Wu, et al. 2003]:
        • Translating DAML-S to HTN, and use HTN planner SHOP2 for plan generation
        • Makes many simplifying assumptions
    • 10. Planning for WS, examples cont'd:
      • [Mandell,McIlraith,2003]:
        • approach to integrate SemWeb technologies (particularly OWL-S) on top of BPEL4WS+BPWS4J to enable dynamic binding in BPEL4WS
        • First approach to integrate semantic mismatches
        • Mentions prototype at however not (yet?) provided
        • In principle only discovery for dynamic binding, but propose a simple recursive search algorithm similar to planning for creating chains of missing services.
      • [Heflin,Mu ñ oz-Avila,2002]:
        • Use HTN planning for information gathering exploiting LCW information.
        • Tackles the problem of unbounded search by trying to exploit LCW information
        • Not really "planning for Web Services", but interesting application of planning techniques for SemWeb information gathering.
      • [Thakkar,Knoblock,Ambite,2003]:
        • primarily on information discovery, extraction and integration,
        • Query planning for information gathering. Not really comparable with classical planning but uses similar techniques, services described in terms of LAV views, modified inverse rule algorithm which allows to consider binding patterns and optimize wrt. LCW information.
      • Most likely this list is incomplete…
    • 11. Open Questions & Challenges:
      • compensation in case of failure and dynamic replanning not yet tackled
      • scaling not proven in real scenarios, large testbeds missing (Approach in this direction: [Constantinescu et al.,2004])
      • Collaboratively resolving complex communication interfaces? (e.g. in the [Pistore et al.,2004] approach.)
        • Conjecture: only if you size down the number of possible services beforehand by intelligent discovery mechanisms (see next slide)
    • 12. Open Questions & Challenges cont'd
      • fully automated vs. semi-automated (approximation might help for the latter)
      • Interleaving planning and execution:
        • assuming the same context at plan time than et execution time might cause problems
        • planning neglects exogeneous events
        • preconditions vs. outputs.
      • Selection step from a set of outputs instead of conditions on all outputs (e.g. picking a flight)
      • Maybe no negative effects, but non-deterministic effects!
      • As opposed to planning: often many services available which basically offer the same, but at different costs. This is not the case for the usual planning examples.
      • Synthesis is ideally less frequent than access: So, composite services, if stored have special necessities on persistence of the service, availability needs to be checked and/or HOW LONG are the descriptions valid?
      • dynamic object generation: web services create new objects "at run-time", It is unlikely that this can be adequately modeled with the current planning techniques.
      • How to connect SWS and real services?
      • Partly own ideas, [McIlraith,Son,2002], [Srivatava,Koehler,2003]
    • 13. Relations With WSMO
      • Current focus in Discovery, define different levels of abstraction for discovery [WSMO D5.1]: different levels of abstraction shall filter the number of relevant (approximately matching) services before detailed checking, similar applies to composition
      • WSMO: preconditions/postconditions/effects involve complex FOL formulae: WSML dialects [WSML D16.x, WSML D20.x]: restrictions which allow decidable logical reasoning:
        • DL style
        • LP style
        • etc.
      • Discovery is to be solved before we can compose and execute SWS!
      • Grounding , Orchestration and Choreography under development. Need to have a clear formal semantics in order to enable (semi-)automatic composition and execution/verification of composed services (which e.g. BPEL4WS, OWL-S do not provide (yet?)).
    • 14.
      • What does Service Discovery mean in terms of WSMO?
        • 1) Match goals against WS capabilities
        • 2) Enable Executability (semi-automatically)… WSMX!
        • Aim:
        • More accurate discovery by semantic annotiations!
      Discovery Discovery in WSMO Mediators WSMO WSML WSMX Goals Web Services Ontologies
    • 15. Discovery: Goal-Capability Matching
      • Different approaches:
        • Level 1: Keyword-based search (similar UDDI)
        • extract keywords intelligently from WSMO descriptions
        • Level 2: Using controlled vocabulary and conceptual
        • descriptions of goals and capabilities, using goal ontologies!
        • Level 3: Logical Level: Reasoning on the declarative
        • descriptions of goals and capabilities!
      • Necessity for matching: Different levels of abstraction within the description are necessary on different levels of discovery!
      • Further abstraction looses information but
      • Decrease complexity
      •  Trade-Off! Semi- automatic!
        • Further steps: contracting, etc. see [Kifer etal. 2004]
    • 16. Key aspect: Goal discovery vs. Service Discovery
      • In first place:
      • - Services have to provide the abstract descriptions to
      • be discovered, annotation tool support necessary!)
      • The user can subscribe to a defined goal (tool support, goal browser necessary!)
      • For discovery: abstract from concrete input
      •  Semi- automatic!
      Goal Input Abstracted goal Service Abstracted Service Figure 1 The three major processes of heuristic classification. Goal Discovery Service discovery matching
    • 17. Level 2:
      • Could be a simple hierarchy of action-object pairs
      • Can be conceptual description od goals and capabilities
    • 18. Level3: Logical Descriptions of Services:
      • Currently as general as possible: FOL
        • (e.g. in the SWF Project FOL reasoner used for goal
        • resolution)
      • Different restrictions which allow decidable logical reasoning:
        • DL style
        • LP style
        • etc.
    • 19. WSMO Logical Descriptions of Services, by example:
      • just an example of what we want to express.
      • - This simple example does not include terminological mismatches yet.
      • We are interested in use case requirements input from this project here:
        • to find useful restrictions to allow
        • decidable reasoning, etc.
      Conjecture: what we need is something in between theconceptual matching And rules describing input/output relation
    • 20. References
      • [Cimatti,E.Guinchiglia,F.Giunchiglia,Traverso,1997] Planning via Model-Checking: A Decision Procedure for AR , ECP-97.
      • [Constantinescu,Faltings,Binder,2004] Large scale testbed for type compatible service composition, ICAPS Workshop on Planning for Web Services, 2004
      • [Erol,Hendler,Nau,94] UMCP: A Sound and Complete procedure for Hierarchical Task-Network Planning , AIPS 1994.
      • [Goldman,Boddy,96] Expressive Planning and Explicit Knowledge . AIPS 1996.
      • [Jensen,Veloso,Bowling,2001] OBBD-Based optimistic and strong cyclic adversarial planning , ECP-01.
      • [Heflin,Mu ñ oz-Avila,2002] LCW-Based Agent Planning for the Semantic Web , AAAI, 2002.
      • [McDermott,2002] Estimated-Regression Planning for Interactions with Web Services .
      • [McIlraith,Son,2002] Adapting Golog for Composition of Semantic Web Services, KR 2002.
      • [Peot,Smith,92] Conditional Nonlinear Planning . AIPS 1992.
      • [Pistore,Barbon,Bertoli,Traverso,2004] Planning and Monitoring Web Service Composition , ICAPS Workshop on Planning for Web Services, 2004.
      • [ Srivatava,Koehler,2003] Web Service Composition - Current Solutions and Open Problems. ICAPS 2003 Workshop on Planning for Web Services
      • [Knoblock,Ambite,2004] Tutorial: Planning on the Web , ICAPS 2004, con be found on C.Knoblock's Webpage.
      • [Thakkar,Knoblock,Ambite,2003] A view Integration Approach to Dynamic Composition of Web Services , ICAPS 2003 Workshop on Planning for Web Services.
      • [Wu,Parsia,Sirin, Hendler,Nau,2003] Automating DAML-S Web Services Composition using SHOP-2 , ISWC 2003.
      • [WSMO D5.1] Discovery in WSMO . Draft available at
      • [WSML D16.x] WSML. Drafts available at http://
      • [WSML D20.x] OWL Lite-, OWL Flight . Drafts available at http://