This pattern has been certified.

Related submission, with evaluation history, can be found here

If you are a member of quality committee please visit the evaluation section If you are author of this proposal or you want to contribute to this pattern's review, you can: ask for a review post your open review specify if this revision takes in account any of the review(s) add a new scenario for Controlflow In general, it could be useful to visit the evaluation section to have information about the evaluation process of this proposal Current revision ID: 9085

AbstractMergingTask (owl:Class) An abstract merging task is a merging aimed at 'formally' joining the tasks that are direct successor to a case task.

Differently from synchronization tasks, which are expected to be executed, abstract mergings only provide abstract boundaries to a task structure, because in a case task, only one action task is supposed to be executed.

ActionTask (owl:Class) 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.

ActivationTask (owl:Class) A control task aimed at starting an activity. It is specialized either by a beginning task or a reactivation task.

BooleanCaseTask (owl:Class) E.g. a yes-or-no case task, requiring exactly two deliberation tasks.

BranchingTask (owl:Class) A task that articulates the plan into an ordered set of tasks.

CaseTask (owl:Class) A case task is a control task branched to a set of tasks that are not executable concurrently. In order to choose which task has to be undertaken, preliminary deliberation tasks should be executed, possibly based on information-gathering and decision rationales.

ConcurrencyTask (owl:Class) 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).

ControlTask (owl:Class) A control task is a task executed during 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.

DecisionActivity (owl:Class) An activity related to planning. It is supposed to execute a 'case task', and can contain an information gathering activity.

DeliberationState (owl:Class) A state related to planning. It finalizes the execution of a 'deliberation task', and is preceded by a decision activity.

DeliberationTask (owl:Class) A deliberation task is a control task that is executed in a deliberation state (a decision taken during a case task execution, e.g. a yes or a no, or a known value, etc.).

EndingTask (owl:Class) An ending task is a control task that has no successor tasks defined in the plan.

LoopTask (owl:Class) 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.

MergingTask (owl:Class) A task that joins a set of tasks after a branching.

SynchroTask (owl:Class) A synchronization task is a merging aimed at waiting for the execution of all (except the optional ones) tasks that are direct successor to a concurrent or any order task.