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) (type: truth; paradigms: science: comment)

----#1):: . Sounds logical but then the purpose will get very long. so the purpose IS something like the scope? -- Alexandra Kuhn (type: truth; paradigms: science: comment)

----#(number):: . Purpose is the SAME as scope and it is the first P in PSSP ontology. We use the word scope for variables, because it is confusing to think that real-world phenomena should have a purpose (and it is not easy to remember that we are actually talking about the purpose of the description of the thing, not the thing itself). --Jouni 11:39, 4 April 2008 (EEST) (type: truth; paradigms: science: comment)

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) (type: truth; paradigms: science: comment)

----#1):: . Yes, I was talking about those. -- Alexandra Kuhn (type: truth; paradigms: science: comment)

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) (type: truth; paradigms: science: comment)

----#1):: . ??? I thought a process (of which the software model is the incarnation) should be independent of scenarios and assessments. Do the measures belong to the scenarios? -- Alexandra Kuhn (type: truth; paradigms: science: comment)

----#(number):: . The process (or a variable) IS independent of assessment, GIVEN its scope/purpose. But you can define the purpose in any way you want, as long as it describes a research question, either: "What is the ...?" or "How can you...?" That question may contain boundaries that restrict e.g. to a set of abatement strategies. The same list of strategies can be used on some assessment as scenarios. But it is just the same list, the process/model is not dependent on the assessment. --Jouni 11:39, 4 April 2008 (EEST) (type: truth; paradigms: science: comment)

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.