New thoughts and discussions

From Testiwiki
Revision as of 08:57, 2 January 2007 by Jouni (talk | contribs) (location of arguments)
Jump to: navigation, search

This page is intended for sharing your latest Intarese related thoughts and discussion topics that are already worth disseminating among interested people, but that might not be ripe enough to deserve their own pages yet. Feel free to write and process your thoughts here, no matter how unorganized they may be. Please edit the page so that the latest thoughts and discussions come on the top of the page.

Location of arguments in wiki and ana, 2.1.2007

  • Participants: Jouni

We have used orange (or yellow) trapezoids for arguments (and comments) in pyrkilo diagrams. These are issues, opinions, or conclusions based on other variables, and they are treated as variables in the Analytica environment that is used to draw the diagrams. However, it is not clear how this should be done in Wiki environment. Most discussions are located in the Talk pages of the respective variables, so they are parts of the variables that point to them. This raises a few questions:

  1. Are ALL arguments and comments parts of a variable?
  2. If they are, how can you make links from several variables to an argument, when it can only be located under one?
  3. If they are not, how do you distinguish between discussions that belong to a variable and those that are independent variables themselves?

Suggestions:

  • Some arguments are variables, but most are discussions. The latter type is clear if an argument relates to only one variable, and the main content is a statement. An argument should be a variable if it is for example data (measurements) about a variable. This is marked in a diagram as a pink trapezoid.
  • If an argument is related to several variables, the appropriate links are written within the Discussion to Dispute or Argumentation attributes. The discussion is located under the most important variable.

About practical implementation of pyrkio method, 14.12.2006

