Information about http://www.ai.sri.com/pubs/files/1150.pdf
A Portable Process Language …
Tags: abstraction, action selection, artificial intelligence center, boeing, chaudhri, explanation generation, inferences, menlo, menlo park, menlo park ca, morley, phantom, ppl, reasoning capabilities, reasoning methods, representation languages, seattle wa, sri international, task decomposition, vinay,Pages: 7
Language: english
Created: Mon Apr 18 17:26:41 2005
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
A Portable Process Language
Peter E. Clark1, David Morley2, Vinay K. Chaudhri2, Karen L. Myers2
1
M&CT, Boeing Phantom Works, PO Box 3707, Seattle, WA 98124
2
Artificial Intelligence Center, SRI International, Menlo Park, CA 94025
peter.e.clark@boeing.com, {morley,chaudhri,myers}@ai.sri.com
Abstract may play out. However, many tasks require that a system
Process representation languages designed to support execution be able to introspect on its own general procedures, in
have evolved to support specialized reasoning capabilities like particular language understanding, question answering,
action selection and task decomposition, but do not readily and explanation. This has been particularly true in the
support inferences that one might need for explanation or context of CALO, an integrated cognitive assistant.1 As a
question answering. In this paper, we report on a process result, we have enhanced SPARK with a second API
language, PPL, that we have designed to serve as a bridge allowing it to export (an abstraction of) its general
between a representation designed for execution and a procedures also. These exported procedures are expressed
representation designed for applications such as question
in logic in Portable Process Language (PPL), a language
answering and explanation generation. Through its use of a
propositional-style representation of process structure, PPL can we have designed for this purpose, complementing
enable the use of generalized reasoning methods for those SPARK-L, the native process language of SPARK. The
purposes. PPL is novel in that it directly encodes the process goals of PPL are to make explicit the steps, their
"flow chart" in a neutral, KIF-like syntax, allowing other modules arguments, and their relationships in the procedures, and to
to introspect on the process structure. abstract away some of the details critical for execution but
not needed for introspection.
Introduction
SPARK (SRI Procedural Agent Realization Toolkit)
[Morley and Myers 04] is an agent framework that builds
on a Belief-Desire-Intention (BDI) model of rationality.
SPARK provides a flexible plan execution mechanism that
interleaves goal-directed activity and reactivity to changes
in its execution environment. SPARK's procedural
language has a clear, well-defined formal semantics that
can support reasoning techniques for procedure validation,
synthesis, and repair. The SPARK representation language
(called SPARK-L) is an extended form of Hierarchical
Task Network (HTN) representation [Erol et al. 04].
Extensions beyond standard HTN include iteration,
conditional branching, and certain runtime-specialized
constructs (WAIT, TRY). As a close analogy, consider a system wanting to
introspect on a piece of software, but only having an API
SPARK includes a comprehensive API for monitoring to the trace of that software executing. The system could,
executing procedures--called procedure instances-- of course, literally try to parse the source code
allowing external modules to view the "trace" of a representation of the software and try to work out what it
procedure's execution. For example, by using this API an did (in fact, some software analysis tools do exactly this),
external module can find the specific task(s) currently but this requires the system to have a complete internal
being executed, and trace back to find specific previously model of the programming language, both syntax and
executed tasks and their details. However, while allowing semantics. Instead, it would be nice if the software could
access to how a general procedure is playing out, this API export a high-level summary of its behavior--literally, a
does not allow access to the general "flow chart" of the flow-chart-like data structure--that other systems could
procedure itself, for example, to find possible future tasks,
choice points, cycles, and alternative ways the procedure 1
See http://www.ai.sri.com/project/CALO
then manipulate, expressed in some relatively
implementation-independent language. Our goal is that [set: V T] - Set variable V to the value T.
PPL be such a language, in the specific context of SPARK- [do: A ] Perform action A.
like planning systems. [seq: N1 N2 ... ] Attempt task networks N1, N2, ...
sequentially.
In this paper, we describe a simplified version of the [parallel: N1 N2 ... ] Attempt task networks N1, N2,
SPARK language and how it is executed, the reasoning ... in parallel.
requirements, PPL, and experiences in using the language [select: P1 N1 P2 N2 ... ] Execute the task expression
in the context of an agent system. We conclude with Ni corresponding to the first logical expression Pi that has
directions for future work. a solution. Fail if none has a solution.
[wait: P1 N1 P2 N2 ... ] As select, but wait instead of
failing.
Description of SPARK Process Language [while: P N] While P has a solution execute N.
The SPARK process language provides a hierarchical
representation of processes. A library of procedures At its simplest, a SPARK procedure has the form
provides declarative representations of activities for {defprocedure name cue: trigger precondition: P
responding to events and for decomposing complex tasks body: N}
into simpler tasks. Each procedure has a precondition
stating conditions under which it can be applied, and a task This indicates that if P is true when trigger occurs, then
network expression describing how to respond to an event executing N is a valid way of responding. The cue may be
or to decompose a non-primitive action. The hierarchical of the form [newfact: P] to respond to the fact P being
decomposition of tasks bottoms out in primitive actions added to the KB, or [do: A] to expand the action A.
that bring about some change in the outside world or the
internal state of the agent. A SPARK agent specification For example, the following procedure, Get_Bid, describes
includes declarations of predicate and task symbols, facts one way of expanding the task of performing action
about the initial state, and a library of procedures. The key find_bids. It is applicable if the condition (Online
syntactic structures include term expressions, logical "DM4QR") holds. It performs a laptop_query action that
expressions, actions, task expressions, and procedures. binds variable $temp_quotes and then depending upon
whether or not this list is empty, either performs
relax_and_redo_query, binding $quotes, or binds
A term expression represents a value. Atomic term
expressions are constants such as 42 and "Hi", and $quotes to $temp_quotes.
variables of the form $x. These are combined to form {defprocedure Get_Bid
compound term expressions, including lists such as [1 2 cue:
3]. [do: (find_bids $item $criteria $quotes)]
precondition: (Online "DM4QR")
Logical expressions are constructed from predicate (fluent) body:
[seq:
symbols applied to term expressions, e.g., (= 1 $x), [do: (laptop_query $criteria
(True), logical operators, and quantifiers. These $temp_quotes)]
expressions can be used to alter the flow of execution or to [select:
bind variables for use later in the procedure. (= $temp_quotes [])
[do: (relax_and_redo_query $criteria
$quotes)]
An action is constructed from an action symbol and term (True)
expressions as parameters, for example, (laptop_query [set: $quotes $temp_quotes]]]}
$criteria $quotes). The action may be primitive,
which is performed by executing some procedural SPARK Process Execution
attachment, or nonprimitive, which is hierarchically
expanded into subtasks using procedures. The parameters Figure 1 shows the architecture of each SPARK agent.
of an action may include free variables that are not bound Each agent is embedded in the world and interacts with the
at the time the action is attempted. These variables are world though sensors and effectors. Each agent has its own
bound by the successful execution of the action and knowledge base of beliefs and library of procedures. The
provide a means of returning values from executing the initial state of the beliefs and procedure library are initially
action. loaded from files written in the SPARK language. The
beliefs are updated by the agent's sensors and through the
A task network expression is a pattern of activity that when agent executing procedures. The set of procedure instances
attempted may either succeed or fail. Task network that the agent is executing at a given time form the
expressions include such constructs as intentions of the agent. At any time an agent may be
executing multiple intentions. At SPARK's core is the
executor whose role is to manage the execution of
intentions. The executor can post procedure subtasks as Reasoning Requirements
actions. Primitive actions cause effects through the We consider here the reasoning requirements for three
effectors. Non-primitive actions are expanded by the applications, and how introspection on the process model
executor according to the procedures the agent has itself is necessary to support them: (1) dialog
available. interpretation, (2) question answering, (3) explanation
generation.
Reasoning Requirements for Dialog Interpretation
Robust language processing is challenging in that what the
user says can be ambiguous, incomplete, and erroneous. In
the context of the CALO system that we are developing,
one class of dialogs (between the user and computer) that
we have been studying is "purchase dialogs", where the
user is directing CALO to purchase an item on the user's
behalf. In these dialogs, these problems can all occur, and
resolution of them requires the system to have strong
expectations, hence requiring knowledge of the processes
themselves.
For example, while instructing CALO to buy a computer,
if the user says "Find me an appropriate machine", the user
Figure 1: The Architecture of each SPARK agent. actually means "You have authorization to start retrieving
quotes from vendors for the laptop I want to purchase" (as
SPARK process execution proceeds as follows: (1) opposed to, for example, start physically searching the
Sensors update the agents beliefs. (2) These belief changes building to find machines). To find the correct
trigger the instantiation of procedures - those with a cue interpretation, CALO needs to have strong expectations
that matches the event and a precondition that is satisfied about what sort of activities may occur in the future, and
with respect to the agent's beliefs. (3) A subset of these then match the user's utterance with those expectations. In
applicable procedures is selected to be added to the this case, CALO contains a process model of how to
intentions. (4) The executor selects one intended procedure purchase items, and as this process model is currently
instance to progress by executing a single step. (5) This active (triggered by earlier statements by the user, such as
may cause updates to the beliefs or the posting of new "I want to purchase a laptop"), CALO should be able to
subtasks. (6,2) This in turn triggers the instantiation of look at future steps that could be construed as "finding a
procedures, and so on. machine" to identify what the user is referring to. In this
case, a subsequent step in the process is to retrieve quotes
The step by step execution of each procedure instance for the to-be-purchased computer, and a matching
results in the binding of values to variables in the algorithm can identify this as the most likely thing to
procedure instance. Each predicate that is tested or action which the user is referring [Yeh et al. 03]. To do this, the
that is executed results in all free variables becoming system needs to introspect on its general purchase plan
bound. Usually when a logical expression (such as may (procedure), to identify that a future step that can be
appear in a context: or select: task network expression) is construed as "finding" will occur.
tested, SPARK needs to commit to a single solution
without the possibility of backtracking. Reasoning Requirements for Question Answering
As a general-purpose assistant, CALO is expected to field
The approach that SPARK and many other BDI agent answers to a wide variety of questions from a user,
systems take to the hierarchical expansion of tasks is based including about its (CALO's) own knowledge of how to do
on an expectation that the agent is working in a highly things. While SPARK's execution trace API allows CALO
dynamic environment: the expansion of tasks is performed to answer questions about specific things it has done (e.g.,
at the time the task is to be executed and the choice of the "When you purchased the laptop, did you request
procedure to use is based on the current state of the agents authorization?"), CALO also needs knowledge of the
beliefs. BDI agent systems have been integrated with procedural flow chart itself for more general questions
planning systems (e.g., [Myers 99, Lemai and Ingrande about procedures, for example,
04]) however SPARK currently has no planning
component. 1. How do you purchase a laptop?
2. Will you need to access to the Web during the We now describe PPL, and then describe how it
purchase? complements PSL (Process Specification Language), a
3. Is authorization required [i.e., is there an language that captures the semantics but not the explicit
authorization step] to purchase a laptop over structure of a process flow chart.
$2000?
4. What will happen if the authorizing manager is Consider a toy example of a two-step process--namely,
unavailable? going to work--with a trivial two-step flow chart
5. Email the quotes you find to my home email consisting of (i) entering a car and then (ii) driving the car
address. to work:
6. Get authorization from Joe, not Steve.
The first four of these questions are independent of any Goto Work
specific execution of the procedure, and necessarily substeps
require access to the general procedure itself to answer the then
questions. The last two questions are in the context of a Enter Drive
partially executed procedure, in which the user is making object agent
agent object
reference to a to-be-executed future step. Again with these
two questions, the system needs a representation of the Person Car
general procedure to identify the future step to which the
user is referring (these are not in the execution trace, as
they have not yet happened). The PPL for a skolem instance process is follows:
Requirements for Supporting Explanation ;;; Steps in the flow chart
(instance-of goto-work1 goto-work-step)
In a related piece of work reported elsewhere, we are
(instance-of enter1 enter-step)
working on explaining processes. Answering "why"
(instance-of drive1 drive-step)
questions particularly requires introspecting not just on
what happened, but the specific tests and conditions that
(possibleTask goto-work1 enter1)
caused those things to happen, a particular form of meta-
(possibleTask goto-work1 drive1)
reasoning. Again, knowledge of the structure of the
(followedBy enter1 drive1)
process flow chart is often required to answer these
questions, including details of tests directing flow of
;;; Parameters to those steps
execution at branch points, and details of how earlier steps
(instance-of person1 person-var)
support later steps. (In its current form PPL does not
(instance-of car1 car-var)
capture all this knowledge, but it is a step toward this.)
Example questions from the user to CALO include
(agent goto-work1 person1)
(object goto-work1 car1)
1. Why didn't you ask for authorization?
2. Why did you send the purchase request to Dallas?
(agent enter1 person1)
3. Why haven't you started searching yet?
(object enter1 car1)
Portable Process Language (PPL) (agent enter1 person1)
(object drive1 car1)
Overview
To meet the reasoning requirements already identified, we In PPL, each of the steps in the flow chart is denoted by a
must be able to introspect SPARK processes to obtain specific individual. Note that these individuals are not
information as follows: What tasks are involved in task X? instances of events in the world (e.g., the specific event of
What task comes after task Y? Might task Z occur in entering the car at a certain time); rather, they are instances
process W? The goal of the Portable Process Language of steps in a flow chart. Similarly, each parameter (e.g., the
(PPL) is to represent just this kind of "flow chart" person, the car) for a flow chart step is denoted by a
information. PPL captures a filtered view of the SPARK specific individual. Again, note that these individuals are
process models to include tasks, subtasks, task parameters, not instances of objects in the world (e.g., a specific person
and task ordering. It does not currently capture the or car); rather, they are instances of parameters (variables)
semantics of conditional tests, context, and other logical in the flow chart. In other words, PPL is a somewhat literal
evaluations. Such extensions can be added in the future. logical depiction of flow chart steps, rather than of event
sequences. We can relate flow chart steps to event types
(classes), and flow chart parameters to object types laptop, the step "relax-and-redo" follows "laptop-query"
(classes), with some simple correspondence statements: only if no quotes were found. This appears in PPL as
(event-type-for goto-work-step goto-work) (conditionalFollowedBy laptop-query1
(event-type-for enter-step enter) (and "(= $temp_quotes [])")
(event-type-for drive-step drive) relax-and-redo1)
(object-type-for person-var person)
(object-type-for car-var car) This allows the external systems to see that relax-and-
redo1 is a possible next step in the plan, but not at present
where goto-work, enter, drive are types (classes) of actual to understand details of conditions under which it will be
events in the world, and person, car are types (classes) of executed (unless it was to parse the quoted logical
actual objects in the world. expressions).
Given a PPL flow chart, in principle one could "execute" it Additional Representational Properties
to perform the plan it denotes. However, the AI planning
While it is not our intention that PPL capture the full
community has long matured beyond these kinds of "toy"
details of the original SPARK process models, it is clear
executions--in the real world, plan execution also involves
that there are additional details that should be captured.
plan monitoring, recovery in the case of failure,
These include preconditions, "cue" conditions, and better
consideration of time and resource constraints, and so on.
handling of logical assertions and tests in the original
To adequately represent such executable processes, much
SPARK. These are all items for future work.
richer languages are needed, and this is precisely the role
of SPARK. Rather, one should view PPL as capturing a
simple abstraction of a complex executable process, in a How PPL is Generated
language-neutral form suitable for introspection, to support The PPL is generated by introducing specific individual
the kinds of tasks discussed earlier. names for each variable, for the cue task, and for each
atomic step, such as [do: A] in the procedure. SPARK
For contrast, a simple SPARK representation of the above action symbols, such as enter, become event types. Type
procedure would be and role declarations for the actions are translated into
object type statements and role statements. Thus, for an
{defprocedure Goto_Work_by_Car action enter with parameter roles agent of type person and
cue: [do: (goto_work $person $car)]
precondition: (True) object of type car, we translate
body:
[seq: [do: (enter $person $car)] [do: (enter $person $car)]
[do: (drive $person $car)]]} into
While suitable for execution, this syntactic structure is (instance-of enter1 enter-step)
more difficult to manipulate for introspection. Note also (event-type-for enter-step enter)
that some information in this SPARK representation is (agent enter1 person1)
implicit: PPL makes explicit the step ordering (implicit in (instance-of person1 person-var)
the ordering of lines of SPARK-L representation) and step- (object-type-for person-var person)
substep relations (implicit in the grouping of tasks within a (instance-of car1 car-var)
single procedure in SPARK-L). This allows other tools (object-type-for car-var car)
easy access to the process itself. (object enter1 car1)
Conditionals Each of the specific individuals corresponding to the
atomic steps is related to the individual corresponding to
PPL denotes conditional branches in a flow chart using a the cue by possibleTask. These tasks are considered only
predicate "possible" because conditional branching or unexpected
failures may prevent the tasks from being attempted:
(conditionalFollowedBy )
(possibleTask goto-work1 enter1)
meaning that if execution is at , and evaluates
to true, then the next step will be . At present, Of more interest is the ordering relationship between the
is the opaque (quoted) logical expression copied atomic steps, represented by the followedBy and
from the SPARK-L test itself, but our plan is to replace conditionalFollowedBy predicates. Determining this
this with a transparent logical expression, whose variables relationship requires walking over the body task network
include the parameter instances in the rest of the PPL. For expression, and keeping track of all the possible prior
example, from the SPARK procedure for purchasing a
atomic steps and the sequences of conditions that must be The last axiom states that for all occurrences of going to
satisfied for the current step to follow each of these. We work, there will be an occurrence of entering followed by
have to consider multiple prior atomic steps when an occurrence of driving. While this makes the semantics
considering a step following a parallel or select construct. of the original flow chart explicit, the actual structure of
An atomic step following a context construct or within a the flow chart has been lost (the simple relationship "enter
select or wait will be executed only if the appropriate drive" is expressed as a complex quantified logical
conditions holds, and there may be multiple conditions expression).
between the execution of one atomic step and another. To
translate iterative constructs, we need to introduce "null" In principle one could perhaps recover the original flow
tasks to link the start and end of the loop. chart by reverse-engineering it from these PSL axioms,
either by parsing the axioms themselves1 or by theorem
For simplicity, we have ignored the possibility of proving the general relationships (e.g., proving that driving
alternative procedures for the same action. However, this always follows entering in goto-work). However, neither
can be represented by making each procedure a subtype of of these options is particularly easy. In contrast, our goal
the event type for the action, and the making the cue an with PPL is to preserve the original flow chart structure so
instance of a step of that subtype. that it is directly accessible for other agents. One could
imagine extending PSL to include some predicate
"macros" that would allow the general flow chart
PPL and other Languages relationships to be made explicit, and which would also
expand to the traditional PSL axioms such as those shown
above. Conversely, PSL makes explicit the actual
PPL and PSL semantics of the flow chart, and PSL could be generated
A well-known standard for process representations is the from PPL if one wanted to make these semantics explicit
Process Specification Language (PSL) [Gruninger 04], a (indeed, PPL could be a "straw man" candidate for such
logic-based standard for capturing the semantics of PSL "macros").
processes.
PPL is intended as a complement to, rather than competitor PPL and OWL-S
of, PSL, as it captures process knowledge in a different
way. The most significant difference between PPL and OWL-S is a OWL-based Web service ontology, which
PSL is that PSL's representation of the ordering of steps is supplies Web service providers with a core set of markup
in terms of actual events ("activity occurrences"), while language constructs for describing the properties and
PPL orders the abstract flow chart steps ("activities") capabilities of their Web services in an unambiguous,
themselves. For example, in PSL the above toy plan for computer-interpretable form. Like PPL, OWL-S represents
going to work would be generic procedures themselves, and similarly uses
individuals to denote process objects and parameters used
% enter is a subactivity of going to work by those processes (In this sense, PPL is more similar to
(forall (?person ?car) OWL-S in approach than to PSL). Generally speaking,
(subactivity (goto-work ?person ?car) OWL-S process is not a program to be executed. It is a
(enter ?person ?car))) specification of the ways a client may interact with a
service. A process can generate and return some new
% driving is a subactivity of going to work information based on information it is given and the world
(forall (?person ?car) state, or it can produce a change in the world. This
(subactivity (goto-work ?person ?car) transition is described by the preconditions and effects of
(drive ?person ?car))) the process. Processes can be atomic or composite. The
composite processes may have control structure such as
% In all occurrences of going to work, a driving sequence, parallel, split, join, if-then-else, etc.
occurrence
% follows a entering occurrence. Clearly, the scope and the applicability of OWL-S is much
(forall (?occ ?person ?car) different from either SPARK-L or PPL. In terms of
(implies (occurrence_of ?occ (goto-work ?person ?car)) expressiveness, OWL-S is comparable to SPARK-L as
(exists (?occ1 ?occ2) both are expressive process description languages. OWL-
(and (occurrence_of ?occ1 (enter ?person ?car)) S, PPL, and SPARK-L all use similar representations for
(occurrence_of ?occ2 (drive ?person ?car)) 1
(subactivity_occurrence_of ?occ1 ?occ) Mike Gruninger reports that a group has done this for a
(subactivity_occurrence_of ?occ2 ?occ) database application, but that this relies on an assumed
(successor ?occ1 ?occ2))))) syntactic regularity in the axioms in order to make parsing
feasible [personal communication].
inputs, outputs, and results. Over and above this shared PPL is used to generate SPARK-L, rather than the reverse.
core, PPL provides a representation for the control Currently PPL is too impoverished to support this, but with
structure in a process by using the followedBy relation. some small extensions this should be possible, so that
The current design of PPL is limited to just that. PPL is a either the PPL contains enough information to
subset of SPARK-L designed to support the requirements generate/modify a SPARK process, or suitable software
of reasoning applications. If one were to perform a similar can be written to "fill in the gaps" appropriately (and
reasoning over OWL-S processes, a PPL-like subset will perhaps interactively) when passing information back to
need to be identified in order to avoid the potential overkill the execution environment.
of using OWL-S in its entirety. In a similar vein, PPL has a
simple KIF-like syntax, intended to be easily generated Although PPL is still preliminary, the general idea of
and processed by sending/receiving applications, both distinguishing representations for execution and
abstracting out some details and making some implicit representations for introspective reasoning has proved
semantics of SPARK-L explicit (e.g., event ordering). In fruitful in our work, and one which we believe will
contrast, OWL-S is specifically designed to support Web- continue to have value as our project progresses further.
based services, and hence uses an RDF-based syntax,
clearly appropriate for Web-based applications but
possibly more cumbersome to deal with in the wider Acknowledgement
context of process communication. Conversely, OWL-S
This material is based upon work supported by the Defense
(and similarly BPEL4WS, the Business Process Execution
Advanced Research Projects Agency (DARPA) under
Language for Web Services) has gone further than PPL in
Contract No. NBCHD030010. Any opinions, findings and
defining different types of process ordering and
conclusions or recommendations expressed in this material
parallelism. Some of these constructs would be useful to
are those of the author(s) and do not necessarily reflect the
incorporate in PPL as it matures.
views of the Defense Advanced Research Projects Agency
(DARPA), or the Department of Interior-National Business
Experience Using PPL Center (DOI-NBC).
PPL directly represents the steps in a procedure, the
parameters of those steps, and their ordering. This References
representation allows a user's ambiguous utterances (e.g.,
Myers, K. L. CPEF: A Continuous Planning and Execution
"find me") to be matched against expected tasks in the
Framework. AI Magazine, vol. 20, no. 4, 1999.
procedure (e.g., ``find_computer") to identify the user's
intent.
Lemai, S., Ingrande, F. Interleaving Temporal Planning
and Execution in Robotics Domains, AAAI 2004, July 25-
We have implemented a translator from the SPARK
29, 2004, San Jose, California, USA.
representation language to PPL. Using this translator, we
exported SPARK process models. Using the exported
Morley, D. and Myers, K. The SPARK Agent Framework,
process model, we ran a suite of tests on a dialog
in Proc. of the Third Int. Joint Conf. on Autonomous
interpretation module, and for answering questions. In both
Agents and Multi Agent Systems (AAMAS-04), New York,
cases, the system was able to resolve the user's utterances
NY, pp. 712-719, July 2004.
correctly in a simple, scripted dialog, illustrating proof of
concept. Obviously, this is only a first step, but the
Yeh, P., Porter, B., and Barker. K. Using Transformations
demonstrated feasibility of the mechanism is encouraging.
to Improve Semantic Matching. Second International
Conference on Knowledge Capture, October 23-25, 2003.
Future Plans
Gruninger, Michael. Ontology of the Process Specification
The work we have reported here is just an initial attempt at Language, in Handbook of Ontologies, pp575-592, Ed: S.
developing a representation that will bridge the Staab, R. Dtuder, Berlin: Springer (2004).
requirements of executing a process, and being able to
answer questions about it. Clearly, more work needs to be Erol, K., Hendler, J., and Nau, D. Semantics for
done. First, the language needs to be extended to capture a Hierarchical Task-Network Planning. Technical Report
larger subset of SPARK-L representation. The current CS-TR-3239, Computer Science Department, University
PPL ignores many of the details of a process model, for of Maryland, 2004.
example, the conditions. Second, we would also like to
use PPL for specifying and/or modifying existing
processes, e.g., through interaction with the user. This
latter goal requires reversing the information flow so that