Model

<section begin=glossary />

• According to open assessment: A method that has its management operationalised into a software so that the method can be performed with minimal human work. A model can be automatically run by a computer after the input parameters have been entered. The output of the computation is optimally the result of a variable. A model can also refer to a freely structured object, see a definition below. D↷
• According to Intarese: A representation or description designed to show the structure or workings of an object, system or concept. In relation to the toolbox a model is a tool that is applied for calculating something, e.g. propagation model of stressors, dose-response-relationships. <section end=glossary />

Model description

Model description contains the general format for the description of models.

Summary

• How to access

Name

Scope

• Purpose
  • The method that this model relates to. (All methods are about information processing, and all models are managing a particular method.)
  • The management needs for which the model is needed (instead of just ad hoc management of the method).
• Boundaries (related to the part of reality that the model deals with)
  • Field(s) of model: Choose between Outdoor Air; Indoor Air; Water; Soil; Noise; Exposure; Multimedia; Consumer products; Drinking water; Dose-Response, PBPK; Integrated Assessment systems; Monetary Evaluation; etc.
  • Spatial coverage
  • Spatial resolution
  • Temporal coverage
  • Temporal resolution
  • Pollutants / Stressors / Agents covered
  • Health effects
  • Population data
  • Source types of emissions / sectors
  • Physical information (e.g. meteorologies)

Definition of the process

• Input (separately described for each input)
  • Data type
  • Data sources
  • Data format
  • Input stemming from other models
• Output (separately described for each output)
  • Data type (incl. if the output is point estimates or a distribution)
  • Data sources
  • Data format
  • Results
  • Output that goes into other models
  • Database type: Please choose between ORACLE; SQL; MS-ACCESS; etc
• Rationale
  • Rationale (general)
  • Weaknesses of the model
  • Comments

Procedure

• Procedure as such
• Assumptions and constraints made to facilitate the calculation
• Management of the model
  • Operating System: Please choose between WINDOWS; UNIX; LINUX; OS-MAC; VAX-VMS; etc.
  • Portability: YES (which OS) / NO
  • Software requirements
  • Please list here the software(s) that are needed to run the model (if someone) ----#(number):: . what do you mean with "if someone?" --Alexandra Kuhn 10:33, 18 June 2008 (EEST) (type: truth; paradigms: science: comment)
  • Hardware platform on which it runs
  • Time required for a typical run
  • Programming language and functions
    • Please specify which programming language and/or functions used
    • Developed by/support available from
    • Intellectual property rights (who is allowed to access or use the model?)
      • Owned by ...
      • Canned model cannot be modified / Open source / Operated under license / Other
    • Degree of mastery (who could use the model? Must he/she be trained?): In familiarization / Basic user / Expert user
    • Can modify/reprogram within platform YES / NO
    • Can transport to alternate platform YES / NO
    • Unit responsible for running and maintenance
    • Contact person

See also

References

Issues to enhance the model

The issues are:

• Sub-attribute "how to access" in "Summary" was only ONE example. so either delete it or give more examples
• "Boundaries": the problem with that is that one tends to forget some of the sub-attributes below boundaries. So they should be listed here. but depending on the purpose of the model and its part in the causal chain the sub-attributes will vary. so either listing them here and have many attributes that only apply to some models, or not listing them here but then people will forget some of them. secondly: is the list of these sub-attributes comprehensive or did we forget some?
• "input" and "output": I have made a distinction between "data" and "input stemming from other models" like in the "variables" the attributes "data" and "causality". does this make sense with the models? secondly, "type" and "format" also applies to the output and input into and from other models and not only to data. thirdly, "database type" might not only be useful for "output" but also for "input" or in general for the model. fourthly, "results" could be specified more (did I put that there???).
• "Rationale" would belong to the "procedure" not to the "definition of the process". or else, if it belongs to the "definition of the process", then also "Procedure as such" and "Assumptions and constraints made to facilitate the calculation" would belong to the rationale. they quite similar anyway. secondly, it's difficult for me to distinguish between "definition" and "procedure". could you clarify this a bit? is "procedure" then the management of the procedure?
• it's not clear to me which parts correspond to what in PSSP ontology.
• do we want to keep the "summary" part? I think, it's useful so let's keep it. but it's not important or adds any information to the other parts.

Gesendet: Dienstag, 17. Juni 2008 15:16 Dear all,

What are the issues that should be improved in the http://heande.pyrkilo.fi/heande/index.php/Model ? It seems to be pretty good to my eye (maybe some unnecessary sub-sub-attributes), so I'm not too worried about testing that with Ineris.

Jouni

On Tue, 17 Jun 2008 14:23:24 +0200 Alexandra Kuhn <alexandra.kuhn@ier.uni-stuttgart.de> wrote: > Hi all > > I just phoned Céline Boudet. She is going into maternity leave soon and will > come back only in January. But she will have s.o. who will be the link to WP > 4.2 in the meantime. > > I agreed with her that as soon as we (meaning KTL and USTUTT) have decided on > a model factsheet format INERIS can try to apply the format using their 2 > already existing model fact sheets and restructuring them. > > BR Alex