Participants: Marko, Mikko, Virpi, Eva, Matti, Anna, Juha V, Marja-Leena, Olli, Jouni, Aleksi, Einari

  • Eva do we decide already about participation
  • Jouni yes, in the beginning
  • marko assume we have perfect data
  • mikko does the data tell the relationships on the variables
  • eva do we have hospital data
  • vifrpi we must have discussion about what is good data
  • mikko we need data on relationships such as functional info
  • marko 2 kinds of data: data about magnitude, data about formulas
  • virpi you must define how you use data and what you want out of it. not everyone agrees on this
  • anna public participation at this phase is important. we need this for drafting
  • virpi yes, i agree. before the vafriables are fixed
  • anna we sould invclude experts and paople
  • eva like in helsinki the ytv they have a good view on the issue
  • anna this might be a slow period it takes time
  • virpi people will bring the data, therefore you need them before you haveall the data
  • marko if someone bring better data we'll replace it
  • marko when do we start to write wiki articles
  • eva
  • virpi you mey think that variable is clear bu not every one may agree
  • eva that will take a lot of time
  • virpi if nobody comments, thats it
  • eva so you'll find stakeholders for the model in general and not for every variable
  • virpi yes, good point is it active of passive collection of contribution
  • marko there could be 2 kind of participation
  • marko lets assume we have data and the relationships
  • marko at which point you would start writinf wiki
  • virpi right in the beginning where you would put focus if not there
  • matti you should not stick to your first focus because it will change
  • mikko to avoid that you go far énough with focus and scope discussion
  • eva but then there is feedback you are dependent on what you have that affects your definition of variable
  • matti you must have conseptual model and some data before you can write focus and scope we need a understanding
  • virpi never the focus comes from a vacuum stakeholders have knowledge on things
  • anna i agree with matti
  • matti you have to have chemical, medium etc in your mind these should be drafted
  • marko we agree that start with pyrkilo diagram then public participation
  • mikko what do we need about public participation here, we should start within the group
  • jouni there is no rule about when you should go public
  • eva we should separate active and passive participation active: we ask comment from defined people passive: you put things to internet and anyone can comment
  • virpi first moderator will draft the first diagram it does not appear itself
  • marko first draft, then active in-house participation
  • anna the active participation is iterative
  • matti we need feedback loops for stages of process especially if people don't agree on what we talk about in the first place otherwise the discussion disperses we must have a reasonably detailed sketch first
  • virpi stuff must be somewhere why not in wiki
  • matti the key is when you go to public wiki is just a technicality
  • virpi do you have a reasonable view when you go to public
  • matti when you go open, focus must be refinded (not closed)
  • mikko do we need sometimes fix some part before we go public?
  • matti yes sometimes but with a reason
  • marko some things may be left open
  • matti like how to weigh thing
  • eva also data about linkages must be discussed
  • matti you need conceptual framework, data, and models
  • marko do you leave things out because of lack of data
  • virpi+matti you cannot leave things out because of this you can proceed without data in a qualitative way things can be included even if you know that you will not get data
  • mikko that will leave it to qualitative discussion
  • virpi you need an idealistic conseptual model and then you deal with that as well s you can
  • jouni we need two models wider and more narrow that is focussed
  • matti do we talk about data or measurements we have some understanding of everything we can narrow anything down to 2 orders of magnitude
  • mikko we need a definition of data figures, numbers, data, what?
  • marko eg air pollution we know that there are thousands of measurements but what we take is a one who number
  • matti we can ask an expert
  • jouni there is a question about the defition data and the result data
  • matti you need to define the output (the ideal form) and you need to describe the validation data this may come from a similar source i see lot of modelling that cannot be validated even theoretically
  • mikko so the purpose of the definition is to make this clear
  • anna i would start RA and then i should have a view that i need different outputs should i then do several risk assessments is i have my focus fixed
  • eva whats the aim of public participation at this stage (5) in 2 it will be about framing, in 5 about data do you have more precise data than what we have now?"
  • mikko would we have now the values of the attributes do we validate the model by showing them to public
  • matti there are 3 points 1 are we talking about the real problem 2 public may have data we dont 3 issue of transparency
  • marko so 1 public hearing 2 moderator talks with some people or internet 3 like evaluation
  • mikko 3 is more like allowing access
  • marko does the opeenness mean internet
  • matti we dont bother most people dont want to work through
  • eva we can
  • virpi when do we fix focus
  • marko id like to add 4 to participation: risk communication seminar or similar to stakehodler
  • eva that the same as 3
  • marko its about active or passive process for stakehodler the result is more important thatn process
  • mikko the outcome may be that you understand that
  • marko is the process now clear we must be able to explain this for FMI, GTK, and others within our projects
  • mikko 6 was model+results what does model mean does this model refer to ana model where you have defined variables model could also mean 4
  • marko if we use ana anyway how will we do the model in ana. idea: ana code is in wiki pages
  • matti what are you talking about there is no point in recoding the existing model you just take the result
  • marko we dont add everything we just take a model results in wiki
  • mikko so the modelling refers to simple calculations in ana
  • marko you must be able to combine the whole chain to be estimated
  • mikko so does this include other data from other models
  • marko yes
  • matti my idea in intarese: the model is very simple models that you can actually build in the system
  • jouni complex models are referred to as functions
  • virpi also parameters must be defined
  • matti we cannot describe all model details and we must describe input parameters
  • anna so we lose transparency
  • mikko not everyone understands everything
  • marko never a single person understand everything
  • marko where would you define the DR
  • jouni lond discussion about ana wiki converter
  • matti i dont like the idea most people are not able to read ana code i want to have a filter between ana code only moderator should be able to edit the ana code
  • matti only moderator can edit contents, otherwise a mess
  • virpi who will finally decide when a resolution has emerged
  • what will we do next
  • a case RA: start from scratch Finmerac Harjavalta health effects


About pyrkilo method, its applications and role on Intarese 7.11.2006

Participants: Marko, Jouni, Mikko

