|
Last modified date is: 2010-03-08 |
Diagram (this article has no graphical representation)
| Name: | Controlflow |
|---|---|
| Submitted by: | AldoGangemi |
| Also Known As: | |
| Intent: | To represent control flows: activation, branching, decisions, concurrency, etc. |
| Domains: | |
| Competency Questions: | |
| Solution description: | - |
| Reusable OWL Building Block: | 1 (472) |
| Consequences: | |
| Scenarios: | |
| 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:
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 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 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 BooleanCaseTask (owl:Class) E.g. a yes-or-no case task, requiring exactly two deliberation tasks.
BooleanCaseTask page BranchingTask (owl:Class) A task that articulates the plan into an ordered set of tasks.
BranchingTask page 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 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 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 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 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 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 EndingTask (owl:Class) An ending task is a control task that has no successor tasks defined in the plan.
EndingTask page 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 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 pageNo scenario is added to this Content OP.
This revision (revision ID 9085) takes in account the reviews: none
Other info at evaluation tab
'Ontology Design Patterns'