Semantic Web Service Composition Planning with OWLS-Xplan∗

Matthias Klusch, Andreas GerberGerman Research Center for Artificial Intelligence,

Stuhlsatzenhausweg 3, 66123 Saarbruecken, Germany,{klusch, agerber}@dfki.de

Marcus SchmidtDIaLOGIKa GmbH,

Albertstrasse, 66125 Saarbruecken, GermanyMarkus.Schmidt@dialogika.de

Abstract

We present an OWL-S service composition planner, calledOWLS-Xplan, that allows for fast and flexible compositionof OWL-S services in the semantic Web. OWLS-Xplan con-verts OWL-S 1.1 services to equivalent problem and domaindescriptions that are specified in the planning domain descrip-tion language PDDL 2.1, and invokes an efficient AI plan-ner Xplan to generate a service composition plan sequencethat satisfies a given goal. Xplan extends an action basedFastForward-planner with a HTN planning and re-planningcomponent.

IntroductionOne of the striking advantages of web service technology isthe fairly simple aggregation of complex services out of alibrary of simpler or even atomic services. The same is ex-pected to hold for the domain of semantic web services suchas those specified in WSMO or OWL-S. The composition ofcomplex services at design time is a well-understood princi-ple which is nowadays supported by many broadly availabletools and other composition planners such as SHOP2.

Hierarchical task network (HTN) planners such asSHOP2 perform well in domains for which complete anddetailed knowledge on at least partially hierarchically struc-tured action execution patterns is available, such as, for ex-ample, in scenarios of rescue planning. In domains in whichthis is not the case, i.e., no concrete set of methods and de-composition rules that lead to an executable plan are pro-vided, an HTN planner would not find the solution due to thefixed structure of hierarchical action decompositions storedin its database. That inherently limits the degree of qual-ity of any HTN planner to that of its used methods that arecreated by human experts.

In contrast, action based planners are able to find a so-lution based on atomic actions as they are described inthe methods, but without using the structure of the latter.Atomic actions can be combined in multiple ways to solvea given planning problem. But how to cope with planningproblems that are in part hierarchically structured according

∗This work has been supported by the German Ministry of Ed-ucation and Research (BMBF 01-IW-D02-SCALLOPS), and theEuropean Commission (FP6 IST-511632-CASCOM).Copyright c© 2005, American Association for Artificial Intelli-gence (www.aaai.org). All rights reserved.

to decomposition rules and methods but not solvable exclu-sively by means of HTN planning?

For this purpose, we developed a hybrid AI plannerXplan (Schmidt 2005) which combines the benefits ofboth approaches by extending an efficient graph-plan basedFastForward-planner with a HTN planning component. Touse Xplan for semantic Web-Service composition, XPlanis complemented by a conversion tool that converts OWL-S 1.1 service descriptions to corresponding PDDL 2.1 de-scriptions that are used by Xplan as input to plan a servicecomposition that satisfies a given goal. In contrast to HTNplanners, Xplan always finds a solution if it exists in the ac-tion/state space over the space of possible plans, though theproblem is NP-complete. Xplan also includes a re-planningcomponent to flexibly react to changes in the world stateduring the composition planning process. Together the im-plementations of Xplan and OWLS2PDDL converter makeup the semantic Web service composition planner OWLS-Xplan.

The remainder of this paper is structured as follows. Sec-tion 2 provides an overview of the OWLS-Xplan system ar-chitecture, followed by a brief description of the integratedconverter module OWLS2PDDL in section 3. The core ofOWLS-Xplan, the hybrid planner Xplan, is presented andcompared with SHOP2 in section 4 and 5, respectively. Weconclude in section 6.

OWLS-Xplan OverviewOWLS-Xplan consists of several modules for preprocessinfand planning. It takes a set of available OWL-S services, adomain description consisting of relevant OWL ontologiesand a planning query as input, and returns a plan sequenceof composed services that satisfies the query goal.

For this purpose, OWLS-Xplan first converts the domainontology and service descriptions in OWL and OWL-S, re-spectively, to equivalent PDDL 2.1 problem and domain de-scriptions using its OWLS2PDDL converter. The domaindescription contains the definition of all types, predicatesand actions, whereas the problem description includes allobjects, the initial state, and the goal state. Both descriptionsare then used by the AI planner Xplan to create a plan (repre-senting one composed web service) in PDDL that solves thegiven problem in the actual domain and initial state. For rea-sons of convenience, we developed a XML dialect of PDDL,

