A Proposal for a Process Specification Language (Working Note 21)

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: no yes Knock on door Enter Test: “Door open?”

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

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

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

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

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: * actually, five + two macros M1 and M2. 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.

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. 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: next-step Plan-Step4 Basic-Plan-Step3 do-a An eventdescription. The important thing is that we can generate event instances from this. In most planning systems, they use functions for this, e.g., “knock on the door” KM: knock(?agent,?patient) (Basic-Plan-Step3 has (do-a ((the-class Knock with (agent (path)) (object (path))) (next-step (Plan-Step4))) In KM, we use class descriptions, e.g., (the-class Knock with (agent (path)) (patient (path)))

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

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

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

19. 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: Plan-Step4 conditional-next-step/Open Conditional-Plan-Step3 if-value Plan-Step5 conditional-next-step/Closed “The state of the door” In FOL, this would look like: conditional-next-step(Cond-PS3, Open, PS4). conditional-next-step(Cond-PS3, Closed, PS5). KM: (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) )))

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

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

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

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 TranscriptionKM code (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"))))))))

25. RNA TranscriptionKM code for the iterated step (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)))))))))))

26. Events and Plans • Events and plans are related by a homomorphism: RNA-Transcription-Plan3 RNA-Transcription3 • 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 presented to SME as: ? Plan-Step2 Knock do-a 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?

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?