Model

This page is a encyclopedia article. The page identifier is Op_en2341
Moderator:Nobody (see all) Click here to sign up.
Upload data {{#opasnet_base_link:Op_en2341}}

<section begin=glossary />

• A model is, 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↷
• A model is, 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

Any important information from the attributes that we want to summarise here.

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). Use only those boundaries listed that are relevant for your model.
  • 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 subgroups considered
  • Source types of emissions / sectors
  • Physical information (e.g. meteorologies)

Definition of the process

• Input, including measured data and data from other models (separately described for each input); including data that can be changed using an interface by the user, and data that cannot be changed by the user but forms some kind of baseline fucntionality for the model
  • Data type
  • Data sources
  • Data format
  • Database type: Please choose between ORACLE; SQL; MS-ACCESS; etc
• Output including results and intermediate data for other models (separately described for each output)
  • Data type (incl. if the output is point estimates or a distribution)
  • Data sources
  • Data format
  • Database type: Please choose between ORACLE; SQL; MS-ACCESS; etc
• Rationale: A description of why this model is a good or proper one for the particular method.
  • Rationale (general)
  • Assumptions and constraints made to facilitate the calculation
  • Weaknesses of the model, e.g. due to constraints made in the assumptions, or due to the spatial and/or temporal resolution used
  • Comments

Procedure

• Procedure as such, including the model itself and instructions for its use.
• Management of the model (can be used as a separate sub-attribute or described under "procedure as such") Describe those parts that are relevant.
  • Unit responsible for running and maintenance
  • Contact person
  • Time required for a typical run
  • Operating System: Please choose between WINDOWS; UNIX; LINUX; OS-MAC; VAX-VMS; etc.
  • Portability: YES (which OS) / NO
  • Please list here the software(s) that are needed to run the model; software requirements
  • Hardware platform on which it runs
  • Programming language and functions
  • Degree of mastery (who could use the model? Must he/she be trained?): In familiarization / Basic user / Expert user
  • Developed by/support available from (if the model can be bought or transferred and used by the user himself)
  • Can modify/reprogram within platform YES / NO
  • Can transport to alternate platform YES / NO
  • Cost for using the model (if the model is on the sever of the developer and a model run is provided as a service that you can buy)
  • 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

See also

References

Issues to enhance the model template

The issues are:

• Sub-attribute "how to access" in "Summary" was only ONE example. so either delete it or give more examples ⇤--#(number):: . Deleted. --Jouni 16:30, 19 June 2008 (EEST) (type: truth; paradigms: science: attack)
• "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? ←--#(number):: . Sub-sub-attributes are not a part of the method, so there is a lot of freedom there. Let's keep a long list, and only relevant parts are used. --Jouni 16:30, 19 June 2008 (EEST) (type: truth; paradigms: science: defence)
• "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? ⇤--#(number):: . No, it does not. Causality is a basic concept and causal information is theoretically different than non-causal data. Model results are just data. --Jouni 16:30, 19 June 2008 (EEST) (type: truth; paradigms: science: attack)
• 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? ←--#(number):: . Rationale and definition (Structure in PSSP) answer this question: How can you know what is a good model/method for this purpose? Procedure (State in PSSP) answers this question: What is the good model/method for this purpose? --Jouni 16:30, 19 June 2008 (EEST) (type: truth; paradigms: science: defence)
• 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.
  ←--#(number):: . It is useful and we should keep it. But it is not an attribute. --Jouni 16:30, 19 June 2008 (EEST) (type: truth; paradigms: science: defence)

--Alexandra Kuhn 10:49, 18 June 2008 (EEST)

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