called PDDXML, that simplifies parsing, reading, and com-municating PDDL descriptions using SOAP. Table 1 showsthe corresponding notions of both the AI planning and se-mantic web service domain.

planning domain semantic web service domain(atomic) operator service profile(atomic) action atomic web service,

atomic processcomplex action service model

method composed web service,workflow, composite process

Table 1: Correlating notions of the planning and semanticweb service domain

An operator of the planning domain corresponds to a ser-vice profile in OWL-S: Both operator and profile, in essence,describe a pattern or template of how an action or web ser-vice as an instance should look like. A method is a specialtype of operator, that allows the user to describe workflowsor composed web services. The planner may use methods asa hierarchical task network during its planning process.

Converter OWLS2PDDLThe conversion of OWL-S 1.1 service descriptions toPDDXML requires not only the straight forward transcrip-tion of types and properties to PDDL predicates but the map-ping of services to actions (cf. figure 1). Due to space limi-tations, we only describe the essential translation process.

Figure 1: Mapping between OWL-S service and PDDL ac-tion description

Any OWL-S service profile input parameter correlateswith an equally named one of an PDDL action, and thehasPrecondition service parameter can directly be trans-formed to the precondition of the action by use of predi-cates. The same holds for the hasEffect condition parame-ter. Figure 3 provides an example of such a mapping of anOWL-S 1.1 service that calculates the route from given GPS-position of an accident to the nearest hospital for an emer-gency physician to the equivalent PDDL 2.1 action descrip-tion. Either this service already exists, hence its translationis part of the planning domain description, or, as a requested

service (query) becomes part of the planning problem de-scription.

Figure 2: Part of OWL-S 1.1 service description

Figure 3: Part of action description in PDDXML convertedby OWLS2PDDL

However, the conversion of the output of an individualOWL-S service, that is the information the service offers tothe world, to PDDL turns out to be more problematic. Theproblem is that the service hasEffect condition explicitly de-scribes how the world state will change while this is not nec-essarily the case for an hasOutput parameter value, though itindeed could implicitly influence the composition planningprocess. However, PDDL does not allow to describe non-physical knowledge such as train connections produced asan output of a service.

This problem can be solved by mapping the service outputparameter X to a special type of the service hasEffect pa-

rameter. In particular, every output variable X is describedin, and added to the current (physical) planning world stateby means of a newly created add-effect predicate in PDDLuniquely named ”agentHasKnowledgeAbout(X)”. Sim-ilarly, each input variable Y is mapped to an input pa-rameter Y of an PDDL action complemented by precondi-tion predicate ”agentHasKnowledgeAbout(Y )”. OWLS-Xplan would only use a service description during itsplanning process, if the additional precondition predicate”agentHasKnowledgeAbout(Y )” on available knowl-edge about service input data is satisfied such that X = Yholds. Otherwise the service execution could fail sincechecking the service preconditions may reveal that they arenot satisfied in the actual world state.

Figure 4: Part of initial world state semi-automatically builtby OWLS-Xplan editor

Figure 5: Part of problem description in PDDXML con-verted by OWLS2PDDL

Figure 4 shows an example of an inital world state thathas been semi-automatically built by the OWLS-Xplan ed-itor. In particular, it currently provides application-orientedtemplates to the user that allow her to quickly enter, mod-ify, and validate the initial world state and the query, i.e.,the goal state, depending on the specific situation and prob-lem at hand. If the user wants to query the agent for a

medical transporation service, she only has to fill in a fewpre-given templates, thereby setting the values of default pa-rameters of world state and one requested service with re-lated OWL ontologies attached to the template. This ini-tial state and request description is then automatically con-verted to the corresponding PDDXML problem descriptionby OWLS2PDDL (cf. figure 5). This, in turn, is fed intothe planner Xplan to find a solution, i.e. a plan sequence ofservices or actions on the initial world state that satisfy thegiven goal.

