A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments.

A Proposal for a Process Specification Language

(Working Note 21)

Peter Clark and John ThompsonKnowledge 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 5pm 1/26/01”

– Each event instance happens only once ever!

– KM syntax: (a Move with …)

Three Important Concepts2. 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

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 …)

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:

Knockon door Enter

Test:“Door open?”

no

yes

Plan-Step1

Plan-Step2 Plan-Step3

Knock

Plan-Step4

Enter“Door open?”

next-step next-step-if-yes

next-step-if-no

test

substepsKnock-And-Enter

ProcessSpecification

(“Plan”) do-a do-a

do-a

An event description. The syntax for this will be described later.

A plan-step

– More formally, looks like:

Plan-Step1


Knock

Knock5Knock4 Enter6

Knock-And-Enter7

then then

subevents

Plan-Step4



next-step-if-no

test

substepsKnock-And-Enter


(“Plan”)

An ExecutionTrace

(“Event Sequence”)

do-a do-a

do-a

An event instance

Plan-Step1


Knock

Knock5Knock4 Enter6

Knock-And-Enter7

then then

subevents

Plan-Step4



next-step-if-no

testdo-a do-a

do-asubsteps

Knock-And-Enter


(“Plan”)

An ExecutionTrace


occurrence-of-plan-step

occurrence-of-plan-step

Plan-Step1


Knock

Knock5Knock4 Enter6

Knock-And-Enter7

then then

subevents

Plan-Step4



next-step-if-no

testdo-a do-a

do-asubsteps

Knock-And-Enter


(“Plan”)

An ExecutionTrace


instance-of

instance-of

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.

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.

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

Basic-Plan-Step3

knock(?agent,?patient)

Plan-Step4next-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?

Disjunctive-Plan-Step3

Plan-Step5

Plan-Step4next-step

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:

Conjunctive-Plan-Step3

Plan-Step7

Plan-Step4next-step

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

next-step

next-step

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.

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:

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 <value plan-step> pair. If the

expression evaluates to value, (i.e., the proposition ‘(expression=value) is true), then execute plan-step next.

Sketch:

KM:

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”?

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

“Polymerasecollides

with DNA”

next-step“PolymeraserecognizesPromotor”

next-stepRepeat “Copy a nucleotide” until at terminator.

next-step “RNA is released”

RNA-Transcription-Plan

next-step“Createribonucleotide”

“Attach itto the RNA”

next-step“Move tothe nextnucleotide”

substeps

substeps

RNA Transcription - Informal(Illustrative - this obviously omits some of the important steps)

“Copy anucleotide”

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

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

(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 TranscriptionKM code for

the iterated step

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.

Some Final Comments• Need to hide the complexity of the plan structure

from the SME

Plan-Step2

Knock

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?

?

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?

A Proposal for a Process Specification Language (Working Note 21) Peter Clark and John Thompson Knowledge Systems, Boeing Research inspired by comments.

Documents