Model: Difference between revisions
mNo edit summary |
|||
(9 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{encyclopedia|Method}} | |||
[[Category:Glossary term]] | [[Category:Glossary term]] | ||
<section begin=glossary /> | <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. {{disclink|Structured and unstructured models}} | ||
:* | :* A '''model''' is, according to [http://www.intarese.org 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. <ref>[[:en:Model|Wikipedia]] and old working definition of SP 4.</ref><section end=glossary /> | ||
==Model description== | ==Model description== | ||
Line 11: | Line 11: | ||
'''Summary | '''Summary | ||
Any important information from the attributes that we want to summarise here. | |||
'''Name | '''Name | ||
Line 21: | Line 22: | ||
**The [[method]] that this [[model]] relates to. (All methods are about information processing, and all models are managing a particular method.) | **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). | **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) | *'''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. | ** 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 coverage | ||
Line 29: | Line 30: | ||
**Pollutants / Stressors / Agents covered | **Pollutants / Stressors / Agents covered | ||
**Health effects | **Health effects | ||
**Population | **Population subgroups considered | ||
**Source types of emissions / sectors | **Source types of emissions / sectors | ||
**Physical information (e.g. meteorologies) | **Physical information (e.g. meteorologies) | ||
Line 36: | Line 37: | ||
'''Definition of the process | '''Definition of the process | ||
*'''Input (separately described for each input) | *'''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 type | ||
** Data sources | ** Data sources | ||
** Data format | ** Data format | ||
** | **Database type: Please choose between ORACLE; SQL; MS-ACCESS; etc | ||
*'''Output (separately described for each output) | *'''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 type (incl. if the output is point estimates or a distribution) | ||
** Data sources | ** Data sources | ||
** Data format | ** Data format | ||
**Database type: Please choose between ORACLE; SQL; MS-ACCESS; etc | **Database type: Please choose between ORACLE; SQL; MS-ACCESS; etc | ||
*'''Rationale | *'''Rationale: A description of why this model is a good or proper one for the particular method. | ||
**Rationale (general) | **Rationale (general) | ||
**Weaknesses of the model | **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 | **Comments | ||
Line 56: | Line 56: | ||
'''Procedure | '''Procedure | ||
*Procedure as such | *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. | |||
*Management of the model | **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. | **Operating System: Please choose between WINDOWS; UNIX; LINUX; OS-MAC; VAX-VMS; etc. | ||
**Portability: YES (which OS) / NO | **Portability: YES (which OS) / NO | ||
**Please list here the software(s) that are needed to run the model; software requirements | |||
**Please list here the software(s) that are needed to run the model | |||
**Hardware platform on which it runs | **Hardware platform on which it runs | ||
**Programming language and functions | **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?) | |||
*** Can modify/reprogram within platform YES / NO | *** Owned by ... | ||
*** Canned model cannot be modified / Open source / Operated under license / Other | |||
** | |||
*** | |||
Line 89: | Line 87: | ||
The issues are: | The issues are: | ||
* Sub-attribute "how to access" in "Summary" was only ONE example. so either delete it or give more examples | * Sub-attribute "how to access" in "Summary" was only ONE example. so either delete it or give more examples {{attack|#(number): |Deleted.|--[[User:Jouni|Jouni]] 16:30, 19 June 2008 (EEST)}} | ||
* "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? | * "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? {{defend|#(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.|--[[User:Jouni|Jouni]] 16:30, 19 June 2008 (EEST)}} | ||
* "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???). | * "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? {{attack|#(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.|--[[User:Jouni|Jouni]] 16:30, 19 June 2008 (EEST)}} | ||
* "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? | * 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? {{defend|#(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?|--[[User:Jouni|Jouni]] 16:30, 19 June 2008 (EEST)}} | |||
* it's not clear to me which parts correspond to what in PSSP ontology. | * 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. | * 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. <br>{{defend|#(number): |It is useful and we should keep it. But it is not an attribute.|--[[User:Jouni|Jouni]] 16:30, 19 June 2008 (EEST)}} | ||
--[[User:Alexandra Kuhn|Alexandra Kuhn]] 10:49, 18 June 2008 (EEST) | |||
Gesendet: Dienstag, 17. Juni 2008 15:16 <br> | Gesendet: Dienstag, 17. Juni 2008 15:16 <br> |
Latest revision as of 12:55, 17 November 2009
This page is a encyclopedia article.
The page identifier is Op_en2341 |
---|
Moderator:Nobody (see all) Click here to sign up. |
|
Upload data
|
<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. [1]<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
- 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
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