]> 1.0 1.1 added rdfs:isDefinedBy for all named entities Aldo Gangemi Created by Aldo Gangemi To represent control flows: activation, branching, decisions, concurrency, etc. http://www.loa-cnr.it/ontologies/PlansLite.owl Abstract merging task 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. Action task 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. Activation task A control task aimed at starting an activity. It is specialized either by a beginning task or a reactivation task. Boolean case task 2 E.g. a yes-or-no case task, requiring exactly two deliberation tasks. Branching task 2 A task that articulates the plan into an ordered set of tasks. Case task 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. Concurrency task 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). Control task 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. Decision activity An activity related to planning. It is supposed to execute a 'case task', and can contain an information gathering activity. Decision state A state related to planning. It finalizes the execution of a 'deliberation task', and is preceded by a decision activity. Deliberation task 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.). Ending task An ending task is a control task that has no successor tasks defined in the plan. Loop task 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. Merging task A task that joins a set of tasks after a branching. Synchro task 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.