The AI planner XplanXplan is a heuristic hybrid search planner based on the FF-planner developed by Hoffmann and Nebel (Hoffmann &Nebel 2001). It combines guided local search with graphplanning, and a simple form of hierarchical task networks toproduce a plan sequence of actions that solves a given prob-lem. This yields a higher degree of flexibility compared topure HTN planners like SHOP2 (Sirin et al. 2004) whereasthe use of predefined workflows or methods improves the ef-ficiency of the FF-planner. In contrast to the general HTNplanning approach, a graph-plan based planner is guaran-teed to always find a solution independent from whether thegiven set of decomposition rules for HTN planning would al-low to build a plan that contains only atomic actions. In fact,any graph-plan based planner would test every combinationof actions in the search space to satisfy the goal which, ofcourse, can quickly become prohibitively expensive.

Xplan combines the strengths of both approaches. It isa graph-plan based planner with additional functionality toperform decomposition like a HTN planner. Figure 6 showsan example of how Xplan of OWLS-Xplan uses only thoseparts of a given method for decomposition that are requiredto reach the goal state with a sequence of composed servicesWS1 and WS3. In contrast, HTN planning would com-pletely decompose M into WS1 followed by WS2, henceoutput also WS2 which is of no use for reaching the goal.

Figure 6: Using parts of methods to reach a goal state inOWLS-Xplan

OverviewThe Xplan system consists of one XML parsing module, andfollowing preprocessing modules. First, required data struc-tures for planning are created and filled, followed by thegeneration of the initial connectivity graph and goal agenda.The latter two actions are interleaved with replanning. Thecore (re-)planning modules concern the heuritically relaxed

Figure 7: Architecture of Xplan

graph-plan generation and enforced hill-climbing search (cf.figure 7).

After the domain and problem definitions have beenparsed, Xplan compiles the information into memory effi-cient data structures. A connectivity graph is then generatedand efficiently realized by means of a look up table, whichcontains information about connections between facts andinstantiated operators, as well as information about numeri-cal expressions which can be connected to facts. This con-nectivity graph is maintained during the whole planning pro-cess and used for the actual search. In case of a replanningsituation, the connectivity graph is adjusted according to thechanged new world state.

Xplan uses an enforced hill-climbing search method toprune the search space during planning, and a modified ver-sion of relaxed graph-planning that allows to use (decom-position) information from hierarchical task networks dur-ing the efficient creation of the relaxed planning graph, ifrequired, such as in partially hierarchical domains. Infor-mation on the quality of an action (service) are utilized bythe local search to decide upon two or more steps that areequally weighted by the used heuristic.

In addition, Xplan includes a replanning componentwhich is able to re-adjust outdated plans during executiontime. Therefore, the execution engine informs the planningmodule about changed world states, and the Xplan replan-ning component decides whether the remaining plan frag-ment to execute is still valid or whether a re-planning has tobe initiated. Figure 9 shows a fragment of the plan descrip-tion produced by Xplan, i.e., a sequence of actions, that isthe composed sequence of corresponding OWL-S services,that can be executed by the agent.

We implemented Xplan modularly in C++, using the Mi-crosoft MSXML Parser for reading PDDXML definitionsand generating plans in XML format. Alternatively, Xplanalso provides an interface for direct interchange of planningdata without having to use PDDXML as interchange format.Each component of Xplan will be described in more detailin subsequent sections.

Data preprocessing componentSolving a planning process can be viewed as a search prob-lem in the space of all possible combinations of action se-

Figure 8: Part of plan description in PDDXML.

quences. Xplan starts off with preprocessing the input dataassigning initial values to each predicate of the given (prob-lem and domain) state description in PDDL.

Type relation, conversion and simplification of formu-las. In the second step, Xplan creates a matrix, that describesall type relations and type inclusions. Predicates which areneither negative nor positive in the effect list of an opera-tor are considered static for the complete planning process,hence are removed from all preconditions and effect lists.Then, the preconditions and effects are converted to disjunc-tive normal form.

Operator-templates, instantiation and reduction ofsearch space. Xplan creates templates from these simpli-fied operators which are instantiated by all possible combi-nations of input data based on object instances as describedin the PDDL problem description. The set of instantiated op-erators is then reduced by means of fixed point computationleading to useable and relevant operators. This is achievedby iteratively starting with applying all operators to the ini-tial state. Facts that are added to the state by operators willbe stored in a potential positive facts list. The respectiveoperators are marked as relevant. This process is repeateduntil either no new facts nor operators are added to the lists.Operators and facts that are neither reachable nor able to befulfilled, are removed from the basis set of instantiated op-erators. Relations between instantiated methods, complexactions and atomic actions are built, to speed up the searchand decomposition later on. Furthermore, to guarantee com-pleteness while searching, all negative facts that have a cor-responding fact in the potential positive facts list are alsostored in the list of relevant facts. Both relevant facts andoperators are used to build the connectivity graph.

