Ontology
version info: 397
comment: Imports: FunctionalParticipation
imports: FunctionalParticipation.owl
comment: The Plan Ontology. OWL engineering by Aldo Gangemi.

schedule
type: Class
comment: A scheduling is a task that cannot be executed twice, since it has a temporal parameter restricted to one value, e.g. it classifies an event that is valued by a definite temporal value.
equivalent class: Class
  intersection of: task
  intersection of: Restriction
    some values from: Class
      intersection of: Restriction
        on property: valued-by
        some values from: time-interval
      intersection of: parameter
    on property: requisite

decision-activity
type: Class
comment: An activity related to planning. It is sequenced by 'case task', and can contain an information gathering activity.
subclass of: Restriction
  some values from: Class
    one of: case-task
  on property: sequenced-by
subclass of: activity

case-task
type: Restriction
  all values from: decision-activity
  on property: sequences
specialized-by: alternate-task
type: control-task
comment: A case task is a task branched to a set of tasks that are not executable concurrently. In order to choose the task to be executed, preliminary deliberation tasks should be executed. A case task sequences a decision activity (a kind of mental event involving rationality) that has a deliberation state as outcome (sequenced by a deliberation task).
type: Restriction
  on property: direct-successor
  some values from: Class
    one of: deliberation-task
specializes: branching-task

alternate-task
type: Restriction
  on property: direct-successor
  cardinality: 3
specializes: case-task
type: Restriction
  on property: direct-successor
  some values from: Class
    one of: deliberation-task
type: control-task
type: Restriction
  all values from: decision-activity
  on property: sequences
comment: A case task branched to exactly 2 tasks, not executable in parallel.

deliberation-task
type: control-task
comment: A deliberation task is a control task that sequences deliberation states (decisions taken after a case task execution).
type: Restriction
  on property: sequences
  all values from: decision-state

decision-state
type: Class
equivalent class: Class
  intersection of: state
  intersection of: Restriction
    some values from: Class
      one of: deliberation-task
    on property: sequenced-by
  intersection of: Restriction
    on property: follows
    some values from: decision-activity
comment: A state related to planning. It is sequenced by 'deliberation task', and is preceded by a decision activity.

control-task
type: Class
disjoint with: action-task
equivalent class: Class
  intersection of: elementary-task
  intersection of: Restriction
    all values from: Class
      union of: planning-activity
      union of: decision-state
    on property: sequences
comment: A control task is an elementary task that sequences a planning activity, e.g. an activity aimed at (cognitively or via simulation) anticipating other activities. Therefore, control tasks have usually at least one direct successor task (the controlled one), with the exception of ending tasks.The reification of control constructs allows to represent procedural knowledge into the same ontology including controlled action. Besides conceptual transparency and independency from a particular grounding system, a further advantage is enabling the representation of coordination tasks. For example, a manager that coordinates the execution of several related activities can be represented as a role with a responsibility (duty+right) towards some complex task.

branching-task
type: Restriction
  min cardinality: 2
  on property: direct-successor
comment: A task that articulates the plan into an ordered set of tasks.
type: Restriction
  all values from: planning-activity
  on property: sequences
specialized-by: case-task
type: control-task
type: Restriction
  some values from: task
  on property: direct-successor
specialized-by: concurrency-task
specialized-by: partly-case-task

planning-activity
type: Class
subclass of: activity
subclass of: Restriction
  on property: expected-by
  some values from: planning-as-technique
comment: The activity to generate a plan.
subclass of: Restriction
  on property: product
  all values from: plan

synchro-task
type: control-task
comment: A task that joins a set a tasks after a branching.In particular, a synchronization task is aimed at waiting for the execution of all (except the optional ones) tasks that are direct successor to a concurrent or any order task.
type: Restriction
  some values from: Class
    intersection of: Class
      union of: action-task
      union of: complex-task
    intersection of: Restriction
      on property: direct-predecessor
      some values from: Class
        one of: any-order-task
        one of: concurrency-task
  on property: direct-predecessor

