Talk:Process

Comments from Alex 4.4.2008

evaluation of the appliance of the method: the description of a model

• all in all it was a bit difficult to allocate all the content to the attributes
  • because it is a whole sytem
  • because the "modell"-structure is "ab"used (process structure taken for a model)

I wished to have a place where to put the "scope", e.g. which pollutants are considered; I only found "input" but this is not very suitable for everything. what about spatial and temporal resolution and coverage?

--#1): : The pollutants considered belong to Purpose. Now remember that you are asking a research question: "What is the best way to estimate cost-efficient measures for pollutant X in...?" and you want that the answer is: "GAINS" (or some other model). Thus, you want to formulate the question in a way that the answer IS your model (until you or someone develops a better model for that purpose). But at the same time, you want to formulate a good question for your needs. Purpose is like an employment advertisement or a call for bids: you must think what you want, but if you already have a particular person/product you want, you must formulate it wisely to fulfil both the explicit and implicit purposes. --Jouni 16:57, 3 April 2008 (EEST)

they use typical indicators for their assessments, do they belong to output?

--#2: : Yes, if you are talking about indicators that come out of the model. --Jouni 16:57, 3 April 2008 (EEST)

the "input" and "output" are like the variables: "causality" = "other models" and "data" = "databases"

then, the building of the scenario is highly interwoven with the methodology. but a scenario is something else and does not really belong to the method/model. so although i try to be very explicit and clearly to distinguish between modell (method), assessment, scenario and variable here, it does not feel easy and intuitive at all this time. so i wonder what the reasons for this are . . .

--#3: : The scenarios may be built in the Purpose, if there are fixed cost functions for predefined measures. Or, you might not want to include the scenarios in the Purpose, but then you might be attacked because your model does not cover important measures. --Jouni 16:57, 3 April 2008 (EEST)

Some more general thoughts about models, model descriptions and model fact sheets: For Intarese we (Jouni and I) said that the model fact sheets might be similar to the method templates because a model is the implementation of a process. there is some place in the process description for the management process, but I suggest to put only links to other model factsheets there (if appropriate). so, the current state is that we use this process-like template. volker and I agree that we should use some more detailed information in intarese (and i will probably do so for our inhouse models/modules). this would more or less add to the attributes, not change them. I think I might be happy with those templates then. but for this purpose to just shortly describe other model systems, i have some problems (see above). not yet sure how to solve them without making to much fuss.