Opasnet:Guidance system development

<accesscontrol>Members of projects</accesscontrol>

Guidance system development contains specification and other information about the information system to be developed for carrying out and managing risk/impact assessments and to storing the products of the assessments as well as information that is useful as input for the assessments. As issues become worked out their implications should be transferred or built-in to the relevant content pages of guidance system, i.e. Guidebook, Toolbox or Data center.

Dimensions and hierarchies

The guidance system has two distinct dimensions. It can be confusing to browse through different parts. This is an attempt to clarify these issues. The hierarchy levels are listed from bottom to top for each dimension. The hierarchy list has dramatically changed; the original list was much longer and more complex. However, the old "dimensions" are captured in the new two dimensions. "Class", "real world", and "work environment" are actually examples of structures in the complexity dimension. "Meta" still exists but in a more rich form. "Guidebook articles" about glue (summary) articles, structured (according to the method) articles, and background articles is a practical grouping of objects inside and outside the method. "Resource Centre" is an application of the meta dimension. "Tools/Models" is an application of the complexity dimension.

• Dimension: Meta (or Abstraction level)
  1. Zero meta level is the real world: the real objects and events.
  2. First metal level contains the descriptions of the real world (such as variables and assessments) and the collection and synthesis processes of the first meta level information.
  3. Second meta level contains the general structures of the first-level objects, and the descriptions of these objects (such as process descriptions).
  4. Third meta level describes the development processes and the descriptions of the second-level objects.
  • For objects in the Resource Centre
    1. (Nothing exists from the zero meta level)
    2. Tools/models (software or programs) and core data sets
    3. Descriptions of tools, models, and core data sets, including links to those that are not within the Resource Centre.
    4. Descriptions and links to tool, model, and databases (meta-metadata).

• Dimension: Complexity (or composition level)
  • For product objects
    1. Variable: this level looks at individual product objects (typically variables) that describe particular pieces of reality.
    2. Assessment: this level looks at groups of variables that together form a synthesis of a particular problem at hand.
    3. Policy context: this level looks a particular problem as its relation to the policy context in which it is assessed. This level is usually not described explicitly.
  • For process objects
    1. Method: a procedure for manipulating information (about the real world) into a useful form for a particular place in an assessment.
    2. Assessment framework: A distinct set of methods that, when used together, form a scientifically coherent and efficient way for manipulating all information that is needed to perform a particular kind of an assessment.
    3. Scientific context: this level looks at the assessment frameworks in their scientific context in which they are used. This level is usually not described explicitly.
  • For Classes
    1. Item: an object (typically a variable or a class) that belongs to a particular class. For example, a pollutant concentration in a particular location at a particular time.
    2. Class: a set of all objects that share a key property, defined in the scope of the class. For example a class of "dioxin concentration objects" (in any spatio-temporal location) forms a class that can be useful when utilising the full chain approach for a dioxin assessment.
  • For tools:
    1. Tools/Models that help to specify the result of the variables (e.g. Chimère, WATSON)
    2. Tools that help to perform the assessment as such (so dealing with the process of an assessment). These would be e.g. a tool for stakeholder involvement.

What are processes and products?

Fundamentally, a process is an event, or a composite of events, that produces something; a product. Product is an object which has been produced by some process, and has a potential of being used for something built in its structure. So, process produces a product, which in turn can initiate its use process. Processes thus use products (as their input) and produce products (as their output). Products have a history of being produced by a product and bear in them the potential of initiating its use process. Processess and products can be seen as different sides of the same coin. The same thing could (often) be considered from the point of view of a product: what is it, what produced it, what can it be used for - or from the point of view of a process: what is it, what inputs does it need, what does it produce. A process can produce several products and products can be produced by several processes. Similarly, a product can be used in several processes and a process can use several products (there does not necessarily have to be a 1-1 relationship between processes and products). It is merely a question of the chosen level of observation/description (could be also be referred to as granularity or resolution), that defines how the boundaries of the processes and products are set.

Processes and products in risk/impact assessments

An assessment can be seen as consisting of the process of making the assessment and the product(s) that are produced by the process. The products are produced according to some needs (use purpose of the product), which defines the intended (desired?) structure (contents, appearance, form, etc.) of the product. The use purpose further defines, or at least sets requirements for, the structure of the process that produces, or is intended to produce, the product (which has the structure that meets the requirements set by the use purpose). In general it can be said that the the purpose of the process is to produce the product, whose purpose furthermore is to initiate (become a part of, fulfill its task within, ...) its use process.

When talking about risk or impact assessments the level of observation is such that the term product refers to the certain kind of description of reality within a certain scope. It is thus a composite information object synthesized of smaller chunks of information. The term process then refers to the (organized?) compilation of activities or events that produce this composite information object. They can be of types such as observation, information collection and synthesis. Furthermore, the term process can also refer to the activities of managing, or organizing, these above-mentioned activities.

The term process object may be used to refer to the structural parts of the process or their composites, including also the whole process. The term product object may be used to refer to the structural parts of the product or their composites, including also the whole product.

The risk/impact assessment product is information. The product and its parts are descriptions of reality, information about the reality. The risk/impact assessment process is producing, collecting and synthesizing information and management of these activities (let us call them sub-processes). The target of information collection and synthesis sub-processes is information about reality, the target of observation is the reality itself. The target of management sub-process is the composite of the other sub-processes. It can also be argued that management is a meta-process of risk/impact assessment process, that observation is a sub-process of risk/impact assessment process, and that only collection and synthesis sub-processes actually belong to the risk/impact assessment process as its internal structural parts. This is merely a boundary definition issue, and in any case it is easy to see that the above-mentioned structural parts of the process are hierarchically related.

Risk/impact assessment is thus (almost?) all about information. It deals with descriptions of phenomena, not directly the phenomena themselves. A variable (a part of the assessment product, a product object) is a description of a part of reality, not the part of reality itself. The process objects, such as editing a particular variable, on the other hand could be argued to be reality itself.

What does this all mean when thinking of risk/impact assessment information systems and their contents? Naturally, information products can be easily captured within such systems, but processes not (directly). It is obvious that the objects that can be stored within an information system are of the type product and that processes can only be built-in indirectly. However, the contents of these product type objects can of course be about either products or processes - descriptions of something.

A guidebook of risk/impact assessment should contain:

• generalized description(s) of the product, and its structural parts, of risk/impact assessment (2nd meta)
• descriptions of the risk/impact assessment process, and its structural parts, that produces such product (2nd meta)

A resource center should contain:

• unorganized or untargeted descriptions of reality (1st meta, result of information collection and/or observation)

A result database should contain:

• organized, targeted descriptions of reality (1st meta, result of information synthesis)

The above-mentioned parts of a risk/impact assessment information system are storages of product type objects. Perhaps, however, for clarity it might be good to reserve the term product only for the result database contents(?).

If we wish a risk/impact assessment information system to not only be a storage of information, but to make it functional, we should to try to build in some processes into it. This can, as mentioned above, only be done indirectly, i.e. by providing support of some kind for carrying out the needed parts of the process. In part the guidebook is intended provide this kind of support, but the system would also require a workspace where the process can be carried out, in part or wholly, and specific tools for information synthesis as required.