Conditional Constraint Networks for Interleaved Planning ... · expansion variable. Figure 4 shows...

MARCH/APRIL 2005 1541-1672/05/$20.00 © 2005 IEEE 25Published by the IEEE Computer Society

P l a n n i n g w i t h T e m p l a t e s

Conditional ConstraintNetworks forInterleaved Planningand InformationGatheringJosé Luis Ambite, Craig A. Knoblock, and Maria Muslea,University of Southern California, Information Sciences Institute

Steven Minton, Fetch Technologies

For any activity, a wealth of information is available through public and private net-

works. Unfortunately, such information is distributed among many sites, with dif-

ferent data formats, schemas, and semantics. Moreover, information access per se is of

limited value. What is needed is a system that integrates and structures diverse information

to support user tasks and goals. The system mustgather the relevant information, evaluate trade-offs,and suggest courses of action to the user.

For example, consider travel planning. Numeroussites provide relevant information, such as

• flight schedules and fares (for example, www.orbitz.com),

• hotel locations and rates (for example, www.itn.com),

• car rental information (for example, www.hertz.com),

• weather information (for example, http://weather.yahoo.com),

• maps and routes (for example, www.mapquest.com), and

• airport parking rates (for example, www.airwise.com).

A travel planner must integrate this information withuser preferences, such as for airlines or flying times(for example, avoid red-eye flights); cost constraints;and company policies, such as allowable airlines,expense caps, and per-diem or mileage reimburse-ment rates. Although the user can visit these sitesand deal with all the constraints and preferencesmanually, this is extremely tedious, error prone, andtime consuming. A system that queries the remote

sites, accesses local information, and enforces theconstraints and preferences is much more desirable.

The main requirements for such a system are plan-ning support and interactivity. To support planning,the system must

1. gather and integrate the information in a coher-ent structure that captures the tasks needed forthe application domain,

2. evaluate trade-offs and select among alterna-tive courses of action, and

3. let the user explore and override system sug-gestions.

To provide flexible interaction, the system must

1. let the user input data or change choices any-time during planning, and

2. handle information sources that return resultsasynchronously.

To address these challenges, we have developedHeracles II, a framework for mixed-initiative planningand information gathering. Heracles II maps the hier-archical task structure of the planning domain into aconditional constraint network.1 It also ensures cor-rect constraint propagation in the presence of cycles,user interaction, and asynchronous sources. We have

The Heracles II

framework allows

planning in a mixed-

initiative fashion,

where the user can

explore alternatives

and override the

system suggestions

as needed.

applied the Heracles II framework to severaldomains including travel planning and geo-spatial data integration.

The original HeraclesOur initial approach, the Heracles frame-

work, models each piece of information as avariable in a constraint network and uses con-straints to integrate such information.2 Theresulting constraint network provides a coher-ent view of user activities and captures the rel-evant information and user preferences.

Any nontrivial user activity involves a verylarge number of variables and constraints.So, Heracles partitions the network hierar-chically corresponding to the task structureof the application domain, in a manner sim-ilar to hierarchical-task-network planning.3

The application designer groups variablesand constraints related to a distinct task intoa package we call a template.

For example, consider the templates inFigure 1. Figure 1a shows the top-level tem-plate of our travel planner, which includesthe most important information about thetrip such as the origin, destination, and datesof travel. The next layer of decisions includes

• the alternative means of transportation, suchas flying, taking a train, renting a car, dri-ving the user’s own car, or taking a taxi; and

• choices of accommodation at the destination.

Figure 1a shows that the system suggests fly-ing. The variables and constraints related toflying constitute another template (see Figure1b). Heracles further decomposes each tem-plate into more specific subtemplates. Forexample, once the user chooses flying as themain transportation mode, the system mustevaluate how to get to the airport: by taxi, bydriving a car and parking it at the airport, andso on. Figure 2 shows the task/template hier-archy for the travel planner.

In Heracles, the information gathered bythe system or input by the user is propagatedautomatically in the constraint network. Her-acles also lets the user override the values thesystem suggests. For example, Figure 3shows the changes to the Taxi template whenthe user selects a different departure airportin the Round Trip Flights template. Figure 3a


26 www.computer.org/intelligent IEEE INTELLIGENT SYSTEMS

TripAND

Taxi HotelRentCarFlyDrive NoOvernight

1 2

1 2

ModeToAirport FlightDetail

ModeToDestination Lodging

ModeFromAirport

3AND

OROR

Drive Taxi

OR

RentCar Taxi

OR

Figure 2. The hierarchical organization oftemplates for the travel planner.

Figure 1. Travel planner templates: (a) the top-level template; (b) the Fly template.

(a)

(b)

shows the information relevant to going tothe airport by taxi, including cost, time esti-mate, map, and route from the user’s loca-tion (the University of Southern California)to Los Angeles International Airport (LAX).Figure 3b shows the user selecting LongBeach Airport (LGB) instead of LAX.Finally, Figure 3c shows the Taxi templatereflecting this change, including the newcost, times, and maps.

Heracles shows that a constraint-basedapproach is well suited to support mixed-initiative planning where user interaction andasynchronous information gathering are cen-tral requirements. However, the original Her-acles has two serious limitations.

First, the template selection mechanismis hard-coded into the implementation andnot integrated with the constraint network.To perform template selection in Heracles, aprocedure inspects the values of expansionvariables. For example, the ModeToDestinationvariable in Figure 2 (labeled OutboundMode in Figure 1a) is an expansion variablethat can take the values Fly, Drive, RentCar, orTaxi. Whenever an expansion variable in aparent template is set, Heracles adds the cor-responding child template to the constraintnetwork and removes the alternative (child)templates. This hard-coded behavior meansthat most of the logic for selecting amongtemplates must appear in the parent tem-plate, even if such information logicallybelongs to the child templates. This dimin-ishes template modularity and tends to cre-ate large, monolithic templates. The prob-lem becomes ever more acute the deeper thetask/template hierarchy.

The second limitation is that Heracles can-not handle cycles in the constraint network.So, the template designer must specify theconstraints sometimes in an unintuitive wayor forego some lines of reasoning altogether.

Heracles IIHeracles II provides solutions to these

limitations while preserving the advantagesof Heracles. First, Heracles II is uniformlyrepresented as a conditional constraint net-work, and template selection follows natu-rally from the evaluation of activity con-straints. To ensure that Heracles II alwaysconsiders all information relevant to thechoice of tasks/templates, we introduce theconcept of a core network that is alwaysactive. Second, we designed a new constraintpropagation algorithm that can handle cycli-cal networks in the presence of user interac-

tion and asynchronous sources.For a comparison of Heracles II to other

approaches to the problem of combiningplanning, information gathering, and userinteraction, see the sidebar, “Related Workin Interactive Planning.”

Conditional constraint networksand hierarchical planning

As the complexity of a planning domaingrows, designing and maintaining a mono-lithic network becomes infeasible. Similarly,presenting a large network for the user tointeract with quickly becomes unmanage-able and confusing. Templates help HeraclesII avoid these problems.

Template specification. A template consistsof a name, arguments, variables, constraints,and expansions. The name uniquely identi-fies the template. The arguments specify theinput variables, which receive values fromother templates or from the user, and the out-put variables, whose values are used in othertemplates. All other variables are internal tothe template. Each expansion specifies howa template is elaborated into the appropriatesubtemplates on the basis of the value of theexpansion variable.

Figure 4 shows a fragment of the specifi-cation of the Fly template focusing on the ModeToAirport decision. The input variablesinclude OriginAddress and DepartureDate. The out-put variables are SelectedFlight and FlyCost. TheselectModeToAirport constraint selects the cheap-est mode of transportation to the airport.

Heracles II receives as input a set ofdeclarative XML template definitions. Fig-ure 4 shows some of the main constructs.The values of variables can also be XMLobjects that are processed using XQuery. Atemplate also includes a declarative specifi-cation of the user interface. The constraintnetwork can control which widgets appearin the interface depending on runtime values.A full description of the XML syntax and theconstraint-based control of the interface isoutside the scope of this article.

Template hierarchy. The templates are orga-nized hierarchically to model the task struc-ture of the planning domain, to help the userunderstand the planning process, and to facil-itate presentation of the information. Figure 2shows the (simplified) hierarchy of our travelplanner. Planning a successful trip requiresachieving two subtasks: determining how toget to the destination and choosing an accom-

modation. These decisions are associated withtwo expansion variables in the travel-planninghierarchy: ModeToDestination and Lodging. Becauseboth subtasks must be achieved, we label thesubtask decomposition with an AND. Severalalternative means exist for achieving each sub-task. The figure shows the choices as ORbranches. For example, recall the ModeToDestina-tion expansion variable with the possible val-ues of Fly, Drive, RentCar, or Taxi. The Fly templatefurther decomposes into three subtemplates

MARCH/APRIL 2005 www.computer.org/intelligent 27

Figure 3. User interaction and constraintpropagation for the travel planner: (a) the Taxi template; (b) the user changesvalues in Round Trip Flights; (c) the changespropagate to the Taxi template. Maps ©2002 NAVTEQ All rights reserved.

(a)

(c)

(b)

that handle ground transportation at the originand destination airports and the flight details.

Conditional constraint network. Heracles IIreads the set of declarative template specifi-cations for a given application and automat-ically constructs a conditional constraint net-work based on them.

Figure 5 shows a fragment of the con-straint network for travel planning thataddresses the selection of the method oftravel from the user’s initial location to theairport. The choices under consideration aredriving a car (which implies parking it at theairport during the trip) or taking a taxi. Fig-ure 5a shows the constraint network that theoriginal Heracles system would evaluate tomake this decision. This network would needto be in the same template although somevariables naturally should appear in subtem-

plates. Figure 5b shows the same network inHeracles II. The variables and constraints arepartitioned across several templates in a moremodular way that corresponds more closelywith the task structure of the domain.

Variables. Each distinct piece of informationin an application is represented as a variable inthe constraint network. These values are setby the system by constraint propagation ordirectly by the user from the graphical inter-face. In a conditional constraint network, eachvariable has not only a value, as in the classi-cal case, but also an activity status. If a variableis inactive it does not participate in the net-work. Figure 5 shows the variables as dark rec-tangles and the values as white rectangles nextto them. For example, DepartureAirport has thevalue LAX (Los Angeles International), whichthe system assigns because LAX is the clos-

est airport to the user’s address.

Classical constraints. A constraint is a sub-set of the Cartesian product of the domains ofthe participating variables. A constraint is acomputable component that can be imple-mented by a local table look-up, by the com-putation of a local function, by retrieving aset of tuples from a remote source, or by call-ing an arbitrary external program.

Figure 5 shows the constraints as roundedrectangles. For example, the computeDurationconstraint involves three variables (Departure-Date, ReturnDate, and Duration) and is imple-mented by a function that computes the dura-tion of a trip given the departure and returndates. To implement the getParkingRate con-straint, Heracles II calls a wrapper thataccesses a Web site containing parking ratesfor US airports (www.airwise.com).



Here we compare Heracles to other approaches for combin-ing planning, information gathering, and user interaction.

Travel planningThe SmartClients system uses constraint satisfaction to sup-

port the user in planning and information gathering.1 TheSmartClients system has also been applied to travel planning.When the user inputs a trip’s origin, destination, and dates,SmartClients automatically compiles a constraint network toexplore the possible trips. To function, SmartClients must beable to access a remote database with flight information suchas Sabre, so that it can retrieve all the flights between theselected cities in the given dates and populate the appropriatevariables and constraints in the network. Once the networkhas been initialized by calling such a database, SmartClientssearches for a solution trip that satisfies all the constraints,using classical constraint satisfaction algorithms.

Heracles (see the main article) and SmartClients have severalcrucial differences. First, SmartClients retrieves all informationbeforehand, assuming that the size of the relevant sections ofthe flight database can be compactly encoded and efficientlytransmitted to the user client. However, this approach cannotscale to larger problems that incorporate a broader range ofinformation sources. Retrieving all the relevant information,such as flight schedules, hotel locations and rates, rental cars,and maps, before the search starts is not feasible. In contrast,Heracles accesses the external sources only during planning, foronly those values that are already part of a consistent partialsolution. The more focused search of Heracles is more scalableand allows for an arbitrary exploration of the information space.

Second, the user can interact with Heracles at any point dur-ing planning and can change the values of variables through-out the network, resulting in arbitrary retrievals of externalinformation. In SmartClients, the domains of the variables in the constraint network are fixed initially, so the user canexplore only solutions within such a space (or must restart the

whole constraint network construction and search process).Finally, SmartClients performs full constraint satisfaction, so

it finds optimal solutions according to the user preferences.However, it does this in the smaller search space defined at ini-tialization time. Heracles performs constraint propagation anddoes not attempt to find an optimal solution. However, in Her-acles the user can explore the full solution space with the lat-est information obtained in real time from external sourcesand understand the different trade-offs. In our experience, let-ting the user interactively guide the process toward a desirableplan yields better results.

The Trip-planner agent framework employs a differentapproach to collaborative planning and information gathering.2

Trip-planner is also based on a constraint network that integratesdifferent sources related to travel planning. The user specifieshis or her preferences at the start of planning. During the con-straint network evaluation, the system calls different sources,guided by the user preferences. It consults the user again atpredefined points during planning. For example, after Trip-planner has found the 10 cheapest flights, it prompts the userto select one. However, the user cannot interact with the con-straint reasoner at any point during constraint evaluation,unlike with Heracles.

Travel Web sites such as Expedia, Travelocity, and Orbitz pro-vide good support for information gathering and user interac-tion. However, they lack support for an integrated view of the(travel) planning process that satisfies complex constraints andpreferences of the user.

As Table A shows, other approaches do not meet our require-ments for a uniform framework that combines user interaction,information gathering, and planning and constraint-reasoningcapabilities.

Other interactive-planning researchThe research on collaborative3 and mixed-initiative4–6 plan-

ning is related in spirit to our research on Heracles. A central

Related Work in Interactive Planning

In Heracles and Heracles II, most con-straints have an implementation in only onedirection. For example, we can find out theparking cost at a given airport, but not whichairports have parking lots that cost less than$7 a day. This is one reason why Heraclesperforms only constraint propagation insteadof full constraint satisfaction.

Activity constraints. An activity constraintcontrols the activity status of a variable giventhe values of other variables. For example,consider an activity constraint ac(v1, ..., vn�1,vn) that is computed by the rule

(v1 = k1) � ... � (vn�1 = kn�1) � active(vn)

That is, the activity constraint will make vari-able vn active whenever the variables [v1, ...,vn�1] take the values [k1, ..., kn�1], respectively.

Template selection using activity con-straints. Heracles II uses activity constraintsand expansion variables to select amongalternative templates. It automatically gen-erates activity constraints based on theexpansion section of each template specifi-cation. For each expansion variable, it addsan activity constraint that acts as a multi-plexor, making the selected template activeand making the alternative templates inac-tive. To achieve this effect, Heracles II usesno special mechanism other than the normalevaluation of the activity constraints in theconditional network.

For example, in Figure 5b, the expansionvariable ModeToAirport in the Fly template selectsbetween the Drive and Taxi subtemplates. Theactivity constraint, represented in the figureby the dashed lines from the ModeToAirport vari-able to the Drive and Taxi subtemplates, is

Fly.ModeToAirport = “Taxi” �active(Taxi.TaxiFare) � active(Taxi.Distance) �¬active(Drive.Map) � ¬active(Drive.Directions)

The core network. To ensure that templateselection is responsive to changing user inputsor new information from asynchronoussources, Heracles II maintains the subset ofthe network that affects the computation ofthe expansion variables, called the core net-work, always active. Otherwise, when a tem-plate becomes inactive its variables cannotaffect the rest of the network and the choiceswould lack relevant information.

For example, in Figure 5b, all variables andconstraints, except Map, Directions, and getMapDi-rections, belong to the core network becausethey contribute to the computation of the ModeToAirport expansion variable. This is whythe activity constraint we just mentioned does


goal in these systems is to help the user develop a plan inter-actively. Although each system employs different planning tech-nology, in each case the user interactively modifies the planningprocess. In James Allen and George Ferguson’s system, the usercan perform actions such as refining a goal or rejecting an op-tion.3 Karen Myers and her colleagues devised a frameworkwhere the user can drop or modify constraints and tasks.4 Man-uela Veloso and her colleagues developed a system that uses acase-based planner to propose modifications to an initial plan.5

Unlike these systems, our Heracles framework uses a prede-fined set of templates that define the space of possible plans,and it uses constraint propagation instead of a general-purposeplanner to reason about plans. This supports combined plan-ning, user interaction, and information gathering, unlike theother systems, which focus only on integrating user interactionand planning.

Evelina Lamma and her colleagues propose a framework forinteractive constraint satisfaction problems (ICSP) that interleavesthe acquisition of values for each variable with constraint enforce-ment.7 The interactive behavior of our constraint reasoner can beseen as a form of ICSP. However, our approach includes a notionof hierarchical decomposition and task orientation.

References

1. M. Torrens, B. Faltings, and P. Pu, “Smart Clients: Constraint Satisfac-

tion as a Paradigm for Scalable Intelligent Information Systems,”Constraints, vol. 7, no. 1, 2002, pp. 49–69.

2. A. Homb et al., “Trip-Planner: An Agent Framework for Collabora-tive Trip Planning,” Proc. AAAI-99 Workshop Mixed-Initiative Intel-ligence, AAAI Press, 1999.

3. J. Allen and G. Ferguson, “Human-Machine Collaborative Planning,”Proc. 3rd Int’l NASA Workshop Planning and Scheduling for Space,2002.

4. K.L. Myers et al., “A Mixed-Initiative Framework for Robust PlanSketching,” Proc. 13th Int’l Conf. Automated Planning and Sched-uling (ICAPS 2003), AAAI Press, 2003, pp. 254–265.

5. M.M. Veloso, A.M. Mulvehill, and M.T. Cox, “Rationale-SupportedMixed-Initiative Case-Based Planning,” Proc. 9th Conf. InnovativeApplications of Artificial Intelligence (IAAI 97), AAAI Press, 1997,pp. 1072–1077.

6. M.H. Burstein and D.V. McDermott, “Issues in the Development ofHuman-Computer Mixed-Initiative Planning Systems,” CognitiveTechnology: In Search of a Humane Interface, B. Gorayska and J.Mey, eds., Elsevier Science, 1996, pp. 285–303.

7. E. Lamma et al., “Constraint Propagation and Value Acquisition:Why We Should Do It Interactively,” Proc. 16th Int’l Joint Conf.Artificial Intelligence (IJCAI 99), vol. 1, Morgan Kaufmann, 1999,pp. 468–477.

Table A. A comparison of travel-planning approaches.

Planning/constraint satisfaction programming User interaction Information gathering

Heracles, Heracles II ✓ ✓ ✓

SmartClients ✓ ✓

Trip-planner ✓ ✓

Expedia and other travel Web sites ✓ ✓

not make inactive the core variables ParkingRateand ParkingTotal of the Drive template. This isalso why we did not include the case forFly.ModeToAirport = Drive in the activity constraint,because all the variables of the Taxi templateare core variables. We call those variables notin the core network information variablesbecause their values do not affect task choicesbut provide additional information to the user.

Heracles II determines the core networkautomatically by reachability analysis. Itsearches the constraint network, startingfrom the expansion variables and traversingconstraints from output to input variablesuntil it reaches the “source” variables (thatis, those variables that are not the output ofany constraint and must be set by the user).The variables and constraints visited in thissearch constitute the core network.

Analysis. To understand the savings that theconditional constraint network and the tem-plate selection mechanism provide, considera task hierarchy of depth d where each taskhas a single decision point (expansion vari-able) with two possible alternatives (subtem-

plates). This hierarchy induces a binary ORtree with 2d � 1 nodes. Further assume thateach template has c core constraints and iinformation constraints. After Heracles IIevaluates the core network and decides on thetop-level choice, all the information variablesand constraints in one of the top two subtreesremain inactive. Moreover, this behaviorrepeats at each level of the selected subtree.So, the only information constraints (and vari-ables) that become active are those of theselected course of action, a total of (d + 1)i.This saves the evaluation of an exponentialnumber, (2d � d)i, of information constraints.In practice, the core network is often a smallsubset of the constraint network. So, the Her-acles II template selection mechanism con-siderably reduces constraint evaluation effort.

Interactive constraint propagationThe basic constraint propagation algo-

rithm proceeds as follows. When either thesystem or the user assigns a value to a vari-able, the algorithm fires all constraints thathave that variable as an input. This mightcause the output variables to change their

value (or activity status), and the process con-tinues recursively until no more changesoccur in the network.

For example, consider the network in Fig-ure 5. First, the constraint that finds the air-port closest to the user’s home addressassigns the value LAX to the variable Depar-tureAirport. Then, the constraint getParkingRate,which is a call to a Web wrapper, producesthe rate $16.00 a day. The algorithm multi-plies this value by the duration of the trip tocompute the ParkingTotal of $64.00 (using thesimple local constraint multiply). A similarchain of events results in the computation ofTaxiFare, based on the distance between theorigin address and the airport. Once the algo-rithm has computed ParkingTotal and TaxiFare,the selectModeToAirport constraint compares thecosts and chooses the cheapest means oftransportation, which in this case is a taxi.

Constraint propagation in Heracles II canbe seen as following a cyclic directed graph.Since the user can change the value of a vari-able in the network at any time and remotesources return data asynchronously, HeraclesII must take special care to prevent infiniteloops, to ensure that all the appropriate con-straints are fired and the values propagated,and to disregard obsolete values.

To address these requirements, HeraclesII’s constraint propagation algorithm in-cludes a time-stamping mechanism. Thealgorithm annotates each variable with auser-time, an integer incremented every timethe user inputs a new value or changes avalue. In addition, it annotates each variablewith the set of variables that have contributedto its value (that is, those variables that werevisited in the chain of constraints that set thevariable in the current user-time). This vis-ited set is necessary to prevent cycles. Boththese annotations are propagated as the algo-rithm evaluates the constraints along with theactual values assigned to the variables.

The algorithm for time-stamped constraintpropagation follows these rules:

R1 Whenever the user changes some valuein the interface, the user-time of the cor-responding variable is incremented andthe visited set is set to empty.

R2 A constraint fires whenever any of itsinputs changes.

R3 When a constraint fires, each outputvariable inherits the latest user-time ofthe input variables and gets an updatedvisited set consisting of the union of theinput variables and their visited sets.



Figure 4. A fragment of the Fly template specification.

<template name=“Fly”><args> <in>OriginAddress</in> <in>DepartureDate</in> ...

<out>SelectedFlight<out/> <out>FlyCost</out></args><vars>

<var name=“OriginAddress”/> <var name=“FlyCost”/><var name=“TaxiFare”/> <var name=“ParkingCost”/><var name=“ModeToAirport”/> ... </vars>

<constraints><constraint name=“selectModeToAirport” type=“XQueryConstraint”>

<args> <in>TaxiFare</in> <in>ParkingCost</in><out>ModeToAirport</out> </args>

<output><xquery><![cdata[<row> <TaxiFare>{$TaxiFare}</TaxiFare>

<ParkingCost>{$ParkingCost}</ParkingCost><ModeToAirport>{ if ($TaxiFare >= $ParkingCost)

then “Drive”else “Taxi”}</ModeToAirport>

</row>]]></xquery></output></constraint> ... </constraints><expansions>

<expansion><var name=“ModeToAirport”/><template-call name=“Drive” printname=“Drive and Park”>

<in>DepartureAirport</in> <in>Duration</in><out>ParkingCost</out> </template-call>

<template-call name=“Taxi” printname=“Take a Taxi”><in>OriginAddress</in> <in>DepartureAirport</in><out>Taxifare</out> </template-call>

</expansion> ... </expansions> </template>

R4 A constraint blocks (does not fire) ifthere exists a variable Vo in the con-straint’s outputs and a variable Vi in the constraint’s inputs such that user-time(Vo) � user-time(Vi) and Vo � vis-ited(Vi).

Figure 6 shows sample simulations of theconstraint propagation algorithm. Con-straints are shown as rectangles and variablesas simple nodes. Arcs denote the direction ofconstraint propagation. Each variable anno-tation has the syntax “simulation-step) user-time / visited variables [ value”. For exam-ple, the annotation “1 ) 1 / � [ LA” ofvariable v1 means that at simulation step 1the user-time was 1, no other variables wereused in the computation of its value (that is,the user set the value), and its value was“LA” (Los Angeles).

Figure 6a shows a simulation of con-straint propagation in a cyclic network thatpicks the geocoordinates of interest (v3) inone of our applications. The network hasthree constraints:

• C1, which given the name of a city (v1),produces the geocoordinates of the citycenter (v2);

• C2, which copies the geocoordinates intov3; and

• C3, which finds the closest city (v1) to thegiven latitude and longitude (v3).

This network aims to give the user flexibilityin selecting a geopoint of interest by eitherentering a city (v1) and getting the city cen-ter as the coordinates of interest (v3) or enter-ing a latitude and longitude (v3) and deter-mining the closest city (v1). The intention ofC2 is to copy its input to its output only whendoing so is consistent. The time-stampingalgorithm helps enforce those semantics eventhough the implementation of C2 can be asimple copy.

The simulation starts with the user enter-ing LA in v1. The algorithm then propagatesthe corresponding city center coordinates(34N118W) to v3 (step 3). Because v3 has anew value, C3 is scheduled to fire. However,rule R4 blocks such firing because v1 hadalready been visited for the computation ofv3 during the same user-time phase (step 4).This prevents the possible infinite cycle ofpropagation. With such state of the network,the user now inputs the latitude and longitude40N70W in v3 (step 5). C3 fires normallybecause the user input resets the visited vari-

ables of v3. Propagation continues, setting v1

to New York (NY) and v2 to its city center(40N73W), but R4 prevents the firing of C2,again blocking a possible infinite cycle.

The algorithm requires both the user-timeand visited-set annotations. Consider theacyclic network in Figure 6b, where con-straint propagation reaches a given variable

through different paths. When the user inputsa value in v1, C1 fires, and the values of bothv2 and v3 change. This causes both C2 andC3 to fire. So, by step 3, v5 obtains a newvalue. However, by step 5, the updated valueof v4 makes C3 fire again. This correctlychanges v5 a second time even though v5 hasthe same user-time (1) as v3 and v4 (the inputs


computeDuration

multiply

getDistance

getTaxiFare

findClosestAirport

DepartureAirportLAX

getParkingRate

DirectionsMap

DepartureDate

Mar 15, 2001

ReturnDateMar 18, 2001

Duration4 days

TaxiFare$23.00

ParkingTotal$64.00

ParkingRate$16.00/day

Distance15.1 miles

DepartureAirportLAX

DepartureDate

Mar 15, 2001

ReturnDateMar 18, 2001

computeDuration

getMap&Directions

OriginAddress

Duration4 days

TaxiFare$23.00

getTaxiFare

Distance15.1 miles

ParkingRate$16.00/day

DirectionsMap

getMap&Directions

ParkingTotal$64.00

selectModeToAirport

ModeToAirportTaxi

OriginAddress

Fly

Drive

findClosestAirport

getDistance

selectModeToAirport

multiply

getParkingRate

(b)

(a)

ModeToAirportTaxi

Taxi

Figure 5. Driving versus taking a taxi: (a) The original Heracles evaluates a flat constraintnetwork; (b) Heracles II evaluates a hierarchical conditional constraint network.

of C3). Since v5 � visited(v4) and v5 � vis-ited(v3), the propagation through C3 is notblocked. Only propagating the user-time oronly keeping track of visited variables wouldnot produce the correct propagation. Furtheruser inputs occur at steps 6 and 9 and pro-duce correct propagation.

HeraclesMaps: Geospatial-dataintegration

To build a new application in Heracles, thedesigner just needs to specify a set of tem-plates that represent the hierarchical task struc-ture of the application along with constraintsthat access the relevant sources. To facilitatedevelopment, our framework includes prede-fined constraint types for the most commontypes of sources, including wrappers, data-bases, and XML files, and of data manipula-tion operations, including XQuery processingand arbitrary Java functions.

We used the Heracles II framework torapidly build and maintain HeraclesMAPS,

an application that integrates multiple geospa-tial and online sources. HeraclesMAPS letsa user gather information about a specificarea, including satellite images, maps, topog-raphy, hydrography, transportation networks,points of interest, airport and seaport data,and weather information. HeraclesMAPS hasbeen deployed to US Special OperationsForces.

In the top-level template of HeraclesMAPS,the user selects a location by drilling downto a continent, country, and city (populatedplace) or by entering latitude and longitude.This initial location triggers constraint com-putation. The constraint network keeps allthe information consistent. For example, ifthe user recenters a map in a subtemplate, theapplication will recompute all the relatedmaps, images, and vector and point data tomatch the new area of interest. Heracles IIissues the corresponding information-gath-ering constraints that retrieve such data as theuser navigates the information space.

Figure 7 shows two sample templates ofHeraclesMAPS. Figure 7a shows a satelliteimage and the corresponding map of the portof Umm Qasr in Iraq. Vector data of trans-portation features such as roads and railroadsappears overlaid on the image. Figure 7bshows an elevation map (the upper-leftimage), the area visible (yellow) and not vis-ible (red) from a given point (upper right),and the altitude profile (lower right) betweentwo given points (from the origin specifiedin the upper-right image to the target in thelower-left image). The altitude profile ex-plains why the target point is not visible fromthe origin.

Despite the breadth of research in plan-ning and constraint programming, the

interplay between planning, informationgathering, and user interaction that manyimportant applications require presents a sig-nificant challenge. The Heracles II frame-work and the techniques we have presentedin this article bring us closer to meeting thischallenge.

We plan to formalize the Heracles II plan-ning and information-gathering approach,combining ideas from conditional1 and inter-active4 constraint satisfaction. Also, we planto explore the trade-offs between performingconstraint propagation and satisfaction insuch systems. Although our experience is thatfull constraint satisfaction tends to confuseusers as they interact with the system, localconstraint satisfaction might be valuable.

AcknowledgmentsThis material is based on research supported

partly by DARPA, through the US Department ofthe Interior, National Business Center,AcquisitionServices Division, under contract NBCHD030010;partly by DARPA and the US Air Force ResearchLaboratory under contract/agreement numbersF30602-01-C-0197 and F30602-00-1-0504; partlyby the US Air Force Office of Scientific Researchunder grant FA9550-04-1-0105; partly by the USAir Force under contract F49620-02-C-0103; andpartly by a gift from Microsoft. The US govern-ment is authorized to reproduce and distributereports for governmental purposes notwithstand-ing any copyright annotation thereon. The viewsand conclusions contained herein are those of theauthors and do not necessarily represent the offi-cial policies or endorsements, either expressed orimplied, of any of the above organizations or anyperson connected with them.



(b)

(a)

1 ) 1 / ∅ [ LA4 ) Blocked! t (v3) = t (v1) ^ v1 ∈ visited(v3)6 ) 2 / v3 [ NY

2 ) 1 / v1 [ 34N118W7 ) 2 / v3 v1 [ 40N73W

3 ) 1 / v1 v2 [ 34N118W5 ) 2 / ∅ [ 40N70W8 ) Blocked! t (v3) = t (v2) ^ v3 ∈ visited(v2)