Fairly unorganized list of issues mentioned (correct and continue the list as needed):

  • pyrkilo method should be developed separately from its applications
  • the idea of Mediawiki based intra-project communication should be kept separate from the method development itself
    • these two do have a strong relation and synergistic potential, however
  • in principle, there are several other ways of applying the pyrkilo method in addition to the ones we are developing
  • pyrkilo method could be fed also as such as an input to Intarese and not tie it too tightly with our own applicative developments
    • without sufficient understanding of the basic ideas and goals behind the method and the conceptual operationalization of the ideas, the partners are not ready to welcome our "technical" applicative ideas
  • we should better define how the method is located within the field of risk governance (see e.g. IRGC's white paper) and which identified challenges is it addressing and how
    • this needs first to be clear to us, then we can and must make it clear to others
  • the final product of Intarese should be better defined - maybe a book or corresponding, so that all partners would better realize their roles and the expected contribution
  • we, both in pyrkilo development and in Intarese, should ask ourselves (in this order!):
  1. what are the properties that a good RA has?
  2. what kind is the method that fulfils the above mentioned requirements?
  3. what kind of technical application(s) do we need to apply this method effectively?

About role of SP4, 6.10.2006

  • Participants: Reiner Friedrich, David Briggs

Dear David,

Formally, scope and content of the tool box will be determined within WP 4.1, based on discussions with the partners involved in this WP and on the findings of user consultations. As this has not been finalised, it is not possible to determine and allocate tasks in WP 4,2; this was clearly stated in the preliminary description of WP 4.2, however we have nevertheless included some exemplary tasks to give the partners a feeling on the areas on which they might contribute and to start discussion about this (which obviously has worked). As a consequence to your perception on this we have thus omitted this list of tasks in WP 4.2 (new version already distributed).


Nevertheless some thoughts on your email:

I do not see the firm necessity to choose between black and white or alternative 1 and 2, but have the feeling that it might be possible to include as well some webbased information about integrated risk assessment, some guidance about how to proceed, which relations and parameters to choose, how to deal with uncertainties, how to present results and a description of the case studies on the one hand and some links to models and the provision of some basic data and tools for transforming data on the other hand (at least this was the current plan, which in my view was reflected in our tasks – only the communication of results was not included as this would come after month 30). Of course for all these items an analysis of whether this is really useful and used by users (whom?) is necessary.

I am especially confused as you on the one hand appreciate the demonstrator, on the other hand the demonstrator only makes sense in the current form and has explicitly foreseen links to models and the provision of data sets in a defined format ??

If however I would have to interpret your email as saying that there should not be any tool or data sets at all in the ‘tool’ box, there are a number of issues to think about:

  • Tools and data sets in the tool box are explicitly mentioned in the DOW (and thus seen as valuable by the Commission and the evaluators), so the aim of stream 4 has to be somehow formally changed – and this would need some arguments (which?, your remarks do not contain much argumentation, so what is the (your) motivation?)
  • to carry out the three case studies in WP 4.3 would require the use of certain data, tools and models (which of course could also run outside the toolbox, but then it would not or only partly be a demonstration of the tool box).
  • I would imagine that at least users that want to carry out integrated risk assessment themselves would be happy to have not only guidance, but also some kind of improved data sets and access or links to models to carry out their analysis.

I look forward to a constructive discussion of these issues in the next meetings; thanks Jouni for your initiative.

With best wishes

Rainer



Von: Briggs, David J [1] Gesendet: Donnerstag, 5. Oktober 2006 16:40 An: Alexandra Kuhn; Aasmund Fahre Vik; Agnes Dudek; Alexandra Kuhn; Anne Knol; Anne-Catherine Viso; Cécile Honoré; Céline Boudet; Cheikh Diack; Edzer J. Pebesma; Emelie Vermande; Erik Lebret; Hildegunn T. Blindheim Jablonska; Jouni T. Tuomisto; Laurence Rouil; Leendert van Bree; Mikko Pohjola; Sjur Bjoernsdalsaeter; Tassos J. Karabelas Cc: Rainer Friedrich; Volker Klotz; Udondem, Samantha A Betreff: Intarese: WP 4.2 Plan for next 18 months


Dear Alex et al,


I hate to be a problem and a pain, but I have some difficulties with the draft plan for WP4.2. I will try to explain my difficulties clearly, though this risks seeming very negative and a bit confrontational. Forgive me if this is how it seems - but it's important we resolve this issue once and for all.


The basic problem is that there still seems to be quite a deep-seated conflict in concept about what the toolbox will be. I characterise it in this way:


1) some see it as an all-singing all-dancing piece of software that will deliver lots of linked models for risk assessment (e.g. emissions, dispersion) and come up with an estimate of risk


2) others see it as a computer-based set of tools and information that can help people design an integrated risk assessment and communicate the results to users (but would not necessarily actually DO the assessment itself).


