pdf: 600KB - Potsdam Institute for Climate Impact Research

More documents

Recommendations

Info

36 7.3 Designing the model-representation language: ontology The word 'ontology' is used to refer to the terms used in a language (in particular, computer-based languages), the relationships between the terms, and their meaning (http://www.ontology.org). For example, a language for representing electronic circuits might include the terms resistor and passive_device, the relationship 'resistor is_a_type_of passive_device', and a definition of what a resistor is. Some aspects of an ontology may be defined formally, in a form that can be represented on a computer: for example, the list of terms and possible synonyms, and the is_a_type_of relationships. Other aspects may be defined in a prose document: for example, the precise definition of a transistor. The need to be precise in defining the terms used in a particular area of informatics is now widely recognised, and there are numerous ontology-development initiatives in many subject areas (http://www.ontology.org). This is seen as particularly important in permitting information exchange between software systems, especially over the internet, since commitment to a shared ontology enables two software systems to share information confident in the belief that they each share the same understanding about what the information means. This is crucial to the development of the Semantic Web, in which web-based programs exchange and process information without human intervention. Fig. 7.1 A partial view of Simile's ontology, in the Protegé ontology-design software
37 Figure 7.1 is a partial view of the ontology underlying Simile's model-representation language. This is presented in the form of a screen dump from Protegé, one of a number of software packages specifically developed for ontology design. It shows, on the left, the taxonomy of model-building elements: for example, it shows that compartment is a type of node. On the right, we see more information for the selected class, including its 'slots' (attributes) and some free-form text. We see that compartment has the attributes label, complete, ID, position and size. label and ID are string (character) attributes. complete (denoting whether the element has the required mathematical information associated with it) is a Boolean (true/false) attribute. position and size are defined by another class, which in turn represent the fact that each has two numeric values. Each slot is required to have a single value. We can evaluate Simile against the design criteria. Its model-representation language is very expressive: a wide range of ecological and environmental simulation models can be represented in it (Muetzelfeldt 2003). It is parsimonious, having a language based on only some 12 symbols. And it is pretty intuitive, using the widely-used System Dynamics notation plus a clear symbolism for representing objects. 7.4 Designing the model-representation language: syntax The ontology defines what we might consider to be the abstract language: the set of concepts that our language is capable of representing. In order for models to be actually represented on a computer, we require a syntax for statements in the language. This might be in binary form - written and read only by a computer program - or it could be in text form, so that it can be processed both by computers and also by humans (entered using a word processor, and printed out). A few years ago, a group of people designing a new language might very well have come up with a new syntax, without regard to the syntax of languages designed for other purposes. For example, the statement compartment: name=biomass, initial=100 might represent the fact that the model contains a compartment 'biomass' with an initial value of 100. Over the last few years, however, there has been a huge increase in the use of XML (the eXtensible Markup Language) as a metalanguage within which other languages can be expressed. Section 6.7 introduces XML notation for representing model structure, and Appendix A2 provides some more detail. I simply reiterate here that XML is the obvious metalanguage to use for representing simulation models. Not only does it give access to the technologies developed around it, but it also means that some parts of the notation exist already, such as the use of MathML [see URLs] for representing equations. There is not, however, a one-to-one correspondence between the ontology for a language and its syntax, even given a commitment to the XML metalanguage. There are still many choices to be made about representation, which will affect the readability of model description files (if that is desired), the size of the files, and the ease of processing by software tools. XML supports the concept of namespaces. In this context, this enables all the language elements that relate to a particular modelling paradigm - such as System Dynamics - to be grouped together. This means that groups developing software tools do not have to commit themselves to dealing with all concepts that the full language supports: rather, one tool might restrict itself to (for example) the System Dynamics namespace.
Page 1 and 2: 1 Position Paper on Declarative Mod
Page 3 and 4: 3 8.3 Exploiting the declarative na
Page 5 and 6: 5 15. It is argued that the efficie
Page 7 and 8: 7 another for comparing the structu
Page 9 and 10: 9 • Programs for research-grade m
Page 11 and 12: 11 3.2 Modular modelling, component
Page 13 and 14: 13 into the correct order. In some
Page 15 and 16: 15 LAMOS: Landscape Modelling Shell
Page 17 and 18: 17 5. What does 'declarative' mean?
Page 19 and 20: 19 and write a generic program whic
Page 21 and 22: 21 functions that can calculate vol
Page 23 and 24: 23 5.5 What are the benefits of gre
Page 25 and 26: 25 6.2 Mathematical description The
Page 27 and 28: 27 6.4 Representation of the model
Page 33 and 34: 33 7. Architecture for a declarativ
Page 35: 35 7.2 Designing the model-represen
Page 39 and 40: 39 context of spatial modelling). T
Page 41 and 42: 41 ensure that the various packages
Page 43 and 44: 43 and run as a stand-alone model (
Page 45 and 46: 45 Desktop temperature = graph(time
Page 47 and 48: 47 generates a procedural version o
Page 49 and 50: 49 Example 2: Generating audio desc
Page 51 and 52: 51 8.4 Conclusions The aims of this
Page 53 and 54: 53 Sector Ecosystem services Indica
Page 55 and 56: 55 The XML model documents will be
Page 57 and 58: 57 Note the difference between a de
Page 59 and 60: 59 process must be clarity and rigo
Page 61 and 62: 61 product. The other, considered i
Page 63 and 64: 63 11. Critical evaluation of the d
Page 65 and 66: 65 Restriction to scientific freedo
Page 67 and 68: 67 are, for example, initiatives to
Page 69 and 70: 69 Acknowledgements and declaration
Page 71 and 72: 71 Forrester, J.W. (1971) World Dyn
Page 73 and 74: 73 URLs: (Web links) ACSL Advanced
Page 75 and 76: 75 Glossary See "URLs: Web links" a
Page 77 and 78: 77 Appendix 1. The Modelica, MODCOM
Page 79 and 80: 79 Appendix 2. A brief introduction
Page 81 and 82: 81 bank vole Clethrionomys glareol
Page 83 and 84: 83 eats(bank_vole,seeds). eats(bank
Page 85: 85 Modelica .......................

pdf: 600KB - Potsdam Institute for Climate Impact Research

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?