1 ) 1 / ∅C1 C3v1

v2

v3

v4

v5

2 ) 1 / v16 ) 2 / ∅

3 ) 1 / v1 v3 v4 5 ) 1 / v1 v2 v3 v4 not blocked because v5 ∉ visited(v4) ^ v5 ∉ visited(v3) 8 ) 2 / v2 v3 v410 ) 3 / v3 v4

2 ) 1 / v19 ) 3 / ∅

4 ) 1 / v1 v27 ) 2 / v2

C1: Findcity center

C2: Copy (if not inconsistent)

City (v1)

City center (v2)

Latitude &longitude (v3)

C3:Closest city

C2

Figure 6. Interactive constraint propagation: (a) a cyclic network; (b) an acyclicnetwork (race condition).

References

1. S. Mittal and B. Falkenhainer, “DynamicConstraint Satisfaction Problems,” Proc. 8thNat’l Conf. Artificial Intelligence (AAAI 90),AAAI Press, 1990, pp. 25–32.

2. C.A. Knoblock et al., “Mixed-Initiative,Multi-source Information Assistants,” Proc.10th Int’l World Wide Web Conf. (WWW 10),ACM Press, 2001, pp. 687–707.

3. K. Erol, J. Hendler, and D. Nau, “HTN Planning:Complexity and Expressivity,” Proc. 12th Nat’lConf. Artificial Intelligence (AAAI 94), vol. 2,AAAI Press/MIT Press, 1994, pp. 1123–1128.

