krsl-plans Working Group - Plans and Activities

DRAFT 2-Feb-95 (minor lexical edits 16-May-95 and 11-Sep-95)

Level 1: Overall Framework - PLANS

The following preliminary definitions of a plan were adopted as a framework for the work of the working groups at the Plan Ontology kick-off meeting in Washington D.C. on 12th October 1994

Level 2: ACTIVITY

Note: ACTIVITY is an important building block in the Plan Ontology. A Plan is itself a description of activity but with the additional relationship of the activity to purpose (and the agents which have the purpose).

An Activity can relate directly to an action that is performed in a discrete fashion, or may relate to the period of usage of resources. This can allow the ontological entity of activity to merge both action planning and resource scheduling perspectives.

BEHAVIOUR is the performance of one or more ACTIVITIES (a non-empty set of activities).

An ACTIVITY takes place over a TIME INTERVAL.

The TIME INTERVAL for an ACTIVITY is indentified by its two ends, the BEGIN TIME POINT and the END TIME POINT.

An ACTIVITY may optionally have CONSTRAINTS associated with it or with its TIME INTERVAL.

An ACTIVITY may bring about certain STATES OF AFFAIRS.

                        Activity
                           ^
                           |
                           |
                           |
                 begin     |       end
                 +-------------------+
                 |  optional         |
                 |  activity         |
                 |  decomposition(s) |
                 +-------------------+
Optionally, an ACTIVITY may be decomposed into one or more SUB-ACTIVITIES to provide more detail. There can be several alternative such ACTIVITY DECOMPOSITIONS.

SUB-ACTIVITY: Sub-activities are the constituent activities designated in any ACTIVITY DECOMPOSITION.

Notes: Refering to an activity as a sub-activity refers to the role of an ACTIVITY in a relationship with another ACTIVITY such that performance of the SUB-ACTIVITY is considered to be part of the performance of the other ACTIVITY.

ACTIVITY DECOMPOSITION: The specification of how an ACTIVITY is decomposed into one or more SUB-ACTIVITIES; this may include the specification of constraints on and between the SUB-ACTIVITIES.

Notes: The constraints can be sub-activity orderings, world conditions, effects, resource requirements, organisational permissions, etc.

Abstraction Levels in the Domain Model

Activity decomposition does not necessarily imply that a different level of abstraction to that used in the main activity is used in the description of the sub-activities and the constraints on them. For example, it is possible to provide an activity decompositions which uses recursion by including the parent activity type as a sub-activity. Model Abstraction level is orthogonal to structural activity decomposition level.

PRIMITIVE ACTIVITY is an ACTIVITY with no (further) ACTIVITY DECOMPOSITION.

STATES OF AFFAIRS - broadly defined to mean things we can evaluate as holding or not in the (model of the) world. They can refer to an individual world state (such as NOW), or may refer to world histories, changes between world states, etc.

An ACTIVITY may change the STATE-OF-AFFAIRS during its performance.

CONSTRAINTS can be stated with respect to none, one or more than one time point. They express things which are required to hold. They are evaluable with respect to a specific PLAN as holding or not holding.

Such constraints may refer to world statements (conditions and effects), resource requirements and usage, authority requirements or provision, etc.

Level 3: Detailed-Level Proposal

An activity can be described by stating constraints that apply across all posible decompositions (if any) on its defining envelope (bounded by its begin and end time point). There can be constraints specified on either the begin time point, the end time point or stated as applying over the time interval bounded by these two time points.

More detailed constraints may be introduced within the activity decomposition if there is one (or more).

ACTIVITY NAME 
         ARGUMENTS 
         OTHER VARIABLES 
         TIME BEGIN TIME POINT                     ( defines
                    END TIME POINT                 ( time interval
         ACTIVITY DECOMPOSITIONS <0 or more>

         CONSTRAINTS
               TIME                                (
               OBJECTS/VARIABLES                   ( can refer to
               INPUT CONSTRAINTS                   ( begin time point
                    WORLD CONDITIONS               ( end time point
                    RESOURCE REQUIREMENTS          ( or whole time interval
                    AUTHORITY REQUIREMENTS         (
                    OTHER CONSTRAINTS              (

               EFFECTS  States-of-affairs brought about by performing the
                        activity (for any chosen activity decomposition if
                        any is present).
                    WORLD EFFECTS                  ( can refer to
                    RESOURCE EFFECTS               ( begin time point
                    AUTHORITY EFFECTS              ( end time point
                    OTHER EFFECTS                  ( or whole time interval

                    These may in turn be used to satisfy
                    world conditions, resource requirements,
                    authority requirements, etc.
ACTIVITY DECOMPOSITION
         ISSUES  to contain a work list of things still to address.

         NODES which may include SUB-ACTIVITY
                                 AND-SPLIT
                                 AND-JOIN
                                 OR-SPLIT
                                 OR-JOIN
                                 ITERATE
                                 DUMMY NODE

         CONSTRAINTS
             TIME                                  (
             OBJECTS/VARIABLES                     ( can refer to
             INPUT CONSTRAINTS                     ( points or time intervals
                     WORLD CONDITIONS              ( begin or end time
                     RESOURCE REQUIREMENTS         ( of any sub-activity
                     AUTHORITY REQUIREMENTS        ( or parent activity
                     OTHER CONSTRAINTS             (

             EFFECTS     States-of-affairs brought about by performing this
                         activity decomposition.
                     WORLD EFFECTS                 ( can refer to
                     RESOURCE EFFECTS              ( begin time point
                     AUTHORITY EFFECTS             ( end time point
                     OTHER EFFECTS                 ( or whole time interval

                     These may in turn be used to satisfy
                     world conditions, resource requirements,
                     authority requirements, other constraints, etc.
Note: "dummy" nodes allow for the expression of additional types of tempral and other constraint. Are these needed, or should we force a simpler nested view. Maybe this is an issue for ontology USE rather than the ontology itself.

Notes: may need to include a special type of constraint or condition that relates to the triggering preconditions or context filters used to specify the context within which an activity or activity decomposition is applicable. For now, assume this is covered by the constraints and condition hooks already included.

The split into World Conditions, Resource Requirements and Authority Requirements is intended to reflect modelling experience in AI and elsewhere (e.g. IDEF, R-Charts, Enterprise modelling projects, Workflow tools, etc). To an extent this split is a bit arbitrary and we should ensure uniformity of the way in which all these are expressed to allow for unification if desirable. "Other Constraints" is added to allow for extendibility.

An alternative would be to put in a single term "VARIOUS CONSTRAINTS" and define this as:

       VARIOUS CONSTRAINTS are any of
                           WORLD CONDITIONS
                           RESOURCE REQUIREMENTS
                           AUTHORITY REQUIREMENTS
                           OTHER CONSTRAINTS