From Odp

Jump to: navigation, search

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:

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

Graphical representation

Diagram (this article has no graphical representation)

General description

Name: Controlflow
Submitted by: AldoGangemi
Also Known As:
Intent: To represent control flows: activation, branching, decisions, concurrency, etc.
Competency Questions:
Solution description: -
Reusable OWL Building Block: (829)
Known Uses:
Web References:
Other References:
Examples (OWL files):
Extracted From:
Reengineered From:
Has Components:
Specialization Of:
Related CPs:


The Controlflow Content OP locally defines the following ontology elements:

Class 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.

AbstractMergingTask page
Class 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.
ActionTask page
Class ActivationTask (owl:Class) A control task aimed at starting an activity. It is specialized either by a beginning task or a reactivation task.
ActivationTask page
Class BooleanCaseTask (owl:Class) E.g. a yes-or-no case task, requiring exactly two deliberation tasks.
BooleanCaseTask page
Class BranchingTask (owl:Class) A task that articulates the plan into an ordered set of tasks.
BranchingTask page
Class 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.
CaseTask page
Class 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).
ConcurrencyTask page
Class 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.
ControlTask page
Class DecisionActivity (owl:Class) An activity related to planning. It is supposed to execute a 'case task', and can contain an information gathering activity.
DecisionActivity page
Class DeliberationState (owl:Class) A state related to planning. It finalizes the execution of a 'deliberation task', and is preceded by a decision activity.
DeliberationState page
Class 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.).
DeliberationTask page
Class EndingTask (owl:Class) An ending task is a control task that has no successor tasks defined in the plan.
EndingTask page
Class 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.

LoopTask page
Class MergingTask (owl:Class) A task that joins a set of tasks after a branching.
MergingTask page
Class 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.
SynchroTask page

Additional information


Scenarios about Controlflow

No scenario is added to this Content OP.


Reviews about Controlflow

There is no review about this proposal. This revision (revision ID 9085) takes in account the reviews: none

Other info at evaluation tab

Modeling issues

Modeling issues about Controlflow

There is no Modeling issue related to this proposal.


Add a reference

Personal tools
Quality Committee
Content OP publishers