Generation of the connectivity graph and goalagenda

The connectivity graph is built upon the list of relevant facts,and relevant operators in an iterative process that detects the

dependencies between the precondition, add- and delete listsof operators and facts. Once created, the connectivity graphremains static during the search and planning process. Incontrast to traditional plan graph algorithms, Xplan does notconsider the complete set of goals as a whole but computesan ordered list of goals, the so called goal agenda. The cor-responding goal graph is generated based upon this agendaand the FALSE-sets of each goal. Finally, the transitive hullover the goal graph is being computed which is then used toclassify goals into goal sets.

Let (O, I,G) be a planning problem for which a goalagenda with n goal-sets Gs0, . . . , Gsn exists. The searchalgorithm starts with the initial state I0 = I and the firstgoal-set Gs0 as the planning goal G. If a solution P1 isfound which leads from I0 to Gs0, then the plan is used onP1 and I0. The resulting state I1 = Result(I0, P0) is thenused as the starting point for the search using I1 as initialstate and planning goal G = Gs0 ∪ Gs1. Thus all reachedgoals Gs0 to Gsk−1 remain valid while searching for a so-lution for Gsk. For the current planning goal Gk in iterationk it holds that

Gk =k⋃

i=0

Gsi

The Xplan search algorithm uses a no-ops first-strategy, i.e.,goals achieved in previous iterations are marked and onlytemporally deleted if they will be generated again later on.This guarantees that the planner generates no sub-optimalplans with loops.

The Relaxed Graphplan heuristicAfter the goal-agenda has been generated, the search pro-cess starts. The search consists of two interleaved processes.The Relaxed Graphplan heuristic (Hoffmann 2000) approx-imates the distance between the initial state I to all reach-able states S. These distance values are then used to guidethe forward directed search. After each successful step thedistance values are updated again using the heuristic.

Definition 0.1 A state S = (FS , hS , NS) is defined as

• FS is a set of all facts which are true in state S.• hS is distance to the goal given by a heuristic.• NS is a set of helpful action which can be used in state S.

Complex actions and hierarchical task networkswithin relaxed Graphplan We have expanded the Re-laxed Graphplan heuristic based algorithm by adding anHTN planner component, and utilization of numerical andboolean facts that can be updated online during the planningphase by external function calls. As a consequence, not onlyatomic operators but also complex actions and methods areallowed during planning. If a complex action is used whilegenerating a plan graph of which preconditions on somegraph layer Ei are satisfied, the HTN component then triesto decompose the complex action using a method-structureelement or complex task. A relevant method is searchedfor by looking up the connectivity graph. Since more thanone method could be relevant for decomposition, a heuristichd

htn is used to determine the most useful one. The selected

partial task network itself may contain complex actions thathave to be recursively decomposed. Through selection ofuseable operators Oi of plan graph layer Ei the algorithmfirst tries to select complex actions. If a solution cannot befound by decomposition, Xplan tries to find a solution with-out using the HTN component.

External procedure calls Many planners offer the possi-bility to use numerical values with the standard operators+,−, ∗,÷, . . . during the planning process. In most casesthese functions are not only bounded in their number butrather hard-coded in the planner such as in the Metric-FFplanner (Hoffmann 2003). This is a drawback because thesystem cannot be expanded without having to change thecode. In contrast, Xplan offers the use of so-called exter-nal call-back functions. A call-back function is linked to apredicate by means of a fluent variable which contains its re-turn value. This way, Xplan is able to obtain actual informa-tion on the value of predicates during the planning proces bycalling the linked call-back function. The function returns aboolean value which indicates whether the linked predicateis set or removed from the world state in the next layer of theplan graph. New call-back functions can be added withoutchanging the code of the planner itself.

The fluents are utilized by the planner on both the globalfluent-layer of the plan graph, that represents the currentstate in the computed plan, and the local fluent-layer stor-ing the changed new states of the fluents for their use in thenext planning steps. An update of the global fluent-layer isperformed each time the fast-forward search finds a betterstate with respect to a given utility function. The values ofthe local fluent-layer are used for calculating those facts thatare satisfied by executable actions of some layer of the plangraph. The pseudo-code of the algorithm 1 for generatingthe relaxed plan graph is provided in the annex of this paper.

