Task-oriented information modelling

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Task-oriented information modelling (TIM) designates a formal language engineered to allow the description of working situations by means of a task tree and to structure the information related of the tasks included in it. TIM models can provide the content for product-related documents (such as user-manuals, on-line helps and maintenance manuals) but also represent processes or express the functional specifications of hardware and software systems alongside with main features of their interfaces. TIM has been engineered by Tanguy Wettengel at the Centre de Recherches Sémiotiques (University of Limoges, France).

TIM is an environment allowing to model work in different contexts. TIM models can be used to provide the content of instructions (such as manuals and on-line helps) but equally to plan production processes or define functional specifications. TIM is thus a method for describing work and not a tool for describing documents. The choice of sharply separating task modelling and content publishing explains why TIM does not include any means to specify the structure or the layout of documents.

Unsurprisingly, a TIM task's meta-model only bears semantic components related to the analysis of work, such as input, output, side effect, as shown by the image below.

Information relevant to task engagement is distributed between categories named "access" (pre-requisites), input, output and side effect. last level tasks express the activity allowing the transition from input to output as a list of actions named "procedure", while other task distribute this activity among the subtasks included in them. Task engagement related information is limited to descriptions that are typed to properties or to states, depending on the persistence throughout the model of the situations they describe. States are reversible (a light that is on, in case it might as well be off) whereas properties are not (the colour of a cable, for example).

Each task holds a place in a task tree. If a task is split into sub-tasks, the sub-tasks included in it may be mandatory or optional. Any task may bare engagement conditions or not (the ones that do, are called "conditional" tasks in TIM). Any task that may need to be re-engaged in order to allow satisfaction of a condition stated in its access is viewed as a "cyclic" task. if the engagement of a single subtask is enough to produce the transition from input to output, the siblings of the same level are considered as "Alternatives". Because of this rich structure, TIM task trees conveys complete information about mandatory sequences, options, alternatives, conditions and cycles. They therefore are not bound to external enhancements, such as the "Plans" that are mapped onto task trees in HTA.

The formal language monitoring this architecture is built up by combining three primitive entities, namely "objects", "facets" and "operations". Objects are entities baring properties or being affected by operations, Facets stand for some feature of an object in a given situation, Operations express concrete or abstract manipulations performed on objects.

States and properties (descriptions) populate the perimeter of a task (access, input, output, side effect); actions (at least one) build up the task's procedure. Whereas the goal (the polarity between input and output) distinguishes optional tasks from mandatory ones in a given situation, the access allows to code task features, such as "conditional" or "cyclic" without any enhancement of the basic task tree. The blue text in the-figure below shows a syntactic model of a simple task.

The actual model reduces in fact to the following expressions:

The positions of the elements define the category they belong to (in sequence, task name, access, input, output, side effect and procedure). The combination of the meaning of the expressions and the category they belong to allow appropriate translation into natural language: the access is here translated into "the target file's icon must be displayed", "must" expresses the fact that the description is placed within the access. Moreover, the fact that the access is not empty reveals the fact that the task is conditional (in our example task, if the icon is not displayed, the procedure cannot be performed).

Timgroup [1]