Opasnet talk:Guidance system development: Difference between revisions

From Opasnet
Jump to navigation Jump to search
No edit summary
(parameters updated)
 
(One intermediate revision by one other user not shown)
Line 2: Line 2:


{{discussion
{{discussion
|Dispute= what is the difference between "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." and "Tools that help to manage the assessment process"?  
|Statements = what is the difference between "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." and "Tools that help to manage the assessment process"?  
|Outcome= Under discussion (to be changed when a conclusion is found)
|Resolution = Under discussion (to be changed when a conclusion is found)
|Argumentation =
|Argumentation =
{{comment|#(number): |I don't see the difference between point 2 and 3. Or is 3 a (generic) project management tool?|--[[User:Alexandra Kuhn|Alexandra Kuhn]] 12:30, 4 February 2008 (EET)}}
{{comment|1 |I don't see the difference between point 2 and 3. Or is 3 a (generic) project management tool?|--[[User:Alexandra Kuhn|Alexandra Kuhn]] 12:30, 4 February 2008 (EET)}}
}}
}}


{{discussion
{{discussion
|Dispute= Unstructured information should be structured as well
|Statements = Unstructured information should be structured as well
|Outcome= Under discussion (to be changed when a conclusion is found)
|Resolution = Under discussion (to be changed when a conclusion is found)
|Argumentation =
|Argumentation =
{{defend|#(number): |Unstructured information should also be structured (kind of the general thing like "Name, Scope, Rest") although not to that degree that the structured information is structured.|--[[User:Alexandra Kuhn|Alexandra Kuhn]] 13:38, 4 February 2008 (EET)}}
{{defend|2|Unstructured information should also be structured (kind of the general thing like "Name, Scope, Rest") although not to that degree that the structured information is structured.|--[[User:Alexandra Kuhn|Alexandra Kuhn]] 13:38, 4 February 2008 (EET)}}
}}
}}
== Jouni's letter on toolbox and its importance ==
'''The toolbox-that-cannot-be-ignored
I wrote this message to encourage people to see how important our work with environmental health risk assessment is, and how we should work even harder to achieve the challenging goals we have set to ourselves in toolbox development.
==An optimal toolbox and a depression==
There is more and more need for a risk assessment or impact assessment toolbox. There are also a lot of ideas what the toolbox should do. It would offer '''guidance''', '''information''', and '''data''' needed for doing assessments. It would enable '''modelling''' and '''computing numerical results''' using state-of-the-art methods. It would help '''assigning values and preferences''' to health and environmental impacts for risk appraisal. It would provide '''ready-made assessments and conclusions''' based on these assessments. It would be useful for real decision-making. It would promote the policy-making related to the Environment and Health Action Plan of the European Union.
I am involved in several EU-funded and other risk assessment projects. Many of these have started with enthusiasm described above. But after a year or so, many people start saying that it is not possible to build such a fancy toolbox. Not in this project. Not with these resources. Not with this group that does not have a common view of the toolbox. The window of opportunities was open last year, but now it has closed.
I believe these people are wrong.
I believe these people are wrong, because they don't look far enough. The crucial thing is not to finish the toolbox within a particular project. The crucial thing is to get the basics right. The crucial thing is to build it in such a way that new functionalities and features can be built on top of it later. The crucial thing is to get far enough within the first project so that other projects and developers become interested and start using and developing the toolbox further.
==An ecological niche==
To be attractive to the other users and developers, the toolbox must have certain properties. It must have its own ecological niche (or position in its environment): it must become the method-of-choice for a large enough group of environmental and health people. It must be based on a systematic structure that is very flexible and not too much limited by the actual questions asked or methods needed. Always when we fail in generality, the number of potential users gets smaller, and it will become harder to find an ecological niche. I have suggested that we should first target the environmental and health students. This is not because they are our final target group, but because that is an ecological niche from where we can start more easily that from elsewhere.
I am a realist. I believe we have found the important properties we want the toolbox to do. They are listed in the beginning. I believe we have developed a clear enough view of the general properties and structures the toolbox should have. There are several projects (such as Intarese, Heimtsa, Beneris, Hiwate, Finmerac, Piltti, iF, and others) where there are a lot of talented researchers with a wide variety of expertise. I believe that there are enough expertise and resources in these projects that is needed to get the toolbox built and running. It will be a very crude first draft, but just think of the first cars or air planes compared with their modern versions. I believe that it is possible to build the first version of such a toolbox that will later grow into the default tool for making environmental and health impact assessments. This toolbox can become an information source you cannot ignore when making decisions related to environment and health.
What I mentioned above is realism. This is because I have learnt from several experts about different methods that are needed in the toolbox. I know they work because they have already been used successfully in separate tasks. I also have a rather detailed view on how these methods can and should be combined into a single toolbox. This has only been tested in a preliminary way, but the results are promising. Severe faults or defects have not been identified.
==An optimistic trooper==
But I am also an optimist. I don't only believe it is possible. I believe that such a toolbox (or the first running draft of it) is '''likely''' to be built, if we join forces within the projects I mentioned, and between the institutes that are involved. It will be hard work and struggle with many problems. It will require a lot of talent to overcome the problems. It will require a lot of enthusiasm not to be discouraged.
In addition to being an optimist, I am a trooper (I learnt this word from colleagues who used to be boy scouts: a trooper is someone who just carries on despite rain, heavy backpack, and a long way to go). Even if we do not join forces, my group and I will try to achieve the toolbox I described. Of course, doing this alone will delay the process for several years, and some parts will not be developed at all during the first years because of the lack of expertise and resources. But I believe that at some point, researchers and users outside my goup will get interested, and that will be the time when the toolbox development really starts to gain speed.
==Essential steps==
What should we do to create the toolbox-that-cannot-be-ignored?
'''First, clear objectives and practical targets must be set.''' But we all have our pet ideas and pet methods we want to promote. Because we are protective, we are willing to go for decisions that are vague enough so that they do not prevent us from promoting our pet ideas later. We must get rid of this protectionism.
I admit that I have also been guilty of protectionism. But as I have learnt to understand the pet ideas of other people, I have realised that they are not contradictory. Actually, the pet ideas that I am aware of are about different aspects of the toolbox, and they are complementary or even synergistic. But this is not easy to see because of problems related to different words used and lack of understanding of methods other people apply. Unfortunately, in the current situation, we protect our own ideas in such a way that it actually prevents the promotion of the very same ideas.
'''Second, we should have a single site for the most up-to-date information''' about the contents and methods of the toolbox. The information should have a proper structure, which should basically follow the structure of the toolbox and the underlying method. People must be able to see that their ideas have been included in the toolbox. Otherwise we cannot get rid of protectionism. A single site also makes it possible to contribute at a right time. We will fail, if we try to send pieces of information around to those we anticipate are interested in that particular piece at that particular time. The toolbox is far too complex thing for us to guess who has something to contribute to which part.
Those who know me should note this: I am not saying that we must use collaborative workspaces or wiki environments. The critical thing is that the content must be available to read. But contributions can be sent around via email or Word files, if people prefer that. In my opinion, collaborative systems are more efficient because they enable on-line editing, but that is not a critical thing.
'''Third, we should clarify some basic things that underlie the toolbox structure and its methods.''' There are several things that cannot be left out or done otherwise without severely hampering the toolbox functionalities and further development. I will mention a few major ones here. I sincerely hope that if people disagree on these, they will notify immediately, because these things must be fixed soon to prevent further divergence and disaggregation of resources.
===Underlying assumptions===
# Causal diagrams should be used to describe risk situations in an assessment. {{disclink|Assumption 1}}
# Probabilities should be used to describe the variables (or nodes) in a causal diagram. (Note that also point estimates can be used if full uncertainty cannot be characterised. Technically, point estimates are probability distributions with zero variance.)
# Variables, and preferably also other objects, should have a uniform structure.
# The assessment and the variables used in the assessment should reflect reality. This means that the variables can be "validated" (or more specifically, tested for falsification) using data about the phenomenon that the variable describes. {{disclink|Assumption 4}}
# The toolbox should reflect state-of the-art methods from relevant disciplines (such as probability theory, decision analysis, epidemiology, toxicology, environmental sciences, economy).
# The toolbox should be based on a systematic theory of risk assessment (or impact assessment). In other words, there should be a coherent continuum from a) the theory to b) applications of the theory in methods to c) practical operationalisation of the methods in the toolbox. {{disclink|Assumption 6}}
--[[User:Jouni|Jouni]] 01:03, 18 December 2007 (EET)

Latest revision as of 16:48, 3 January 2010

-- Alexandra Kuhn 12:30, 4 February 2008 (EET)

How to read discussions

Fact discussion: .
Opening statement: what is the difference between "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." and "Tools that help to manage the assessment process"?

Closing statement: Under discussion (to be changed when a conclusion is found)

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:
----1: . I don't see the difference between point 2 and 3. Or is 3 a (generic) project management tool? --Alexandra Kuhn 12:30, 4 February 2008 (EET) (type: truth; paradigms: science: comment)

How to read discussions

Fact discussion: .
Opening statement: Unstructured information should be structured as well

Closing statement: Under discussion (to be changed when a conclusion is found)

(A closing statement, when resolved, should be updated to the main page.)

Argumentation:
←--2: . Unstructured information should also be structured (kind of the general thing like "Name, Scope, Rest") although not to that degree that the structured information is structured. --Alexandra Kuhn 13:38, 4 February 2008 (EET) (type: truth; paradigms: science: defence)

Jouni's letter on toolbox and its importance

The toolbox-that-cannot-be-ignored

I wrote this message to encourage people to see how important our work with environmental health risk assessment is, and how we should work even harder to achieve the challenging goals we have set to ourselves in toolbox development.

An optimal toolbox and a depression

There is more and more need for a risk assessment or impact assessment toolbox. There are also a lot of ideas what the toolbox should do. It would offer guidance, information, and data needed for doing assessments. It would enable modelling and computing numerical results using state-of-the-art methods. It would help assigning values and preferences to health and environmental impacts for risk appraisal. It would provide ready-made assessments and conclusions based on these assessments. It would be useful for real decision-making. It would promote the policy-making related to the Environment and Health Action Plan of the European Union.

I am involved in several EU-funded and other risk assessment projects. Many of these have started with enthusiasm described above. But after a year or so, many people start saying that it is not possible to build such a fancy toolbox. Not in this project. Not with these resources. Not with this group that does not have a common view of the toolbox. The window of opportunities was open last year, but now it has closed.

I believe these people are wrong.

I believe these people are wrong, because they don't look far enough. The crucial thing is not to finish the toolbox within a particular project. The crucial thing is to get the basics right. The crucial thing is to build it in such a way that new functionalities and features can be built on top of it later. The crucial thing is to get far enough within the first project so that other projects and developers become interested and start using and developing the toolbox further.

An ecological niche

To be attractive to the other users and developers, the toolbox must have certain properties. It must have its own ecological niche (or position in its environment): it must become the method-of-choice for a large enough group of environmental and health people. It must be based on a systematic structure that is very flexible and not too much limited by the actual questions asked or methods needed. Always when we fail in generality, the number of potential users gets smaller, and it will become harder to find an ecological niche. I have suggested that we should first target the environmental and health students. This is not because they are our final target group, but because that is an ecological niche from where we can start more easily that from elsewhere.

I am a realist. I believe we have found the important properties we want the toolbox to do. They are listed in the beginning. I believe we have developed a clear enough view of the general properties and structures the toolbox should have. There are several projects (such as Intarese, Heimtsa, Beneris, Hiwate, Finmerac, Piltti, iF, and others) where there are a lot of talented researchers with a wide variety of expertise. I believe that there are enough expertise and resources in these projects that is needed to get the toolbox built and running. It will be a very crude first draft, but just think of the first cars or air planes compared with their modern versions. I believe that it is possible to build the first version of such a toolbox that will later grow into the default tool for making environmental and health impact assessments. This toolbox can become an information source you cannot ignore when making decisions related to environment and health.

What I mentioned above is realism. This is because I have learnt from several experts about different methods that are needed in the toolbox. I know they work because they have already been used successfully in separate tasks. I also have a rather detailed view on how these methods can and should be combined into a single toolbox. This has only been tested in a preliminary way, but the results are promising. Severe faults or defects have not been identified.

An optimistic trooper

But I am also an optimist. I don't only believe it is possible. I believe that such a toolbox (or the first running draft of it) is likely to be built, if we join forces within the projects I mentioned, and between the institutes that are involved. It will be hard work and struggle with many problems. It will require a lot of talent to overcome the problems. It will require a lot of enthusiasm not to be discouraged.

In addition to being an optimist, I am a trooper (I learnt this word from colleagues who used to be boy scouts: a trooper is someone who just carries on despite rain, heavy backpack, and a long way to go). Even if we do not join forces, my group and I will try to achieve the toolbox I described. Of course, doing this alone will delay the process for several years, and some parts will not be developed at all during the first years because of the lack of expertise and resources. But I believe that at some point, researchers and users outside my goup will get interested, and that will be the time when the toolbox development really starts to gain speed.

Essential steps

What should we do to create the toolbox-that-cannot-be-ignored?

First, clear objectives and practical targets must be set. But we all have our pet ideas and pet methods we want to promote. Because we are protective, we are willing to go for decisions that are vague enough so that they do not prevent us from promoting our pet ideas later. We must get rid of this protectionism.

I admit that I have also been guilty of protectionism. But as I have learnt to understand the pet ideas of other people, I have realised that they are not contradictory. Actually, the pet ideas that I am aware of are about different aspects of the toolbox, and they are complementary or even synergistic. But this is not easy to see because of problems related to different words used and lack of understanding of methods other people apply. Unfortunately, in the current situation, we protect our own ideas in such a way that it actually prevents the promotion of the very same ideas.

Second, we should have a single site for the most up-to-date information about the contents and methods of the toolbox. The information should have a proper structure, which should basically follow the structure of the toolbox and the underlying method. People must be able to see that their ideas have been included in the toolbox. Otherwise we cannot get rid of protectionism. A single site also makes it possible to contribute at a right time. We will fail, if we try to send pieces of information around to those we anticipate are interested in that particular piece at that particular time. The toolbox is far too complex thing for us to guess who has something to contribute to which part.

Those who know me should note this: I am not saying that we must use collaborative workspaces or wiki environments. The critical thing is that the content must be available to read. But contributions can be sent around via email or Word files, if people prefer that. In my opinion, collaborative systems are more efficient because they enable on-line editing, but that is not a critical thing.

Third, we should clarify some basic things that underlie the toolbox structure and its methods. There are several things that cannot be left out or done otherwise without severely hampering the toolbox functionalities and further development. I will mention a few major ones here. I sincerely hope that if people disagree on these, they will notify immediately, because these things must be fixed soon to prevent further divergence and disaggregation of resources.

Underlying assumptions

  1. Causal diagrams should be used to describe risk situations in an assessment. D↷
  2. Probabilities should be used to describe the variables (or nodes) in a causal diagram. (Note that also point estimates can be used if full uncertainty cannot be characterised. Technically, point estimates are probability distributions with zero variance.)
  3. Variables, and preferably also other objects, should have a uniform structure.
  4. The assessment and the variables used in the assessment should reflect reality. This means that the variables can be "validated" (or more specifically, tested for falsification) using data about the phenomenon that the variable describes. D↷
  5. The toolbox should reflect state-of the-art methods from relevant disciplines (such as probability theory, decision analysis, epidemiology, toxicology, environmental sciences, economy).
  6. The toolbox should be based on a systematic theory of risk assessment (or impact assessment). In other words, there should be a coherent continuum from a) the theory to b) applications of the theory in methods to c) practical operationalisation of the methods in the toolbox. D↷

--Jouni 01:03, 18 December 2007 (EET)