Extraction of a relaxed plan from the planning graphLet (O′, Ix,G) the planning problem to solve and PG therelaxed plan graph with k layers. Figure 9 shows a simpleexample of problem and domain description together withinitial part of a corresponding plan graph.

The search for a relaxed plan starts at the top most layerEk−1. For every goal of the current layer E i, i < k, an ac-tion of Ei−1 is selected that satisfies one or multiple goals.Let Fi be the set of facts of layer Ei, then the selection ofgoals is done by use of a heuristic hd that measures the bar-rier for executing an action.

hd(o) :=∑

p∈pre(o)

min{i |p ∈ Fi} + (1 − QoS(o))

with QoS(o) ∈]0, 1] quality of service of action o. The inter-section of the set of selected actions’ preconditions of E i−1

and the facts of Ei−1 makes up the goal set Gi−1 of layerEi−1. This goal set then has to be fulfilled by use of ac-tions of the subsequent layer Ei−2. The recursion is goingon until the lowest layer of the planning graph with initialfacts is reached. This is then the relaxed plan, that consistsof an action sequence A0 . . . Ak−1. k − 1 is the index of thefirst layer which contains all goals of the original problem.

Figure 9: Part of a plan graph with k = 3 layers

To get an approximation how far away it is from state Ix togoal G, a heuristic h(Ix) (described in (Hoffmann 2000)):

h(Ix) :=k−1∑

i=0

|Ai|

The value h(Ix) indicates the length of the relaxed, sequen-tial solution of O starting with Ix. This value in combina-tion with the state information Ix constitutes the new searchstate S which is included into the search space of the fastforward search.

Detecting helpful actionsIn addition to the heuristic, Xplan computes the set HS ofhelpful executable actions for every search state S such thatthe goal G eventually can be reached.

Definition 0.2 A helpful action of a search state S is an ac-tion, that satisfies at least one proposition of the goal set G1

of the first layer in the plan graph. The set of helpful actionsis described as follows:

HS(S) := {o | (pre(o) ⊆ S) ∩ (add(o) ∩ G1(S) �= ∅)}If there are many helpful actions, then actions of an HTNdecomposition are preferred. The reason is, that such actionsare more highly probable to be succeeded by an useful actionin the task network as part of the relaxed plan.

Local search with enforced hill-climbingXplan uses an enforced hill-climbing search algorithm tosearch for best reachable states during generation of theglobal plan to satisfy a given goal. It combines the standardsearch strategy with a breadth search for a better state thanthe given one not only in its direct neighborhood but withinthe set of successor states of S that are reachable by apply-ing a helpful action of NS. This search strategy performs asfollows.

• Compute the distance between the starting state I and thegoal state G by use of Relaxed Graphplan, and the set ofhelpful actions I .

• Initialize the enforced hill-climbing with I =(FI , hI , NI) as input.

• Enforced Hill-Climbing analyzes all reachable states thathave been computed. It assigns each state with its approx-imative distance to the goal by use of Relaxed Graphplan.

• If a better state is found, then include this state into thecurrent plan, and use it as a basis for further search. Up-date all fluents on the current layer by invoking the re-spective call-back functions.

• Terminate if a state S ′ = G is reached in which all givengoals are satisfied. Otherwise, if not at least one goal hasbeen achieved, the search failed. In this case, a new com-plete breadth search is instantiated on I to find a solution,if it exists.

The pseudo-code of the local search by enforced hill-climbing algorithm is shown in algorithm 2.

Re-planning component

During plan execution, the agent has to check for each actionof the plan whether its preconditions hold, or not. If at leastone precondition is not satisfied, Xplan gets informed aboutwhich facts are invalid, at which position in the plan thisproblem occurs, and then checks whether the original planstill can be executed. Otherwise, it tries to fix the problemby searching for an alternative path in the connectivity graphfrom the actual position in the plan to the goal state. In addi-tion, it may temporally block unnecessary actions to reducethe search space, thereby avoiding a complete preprocessingphase.

Plan patterns

