|| ||Planning Initiative
SPAR - Sentences
This is a more detailed discussion of the SPAR issue 32, "Modification to KRSL-Plans 20-Sep-96 Definition
in 15 Sentences".
Current working version
KM stated: Some of these terms should perhaps be
defined more explicitly (OBJECTIVE, WORLD-STATE). Others should
simply be declared as primitive concepts for the sentence framework --
perhaps an explicit listing of those terms could be inserted prior to
the presentation of the sentences.
AT stated: Good idea. As in PIF, NIST PSL, etc., the
primitives are meant to be
C.1. A PLAN relates an ACTIVITY-SPECIFICATION and one or more
AP would prefer: C.1. A PLAN relates ACTIVITY(s) to OBJECTIVE(s)
KM stated: Should this include a reference to a
WORLD-STATE? Something along the lines of: A PLAN relates an
ACTIVITY-SPECIFICATION to one or more
OBJECTIVES for a designated WORLD-STATE.
AT stated: ... objectives may relate to more than
the world state. An objective could be to have completed an activity,
or to have used some resource, or to have respected some (say spatial)
constraint over some time period. WORLD STATE based objectives are
common in our AI world but not so common beyond. In SPAR, world state
descriptions are just one of the many possible ways. I also pointed
out that an objective may define some function over sets of world
states or times that is to be satisfied. e.g. the specification of
completing a time trial course where milestone times are part of the
spec. So we should not refer to any designated world state in the
main definition of plan or objective.
C.2 An ACTIVITY-SPECIFICATION denotes or describes zero or more ACTIVITIES.
AT stated: "I agree with AP that ACTIVITY,
SUB-ACTIVITY, PRIMITIVE ACTIVITY, PROCESS and SUB-PROCESS (and even
EVENT) can all be the same entity. Each of these would be ACTIVITY
in SPAR. ACTIVITY has a specification associated with it which may or
may not include more detailed (sub-activities)."
SP: Should we consider keeping SUB-ACTIVITY as
additional terminology via this sentence, "SUB-ACTIVITIES may be
specified as required or prohibited by a set of ACTIVITY-CONSTRAINTS
in an ACTIVITY-SPECIFICATION.", or is it unnecessary?
KM stated: I'm not convinced
that ACTIVITY-SPECIFICATION is really necessary for the kinds of
abstract characterizations that they are intended to provide.
AT stated: We have ended up using the term
"activity" in 2 senses in SPAR. Some of the earlier KRSL-PLans
sentences I felt were clearer in this respect, but others at that time
wanted to be more concrete rather than referring to the "space of
behaviour". I.e. in SPAR we use activity for both "an activity" and
for the more general notion of "activity". Can we reword to make this
clearer? An activity specification describes some sub-set of the whole
space of legitimate behaviour in the domain.
SP stated: With an Activity-spec. we can represent various activity-constraint configurations
independent of a plan (reason about various configurations)
This also separates constraints related to the activity specification
from constraints for a specific plan.
AP stated: I agree with the need for an
C.3 An ACTIVITY-SPECIFICATION may include relationships between those
ACTIVITIES and ACTIVITY-RELATABLE-OBJECTS (AROs).
AP stated: I would prefer to delete this
AT stated: Just to be fully accurate the "and" in
this sentence should be "and/or", as there can be required
relationships just between activities, or relationships just between
AROs (say equality of some objects referred to by variables), as well
as the more usual relationships that mention both activities and
KM stated: ACTIVITY-RELATABLE-OBJECT is never
defined -- frankly, I don't see the value in introducing it. I would
suggest replacing it with the more general concept ENTITY.
C.4. EXECUTION of an ACTIVITY may change the WORLD-STATE.
KM stated: CHANGE TO: EXECUTION of an ACTIVITY
can change the WORLD.
C.5. An AGENT is an ACTIVITY-RELATABLE-OBJECT which can PERFORM
ACTIVITIES and/or HOLD OBJECTIVES.
AP stated: I would prefer to have everything in
SPAR other than CONSTRAINT and ANNOTATION be an
C.6. An ACTIVITY takes place over a TIME-INTERVAL identified by its
two ends, the BEGIN-TIME-POINT and the END-TIME-POINT.
KM: Suggests the addition of the sentence: "The
TIME-INTERVAL, BEGIN-TIME-POINT and END-TIME-POINT need not be
AT: This clarification is inaccurate as the
relationship of actions to timepoints and their relationship to one
another IS a specification.
AT: Suggests the addition of the sentence: "The
BEGIN-TIME-POINT is temporally before the END-TIME-POINT".
AP stated: KM's comment sounds right to me but maybe is
unnecessary. We might state that none of the information specified in
SPAR is required in an instantiated plan. We could have a plan with
just activites, or just objectives, or none of the activities could
have time points etc.
AT stated: I agree we could have some overall
statement that things may be unspecified. But I disagree with all
three parts which give details [to AP's] statement above.
- An activity does have two time points (conceptually) as its begin and
end and these can always be referred to (as activity.begin-time-point
and activity.end-time-point in an object model). But these need not be
actually allocated as "real objects" in an object model implementation
unless they need to be for some other reason.
- A plan may have a specification of activity that does not include any
specific activity at all (zero sub-activities). One legitimate instance
of a plan is literally to do no activity. Constraint may be stated to
avoid some things, etc but that is an orthogonal issue.
- A plan will always contain at least one objective. This is a
defining characteristic of a plan. A specification of activity without
an associated objective is not a plan. Its just a specification of
The following sentences extend the core sentences above to provide
E1.1. An ACTION is an ACTIVITY which has or could have (in the
domain model) an ACTOR.
AT: Alter E1.1 to be ACTION is a SYNONYM for
ACTIVITY, as there is no dispute over that term.
E1.2. An EVENT is an ACTIVITY which does not have and could not have
(in the domain model) an ACTOR.
E1.3. An ACTOR is an AGENT which is the motive force behind an ACTIVITY.
AT: Could add that we call such an ACTOR a PERFORMER.
AP stated: I don't think we need both.
KM stated: What does `motive force' in E1.3
mean? Is the intent here to express a concept that is more general
than `performance' of the activity?
AT stated: No, as you thought, its meant to just
meant to refer to an actor that is in the "perform" relationship to an
activity. This relationship may or may not be specified in the model,
and the performers of some activities may not be expressed in the
model at all - e.g. in the case of some "natural" activities.
SP: It sounds like it would be simplest to to replace motive force with the notion of performer.
E1.4. A RESOURCE is an ACTIVITY-RELATABLE-OBJECT which is USED,
MODIFIED, CONSUMED or DESTROYED during the EXECUTION of an ACTIVITY.
AP stated: I'd like to distinguish between concepts which cover "all
information in the plan" and "physical things". I'd like RESOURCE and
ACTOR to be roles which physical things play. If we stick with the
sentences as given, then we're allowing an ACTIVITY (which is an
ACTIVITY-RELATABLE-OBJECT) to play the role of RESOURCE and that
doesn't make sense to me.
AT stated: Can I suggest the addition of a sentence after E1.4,
meaning that the ones that follow need to be renumbered.
E1.5 A PRODUCT is an ACTIVITY-RELATABLE-OBJECT which is CREATED during
the EXECUTION of an ACTIVITY.
E1.5 A SUB-ACTIVITY of an ACTIVITY is an ACTIVITY included in an
ACTIVITY-SPECIFICATION of the parent ACTIVITY.
E1.6 A PROCESS is an ACTIVITY whose ACTIVITY-SPECIFICATION includes more than
E1.7 A PRIMITIVE-ACTIVITY is an ACTIVITY whose ACTIVITY-SPECIFICATION
includes no SUB-ACTIVITY to the level detailed in the model.
KM stated: I don't see how an
ACTIVITY-SPECIFICATION can possibly determine whether an ACTIVITY is
primitive or not. The notion of `primitivity' seems like it's in
inherent property of a given ACTIVITY type/instance, which will of
course vary with different domain models.
AT stated: Thats why we relate "primitivity" to
whether the model includes a specification of activity that further
decomposes the activity. It it has sub-activities, then it is not
primitive (wrt the given model).
SP stated: Note that if primitivity is simply determined by the number of sub-activities, then all unexpanded activities in a plan would be considered primitive by definition. Intuitively, we should be able to have abstract activities (make-part, fly-to-paris) that are non-primitive irrespective of their expansion state.
KM stated: There is a World in which planning
and plan execution takes place (I actually think that Environment is a
better term, since it doesn't imply a 'global' scope). A particular
snaphsot of the world at a given point in time is called a
World-State. A WORLD-MODEL constitutes a description of the World
(note though, that this description need not be complete or accurate
wrt the actual World). A WORLD-STATE-DESCRIPTION describes an
AT stated: I like this description. It fits with my
own intuition on what we are trying to capture. Do others agree? I
also prefer the term environment and its the term we have used in our
own contributions to plan ontology work.
KM Stated: Here is an attempt to compile a set
of sentences that capture the relevant details (perhaps (1) and (2)
should simply be `background material' rather than sentences, since
they really contribute to defining the background framework for SPAR).
- A PLAN is designed for and (possibly) executed within a specified World (Environment).
- A particular snaphsot of the world at a given point in time is
called a World-State.
- A WORLD-MODEL provides a description of the World
(possibly incomplete and/or inaccurate).
- A WORLD-STATE-DECRIPTION describes one or more World-States
(actual, expected, or hypothetical).
E2.1. A WORLD-STATE-DESCRIPTION partially denotes or describes the
KM: Suggests adding "at some actual or
hypothetical point in time".
AT: Too limiting. May describe a difference
SP: What is the difference between a specification
and a description? Are they roughly the same thing just used for
different purposes? Perhaps, to be uniform, we could call this a
AT: Whole sets of world states could be described by some constructs,
and globally (always) true statements could be made.
AT: I suggest that HOLDS [from E4.3] be added as the
second sentence in the world state extension (E2) so that we have a
"hook" there on which to hang the uncertain values.
E3.1. Any TIMEPOINT may be associated with one or more TIMELINES [or
E3.2. A TIMELINE [or CALENDAR?] has a nominated begin point and a
time unit and may have a nominated end point.
AT stated: I recommend that we adopt the more
generic term "timeline" for this extsnsion. A calendar has a narrower
scope with some idea of DATES on it. We have used it in a broader way
where we just meant any time line with associated "tokens" such as
"Day 32 of the project", but that's not very natural in English.
E4.1. A VALUE is associated with each property of each ENTITY.
AT: Alternatively we could say: Each property of each entity has a VALUE, i.e. PROPERTY(ENTITY)=VALUE
AP stated: I like AT's rewording.
DLD: In order to set up uncertainties (or
imprecision, for that matter), what we really want to express here is
that a property has a "domain", or set of possible values. The
domain might not be (completely) known or specified, it might change
over time, etc., but at some conceptual level at least, there is a
range of possible values that each property could take on.
E4.2. VALUEs may be imprecise.
AP: Suggests that: "An imprecise VALUE may have an
AT: This is an overcommitment for SPAR.
This should be left to specific plug-ins that can coexist with other
approaches. I am pretty sure that there will be no agreement to
this level - and it could be undesirable to try to standardise things
that may be better left to alternatives that can interwork.
DLD: I agree that it would be helpful to distinguish
imprecision from uncertainty (and I think that most researchers in either
area would agree). Treatments of this are, of course, a religious
issue, which raises certain difficulties. It is my belief that one
can completely and soundly represent imprecision by changing the domain
of the attribute to be either a set of values, or more generally, a mapping
from values to fuzzy degrees.
AP: I guess the question is how to specify
imprecision. I still run into occasional confusion about the
difference between imprecision (fuzziness) and uncertainty so I'd like
to make it clear that this sentence is addressing the former. Are
there other ways to relate values to imprecise labels other than fuzzy
So: one way to approach the issue would be minimalist:
an attribute can take a value from a domain, and it is up to the user to
specify if that domain consists of "fuzzy values" (subsets or fuzzy measures)
or not. The advantage of this approach is that it does not require
you to add anything to your specification (not even statement E4.2).
The disadvantage is that it does not provide any support to those who would
wish to make use of fuzziness. The other approach, of course,
is to attempt to explicitly support fuzziness, in which case I like AP's
suggested statement better (though to be general, it should specify it
in terms of the mapping to fuzzy degrees).
E4.3. VALUEs may have a PROBABILITY.
E4.4. PROBABILITYs may be subclassed into PROBABILITY-PREDICTION and
AP: I think this distinction is pretty fundamental
if we're to address both planning and execution monitoring. If we
lump them together we'll be missing an important bit of information
for decision support. Uncertainty due to sensing is very different I
think than uncertainty due to prediction. It's not that the measures
of uncertainty themselves would have a different form, just that they
would be labelled differently as to their source.
DLD: I don't really agree --- see E4.6.
E4.5. A PROBABILITY-PREDICTION is the likelihood of a
WORLD-STATE-DESCRIPTION being valid in the future.
E4.6. A PROBABILITY-SENSED is a likelihood that a WORLD-STATE-DESCRIPTION did
in fact have the specified value in the past or at the current time.
DLD: I'm not sure exactly what the right
distinction to make is here. Note that you can still do
"predictive modeling" about past events---you can predict how a game,
recorded on television, will come out (and in some places, you can
appearantly even bet on it). Also, if you are doing Bayesian
reasoning, you combine both predictive and sensory models to come to a
common probability assessment.
It certainly is important to make clear if an attribute is
(possibly implicitly) time-varying, and it is also important to make
clear if a time-varying attribute's value (or probability
distribution) is changed, does that change reflect a change to the
attribute value, or a change to our knowledge about the attribute
It is will also generally be important to understand where
probabilities come from (i.e. from what models, what inference), and I
think that this need subsumes the predicted/sensed distinction.
E4.7. An INFLUENCE-NETWORK is a structure which relates PROBABILITYs and
specifies their dependency structure.
AP stated: I thought this would actually be one
level up from making the sentence too specific like requiring Bayes
nets. I guess any determination of what is too specific for our model
is a judgement call.
AT stated : I am not happy about including this one.
I feel it is an over commitment for SPAR and thus should not be left
in. This should be left to be something that is a plug-in to the more
generic 6 sentences that come before it. If we can get agreement on
the 6 sentences we will have a suitabvle framework I trust.
AP stated: I'd be happy if we then put this under [another] extension.
DLD: I do not like this statement either. It
is either too specific, or too general.
AT: We [can] create an "E4a: Values, Uncertainty and
Imprecision - Details" extension and move E4.7 across into that as
E4a.1 - as it does not directly refine any others sentence in E4.
E5.1. The CONDITIONS of an ACTIVITY are the ACTIVITY-CONSTRAINTs in
AP: I think all constraints on actions are
E5.1.a The CONDITIONS of an ACTIVITY are called ACTIVITY-CONSTRAINTs.
E5.1.b ACTIVITY-CONSTRAINTs are CONSTRAINTs on ACTIVITES.
E5.1.c CONSTRAINTs restrict the VALUEs of PROPERTIES (unary constraints).
CONSTRAINTS may also restrict the VALUEs of several PROPERTIES relative to
one another (binary or higher arity constraints).
KM stated: I'm not sure why CONDITIONS need to
be introduced (they are never defined anywhere). How about rewording
as follows: ACTIVITY-SPECIFICATIONS include ACTIVITY-CONSTRAINTS that
restrictions on its constituent ACTIVITIES and ENTITIES.
E5.2. The EFFECTS of an ACTIVITY are the changes made to the
WORLD-STATE by EXECUTION of the ACTIVITY.
KM stated: CHANGE TO: The EFFECTS of an ACTIVITY
describe expected changes to the WORLD that would be occasioned by
EXECUTION of the ACTIVITY.
AT stated: I guess we have to be clear if effects
mean "effects in the real world" or a "specification of modelled
effects". KM is using effects to mean the latter.
AP suggests: E5.5 The EFFECTS-RECORD of an ACTIVITY is the record of changes made to the WORLD-STATE by EXECUTION of the ACTIVITY as sensed by some ARO.
KM stated: Actually, my intent was to cover both
-- this comes for free if one adopts the model of WORLD including the
AT stated: So maybe we have to talk about EFFECTS (in the real world) and
EFFECTS-MODEL (in the world model)?
E5.3 CONDITIONS which are mutually exclusive may be associated with a
AT: Believes this may redundant as all VALUES have
already been defined as having a PROBABILITY.
AP: I agree with AT. Should be deleted.
KM stated: I don't understand the need for E5.3
or E5.4 --- it should be possible to associate probabilities (more
generaly, uncertainty information) with all constraints/sentences
E5.4. WORLD-STATE-DESCRIPTIONS which describe changes to the
WORLD-STATE may have a PROBABILITY.
AT: Believes this may redundant as all VALUES have
already been defined as having a PROBABILITY.
AP: Maybe should be deleted.
SP: This has been changed from "EFFECTS may have a
PROBABILITY." because it didn't seem ontologically consistent with the
notion of EFFECTS described above.
E6.1. An OBJECTIVE may have one or more EVALUATION-CRITERIA.
E6.2. An EVALUATION-CRITERION may be applied to WORLD-STATE to create
E6.3. An EVALUATION may be a predicate (holds/does not hold) or a
partial order on the results of [one or more] EVALUATION-CRITERIA.
AT stated: "The 'or' in this needs to be related
correctly. We mean that you can say this criteria holds or does not
(yes/no) or that there is a preference ranking (better or worse) on
the results of applying the criteria to a range of alternatives or
outcomes. We dropped the phrase including the word "ranking" in
favour of partial order, but I thinkwe may have moved away from what
we are trying to communicate. We need BS to adjudicate on this. It
was AP and SP who felt that partial order was a better
description of what was neing defined I think."
AP: I think just having a partial order would be
find. A degenerate case of a partial order would be 1 and 0 or
holds/does not hold.
AT: Lets add an "6a: Evaluation - Details" extension
and put in two sentences compatible with the current E6.3. These
would be say E6.3.1 and E6.3.2. This would address BS's
BS stated: With the "or" there are really two types
of evaluations: those that are categorical---go/no-go and those that
are satisfied to some degree. Perhaps we should distinguish these as
fundamentally different things. In that case, an evaluation criterion
would consist of two parts: categorical criteria and preference(?)
criteria. It might make sense to make this split even at this high
level in the spec, since I think the processing of the two types of
criteria will be quite different.
E7.1. A PLAN-LIBRARY contains PLANs or portions of PLANs which may be
reused in creating new PLANs. A PLAN-LIBRARY has one or more INDEXes
which can be used to catalog PLANs and aid in searching for them.
Page maintained by Steve Polyak
Last updated: Fri Apr 28 13:29:23 2000