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-AFAIRS during its performance.
CONSTRAINTS can be stated with respect to none, one or more than one time point. They expressing things we require 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.
More detailed constraints may be introduced within the activity decomposition if there is one (or more).
ACTIVITY NAMEARGUMENTS 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 ( begin time point RESOURCE EFFECTS ( end time point AUTHORITY EFFECTS ( or whole time interval OTHER EFFECTS ( These may in turn be used to satisfy world conditions, resource requirements, authority requiremnts, etc.
ACTIVITY DECOMPOSITION
ISSUES to contain a work list of things still to address.
NODES which may include SUB-ACTIVITITY
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, I assume this is at least 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. I add "Other Constraints" to allow for extendibility.
You could if you prefer put in a single term "VARIOUS CONSTRAINTS" and define this as:
VARIOUS CONSTRAINTS are any of
WORLD CONDITIONS
RESOURCE REQUIREMENTS
AUTHORITY REQUIREMENTS
OTHER CONSTRAINTS
Notes: SIPE maintains a nominated single "purpose" for
an activity. Others (including ourselves), separate the activity
(or plan) description from the way in which the states-of-affairs it
may bring about are used to support purposes, etc. Annotation
of the core definition could be possible for things like
"main purpose" if needed. To be discussed.