Xplan builds ordered service composition plan sequencesonly whereas OWL-S allows for more complex plan struc-tures such as unordered, choice, if-then-else, iterations,repeat-until loops, repeat-while loops, split, and split+join.However, complex plan structures can be formed out of theproduced plan sequence based on its appropriate analysisand interpretation in posterior. For example, figure 10 showshow a plan sequence looks like, that can be transformed intoa split+join structure. In this case, the input of WS2 doesnot depend on the output of WS1, hence both services maybe executed concurrently. Since both are required to achievethe given goal, their results have to be joined after execution.

Figure 11 shows an example of how to realize a split struc-ture. Like in previous example, both services neither influ-ence each other, nor share a common goal to reach, thus canbe executed in parallel.

However, the plan structures ”choice” and ”unordered se-quence” are not realizable by proper interpretation of plansequences created by Xplan. Though, the latter problem isa hard problem for any AI planner in general, including, forexample, Shop2 (Sirin et al. 2004).

Figure 10: Split + Join interpretation

Figure 11: Split structure of an OWLS-Xplan plan

Related workA logic-based DAML-S composition planner has been de-veloped at the UMBC, USA (Sheshagiri, desJardins, &Finin 2003). This planner uses STRIPS-style services tocompose a plan, given the goal and set of basic services. Itis implemented with JESS (Java Expert System Shell), anduses a set of JESS rules to translate DAML-S descriptionsof atomic services into planning operations.

One of the currently most prominent service compositionplanners is Shop2 (Simple Hierarchical Ordered Planner 2)developed at the University of Maryland, USA (Wu et al.2003). It is a hierarchical task network (HTN) planner well-suited for working with the hierarchically structured OWL-Sprocess model. The authors proved the correspondence be-tween the semantics of Shop2 and situation calculus seman-tics of the OWL-S process model. The implemented Shop2soundly and completely plans over sets of OWL-S descrip-tions, and treats the output of a web service as effects thateither change the planning agent’s knowledge, or the worldstate. Shop2, like HTN planner in general, replaces thoseelements of the provided methods (workflows) by specialmethods or atomic actions until the composition plan con-tains only atomic actions that correspond to available webservices. During planning, web services are not executed,

hence do not affect the world state.Both Xplan and Shop2 base on the closed world assump-

tion, use PDDL for problem description, allow external(call-back) functions to be bounded to variables and exe-cuted during planning, and generate total ordered, instan-tiated plan sequences for a given initial state, goal and plan-ning domain. Among others, the main difference betweenShop2 and Xplan is inherent to the individual planning pro-cesses. In essence, Shop2 plans are generated by use ofgiven decomposition rules (methods), hence a solution tothe planning problem is not always guaranteed to be found(Lotem, Nau, & Hendler 1999). In contrast, hybrid Xplan aspart of OWLS-Xplan tries to plan by means of (a) methoddecomposition using only relevant parts of it, discardinguseless actions, thereby reducing the plan size, and (b) ifthis is not successful, uses its relaxed graph plan algorithmto find a solution, if it exists.

ConclusionWe presented an OWL-S service composition planner, calledOWLS-Xplan, that allows for fast and flexible off-line com-position of OWL-S services by use of an OWLS2PDDL con-verter, and a hybrid AI planner that combines relaxed Graph-plan FF-planner with local search and HTN based planning,and a re-planning component. OWLS-Xplan has been im-plemented in C++ and Java, and is currently in use in a pro-totyped medical health information service system. It is in-tended to make the OWLS-Xplan code package available tothe community at www.semwebcentral.org.

ReferencesHoffmann, J., and Nebel, B. 2001. The FF Planning System: FastPlan Generation Through Heuristic Search. Journal of ArtificialIntelligence Research (JAIR) (14):253–302.

Hoffmann, J. 2000. A heuristic for domain indepndent planningand its use in an enforced hill-climbing algorithm. Proceedingsof 12th Intl Symposium on Methodologies for Intelligent Systems,Springer Verlag.

Hoffmann, J. 2003. The Metric-FF planning system: Translat-ing Ignoring Delete Lists to Numeric State Variables. ArtificialIntelligence Research (JAIR), vol 20.

Lotem, A.; Nau, D.; and Hendler, J. 1999. Using planning graphsfor solving HTN problems. Proceedings of AAAI/IAAI confer-ence, USA.

Schmidt, M. 2005. Ein effizientes Planungsmodul fuer die lokalePlanungsebene eines InteRRaP Agenten. Master’s thesis, Univer-sitaet des Saarlandes.