4. E. Lamma et al., “Constraint Propagation andValue Acquisition: Why We Should Do ItInteractively,” Proc. 16th Int’l Joint Conf.Artificial Intelligence (IJCAI 99), vol. 1, Mor-gan Kaufmann, 1999, pp. 468–477.

For more information on this or any other com-puting topic, please visit our Digital Library atwww.computer.org/publications/dlib.


T h e A u t h o r sJosé Luis Ambite is a senior research scientist at the University of South-ern California’s Information Sciences Institute. His research interests includeinformation integration, automated planning, databases, and knowledge rep-resentation, and his current focus is on automatic Web service composition.He received his PhD in computer science from USC. He is a member of theAAAI and ACM SIGMOD. Contact him at USC Information Sciences Inst.,4676 Admiralty Way, Marina del Rey, CA 90292; [email protected];www.isi.edu/~ambite.

Craig A. Knoblock is a senior project leader at the University of SouthernCalifornia’s Information Sciences Institute and a research associate profes-sor in computer science. He’s also the chief scientist for Fetch Technologies.His research interests include information agents, information integration,automated planning, machine learning, and constraint reasoning. He receivedhis PhD in computer science from Carnegie Mellon University. Contact himat the USC Information Sciences Inst., 4676 Admiralty Way, Marina del Rey,CA 90292; [email protected]; www.isi.edu/~knoblock.

Maria Muslea is a research programmer at the University of Southern Cal-ifornia’s Information Sciences Institute. Her research interests include infor-mation integration and constraint programming. She received her MS in com-puter science from West Virginia University. Contact her at USC InformationSciences Inst., 4676 Admiralty Way, Marina del Rey, CA 90292;[email protected]; www.isi.edu/~mariam.

Steven Minton is the chief technology officer of Fetch Technologies. Hisresearch interests include machine learning, planning, and constraint satis-faction. He received his PhD in computer science from Carnegie Mellon Uni-versity. He founded the Journal of Artificial Intelligence Research and servedas its first executive editor. He has also served as an editor of Machine Learn-ing. He’s a fellow of the AAAI. Contact him at Fetch Technologies, 2041Rosecrans Ave., Ste. 245, El Segundo, CA 90245; [email protected];www.fetch.com.

Figure 7. HeraclesMaps: (a) satellite image, vector data, and map; (b) line-of-sight computation using elevation data.

(a) (b)

Conditional Constraint Networks for Interleaved Planning ... · expansion variable. Figure 4 shows...

Documents

Transcript of Conditional Constraint Networks for Interleaved Planning ... · expansion variable. Figure 4 shows...