My own belief remains firmly that we need a bit of both (but that #2 is the more important, more valuable for users, and more achievable, so requires some emphasis). It's also very clear from the user consultations, and from the discussions we had in Paris and in other meetings, that this is the belief of most other partners and external users. For the most part, also, people seem to agree that the demonstrator captures this balance very well (there have been some comments that the ozone example is a bit too mechanistic and model-heavy, in this respect, but people appreciate that the examples were pulled in from what was readily available), and as such helps to define what the toolbox needs to provide.


My problem is that your description of the planned work speaks to me, at least, mainly of #1 (I don't see much of a link with the demonstrator). I therefore worry that it will speak to others similarly. [I have to say that I also worry that at the heart of there might be a reluctance to give up on the clever techie modelling system, whether the consortium want it or not, because that's what clever techie people like to do!]


All this may just be a matter of language and what we each read into the words. However, what we say, and the way we say it, will define expectations not just of people in this WP, but across the consortium and beyond. As it stands, I believe that the current plan for WP4.2 will raise the wrong expectations - and will be seen to miss the needs which the partners and users have expressed.


So, can I entreat you to redraft the tasks for WP4.2 better to reflect both the framework already developed in the demonstrator, and the clear message from the partners and external users in part 1 of the project - namely that the toolbox is as much as tool for issue framing and for visualising/communicating information (not only on the actual risk estimates but on the whole process of assessment, from issue-framing to risk characterisation) as it is for exposure modelling. Basically, this implies much less emphasis on things such as:


provision of European wide emission data sets in high temporal and spatial resolution, parametrized European atmospheric model, European-wide multi-modal model (soil, water, air), ammonia, PM emissions from agriculture, description on best practice in emission calculation...

emission data base for heavy metals and POP’s to air, water, soil (except agriculture) , description of proceeding and model for urban pollution, link regional-local/urban modelling ...etc


and rather more on how to develop the functionality for designing and negotiating assessments, accessing what's already known from previous assessments, selecting and computing relevant indicators, and visualising the whole process and the results in (hopefully interactive) ways that can engage and inform users.


Incidentally, I'd also like to be sure in this context that the Consortium Requirements Document will reflect this same concept. Again, I remain rather concerned that the Requirements Document will tell us what the techie people think is good for us all, rather than an encapsulation of what the consortium partners (and end users they represent) say they need.


Or if I'm wrong, tell me why!

Best wishes

David

Comparison of approaches to Risk assessments 29.9.2006

Participants: Mikko & Jouni

A draft list of important attributes of RA processes for evaluating and comparing the means/responses of Pyrkilö (KTL), Environmental health planner or EHP (RIVM/MNP) and Impact pathway modelling/cost-benefit analysis or IPM/CBA approaches to each attribute. Attributes mainly based on OMB bulletin + various pyrkilö method related discussions/writings, grouping based on PSSP method process/product model. Renaming, regrouping, reforming, reworking accepted and expected.

Properties of risk assessments (Interior)

the assessment process + the assessment product

Assessment

  • Clarity of objectives & scope
  • Reproducibility
  • Dispute resolving
  • Connectivity with other assessments
  • Dynamics of the process
  • Understandability
  • Informativity
  • Transparency
  • Explicitness of assumptions
  • Utility
  • Version & history control

Data

  • Validity of data
  • Relevance
  • Probability
  • Rationality
  • Objectivity
  • Integrity
  • Quantitative results whenever possible
  • Central estimates+range
  • Explicit separation and analysis of variability & uncertainty
  • Explicit handling of value judgements

Identified/important stakeholders (Exterior)

addressed yes/no?, role receiver/contributor/other?

  • Decision/Policy makers (EU/National/Local administration)
  • Industry & commerce
  • Civic organizations (NGOs)
  • Concerned citizens
  • Public at large (anyone)

Interaction with stakeholders (Interaction)

with who? when? why?

  • Iterative dialogue with stakeholders
  • Public access to original data
  • Acknowledging public concerns
  • Gaining acceptance to assumptions & data

Assessment-stakeholders interface (Boundary)

means of interaction with stakeholders

  • Tools/Media
  • Circumstances/events

Collective intelligence 28.9.2006

by Jouni

  • en:The Wisdom of Crowds is a book by en:James Surowiecki who promotes the idea that a collective judgement is often more precise than judgement by a few experts. To work properly, crowds must have a wide dispersion of opinions, independence, decentralisation, and a mechanism to aggregate opinions. Surowiecki tells several stories where crowds have successfully been wise, and also cases where one or more of these properties have been missing - with poor results.
  • en:Collective intelligence is a more heterogenous page about intelligence that is based on decentralised approaches of group work.

11.9.2006 Connections between WP1.1-WP1.5

Participants: Jouni (motivated by previous discussions today with Matti and Juha)

Motivation: There should more interactions between SP1 WPs. What could this be?

  • There should be methodological guidance for SP3.
  • There should be collaboration related to scientific research within WP1.X, such as
    • intake fraction
    • Bayesian methods
    • expert elicitation
    • coherent analysis of uncertainty

Intake fraction generator

This tool has been invented by Matti, and here I try to operationalise it in Mediawiki as an example of Mediawiki's flexibility.

You want to start with the intake fraction definition:

iF = ∑ci*Pi*BR/Q,

where c=concentration, P=population, BR=breathing rate, Q=emission, i=index for location.
The idea is that you go through the equation step by step and choose the relevant values or models for calculating the values. This can be done in Mediawiki in the following way:

There should be a page named "Intake fraction generator". This page should contain the description of the process, and descriptions of all variables used in the equation. The possible values are described as a list of values or links to more detailed descriptions. When more text is needed to describe which value is appropriate, the links go to the relevant pages.

A new variable is created for the new intake fraction to be estimated. The focus and scope are described. The relevant variable values are copy-pasted from the description pages to the Input attribute. The Definition is of the form: iFgenerator(var1|var2|var3...) where iFgenerator is a function (a special kind of variable) that calculates the intake fraction based on the variables var1, var2, var3...

What wikipedia does is that it takes the code from iFgenerator Definition, replaces the Inputs with var1 and so on, and runs that code in R. The output is printed on a special page "Variable results", which contains results for variables where it has been possible to calculate the result. The result can be copy-pasted from there to the Result attribute of the new intake fraction variable.

A tool can be created that collects the information about all variables used, so that it can be printed out as documentation of the intake fraction estimate. Although we previously talked about Excel as the output format, this can now be forgotten, as the functionalities and documentation can be performed within wiki (using some extensions that are under development).

What this all means

If we are able to describe a process in risk assessment (such as intake fraction estimation) as variables with explicit definitions that only contain R code (including references to other variables), we can create a wiki page system that actually calculates results of such processes given the inputs. As all parts ot the process are wiki pages, they can be edited and improved freely within the system. Editing requires some experience, but when similar processes have been performed, there is an accumulating body of examples and previous estimates.

30.8.2006 Variable classes and discussion structure

Participants: Jouni

I started to think that maybe one attribute should be added to variables: Class. The possible classes could be

  • Variable. The typical case with a physically measurable thing.
  • Function. A procedure for calculating or evaluating the value of other variables. This would require parameters that are inputs for the function so that the value could be evaluated. Function class is necessary because functions will have an obligatory attribute parameters, and they cannot have variable result.
  • Preference. The difference with a variable is that the result of a preference is measured by voting, while usually the result is measured by scientific observations or logical inference. On the other hand, also voting can be seen as a special case of scientific observation methods, and therefore
  • Argument. It is not clear, whether this should be an own class, or whether argumentation will be held on talk pages.


Then I drafted some rules for argumentation:

  • Statements can relate to any part of a variable.
  • The argumentation must be located on the Talk page of the article page where the variable is located. (If the variable is moved to another page, also the argumentation must be moved.)
  • The argumentation must be preceded by a) a subtitle with the same name as the variable and b) a sub-subtitle with a name describing the statement.
  • At the part of the variable, about which the statement is, there must be a link to the talk page: [[Talk:{{PAGENAME}}#Sub-subtitle of the statement]].
  • All arguments must be inside either {{Defend|argument}} or {{Attack|argument}} template.
  • Arguments are structured hierarchically using indent with ':'.
  • When an argumentation has come to a resolution, the outcome is described, and all other argumentation is hidden with {{Resolution|statement|outcome|argumentation}} template. The changes are made to the variable accordingly. Note! This template does not yet exist, because this version of Mediawiki does not support hierarchical templates.

25.8.2006 Refined ideas about pyrkilo object classes and their attributes

(also see below for previous version of the ideas and related links)

Participants: Jouni, Mikko

The only necessary object class is:

  • Variable

The list of attributes that are needed to describe the variable object are:

  • Name
  • Focus
  • Scope
  • Description
  • Inputs
  • Index
  • Definition
  • Unit
  • Result
  • References

Function is a special case of a variable having some certain special characteristics (in practice parameters attribute), but is in its essence similar to other variables and thus belongs (and holds its place) in the variable class.

23.8.2006 Ideas about pyrkilo object classes and their attributes

Participants: Jouni, Mikko

The necessary object classes are:

  • Variable
  • Function

The needed attributes (equal to both object classes) are:

  • Focus
  • Scope
  • Description (less formal definition)
  • Definition (numerical/mathematical definition)
  • Inputs (also Outputs, but this is not required since other attributes already define this)
  • Unit
  • Background information (prior)
  • Result
  • Index (list of independent entities)
  • References (related external literature)

What is new/special about the lists above:

  1. The attributes which values are always required are focus and scope, values for other attributes can be left unspecified if they are not relevant for the certain variable
  2. Links are not considered as an individual object class anymore, instead links are defined as attribute values of variables
  3. Function is a new individual object class which can be be called / pointed to with given parameters in the definition of a variable

Also see Glossary of environmental health#Variable attribute names and Risk assessment on ozone (AOT60) in Europe for more on these issues.


17.8.2006 An idea about combining Analytica and Wiki

Participants: Jouni

Can Analytica models be directly converted to wiki format?

  • The code can be read from the xml file automatically.
  • Variables in Ana can be transformed into Var templates
  • Modules are created as categories
  • When a node (variable) is located in a module, in wiki it means that the var template is categorized by the category defined by the module
  • Nodezise, Nodelocation, and some Analytica-specific attributes are ignored in the transformation process.
  • The wiki variable template must then contain the identical attributes: identifier, unit, title, description, definition, reference.
  • Tables are difficult to transform automatically, but this problem needs not be solved in the first phase.


10.8.2006 A suggestion for the basic question in pyrkilo method

Participants: Jouni

The basic question: What are the rules that enable an open (non-organised, non-fixed) group of rational actors to describe environmental health risks and resolve disputes that arise during the process about the content?

Examples related to climate change

At least the following groups of rules are needed:

  • Rules about participation (reading, editing, creating, and moving pages)
    • Clear: the 10 writers and the moderator may participate
  • Rules about roles of participants (moderator, participants)
    • Clear
  • Rules about structure (variables, links)
    • Structure drafted in Analytica; this is used as a strawman
  • Rules about drafting and fixing the focus and scope
    • There are two different foci:
      1. description of climate change (this is about the world)
      2. description of meta level work about applying these rules and doing the assessment
    • Scope: All material from the 10 writers. Also additional material may be added by the moderator if necessary to make implicit issues explicit.
  • Rules about acceptability of contribution (relevance, consistence etc., see below)
    • everything that is said in the material is relevant.
    • When material is conflicting (eg. Ahlbeck: CO2 does not increase global temperature), a higher-level statement is created: "There are conflicting opinions about CO2 and temperature"
  • Rules about validation (argumentation, falsification)
  • Rules about reorganising contributions (fusion, separation, budding)
    1. Make a strawman about the subject as a whole (after reading all material)
    2. Take the text from each writer and make it fit with the strawman. Reorganise the variables and links in the text as necessary. If there are variables in the text that do not yet exist in the strawman, add them there.
    3. Look at each piece of contribution and the existing strawman together. Make them fuse together either by editing the existing text in the strawman, or creating a new subvariable/link or supravariable/link as necessary, or splitting the variable into two. It is important to describe the relationship between the existing piece and the addition.
    4. After editing the variable, check for the consistence of
      1. incoming links
      2. outgoing links
      3. hierarchical relations up and down
    5. If needed, split or merge text into wiki pages as necessary
  • Rules about resolving disputes
    • Disambiguation
    • Voting for values
    • (There is no need to resolve then in this example)

19.7.2006 Trying to define the objectives of pyrkilo method

Participants: Juha, Mikko, Jouni

The overall methodology for environmental health risk assessment should promote (or even restrict) the examination to have several high-level properties. These, and the tools and method that help to achieve the objective, are described below. The method that we develop in KTL is called the PYRKILO method, and we suggest that this, or selected parts of it, are taken into the INTARESE method as well.

Evaluating the desirability of outcomes
There is a need to perform risk assessment only if some of the possible outcomes are more desirable than others. What is desirable and what is not, is a value judgement. These can be resolved using democratic methods such as voting.


Describing the situation in a rational way
The assessment must be rational and inherently consistent. Logic and directed acyclic graphs (DAGs) are the tools to promote this.


Evaluating relevance of issues
The individual pieces must be relevant for the whole assessment. This can be evaluated using argumentation theory.


Evaluating whether the issues in the assessment are probable
Low probability issues are less important for the assessment, and the tool to evaluate this is probability theory, especially Bayesian statistics, which offer some very nice tools when combined with DAGs. It should be noted, however, that 'low probability' is not a fixed number: the collision of a meteorite to the Earth may have a very low probability, but it may still be important due to its potential impact (see utility).


Evaluating the utility of actions
The utility of the outcome is a key indicator for decision-making.


Evaluating the importance of uncertainties
A value-of-information analysis is needed to estimate, whether a particular uncertainty makes it difficult to decide in a particular context.


Overall, the new pyrkilo method should have such a structure and process rules that it facilitates assessments that are in line with all of these six objectives.

  • Desirability - democracy
  • Rationality - logic, DAGs
  • Relevance - argumentation theory
  • Probability - probability theory
  • Utility - decision theory
  • Importance of uncertainties - value-of-information analysis


How does the first version of the pyrkilo tool look like?

  • It is a systematic collection of relevant and structured information.
  • It does not compute anything. All computing is done with other tools, and results are uploaded to the tool.
  • It is based on Mediawiki program.
  • It is an open-access system, but for a limited group of people. In this sense, it could look much like this Intarese Wiki site.
  • It has a prespecified structure for assessments, variables, and variable attributes.
  • It has a prespecified categorisation systems for a) variables, b) tasks and processes.
  • It has procedural rules for how to link variables to each other.