action-task
type: Class
subclass of: elementary-task
disjoint with: control-task
comment: An action task is an elementary task that sequences non-planning activities, like: moving, exercising forces, gathering information, etc. Planning activites are mental events involving some rational event.

complex-task
type: Class
equivalent class: Class
  intersection of: task
  intersection of: Restriction
    on property: component
    some values from: task
  intersection of: Restriction
    on property: component
    min cardinality: 2
comment: A task that has at least two other tasks as components.

any-order-task
type: Restriction
  on property: successor
  some values from: Class
    one of: synchro-task
type: control-task
comment: An any order task is a branching task that defines no order in the successor tasks. Itís another way of defining a bag task, because any temporal relation can be expected between any two perdurants sequenced by the tasks that are direct successor to the any order task.

concurrency-task
type: Restriction
  min cardinality: 2
  on property: direct-successor
type: control-task
type: Restriction
  some values from: Class
    intersection of: task
    intersection of: Restriction
      on property: sequences
      all values from: Class
        intersection of: activity
        intersection of: Restriction
  on property: direct-successor
specializes: branching-task
specialized-by: parallel-task
comment: A concurrent task is a task branched to a set of tasks executable concurrently -the sequenced perdurants can overlap-, which means that no deliberation task is performed in order to choose among them. A concurrent task has at least one successor synchronization task, which is aimed at waiting for the execution of all -except the optional ones- tasks direct successor to the concurrent -or any order, see below- one.The axioms cannot be expressed fully in OWL-DL (no value mapping available).
type: Restriction
  some values from: Class
    one of: synchro-task
  on property: successor

parallel-task
specializes: concurrency-task
comment: A task for parallel concurrent activities.
type: Restriction
  min cardinality: 2
  on property: direct-successor
type: control-task
type: Restriction
  on property: successor
  some values from: Class
    one of: synchro-task

partly-case-task
specializes: branching-task
type: Restriction
  some values from: Class
    one of: case-task
  on property: direct-successor
type: Restriction
  some values from: Class
    intersection of: task
    intersection of: Class
      complement of: Class
        one of: case-task
  on property: direct-successor
comment: A control task that directly precedes both a case task and some other task.It specializes the branching task.
type: control-task

bag-task
type: Class
subclass of: Restriction
  on property: component
  all values from: Class
    complement of: control-task
comment: A bag task is a complex task that does not include either a control task, or a successor relation among any two component tasks.The last condition cannot be stated in OWL-DL, because it needs a coreference.
subclass of: complex-task

saturated-plan
type: Class
equivalent class: Class
  intersection of: plan
  intersection of: Restriction
    on property: d-uses
    some values from: Class
      intersection of: Restriction
        on property: valued-by
        some values from: space-region
      intersection of: parameter
  intersection of: Restriction
    some values from: Class
      intersection of: Restriction
        on property: valued-by
        some values from: time-interval
      intersection of: parameter
    on property: d-uses
comment: A saturated plan is a plan that cannot be executed twice, since it defines spatio-temporal parameters restricted to one value, e.g. one of its tasks classifies an event that is valued by a definite temporal value in a definite space region.Of course, in the case of maximal spatio-temporal regions, a saturated plan tends to approximate an abstract plan from the execution viewpoint, but these worst cases are unavoidable when dealing with maximality.

planning-as-technique
type: Class
subclass of: technique
comment: The technique by which a planning process can be carried out.

circumstantial-plan
type: Class
comment: A circumstantial plan has all components classifying named individuals from the ground ontology (e.g. only specific persons, specified resources, a finite number of time intervals and space regions, etc.).This condition cannot be formalized in FOL, since we would like to express a condition by which an instance of an circumstantial plan specifies both instances of plan components, and instances of situation elements, e.g. that 'manager' classifies a specified (named) person.
equivalent class: Class
  intersection of: plan
  intersection of: Restriction
    on property: d-uses
    all values from: Class
      intersection of: Restriction
        some values from: particular
        on property: classifies
      intersection of: concept

plan-assessment-task
type: Class
equivalent class: Class
  intersection of: control-task
  intersection of: Restriction
    on property: defined-by
    some values from: plan-assessment