Sheshagiri, M.; desJardins, M.; and Finin, T. 2003. A plannerfor composing services described in DAML-S. Proceedings ofAAMAS 2003 Workshop on Web Services and Agent-Based Engi-neering.

Sirin, E.; Parsia, B.; Wu, D.; Hendler, J.; and Nau, D. 2004. HTNplanning for web service composition using SHOP2. Journal ofWeb Semantics, 1(4) 377–396.

Wu, D.; Parsia, B.; Sirin, E.; Hendler, J.; and Nau, D. 2003.Automating DAML-S web services composition using SHOP2.Proceedings of the 2nd International Semantic Web Conference(ISWC2003), pages 20-23, Sanibel Island, Florida, USA.

function BuildRelaxedPlanningGraph() computesrelaxedPlanningGraph or failsinput: InitialFacts[] : List of Factsinput: GoalFacts[] : List of Factslocal: CurrentLayerFacts[], NextLayerFacts[] : List ofFactslocal: CurrActivActions[] : List of Actionslocal: CurrentLayer : intbegin

CurrentLayerFacts = IntitialFacts;CurrentLayer = 0;while ! AllGoalsActive(GoalFacts) do

foreach Fact f in CurrentLayerFacts doIncrement precondition counter of actionswhich f is a precondition of;

endforeach Fact f in CurrentLayerFacts do

/* First collect all action,that are a result of amethod decomposition andcompute the layer, when itis earliest executed. */

CurrActivHTNActions +=GetActiveHTNActions(CurrentLayer,f );/* Select all remaining

executable actions, thatare part of thecurrent-layer */

CurrActivActions +=GetActivePrimitiveActions(CurrentLayer,f );

endforeach Action a in CurrActivHTNActions do

if all preconditions of a are satisfied ANDLayer of a == CurrentLayer then

/* a is executable, allpreconditions arefulfilled and isexecutable in the layer*/

NextLayerFacts +=GetAddedFactsFromAction(a);RemoveFromList(a,CurrActivHTNActions);

endendforeach Action a in CurrActivActions do

if all preconditions of a are satisfied ANDLayer of a == CurrentLayer then

NextLayerFacts +=GetAddedFactsFromAction(a);RemoveFromList(a,CurrentActivateActions);

endendCurrentLayerFacts = NextLayerFacts;NextLayerFacts = <>;/* Increasing layer counter and

continue with next layer. */CurrentLayer = CurrentLayer + 1;if CurrentLayerFacts == <> then/* If a fix point is reached

regarding facts and actionsand the goal isn’t fulfilled,the problem isn’t solvable.*/

if ! AllGoalsActive(GoalFacts) thenreturn FAILURE;

endendreturn CurrentLayer;

end

Algorithm 1: Generating a relaxed plan graph

function DoEnforcedHillClimbing() computesvalidPlan: Plan or failsinput: InitialState : State input: GoalState : State

local: S : State /* the current computedstate */

local: S’ : State /* possible successor of S*/

local: currPlan : Plan /* current plan */local: hS : int /* the distance of S to a

goal computed by use of RelaxedGraphplan */

local: hS′ : int local: NS[] : List of Actions /* Listof helpful action based on state S*/

local: NS′ [] : List of Actions

begin/* The initial plan is empty */currPlan = <>;S = InitialState; /* Compute the distance

from starting state to goal */hS = BuildRelaxedPlangraph(S,GoalState);/* Compute helpful actions for S

*/NS = GetHelpfulActions(S);while hS �= 0 do

/* Searching with breadth searchfor a state S’ with HS′ < HS

within NS and theirsuccessors. BFS Expandcomputes for every relevantstate the distance betweengoal and helpful actions.This is done byBuildRelaxedPlangraph andGetHelpfulActions */

S’ = BFS Expand(S,NS);if S’ == NULL then

return FAILURE;else

/* If a state S’ is found,the action sequence isattached to the end of thecurrent plan, that enablesto get from S to S’. */

currP lan =currP lan + ActionsPath(S, S′);/* Update fuents of the

global fluent-layer */UpdateGlobalFluents(S,S’);/* The search goes on

beginning with S’. NS′ iscomputed before byBFS Expand and can still beuse. */

S = S’;NS = NS′ ;

endendreturn currPlan;

end

Algorithm 2: Local Search by enforced hill-climbing