--Jouni 14:23, 19 July 2006 (EEST)

4.7.2006 thoughts after the ISSA argumentation conference

Computer aided or web-based argumentatio applications to look into:


Some names with potentially useful ideas/research on argumentation (pragma-dialectics, epistemology...):

  • Gábor Kutrovátz, Eotvos University of of Budapest
  • Ralph H. Johnson, Univeristy of Windsor
  • Dan Cohen, Colby College
  • Robert C. Rowland, University of Kansas
  • Michel Dufour, University Sorbonne Nouvelle
  • Christoph Lumer, University of Siena
  • Fabio Paglieri, University of Siena


Co-operation potential???

  • Gábor Kutrovátz, Eotvos University of of Budapest
  • Sara Rubinelli, University of Lugano
  • David M. Berube, University of South Carolina NanoCenter


Mikko 16:59, 4 July 2006 (EEST)

21.6.2006 technical issues in using Wiki

Mikko Pohjola

To make the Wiki working environment clear, useful and effective we must agree on certain kind of code of conduct and build the system in a way that it guides the users to right kinds of action in using it. In brief it is a question of:

  • effective design of the system
  • good user guidance to
    • the technical questions
    • use of the method
  • (minimal) control of the system

The first bullet, design, actually includes the second bullet, because the guidance is given in/by the system. Also the ways to minimize the need of control are in the design of the system. Since the environment is fixed in using Wiki, the design then means (a) how to make best use of the existing properties of Wiki (b) for the needs of environmental health risk assessment. Therefore the design is first methodological and second technical.