comment: A task defined in a plan assessment.

plan-assessment
type: Class
subclass of: Restriction
  on property: has-in-scope
  some values from: plan-execution
subclass of: technique
comment: A technique to evaluate a plan execution.

subplan
type: Class
comment: A proper part of a plan.
equivalent class: Class
  intersection of: plan
  intersection of: Restriction
    some values from: plan
    on property: proper-part-of

plan-execution
type: Class
equivalent class: Class
  intersection of: situation
  intersection of: Restriction
    some values from: plan
    on property: p-sat
comment: Plan executions are situations that proactively satisfy a plan (cf. definition of P-SAT above). Subplan executions are proper parts of the whole plan execution.

goal-qua-main
type: Class
comment: A main goal can be defined as a goal that is part of a plan but not of one of its subplans. The characteristic axiom cannot be formalized in OWL-DL (it requires coreference).
equivalent class: Class
  intersection of: goal
  intersection of: Restriction
    some values from: plan
    on property: main-goal-of

abstract-plan
type: Class
subclass of: plan
comment: An abstract plan is a plan whose roles and tasks only specify classes of entities that can be included in a plan execution. In other words, a component from an abstract plan does not classify any named entity. This condition cannot be formalized in FOL, since we would like to express a condition by which an instance of an abstract plan specifies instances of plan components, but no instances of situation elements, e.g. that 'manager' classifies some (if any) instance of person, but not a specified (named) person.

maximal-task
type: Class
subclass of: complex-task
comment: A maximal task is a complex task that has all the tasks defined in a plan as components.In OWL-DL the axiom is defined as a concept axiom over plan component task.

information-gathering
type: Class
comment: An activity aimed at gathering information for some purpose. It is typically sequenced by case tasks for taking decisions (can be part of decision activities).
subclass of: activity

elementary-task
type: Class
equivalent class: Class
  intersection of: task
  intersection of: Restriction
    cardinality: 0
    on property: component
comment: An atomic task.

goal-situation
type: Class
comment: A goal situation is a situation that satisfies a goal.Opposite to the case of subplan executions, a goal situation is not part of a plan execution.In other words, it is not true in general that any situation satisfying a part of a description, is also part of the situation that satisfies the whole description. This helps to account for the following cases: a) Execution of plans containing abort or suspension conditions (the plan would be satisfied even if the goal has not been reached, see below), b) Incidental satisfaction, like when a situation satisfies a goal without being intentionally planned (but anyway desired).
equivalent class: Class
  intersection of: situation
  intersection of: Restriction
    some values from: goal
    on property: satisfies

sequential-task
type: Class
subclass of: complex-task
subclass of: Restriction
  some values from: action-task
  on property: component
subclass of: Restriction
  on property: component
  min cardinality: 2
comment: A sequential task is a complex task that includes a successor relation among any two component tasks, and does not contain any control task.The first condition cannot be stated in OWL-DL, because it needs coreference.
subclass of: Restriction
  on property: component
  all values from: Class
    complement of: control-task

adopts-plan
type: ObjectProperty
sub property of: adopts
comment: Adoption holding for plans.
range: plan
domain: rational-agent

task-postcondition
type: ObjectProperty
range: situation
comment: The execution of a task (an action classified by it) can make a new situation emerge: in this case the task has a task-postcondition.
domain: task
inverse of: task-postcondition-of
sub property of: mediated-relation

iteration-interval
type: ObjectProperty
inverse of: iteration-interval-of
sub property of: mediated-relation
range: time-interval
comment: iteration interval can be used to state how much time should be taken by each iteration of the looped activity
domain: task

task-precondition
type: ObjectProperty
comment: The execution of a task (an action classified by it) can require that a situation holds: in this case the task has a task-precondition.
sub property of: mediated-relation
range: situation
domain: task
inverse of: task-precondition-of

