1 / 40

Planning, Executing, Sensing, and Replanning for Information Gathering

Planning, Executing, Sensing, and Replanning for Information Gathering. Presented by Hector Gonzalez (Based on slides from Craig Knoblock and L. Joskowicz). Local Databases. Knowledge Bases. Computer Programs. Motivation: SIMS Information Mediator. Internet. SIMS. Information Mediator.

myron
Download Presentation

Planning, Executing, Sensing, and Replanning for Information Gathering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Planning, Executing, Sensing, and Replanning for Information Gathering Presented by Hector Gonzalez (Based on slides from Craig Knoblock and L. Joskowicz)

  2. Local Databases Knowledge Bases Computer Programs Motivation: SIMS Information Mediator Internet SIMS Information Mediator “Anywhere” Information Retrieval Automatic Planners Decision Support

  3. Information Gathering • GIVEN: • Unifying domain ontology • Description of the contents of sources • PROBLEM: How to plan and execute information queries • many sources, possibly overlapping • distributed and heterogeneous environment • sources may be unavailable or fail • asynchronous queries • efficient access is critical

  4. The Approach • Cast the information gathering task as a planning problem • Build on and extend a Partial Order Planner (UCPOP) with: • parallel execution • interleaved and simultaneous planning and execution • asynchronous goals • replanning for failures • sensing to gather additional information

  5. What is a partial order planner?

  6. Partial Order Planner: Overview • Search through the space of plans. • Regression planning: work from goal to start • Start from the initial plan, add one step (operator) in each iteration • Add only steps that serve to achieve a precondition that has not been achieved yet. • Keep track of interactions with causal links. When a conflict occurs, resolve it by imposing an order between steps • Keep track of all choice points and backtrack as necessary

  7. SM = Supermarket HWS = Hardware Store Example: shopping for groceries Steps: {Start: Op(Action: Start, Effect:At(Home) /\ Sells(HWS,Drill) /\ Sells(SM,Milk) /\ Sells(SM,Banana), Finish: Op(Action: Finish, Precond:At(Home) /\ Have(Drill) /\ Have(Milk) /\ Have(Banana)}

  8. At(here) Go(there) At(there) ~At(here) At(store) Sells(store(x) Buy(x) Have(x) Actions: Go and Buy • Op(Action: Go(there) Precond:At(here) Effect:At(there) /\~At(here)) • Op(Action: Buy(x) Precond:At(store) /\ Sells(store,x) Effect:Have(x)

  9. Plan to achieve three preconditions At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) Have(Drill) Have(Milk) Have(Ban.) Bold links are causal links Light links are ordering links

  10. {s/HWS} {s/SM} {s/SM} Instantiation and causal links At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) Have(Drill) Have(Ban.) Have(Milk) Causal links can be added because there is no conflict! No ordering is necessary

  11. Next step: get to the store At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) At(HWS) ~At(x) At(SM) ~At(x) Have(Drill) Have(Milk) Have(Ban.)

  12. Conflict! Flawed plan! Causal links conflict: cannot be in two places simultaneously ! Re-ordering is necessary Instantiation and causal links At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) {x/Home} {x/Home} At(HWS) ~At(Home) At(SM) ~At(Home) Have(Drill) Have(Milk) Have(Ban.)

  13. promotion c c c conflict demotion Soving causal link conflicts Promotion and demotion sequentialize actions

  14. After threat resolution (demotion) At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) At(HWS) At(SM) Have(Drill) Have(Milk) Have(Ban.) At(Home)

  15. At(Home) Sells(HWS,Drill) Sells(SM,Milk) Sells(SM,Ban.) Final Solution At(HWS) Have(Drill) At(SM) Have(Milk) Have(Ban.) At(Home)

  16. POP algorithm (1) functionPOP(initial,goal,operators) returns plan plan :=Make-Minimal-Plan(initial,goal) loop do if Solution?(plan) then return plan (S-need,c) := Select-Sub-Goal(plan) Choose-Operator(plan,operators,S-need,c) Resolve-Threats(plan) end functionSelect-Subgoal(plan) returns (S-need,c) pick a plan step S-need from STEPS(plan) with a precondition c that has not been achieved returns (S-need,c)

  17. POP algorithm (2) procedureChoose-Operator(plan,operators,S-need,c) choose (a step S-add from operators)or (STEPS(plan) that has c as an effect) if there is no such step then fail add causal link (S-add-- c --> S-need) toLINKS(plan) add ordering constraint S-add < S-need toORDERINGS(plan) if S-addis a newly added step from operators then add S-add to STEPS(plan) add Start < S-add < Finish toORDERINGS(plan) procedureResolve-Threats(plan) for eachS-threat that threatens a link (Si-- c --> Sj) inLINKS(plan) do chooseeither Promotion: add S-threat < Si to ORDERINGS(plan) Demotion:add Sj < S-threat to ORDERINGS(plan) if not Consistent(plan) then fail

  18. Back to information gathering...

  19. Example Query What are the names of all ports that have sufficiently deep channels to accommodate Breakbulk ships ? (retrieve (?name) (:and (ship ?ship) (type-name ?ship “breakbulk”) (draft ?ship ?draft) (port ?port) (channel-depth ?port ?depth) (port-name ?port ?name) (< ?draft ?depth)))

  20. An Information Goal • Goal: • Description of the data required • Desired location • Example (available output (retrieve (?name) (:and (ship ?ship) (type-name ?ship “breakbulk”) (draft ?ship ?draft) (port ?port) (channel-depth ?port ?depth) (port-name ?port ?name) (< ?draft ?depth))))

  21. Information Gathering Operators • Operators: • Move -- moves data from one server to another • Join -- combines two sets of data • Translate -- select a source and translate the results • (define (operator join) • :parameters (?join-op ?data ?data-a ?data-b) • :precondition (:and (join-partition ?data ?join-op ?data-a ?data-b) • (available local ?data-a) • (available local ?data-b)) • :effect (available local ?data))

  22. Searching the Space of Plans • Operators allow only relevant search space • e.g., only considers joins across sources • Branch-and-bound search • expands the lowest-cost plan on each iteration • produces the optimal plan • Good evaluation function • estimates based on size and cardinality information • exploits standard database estimation techniques

  23. An Example Plan Move From: GEO@server1 To: LOCAL Data: port-name channel-depth Translate Source: GEO Move From: LOCAL To: OUTPUT Data: port-name Join (< max-draft channel-depth) Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source:ASSETS

  24. Planning and Execution in Sage • Built on UCPOP Planner [Weld et al.] • Support for simultaneous actions [Knoblock ‘94] • Interleaving of execution and planning [Ambros-Ingerson ‘87] • Planning for asynchronous goals • Replanning failed actions • Sensing with run-time variables [Etzioni et al., ‘92]

  25. Simultaneous Execution • Queries to different information sources can be executed simultaneously • To support this requires: • Explicit resource requirements on actions • Adding ordering constraints to avoid conflicts • Executing each action as a separate process • Unordered actions in a plan can be executed in parallel

  26. Simultaneous Execution Planned Executing Move From: GEO@server1 To: LOCAL Data: port-name channel-depth Translate Source: GEO Move From: LOCAL To: OUTPUT Data: port-name Join (< max-draft channel-depth) Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source:ASSETS

  27. Interleaved and Simultaneous Planning and Execution • Execution is part of the planning process • Each action is either: unexecuted, executing, completed, or failed • Planner is done once the action that achieves the goal is completed • Executing an action commits to the corresponding plan • Delays execution as long as possible • Allows planning and execution to be performed simultaneously

  28. Planning and Execution Algorithm Select from the possible plans and apply first applicable: • Possible conflict? • Add possible ordering constraints • Unachieved goal? • Add possible operators to achieve goal • Completed action? • Success? Record results • Failure? Remove failed actions and update model • Pending goal? • Add goal to unachieved goals • Executable action? • Initiate execution and discard alternative plans

  29. Planning for Asynchronous Goals • Information requests can arise during execution • Adds request to the set of top-level goals • Augments executing plan to solve new goal • Orders actions to avoid conflicts • Exploits any overlap

  30. Planning for Asynchronous Goals Planned Move From: GEO@server1 To: LOCAL Data: port-name channel-depth Executing Translate Source: GEO Completed Move From: LOCAL To: OUTPUT Data: port-name Join (< max-draft channel-depth) Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source:ASSETS (retrieve (?desc) (:and (port ?port) (description ?port ?desc) (port-name ?port “Long Beach”)))

  31. Planning for Asynchronous Goals Planned Move From: GEO@server1 To: LOCAL Data: port-name channel-depth Executing Translate Source: GEO Completed Move From: LOCAL To: OUTPUT Data: port-name Join (< max-draft channel-depth) Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source:ASSETS Move From: GEO@server2 To: OUTPUT Data: port-description Translate Source: GEO

  32. Replanning Failed Actions • Actions may fail • Current state is updated to reflect problem • Plan updated to indicate unachieved goals • Unachieved goals are then replanned • Preserves completed work and work in progress

  33. Replanning Failed Actions Planned Move From: GEO@server1 To: LOCAL Data: port-name channel-depth Executing Translate Source: GEO Completed Failed Move From: LOCAL To: OUTPUT Data: port-name Join (< max-draft channel-depth) Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source:ASSETS Move From: GEO@server2 To: OUTPUT Data: port-description Translate Source: GEO

  34. Replanning Failed Actions Planned Executing Completed Failed Move From: LOCAL To: OUTPUT Data: port-name Join (< max-draft channel-depth) Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source:ASSETS Move From: GEO@server2 To: OUTPUT Data: port-description Translate Source: GEO

  35. Replanning Failed Actions Planned Move From: GEO@server2 To: LOCAL Data: port-name channel-depth Executing Translate Source: GEO Completed Failed Move From: LOCAL To: OUTPUT Data: port-name Join (< max-draft channel-depth) Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source:ASSETS Move From: GEO@server2 To: OUTPUT Data: port-description Translate Source: GEO

  36. Sensing for Information Gathering • Sensing actions can be exploited to improve efficiency • incorporate sensed data to optimize individual queries • gather additional data to narrow down the possibly relevant sources [Knoblock & Levy ‘95] • Incorporate run-time variables in the planning language • Add sensing goals and actions to the planning operators

  37. Sensing for Information Gathering Planned Executing Completed use-sensed-data ?draft = ? Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source: ASSETS Bind-Result ?draft = ?

  38. Sensing for Information Gathering Planned Executing Completed use-sensed-data ?draft = 24 Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source: ASSETS Bind-Result ?draft = 24

  39. Sensing for Information Gathering Planned Executing Completed Move From: GEO@server2 To: LOCAL Data: port-name channel-depth > 24 Translate Source: GEO use-sensed-data ?draft = 24 Move From: ASSETS@server2 To: LOCAL Data: max-draft Translate Source: ASSETS Bind-Result ?draft = 24

  40. Discussion • Databases • Provides a much more flexible approach than conventional query processors • Unlike typical multidatabase systems, does not assume a fixed mapping to the sources • Planning • Integrates previous work on planning, execution, replanning, and sensing • Extends this work to support simultaneous and interleaved planning and execution • Demonstrates the ideas in a real application

More Related