A Proposal for a Process Specification Language Working

A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments from: Pat Hayes, Jim Blythe, Stuart Aitken, UT Group, and others (http: //www. cs. utexas. edu/users/pclark/working_notes)

Pre-notes • We sometimes use the term “plan” as a shorthand for “process specification”. The two phrases should be considered synonymous here.

Three Important Concepts 1. Event instance (PSL: “Activity Occurrence”, Planet: “Event Occurrence” (? )) – – – The actual occurrence of an event Situated in time (e. g. , Has a time of occurrence) E. g. , “Pete getting onto the airplane at 5 pm 1/26/01” Each event instance happens only once ever! KM syntax: (a Move with …)

Three Important Concepts 2. Event description (PSL: “Activity”, Planet: “Operators” (? )) – A description of a type of event (set of event instances) – E. g. “Moving” (refers to all moving event instances) – E. g. , “Pete typing on an airplane” (refers to all the instances of Pete typing on some airplane) – In PSL and Planet and other planners, denoted by a function, e. g. , the term (NB not predicate!): move-onto(Block. A, Block. B) – In KM denoted by a class, e. g. , • Moving • Pete. Typing. On. Some. Airplane • Non-reified class descriptions, e. g. , – (the-class Typing with (agent (Pete)) (location ((a Airplane))) See KM Release Notes, not User Manual

Three Important Concepts 3. Plan-Step (PSL: not reified, Planet: “Events” (? )) – Are instances of “plans” (process specifications), or steps in plans – They connect together to form a graph, which represents the plan. Graph might include cycles. This graph is equivalent to a flowchart for doing the process. – Connections denote the next step in the plan – In KM, denoted by: (a Plan-Step with …)

Two Graphs • The Process Specification (“Plan”) – A network of plan-steps, connected by next-step links – Flow-chart like, can include cycles, branches • The Execution Trace – A network of event instances, connected by temporal links – Usually a simple sequence (unless parallel execution occurred) – There may be multiple execution traces for one plan

For Example… • The plan for “Knock-and-enter”: – Keep knocking on the door until it opens, then enter. – Informally, can be sketched as: no Knock on door yes Test: “Door open? ” Enter

– More formally, looks like: Plan-Step 1 substeps A plan-step Process Specification (“Plan”) do-a Knock-And-Enter next-step-if-no Plan-Step 2 do-a Knock next-step Plan-Step 3 next-step Plan-Step 4 -if-yes test do-a “Door open? ” Enter An event description. The syntax for this will be described later.

Plan-Step 1 substeps Plan-Step 2 do-a next-step Plan-Step 3 next-step Plan-Step 4 -if-yes test do-a “Door open? ” Knock subevents Knock 5 Enter An event instance Knock-And-Enter 7 then Knock-And-Enter next-step-if-no Process Specification (“Plan”) Knock 4 do-a then Enter 6 An Execution Trace (“Event Sequence”)

Plan-Step 1 substeps do-a Knock-And-Enter next-step-if-no Process Specification (“Plan”) Plan-Step 2 do-a next-step Plan-Step 3 next-step Plan-Step 4 -if-yes test do-a “Door open? ” Knock Enter occurrence-of-plan-step Knock-And-Enter 7 subevents Knock 4 then Knock 5 then Enter 6 An Execution Trace (“Event Sequence”)

Plan-Step 1 substeps do-a Knock-And-Enter next-step-if-no Process Specification (“Plan”) Plan-Step 2 do-a next-step Plan-Step 3 next-step Plan-Step 4 -if-yes test do-a “Door open? ” Knock Enter instance-of Knock-And-Enter 7 subevents Knock 4 then Knock 5 then Enter 6 An Execution Trace (“Event Sequence”)

Comments • What we’ve been encoding in the UT component library so far have been execution traces, not process specifications (plans). • This only runs into trouble when we want to talk about process specifications with loops, etc. , in. (Execution traces can’t have loops!)

Seven* Types of Plan-Steps: 1. Basic-Plan-Step: Do an action. 2. Disjunctive-Plan-Step: Alternative next events (“or” split in the plan) 3. Conjunctive-Plan-Step: Multiple next events (“and” split in the plan) 4. Boolean-Plan-Step: Choice of next step depends on a binary test. 5. Conditional-Plan-Step: Choice of next step depends on a test. M 1: Repeat-Until-Plan-Step: Macro: Repeat a plan-step until some condition holds. M 2: Iterate-For-Plan-Step: Macro: Repeat a plan-step a specified number of times. * actually, five + two macros M 1 and M 2.

Seven Types of Plan-Steps (cont): • Some footnotes: – The seven types are a pragmatic set, not an exhaustive set. They should suffice for our purposes, but there are some processes they are unable to describe, e. g. , • interrupts • we haven’t said how to specify temporal relationships or causal ones either (but could be layered on top) – As a pragmatic decision: • The 4 control steps are control structures, denoting branching and conditionals in the process specification. We haven’t given them an associated event description (Should we have done so? ? ? ).

1. Basic-Plan-Step: parameters: • next-step: The next step in the plan. There can be only one. • do-a: The event description associated with this step. “Doing” this step involves executing an instance of this event class. or what should this slot name be? Sketch: Basic-Plan-Step 3 next-step do-a “knock on the door” KM: (Basic-Plan-Step 3 has (do-a ((the-class Knock with (agent (path)) (object (path))) (next-step (Plan-Step 4))) Plan-Step 4 An event description. The important thing is that we can generate event instances from this. In most planning systems, they use functions for this, e. g. , knock(? agent, ? patient) In KM, we use class descriptions, e. g. , (the-class Knock with (agent (path)) (patient (path)))

2. Disjunctive-Plan-Step: parameters: • next-step: Just one of the next steps will be executed next (e. g. , just one branch will be followed). Unspecified which one it will be. (Can have more than two next steps) • We’d like the simulator to try each path in (different) simulations, and report back what happens. Sketch: next-step Plan-Step 4 Disjunctive-Plan-Step 3 next-step KM: (Disjunctive-Plan-Step 3 has (next-step (Plan-Step 4 Plan-Step 5))) Plan-Step 5

3. Conjunctive-Plan-Step: parameters: • next-step: All of the next steps will be executed next, i. e. , parallel execution of the different branches. • We’d like the simulator to explore different interleavings of events in the different branches, possibly with constraints on the allowable interleavings. Sketch: next-step Plan-Step 4 next-step Plan-Step 6 next-step Plan-Step 8 Conjunctive. Plan-Step 3 next-step Plan-Step 5 next-step Plan-Step 7 next-step In the above example, 6 possible execution sequences are possible: • 3 -4 -6 -5 -7 -8, 3 -4 -5 -6 -7 -8, 3 -4 -5 -7 -6 -8, • 3 -5 -7 -4 -6 -8, 3 -5 -4 -7 -6 -8, 3 -5 -4 -6 -7 -8. KM: (Conjunctive-Plan-Step 3 has (next-step (Plan-Step 4 Plan-Step 5))) Concerns: Do we need some sort of a “rejoin” node? This doesn’t allow simulation of “race” conditions.

4. Boolean-Plan-Step: parameters: • test (a proposition) • next-step-if-true, next-step-if-false: Determines the next step depending on whether the proposition is true (at the time the plan-step is “executed”) Sketch: next-step-if-true Plan-Step 4 next-step-if-false Plan-Step 5 Boolean-Plan-Step 3 test Proposition (e. g. “Door is open? ”) KM: Can add parameters like this to the plan-step (Boolean-Plan-Step 3 has (destination (…)) (test (‘(the state of (the Door parts of (the destination of Self)))) = *Open) (next-step-if-true (Plan-Step 4)) A proposition (quoted (next-step-if-false (Plan-Step 5)) KM expression, which can be evaluated)

5. Conditional-Plan-Step: (generalizes Boolean-Plan-Step). Parameters: • if-value: an expression • conditional-next-step: A <value plan-step> pair. If the expression evaluates to value, (i. e. , the proposition ‘(expression=value) is true), then execute plan-step next. Sketch: conditional-next-step/Open Plan-Step 4 Conditional-Plan-Step 3 if-value “The state of the door” KM: conditional-next-step/Closed Plan-Step 5 In FOL, this would look like: conditional-next-step(Cond-PS 3, Open, PS 4). conditional-next-step(Cond-PS 3, Closed, PS 5). (Conditional-Plan-Step 3 has (destination (…)) (if-value (‘(the state of (the Door parts of (the destination of Self))))) (conditional-next-step ( (: args Open Plan-Step 4) (: args Closed Plan-Step 5) )))

M 1. Repeat-Until-Plan-Step: (macro). Parameters: • repeat: the plan-step to repeat • until: A proposition. (Instances of) the event are done until the proposition evaluates to true. Sketch: Repeat-Until-Plan-Step 3 repeat Plan- Step 5 do-a Knock KM: next-step Plan-Step 4 until “The door is open” Do we also need a “Repeat-While”? (Repeat-Until-Plan-Step 3 has (agent (…)) (destination (…)) (repeat ((a Plan-Step with (do-a ((the-class Knock with (agent ((the agent of Self))) (object ((the Door parts of (the destination of Self)))) (until (‘((the state of (the Door parts of (the destination of Self))) = Open))))

M 2. Iterate-For-Plan-Step: (macro). Parameters: • iterate: the plan-step of the thing to do • number-of-iterations: Number of iterations (an integer) Sketch: Iterate-For-Plan-Step 3 Plan-Step 4 number-of-iterations iterate Plan- Step 5 next-step 3 do-a Knock KM: (Iterate-For-Plan-Step 3 has (agent (…)) (destination (…)) (iterate ((a Plan-Step with (do-a ((the-class Knock with (agent ((the agent of Self))) (object ((the Door parts of (the destination of Self)))) (number-of-iterations (3)))

RNA Transcription - Informal (Illustrative - this obviously omits some of the important steps) RNA-Transcription-Plan substeps “Polymerase Repeat “Copy a next-step collides recognizes nucleotide” until with DNA” Promotor” at terminator. next-step “RNA is released” “Copy a nucleotide” substeps “Move to “Create next-step “Attach it next-step the next ribonucleotide” to the RNA” nucleotide”

KM Code for RNA Transcription • The following code is not properly debugged… • We allow both plans and events to be parameterized by agent, patient etc. In this way, a plan can pass its actors onto its events, and vice versa.

(RNA-Transcription-Plan has (superclasses (Plan-Step))) RNA Transcription KM code (every RNA-Transcription-Plan has (agent ((a Polymerase))) (object ((a DNA with (parts ((a Promotor) (a Gene) (a Terminator)))))) (the-RNA ((a RNA))) (substeps ((a Plan-Step called "collide" with (do-a ((the-class Collide with (agent ((the agent of Self))) (object ((the object of Self)))))) (next-step (((the substeps of Self) called "recognize")))) (a Plan-Step called "recognize" with (do-a ((the-class Recognize with (agent ((the agent of Self))) (object ((the Promotor parts of (the object of Self))))))) (next-step (((the substeps of Self) called "copy")))) (a RNA-Copy-Plan-Step called "transcribe" with ; ; ; A type of Repeat-Until-Plan-Step (PTO) (agent ((the agent of Self))) ; ; ; Pass parameters down (object ((the object of Self))) (the-RNA ((the the-RNA of Self)))))) (until ('((the location of (the agent of Self)) = (the location of (the Terminator parts of (the object of Self)))))) (next-step ((the substeps of Self) called "create"))) (a Plan-Step called "release" with (do-a ((the-class Release with (agent ((the agent of Self))) (object ((the the-RNA of Self)))))) (next-step (((the substeps of Self) called "copy"))))

(RNA-Copy-Plan-Step has (superclasses (Plan-Step))) RNA Transcription KM code for the iterated step (every RNA-Copy-Plan-Step has (agent ((a Polymerase))) (object ((a DNA))) (the-RNA ((a RNA))) (location ((the Nucleotide parts-of of (the location of (the agent of Self))))) (the-ribonucleotide ((a Ribonucleotide with (type ((the complement of (the Nucleotide location of Self))))))) (substeps ((a Plan-Step called "create" with (do-a ((the-class Create with (agent ((the agent of Self))) (object ((the the-ribonucleotide of Self)))))) (next-step ((the substeps of Self) called "attach"))) (a Plan-Step called "attach" with (do-a ((the-class Attach with (agent ((the agent of Self))) (object ((the the-ribonucleotide of Self))) (destination ((the the-RNA of Self)))))) (next-step ((the substeps of Self) called "move"))) (a Plan-Step called "move" with (do-a ((the-class Move with (agent ((the agent of Self))) (source ((the location of Self))) (destination ((the next-nucleotide of (the location of Self))))))

Events and Plans • Events and plans are related by a homomorphism: RNA-Transcription-Plan 3 RNA-Transcription 3 • The event sequence can be either specified directly in the KB (which is what we’ve been doing), and/or derived automatically (by the simulator) from the plan.

Some Final Comments • Need to hide the complexity of the plan structure from the SME Plan-Step 2 do-a presented to SME as: Knock ? Knock • Need to (somehow) hide the event description/event instance distinction from the SME • Outstanding issues: • do we need a “first step” pointer to the first step in a plan? And a “last step(s)” pointer?

Worry, Worry. . . • Does the complexity involved in getting the semantics right (and we’re probably still not quite there) makes the whole scheme unusable? • Perhaps some semantically ugly extension on event sequences would be easier, and we drop the whole notion of process specifications? • Drew Mc. Dermott’s “Fundamental Principle of KR” (presented at KR’ 2000): “If KR is done right, the result is too complex to be used. ” Are we in danger here?