precondition
type: ObjectProperty
inverse of: precondition-of
domain: description
range: situation
comment: A situation is a pre-condition of the execution of a method (and of its tasks) when it is a predecessor (however succession is interpreted, although temporal interpretation is the usual one) of that execution, and is constituted by a subset of the individuals that constitute the execution situation. For example, a surgical guideline describes how to carry out a heart transplant: its (expected) execution situation is constituted by the perdurants, endurants, and regions described by the guideline, while its pre-condition situation might be only constituted by the heart to be removed, the one to be transplanted, their anatomical and morphological environment, the physiological functions in which they participates, and some physiological values. But the devices used during the transplantation and the surgeon might (or might not) be external to the pre-condition situation. This definition does not cover the possibility of a pre-condition having constituents that are not involved in the description. This is a difficult issue. A possible solution is that such pre-conditions are actually referenced by other descriptions that -for instance- 'control' the feasibility of a procedure, or 'analyze' a set of events under an independent unity criterion. If this solution is applicable, such pre-conditions would be 'maximal' situations requiring the 'composition' of two or more related descriptions.
sub property of: mediated-relation

adopts-goal
type: ObjectProperty
range: goal
comment: Adoption holding for goals.
domain: rational-agent
sub property of: adopts

influences
type: ObjectProperty
range: goal
inverse of: influenced-by
sub property of: specific-constant-dependent
comment: A relation between a goal and the main goal of the plan it is a subgoal of. Usable for talking of dependencies between goals.
domain: goal

main-goal
type: ObjectProperty
range: goal
inverse of: main-goal-of
comment: The relation between a plan and its main goal.
sub property of: proper-part
domain: plan

achievable-through
type: ObjectProperty
range: task
domain: goal
comment: The goal state described by the goal of a plan can be achieved by executing activities that are sequenced by some task (either elementary or complex). The relation between the goal and the task is called here 'achievable-through'.
inverse of: contributes-to-achieving-of
sub property of: references

sibling-task
type: ObjectProperty
range: task
comment: Two tasks contained in the same plan.
sub property of: mediated-relation
domain: task

subgoal
type: ObjectProperty
domain: plan
range: goal
comment: A subgoal (relative to a plan) is a goal that is a part of a subplan.A goal is not necessarily a part of the main goal of the plan it is a subgoal of. E.g. consider the goal: being satiated; eating food can be a subgoal of the plan that has being satiated as its main goal, but it is not a part of being satiated.See also relations: influence, disposition to.
inverse of: subgoal-of
sub property of: proper-part

postcondition
type: ObjectProperty
inverse of: postcondition-of
domain: description
comment: A situation is a post-condition of the execution of a method (and of its tasks) when it is a successor (however succession is interpreted, although temporal interpretation is the usual one) of that execution, and is constituted by a subset of the individuals that constitute the execution situation. For example, a surgical guideline describes how to carry out a heart transplant: its (expected) execution situation is constituted by the perdurants, endurants, and regions described by the guideline, while its post-condition situation might be only constituted by the transplanted heart, its anatomical and morphological environment, the physiological functions in which it participates, and some physiological values. But the devices used during the transplantation and the surgeon can be external to the post-condition situation. This definition does not cover the possibility of a post-condition having constituents that are not involved in the description. This is a difficult issue. A possible solution is that such post-conditions are actually referenced by other descriptions that -for instance- 'control' the outcome of a procedure, or 'reconstruct' a set of events under an independent unity criterion. If this solution is applicable, such post-conditions would be maximal situations requiring the composition (bundle) of two or more related descriptions.
range: situation
sub property of: mediated-relation

exit-condition
type: ObjectProperty
domain: control-task
range: control-task
inverse of: exit-condition-of
sub property of: successor
comment: Exit condition can be used to state what deliberation task causes to exit a cycle.

disposition-to
type: ObjectProperty
sub property of: mediated-relation
comment: We define a disposition relation between the roles used in a plan having a main goal, and the influenced goal.For example, the role 'eater' can have a disposition to being satiated, meaning that a person playing the role of eater that adopts that plan can act in order to be satiated.Disposition relation is useful to account for those cases in which a task addressed by a role is not internal to the plan, but the plan is a subplan of another one in which that task is represented as a full-fledged goal.
range: goal
domain: role