The methodology is now starting to take shape (Help:Writing pyrkilo risk assessments) in a way that it is about the time to take the technical issues into more detailed scrutiny. Open questions concerning this that require consideration in near future are at least e.g.:

  • use of categories to group the pages
    • operational environment -related
    • substantially relevant
    • managerial (project management etc.)???
  • use of templates to "standardize" the appearance
    • attribute tables
    • pre-framed pages
    • sharing content
  • control of hierarchy???
  • user guidance
    • technical
    • methodological


1.6.2006 On argumentation analysis for risk assessment

Participants: Jouni & Mikko

  • the role of argumentation analysis in risk assessment is to fill the gap between explicit modelling/calculation and unstructured discussion
    • helps e.g. in making complicated models easier to intrepret by non-experts and brings out the essentials of a discourse
  • the primary goal concerning argumentation analysis' utilization for risk assessment is to make it a common, easy-to-use, a priori method for risk assessors
  • also use of argumentation theory as an a posteriori method for reconstructing discourses afterwards can be fruitful
    • this line of use is probably necessary in explicating the usefulness of the method
  • discussion in Science about health risks/benefits of salmon shall be made an example for using argumentation analysis in risk assessment
  • in this example the assessor (as an "outsider") chooses the focus and scope of the argumentation analysis
    • if the basic standpoint of the analysis, and thus the point of view, is chosen solely based on the first article by Hites et al., it would be difficult to fit all the replies in the same picture (the disagreement space varies in settings Hites vs. Rembold, Hites vs. Tuomisto, etc...)