1. 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)

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

3. 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 5pm 1/26/01” –Each event instance happens only once ever! –KM syntax: (a Move with …)

4. 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(BlockA, BlockB) –In KM denoted by a class, e.g., Moving PeteTypingOnSomeAirplane Non-reified class descriptions, e.g., –(the-class Typing with (agent (Pete)) (location ((a Airplane))) See KM Release Notes, not User Manual

5. 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 flow- chart for doing the process. –Connections denote the next step in the plan –In KM, denoted by: (a Plan-Step with …)

6. 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

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

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

9. Plan-Step1 Plan-Step2Plan-Step3 Knock Knock5Knock4Enter6 Knock-And-Enter7 then subevents Plan-Step4 Enter “Door open?” next-step -if-yes next-step-if-no test substeps Knock-And-Enter Process Specification (“Plan”) An Execution Trace (“Event Sequence”) do-a An event instance

10. Plan-Step1 Plan-Step2Plan-Step3 Knock Knock5Knock4Enter6 Knock-And-Enter7 then subevents Plan-Step4 Enter “Door open?” next-step -if-yes next-step-if-no testdo-a substeps Knock-And-Enter Process Specification (“Plan”) An Execution Trace (“Event Sequence”) occurrence-of-plan-step

11. Plan-Step1 Plan-Step2Plan-Step3 Knock Knock5Knock4Enter6 Knock-And-Enter7 then subevents Plan-Step4 Enter “Door open?” next-step -if-yes next-step-if-no testdo-a substeps Knock-And-Enter Process Specification (“Plan”) An Execution Trace (“Event Sequence”) instance-of

12. 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!)

13. 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. M1: Repeat-Until-Plan-Step: Macro: Repeat a plan-step until some condition holds. M2: Iterate-For-Plan-Step: Macro: Repeat a plan-step a specified number of times. * actually, five + two macros M1 and M2.

14. 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???).

15. Basic-Plan-Step3 knock(?agent,?patient) Plan-Step4 next-step (Basic-Plan-Step3 has (do-a ((the-class Knock with (agent (path)) (object (path))) (next-step (Plan-Step4))) 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. Sketch: KM: do-a (the-class Knock with (agent (path)) (patient (path))) “knock on the door” 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., In KM, we use class descriptions, e.g., or what should this slot name be?

16. Disjunctive-Plan-Step3 Plan-Step5 Plan-Step4 next-step (Disjunctive-Plan-Step3 has (next-step (Plan-Step4 Plan-Step5))) 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: KM:

17. Conjunctive -Plan-Step3 Plan-Step7 Plan-Step4 next-step (Conjunctive-Plan-Step3 has (next-step (Plan-Step4 Plan-Step5))) 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: KM: Plan-Step5 Plan-Step6 Plan-Step8 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. Concerns: Do we need some sort of a “rejoin” node? This doesn’t allow simulation of “race” conditions.

18. Boolean-Plan-Step3 Plan-Step5 Plan-Step4 Proposition (e.g. “Door is open?”) test next-step-if-true next-step-if-false (Boolean-Plan-Step3 has (destination (…)) (test (‘(the state of (the Door parts of (the destination of Self)))) = *Open) (next-step-if-true (Plan-Step4)) (next-step-if-false (Plan-Step5)) Can add parameters like this to the plan-step A proposition (quoted KM expression, which can be evaluated) 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: KM:

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

20. Repeat-Until-Plan-Step3 Plan-Step4 “The door is open” until next-step (Repeat-Until-Plan-Step3 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)))) M1. 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: KM: Plan- Step5 repeat Knock do-a Do we also need a “Repeat-While”?

21. Iterate-For-Plan-Step3 Plan-Step4 3 number-of-iterations next-step (Iterate-For-Plan-Step3 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))) M2. Iterate-For-Plan-Step: (macro). Parameters: iterate: the plan-step of the thing to do number-of-iterations: Number of iterations (an integer) Sketch: KM: iterate Plan- Step5 Knock do-a

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

23. 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.

24. (RNA-Transcription-Plan has (superclasses (Plan-Step))) (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 Transcription KM code

25. (RNA-Copy-Plan-Step has (superclasses (Plan-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))))))))))) RNA Transcription KM code for the iterated step

26. Events and Plans Events and plans are related by a homomorphism: RNA-Transcription3 RNA-Transcription-Plan3 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.

27. Some Final Comments Need to hide the complexity of the plan structure from the SME Plan-Step2 Knock do-a presented to SME as: 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? ?

28. 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 McDermott’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?