discarded-within
type: ObjectProperty
range: plan
sub property of: d-used-by
comment: A task can be discarded within some plan. In this case, it is ignored in plan execution without affecting the satisfaction of the plan. A discarded task can appear only as a direct successor to a deliberation task.
inverse of: discards
domain: task

iteration-cardinality
type: DatatypeProperty
range: integer
comment: iteration cardinality can be used to state in a task how many times an action should be repeated
domain: task

loop-for
type: control-task
comment: A loop task with a defined number -and possibly frequency- of iterations.

suspension-task
type: control-task
comment: A specialization of ending-task, aimed at sequencing events that end a plan execution without having reached its main-goal for a certain time

reactivation-task
type: Restriction
  some values from: Class
    one of: suspension-task
  on property: direct-predecessor
comment: An activation task to start a plan execution after it has been suspended.
type: control-task

acceptation-task
type: plan-assessment-task
type: Restriction
  on property: predecessor
  some values from: Class
    one of: consideredness-task
comment: The task sequencing a positive decision to adopt a plan for execution.

consideredness-task
type: plan-assessment-task
comment: The task sequencing a decision activity, aiming at if action has to be taken in order to start a plan execution.
type: Restriction
  on property: direct-predecessor
  some values from: Class
    one of: possibility-task

possibility-task
type: plan-assessment-task
comment: The task sequencing an activity from which the possibility is raised to execute a plan.

readiness-task
comment: The task joining the decision and preparation phases of the plan assessment, with the activation phases of the plan.
specific-constant-dependent: beginning-task
type: Restriction
  on property: direct-predecessor
  some values from: Class
    one of: preparedness-task
type: plan-assessment-task

beginning-task
specifically-constantly-dependent-on: readiness-task
type: Restriction
  some values from: task
  on property: successor
type: control-task
comment: A beginning task is a control task that is the predecessor of all tasks defined in the plan.

decidedness-task
type: Restriction
  on property: direct-predecessor
  some values from: Class
    one of: acceptation-task
comment: The task sequencing a decision to take action in order to start a plan execution.
type: plan-assessment-task

preparedness-task
type: Restriction
  on property: direct-predecessor
  some values from: Class
    one of: decidedness-task
type: plan-assessment-task
comment: The task sequencing an assessment that the activities aiming at creating the prerequisites to start a plan execution are completed.

ending-task
type: Restriction
  some values from: task
  on property: predecessor
comment: An ending task is a control task that has no successor tasks defined in the plan.
type: control-task

rejectedness-task
type: plan-assessment-task
type: Restriction
  on property: predecessor
  some values from: Class
    one of: consideredness-task
comment: The task sequencing a negative decision to adopt a plan execution.

completion-task
type: control-task
comment: A specialization of ending-task, aimed at sequencing events that end a plan execution having reached its main-goal.

loop-until
type: Restriction
  some values from: Class
    one of: deliberation-task
  on property: exit-condition
type: control-task
comment: A loop task, which specifies when a certain condition becomes true for a cyclical task to exit.

activation-task
comment: A control task aimed at starting an activity. It is specialized either by a beginning task or a reactivation task.
type: Restriction
  on property: direct-predecessor
  some values from: Class
    one of: readiness-task
type: control-task

abandonment-task
type: control-task
comment: A specialization of ending-task, aimed at sequencing events that end a plan execution without having reached its main-goal, and with no intention to resurrect the plan.

loop-task
type: control-task
comment: A loop task is a control task that has as successor an action -or complex- task that sequences at least two distinct activities sharing a minimal common set of properties -they have a MinimalCommonType. Notice that MinimalCommonType cannot be formalised as a first-order predicate, and then neither in OWL-DL. It can be considered a trivial guideline: when sequencing looped actions, choose a definite action class from the ground ontology. Some relations typically hold for loop tasks. Exit condition can be used to state what deliberation task causes to exit the cycle; iteration interval can be used to state how much time should be taken by each iteration of the looped activity; iteration cardinality can be used to state how many times the action should be repeated.

abortion-task
type: control-task
comment: A specialization of ending-task, aimed at sequencing events that end a plan execution without having reached its main-goal, but with the possibility or resurrecting the plan.