⇤--1: . Why is a model a description of the computation procedure and not the procedure as such? Or an "incarnation" or a "software"? --Alexandra Kuhn 12:12, 14 May 2008 (EEST) (type: truth; paradigms: science: attack)
- ----2: . Because the computation procedure is the doing of it (after you have taken the input to compute and before you have got the output as the result; the whole thing is a process). Or, in other words, the running of the software is a procedure, the software is a description of a procedure. But you are right, the definition is not very clear. --Jouni 22:07, 14 May 2008 (EEST) (type: truth; paradigms: science: comment)
|Fact discussion: .|
|Opening statement: Structured and unstructured models
Closing statement: Resolution not yet found.
(A closing statement, when resolved, should be updated to the main page.)
Jouni: There are formally structured models (they are methods), and then there are informally structured model (they are not OA objects). Because of this, "model" is an ambiguous word and I try to avoid it in methodology text. The same applies to "tool". I don't like their current definitions (or, I don't see a reason to develop better definitions for them).
How do you know if a model is structured or not???? I think, that there is not such thing as structured or unstructured models. I think the DESCRIPTION is structured or not. --Alexandra Kuhn 08:12, 10 June 2008 (EEST)
A model IS a description of a process for doing something. The model is not DOING, it is a description. The model can be structured if it has the attributes listed on the Model page. For many models, these are not clear. But it is worth putting work on this so that the models can be clarified and the intputs/outputs etc. clearly defined. --Jouni 16:10, 17 June 2008 (EEST)
B) Yes, all models are some kind of descriptions. For me, the critical thing is whether the description complies with the open assessment methodology or not. If yes, a model is a part of a method description. If not, a model is a non-formally structured object that may be useful in developing a structured object (i.e., a method) that we want to use. Although we sometimes play with third meta-level descriptions of descriptions of descriptions, I try to avoid it here. We should not describe models (as such), we should describe methods. A method can include (among other things) descriptions about (1) what input data you need and how to get it, and (2) what is the model you must run (including any narrative description about the model). The (1) belongs to Definition/Input, (2) belongs to Procedure. The model itself IS a part of the actual content of the Procedure attribute of the method description. For obvious reasons, the model is often not located on the wiki page about the method. --Jouni 16:09, 19 June 2008 (EEST)
About models, algorithms etc
- Everything in open assessment is about information processing.
- The whole process that produces an assessment report must be divided into smaller processes for practical reasons.
- To be able to perform right processes in a right way, the assessor needs an instruction=description for each process.
- These descriptions are called methods.
- Sometimes a method is about a very work-intensive computing process, which can fortunately be given to a computer.
- A part of a method that can be exactly described using a mathematical notation or language is called an algorithm.
- An algorithm does not (necessarily) contain enough information about the management of the process in a computer system, so it cannot be run as such.
- A part of a method that a computer can perform alone - and which is often in the form of an executable file - is called a model. Thus, the management of the process is described well enough for a computer.
- There may be several possible models that can be run as alternatives of a part of one process.
- The focus in OA is on the information process and its description (the method). A model is just a part of the method.
- This may be very confusing for a modeller who thinks of the world through the model she knows and uses. For her, other models are mainly nuisance because they rarely match technically with the input and output format that the modeller knows and in which format all her data is.
- For an open assessor, other models are disputes about the best way to perform the information process. The technical formatting issues are secondary to the purpose of the process.
- Some models are well structured: they make a coherent part of some method; and they produce as a result something that can be dierctly used as an output of the information process, e.g. a result of a variable.
- Some models are poorly structured: they are not designed as a part of a well-defined method, or they produce output that deviate from the truth due to some poorly defined assumptions.
- It is very difficult to see a difference between a well or poorly structured model unless you try to fit it into an OA structure.
- Of course, poorly structured does not mean that the model is bad. It means it is not directly applicable in OA. But it can be very good for some other purpose.
- For an open assessor, poorly structured models are material for making well-structured models, just as data is material for making variables.
- Usually people are too focussed in thinking about data and models, so they have difficulties seeing why variables and methods are superior pieces of information. But they are.